View Single Post
Kickaha
Veteran Member
 
Join Date: May 2004
 
2011-06-03, 21:31

LOL I'm so sorry...

The real spiffy part (I think) is that there's an entire 'periodic table' based off of actual OO theory, such that you can describe any method call, or method call chain, (that's all this first book describes, is method calls) in a system in terms of what the relationship is between the end points. This lets someone talk about the system not in regards to the implementation details, but as a series of concepts, independent of the actual implementation structure.

And, since each method call sits within this 'periodic table', and has neighbors, any refactoring can tell you precisely what's going to happen by where your endpoint relationship will end up in the design space. And then you can propagate that up the design hierarchy and watch even very large design patterns change and shift, if the relationships are altered. If the implementation changes, but *doesn't* alter the relationship between the endpoints, then the concepts don't change, and the design remains stable.

By putting it on a formal footing, you get an amazing amount of power, but by writing them up as human-oriented design patterns, you get comprehensibility. By making them *small* concepts, you can introduce the ideas to a beginner, and get them thinking about software at higher levels of abstraction from day 1.

So you learn the concepts, and you learn how they relate to each other, and you get roadmaps for where you're likely to end up next.
  quote