Stable abstractions principle
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 30: | Line 30: | ||
* [[Dependency inversion principle]] | * [[Dependency inversion principle]] | ||
* [[Encapsulate that which varies]] | * [[Encapsulate that which varies]] | ||
| + | |||
| + | [[Category:Bob Martin's principles]] | ||
Latest revision as of 03:21, 25 November 2010
Contents |
Description
"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". Note that afferent (inwards) coupling is defined as the number of components than depend on a particular component, and efferent (outwards) coupling is the number of components that a particular component depends on.
I = (Ce / (Ca + Ce)).
Here, I belongs to the set of real numbers between 0 and 1 inclusive, where 0 is completely stable. For example, a component with an efferent coupling of 0 (that is, it depends on no other components) will be completely stable, while a component that depends on a lot of other components will have a high measure of instability. This measure can be made at the physical, logical, or class boundary.
Quantifying Abstractness
In [1], a measure of abstractness (A) is given as "the ratio of abstract [Na] to concrete [Nc] classes"'.
A = Na / (Nc + Na).
Here, A belongs to the set of real numbers between 0 and 1 inclusive, where 1 is completely abstract. This measure can be applied at the physical or logical boundary.
