Stable abstractions principle
Joey Scarr (Talk | contribs) |
|||
| Line 1: | Line 1: | ||
| + | ---- | ||
| + | <div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;"> | ||
| + | ---- | ||
| + | =[http://ybyfonojot.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]= | ||
| + | ---- | ||
| + | =[http://ybyfonojot.co.cc CLICK HERE]= | ||
| + | ---- | ||
| + | </div> | ||
==Description== | ==Description== | ||
| − | + | "A package should be as abstract as it is stable." -- [http://sis36.berkeley.edu/projects/streek/agile/oo-design-principles.html 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. | 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. | ||
| Line 9: | Line 17: | ||
==Quantifying Stability== | ==Quantifying Stability== | ||
| − | In {{Ref|1}}, a measure of instability ( | + | In {{Ref|1}}, a measure of instability (<tt>''I''</tt>) 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'')). | ''I'' = (''Ce'' / (''Ca'' + ''Ce'')). | ||
| − | Here, | + | Here, <tt>''I''</tt> 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== | ==Quantifying Abstractness== | ||
| − | In {{Ref|1}}, a measure of abstractness (''A'') is given as | + | In {{Ref|1}}, a measure of abstractness (''A'') is given as "the ratio of abstract [''Na''] to concrete [''Nc''] classes"'. |
''A'' = ''Na'' / (''Nc'' + ''Na''). | ''A'' = ''Na'' / (''Nc'' + ''Na''). | ||
Revision as of 05:21, 24 November 2010
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 (<tt>I</tt>) 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, <tt>I</tt> 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.
