Decoupling of Object Oriented
Note: There's an updated version at coldewey.com. We would recommend to download this version
... but we still provide "ye olde project versions :-)"
We have prepared several formats to download:
When an organization starts to use object-orientation, you often find designs like the one depicted below. The team designed the logical class model correctly and then started to implement these classes without a physical class design. The result is a strongly interwoven net of dependencies, that may cause severe troubles during compilation and testing. Because nearly every class depends on every other, any minor change will start a complete recompile of the system. Separate testing of classes is not possible. It is hard to reuse classes from this design in other projects, because you will not be able to cut them out of this dependency network, without rewriting most of it's code. The design shows a phenomenon, Bruce Webster calls Hyperspaghetti Objects and Subsystems
The project team has fallen into a standard pitfall of object-oriented design. "The goal of [object-oriented design] is to manage dependencies within a program. It achieves this goal by dividing the program into chunks of manageable size, and the hiding those chunks behind interfaces..." (Robert Martin). Using functional analysis, we had average functions of three-hundred lines of code that did a certain job. Object-oriented design encourages you to break the code down into very small methods. Typical Smalltalk programs have an average method length of 1.5 lines. The gain is high reusability but you pay with lot more interaction between methods. These interactions couple classes. If you do not manage this coupling, you will get into severe trouble.
Tight coupling has several dangerous consequences:
The paper conatins a set of patterns that help you avoid the above problems
|Copyright © 1996
sd&m GmbH & Co
Jens Coldewey, 28.11.96
modified Mon Sep 8 16:04:46 1997
by Jens Coldewey