Decomposition
From CSSEMediaWiki
(Difference between revisions)
Jenny Harlow (Talk | contribs) m |
Jenny Harlow (Talk | contribs) (Added quote from Bob Martin OO(A, D, P(C++)) and ref) |
||
| Line 3: | Line 3: | ||
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 "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 | + | 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=== | ||
| Line 11: | Line 11: | ||
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. | ||
| − | An interesting book which discusses this is ''Object thinking'' {{Ref| | + | [[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: <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". | ||
| + | |||
==References== | ==References== | ||
| − | #{{Note|1}}West, David (2004). ''Object thinking''. Microsoft Press, Washington. | + | #{{Note|1}}[http://www.objectmentor.com/resources/publishedArticles.html ObjectMentor: Articles by Robert C. Martin] |
| − | #{{Note| | + | #{{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". ''Communications of the ACM'', 15(12), pp.1053-1058. | ||
Revision as of 07:22, 18 October 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.
