Stable abstractions principle
| Line 7: | Line 7: | ||
This idea is also related to the [[Dependency inversion principle]]. | This idea is also related to the [[Dependency inversion principle]]. | ||
| + | ==Quantifying Stability== | ||
| + | In {{Ref|1}}, a measure of instability (''I'') is given as "dividing efferent coupling [''Ce''] by the sum of both efferent and afferent [''Ca''] coupling". ''I'' = (''Ce'' / (''Ca'' + ''Ce'')). Here, ''I'' belongs to the set of real numbers between 0 and 1 inclusive, where 0 is completely stable. | ||
| + | |||
| + | ==References== | ||
| + | #{{Note|1}} http://www.ibm.com/developerworks/java/library/j-cq04256/ | ||
== See also == | == See also == | ||
Revision as of 09:35, 5 October 2008
"A package should be as abstract as it is stable." -- sis36.berkeley.edu
The Stable abstractions principle is closely related to the Stable dependencies principle. It states that the more stable a package is, the more abstract it should be. Any stable (unlikely to change), core concepts in an OO design should be made abstract. Unstable, real world instances (objects) of these concepts should be made concrete. Generally, concepts do not relate to objects in the real world, so it makes sense to make these abstract. Real world objects may change over time, but a concept is likely to remain essentially the same. Flexibility is provided by using abstract classes, as new, different concrete classes can be introduced, with little disruptive effect. Changing an abstract class, which many concrete classes depend on, would require those concrete classes to also be changed. Obviously this has a large cost, and should be avoided. If your abstractions are stable, this situation will not occur.
If you follow this principle, you will have abstract classes that do not change, and concrete classes that provide flexibility. Any changes to the system will only be in concrete classes, which have limited dependent classes, making those changes simpler to implement. Breaking this principle will mean that small changes in the behaviour of the system may require many changes to the code, ultimately leading to more bugs.
This idea is also related to the Dependency inversion principle.
Quantifying Stability
In [1], a measure of instability (I) is given as "dividing efferent coupling [Ce] by the sum of both efferent and afferent [Ca] coupling". I = (Ce / (Ca + Ce)). Here, I belongs to the set of real numbers between 0 and 1 inclusive, where 0 is completely stable.
