Dependency Inversion And Xp

(DIP) The DependencyInversionPrinciple [which see].

One of the PrinciplesOfObjectOrientedDesign.

A fundamental principle of object oriented design that states concrete classes should not be directly depended upon. That rather, the bulk of the code in the system should depend only upon the interfaces that those concrete classes implement.

See http://www.objectmentor.com/publications/dip.pdf and the other papers in the publications section of http://www.objectmentor.com

-- RobertCecilMartin - 9/7/99

Note, this was early in his ExtremeProgramming days. Since then, he has refined his position to include RefactorMercilessly, where "invert" is a transitive verb.

He always defines OO decoupling as equivalent to the DependencyInversionPrinciple over PolymorphicInterface?s, continuously through 2008.

Under ExtremeProgramming, if you do indeed plan to invert, you can write tests and perform refactors that lead simple code to the inversion. And if you don't plan to invert, but discover you then need an inversion, you will have the UnitTests, PairProgramming, and ContinuousIntegration available to assist the inversion.

And some RefactoringBrowsers will help automate it, with commands like ExtractInterfaceClass?.

XP allows you to avoid the high risk of thinking of too many abstractions ahead of time. Architecture evolves, via EmergentDesign, leaving room for just the right mix of patterns, architecture and principles.

Suggested reading:

• AgileSoftwareDevelopmentPrinciplesPatternsAndPractices - for the synthesis of OO design principles and Agile process
• WorkingEffectivelyWithLegacyCode - for some ideas on splitting those million line applications written without the benefit of Agile testing or refactoring. What he calls seams become assembly points where you create a number of classes and wire them together. Use of the DependencyInversionPrinciple will be quite prominent at these points. At the seams you'll probably wish that CeePlusPlus had a standard facility for loading classes dynamically so you don't have to keep changing the resulting factory classes. XPCOM is the most portable solution I know of for C++, check the BoostLibraries though (I haven't been there in a couple years). I'd also suggest thinking about Martin Fowler's StranglerFig? pattern. It probably won't seem obvious how to strangle your application at first.

---

CategoryModelingLawsAndPrinciples CategoryExtremeProgramming