Win a copy of Spark in Action this week in the Open Source Projects forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Righting Software: I didn't know my software was func'd up

 
Greenhorn
Posts: 13
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not a novice developer by any means, and when I take over other projects because they are difficult to maintain and I'm the only guy to attempt fixing them, I have always known there were something wrong with the design, but I just could not put my finger on it.  I surely could not explain it in terms other than 'a gut feeling'.  

You idea of Volatile areas as compared to Variable might be the answer, but I'm still don't quite understand the difference.  For me, Volatile also means changes. So, if I have a system that performs a function (don't cringe - it seems functional), I see some like reading different data format for input as the Volatile or Variable part of the design.  So, we always put that behind an interface.  If we did not put it behind an interface, then every time we had a new input format that needs conversion, it would have a ripple effect in the data input part of the system.  In terms of your book, maybe my example is not correct.

Could explain the difference between Volatility and Variable a little more?
 
Author
Posts: 12
10
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, let's start small – what is the purpose of using properties? To encapsulate the potential change in the business logic or requirements of a piece of data.
Otherwise, when the logic would change, all those that touched the data would have to change.
So the lesson is that when something changes, you better encapsulate it, or you would create dangerous level of coupling. You want to be decoupled from the data.
Does it mean that there is no conditional logic in the rest of the software?

The same is true with architecture. You want to decouple from the possible changes in the requirements, and the only way to do that is to encapsulate the changes in the requirements.
I call that volatility. If you were to use functional decomposition, then when the required functionality changes, your design will have to change, which is exactly the opposite of what I propose.
You must not have a change in the requirements invalidate the architecture.
Does it mean that there is no conditional logic in the rest of the software? Of course not. You still must use if-else, switch, etc. to handle variability in the state or data, but that is not volatility in the requirements.

Juval.
 
Timothy Gallagher
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK - I think I'm getting it.  Thanks for the explanation.  I look forward to reading the book.
 
What are you saying? I thought you said that Santa gave you that. And this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic