Decomposition
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Jenny Harlow) |
|||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Decomposition and complexity== | ==Decomposition and complexity== | ||
===The silver bullet=== | ===The silver bullet=== | ||
The problem is is complexity: the solution is decomposition. Break up a problem to deal with the complexity of size, hide the parts to deal with the problem of the number of broken-up parts, decompose into levels of abstraction to make the system more robust and flexible ... | The problem is is complexity: the solution is decomposition. Break up a problem to deal with the complexity of size, hide the parts to deal with the problem of the number of broken-up parts, decompose into levels of abstraction to make the system more robust and flexible ... | ||
===One size kills all?=== | ===One size kills all?=== | ||
| − | But how do we do decomposition in object-oriented design? It's not just about breaking things up: the [[Object-oriented design anti-patterns|object-oriented design anti-patterns]] list includes | + | But how do we do decomposition in object-oriented design? It's not just about breaking things up: the [[Object-oriented design anti-patterns|object-oriented design anti-patterns]] list includes "Functional decomposition - Classes that resemble the structure of programs created using functional languages". [[Extreme programming]] talks about responsibility-driven design; [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behaviour driven development] is another [[Agile methods|agile]] technique. Are these processes or design principles? Do they encompass what we think decomposition in object-orient design should do? |
==Decomposition in object-oriented design== | ==Decomposition in object-oriented design== | ||
===Classes and behaviour=== | ===Classes and behaviour=== | ||
| − | The [[Design maxims|design maxims]] list includes | + | The [[Design maxims|design maxims]] list includes "[[Define classes by behavior, not state pattern]]" ([[Ken Auer 1995|Ken Auer (1995)]]. Is this the fundamental OO decomposition principle? What about heuristics or maxims that seem to sometimes conflict, like [[single responsibility principle|Single responsibility principle]]/[[Separation of concerns|separation of concerns]]/[[One key abstraction|one key abstraction]] and [[Keep related data and behavior in one place|keep related data and behaviour in one place]]/[[Tell, don't ask|tell, don't ask]]? What about [[Design patterns#Behavioral Patterns|behavioural patterns ]]? |
===It's about behaviour, not data=== | ===It's about behaviour, not data=== | ||
This is a very informal statement, and it is certainly not an original way of putting it, but it seems to capture what many of the more specific rules and maxims are saying once we get above the tensions that can arise in specific situations or the details of exactly how this is implemented. | This is a very informal statement, and it is certainly not an original way of putting it, but it seems to capture what many of the more specific rules and maxims are saying once we get above the tensions that can arise in specific situations or the details of exactly how this is implemented. | ||
| − | [[Bob Martin]] discussed the difference between object-orient analysis (OOA) and object-oriented design (OOD) in an article ''OO(A, D, P(C++))'': | + | [[Bob Martin]] discussed the difference between object-orient analysis (OOA) and object-oriented design (OOD) in an article ''OO(A, D, P(C++))'':<blockquote>"In Object-Oriented Analysis, we start from the required behaviors and we reason backwards to find the abstractions that underlie those behaviors. Then we attempt to define the objects that represent those abstractions, and the messages which those objects pass between each other in order to implement the required behaviors. We do this by studying use cases and their scenarios. We examine each requirement, one by one, and develop dynamic scenarios composed of objects and messages which address those requirements." {{ref|1}} </blockquote> |
| − | An interesting book which discusses this is ''Object thinking'' {{Ref|2}}, which uses the analogy of the Taoist butcher for decomposition: | + | An interesting book which discusses this is ''Object thinking'' {{Ref|2}}, which uses the analogy of the Taoist butcher for decomposition: <blockquote>"The Taoist butcher used but a single knife, without the need to sharpen it, during his entire career for many years. When asked how he accomplished this feat, he paused, then answered, "I simply cut where the meat isn't".</blockquote>West relates this to the 'natural joints' described by David Parnas {{Ref|3}} and claims that "behaviour is the key to finding natural joints in the real world". |
| Line 27: | Line 19: | ||
#{{Note|1}}[http://www.objectmentor.com/resources/publishedArticles.html ObjectMentor: Articles by Robert C. Martin] | #{{Note|1}}[http://www.objectmentor.com/resources/publishedArticles.html ObjectMentor: Articles by Robert C. Martin] | ||
#{{Note|2}}West, David (2004). ''Object thinking''. Microsoft Press, Washington. | #{{Note|2}}West, David (2004). ''Object thinking''. Microsoft Press, Washington. | ||
| − | #{{Note|3}}Parnas, David L. (1972). On the criteria to be used in decomposing systems into modules | + | #{{Note|3}}Parnas, David L. (1972). On the criteria to be used in decomposing systems into modules". ''Communications of the ACM'', 15(12), pp.1053-1058. |
Latest revision as of 03:08, 25 November 2010
Contents |
Decomposition and complexity
The silver bullet
The problem is is complexity: the solution is decomposition. Break up a problem to deal with the complexity of size, hide the parts to deal with the problem of the number of broken-up parts, decompose into levels of abstraction to make the system more robust and flexible ...
One size kills all?
But how do we do decomposition in object-oriented design? It's not just about breaking things up: the object-oriented design anti-patterns list includes "Functional decomposition - Classes that resemble the structure of programs created using functional languages". Extreme programming talks about responsibility-driven design; Behaviour driven development is another agile technique. Are these processes or design principles? Do they encompass what we think decomposition in object-orient design should do?
Decomposition in object-oriented design
Classes and behaviour
The design maxims list includes "Define classes by behavior, not state pattern" (Ken Auer (1995). Is this the fundamental OO decomposition principle? What about heuristics or maxims that seem to sometimes conflict, like Single responsibility principle/separation of concerns/one key abstraction and keep related data and behaviour in one place/tell, don't ask? What about behavioural patterns ?
It's about behaviour, not data
This is a very informal statement, and it is certainly not an original way of putting it, but it seems to capture what many of the more specific rules and maxims are saying once we get above the tensions that can arise in specific situations or the details of exactly how this is implemented.
Bob Martin discussed the difference between object-orient analysis (OOA) and object-oriented design (OOD) in an article OO(A, D, P(C++)):"In Object-Oriented Analysis, we start from the required behaviors and we reason backwards to find the abstractions that underlie those behaviors. Then we attempt to define the objects that represent those abstractions, and the messages which those objects pass between each other in order to implement the required behaviors. We do this by studying use cases and their scenarios. We examine each requirement, one by one, and develop dynamic scenarios composed of objects and messages which address those requirements." [1]An interesting book which discusses this is Object thinking [2], which uses the analogy of the Taoist butcher for decomposition:
"The Taoist butcher used but a single knife, without the need to sharpen it, during his entire career for many years. When asked how he accomplished this feat, he paused, then answered, "I simply cut where the meat isn't".West relates this to the 'natural joints' described by David Parnas [3] and claims that "behaviour is the key to finding natural joints in the real world".
References
- ^ObjectMentor: Articles by Robert C. Martin
- ^West, David (2004). Object thinking. Microsoft Press, Washington.
- ^Parnas, David L. (1972). On the criteria to be used in decomposing systems into modules". Communications of the ACM, 15(12), pp.1053-1058.
