Decomposition
Jenny Harlow (Talk | contribs) |
Jenny Harlow (Talk | contribs) |
||
| 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 | + | An interesting book which discusses this is ''Object thinking'' (West, David (2004). ''Object thinking'', pp. 72-75. Microsoft Press, Washington), 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 (Parnas, David L. (1972). "On the criteria to be used in decomposing systems into modules". ''Communications of the ACM'', 15(12), pp.1053-1058) and claims that "behaviour is the key to finding natural joints in the real world". |
Revision as of 10:56, 10 August 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; 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.
An interesting book which discusses this is Object thinking (West, David (2004). Object thinking, pp. 72-75. Microsoft Press, Washington), 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 (Parnas, David L. (1972). "On the criteria to be used in decomposing systems into modules". Communications of the ACM, 15(12), pp.1053-1058) and claims that "behaviour is the key to finding natural joints in the real world".
