The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.
The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference. [See previous tip about LSP]
The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.
The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface/ Package Design Principles
The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
The Common Closure Principle: Classes that change together, belong together.
The Common Reuse Principle: CClasses that aren't reused together should not be grouped together.
The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.
How relevant are these principles today ? Or, like many a rule, are they meant to be broken . For instance , in the Stable Dependencies principle, the dependee must be more stable than the depender. Functional decomposition has dependencies down the hierarchy but must one ensure that the calling function is more stable than the called function ? Oh, and how ? regards
I'm for em! BTW: Just opening the back cover of Martin's Agile Software Development, you missed his #1: Single Responsibility Priniciple. They are all good things to think about when designing or reviewing a design. There was another thread with some pretty solid arguments against the package rules. I'd try to follow these myself, but stay open to the alternatives. I also like the XP values - I may have em out of order: * Passes all tests and gives correct results * No duplication * Code expresses its intention * Fewest classes and methods to do the above Caveats: Like all rules, they can be broken. XP folk say explicitly they will sometimes conflict one another and you have to choose which fits the situation the best. Some of the metrics suggested to measure them are suspect - a package could be perfectly stable with no interfaces and no abstract classes. I'm very interested in motivation for change. In my current project when we add a new group of users, certain things change. When we add a new product other things change. Can I reduce the number of classes that change for each event? Can I eliminate overlap between product changes and group changes?
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
Originally posted by HS Thomas: For instance , in the Stable Dependencies principle, the dependee must be more stable than the depender. Functional decomposition has dependencies down the hierarchy but must one ensure that the calling function is more stable than the called function ? Oh, and how ?
Isn't it the other way around though? That is, the called function (the dependee) should be more stable than the calling function (the depender).
Enjoy the full beauty of the english language. Embedded in this tiny ad: