Decoupling of Object Oriented Systems A Collection of Patterns [ sd&m Home | ARCUS Home | What's New | Contact ]

Download Paper

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:

• decoupling03.ps.zip [358k] Postscript, zipped (best printed on HP LJ 4Si PS)
• decoupling03.doc.zip [451k] MS Word 7.0, zipped

And if you want to know what you will get: from the introduction

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:

• Particularly with strongly typed languages, such as C++, the compiler parses every class in the web to ensure type correctness. At best, this behavior may result in make-dependencies that cause a recompilation of the complete system after each minor bug fix. At worst, the compiler or linker runs against some internal limitation and refuses to build the program at all.
• It is difficult to isolate a group of classes for component tests. Tracking down errors will be a hard and time-consuming job - harder than in any conventional project.
• The program is hard to maintain. Changes propagate all through the system and it is difficult to determine the responsibilities of a class. Therefore classes blow up with dozens of attributes and methods.

The paper conatins a set of patterns that help you avoid the above problems

Copyright © 1996 sd&m GmbH & Co KG, arcus@sdm.de Jens Coldewey, 28.11.96

Last modified Mon Sep 8 16:04:46 1997 by Jens Coldewey