This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
This is the subject of much discussion. Robert Martin's "Agile Software Development" spends a lot of time on it. The basic secret is interfaces. To take one of his classic examples, say you have three classes (packages in a sec) Reader - reads bytes from disk Writer - writes bytes to disk Copier - Calls reader to read a byte, calls writer to write a byte This works fine. But one day we get a requirement to read from a stream instad of a file. Copier depends on Reader, so if we change Reader, we have to change and retest Copier. Bummer. How do we make Copier NOT depend on Reader? We give Copier ownership of an interface which Reader must implement, and we have a driver program give Copier an object that implements the interface. To give copier ownership of the interface, we package them together. Now reader has a dependency on Copier. This is good, because Copier is much more stable. Martin calls this the "Dependency Inversion Principle". We often draw architectures with "higher" layers depending on "lower" layers. Here we inverted the dependency so the lower details depend on the higher abstractions, the less stable code depends on the more stable code. Here is a bit more that I wrote on this ... see if you think it's correct! http://www.surfscranton.com/architecture/DependencyInversion.htm BTW: This is not easy! I'm writing something with about 50 classes in 6 packages. I downloaded the free JDepend from Clarkware.com, wrote a little script to extract dependencies from JDepend output into the input format for DOT from GraphViz.org to draw package dependency graphs. I haven't spotted an elegant way to get rid of my last cycle yet! [ October 27, 2003: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Dec 08, 2001
Thanks Stan, Your reply was an enlightning one. The Dependency Inversion Principle will surely help me in the long run. Thanks again, Chinmay
Joined: Jan 29, 2003
Forgot to mention, further down the forum list is one about OO, UML, etc. You can draw that gang into wonderful debates about this kind of theory and practice.