CSC/ECE 517 Fall 2007/wiki3 8 42: Difference between revisions
Jump to navigation
Jump to search
m (Reservation of the page (data to follow).) |
(The introduction) |
||
| Line 1: | Line 1: | ||
== Introduction == | |||
The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages. | |||
[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity. | |||
*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed. | |||
*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility. | |||
*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places. | |||
*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high. | |||
The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other. | |||
Revision as of 19:37, 19 November 2007
Introduction
The objective of this document is to introduce a series of design patterns developed by Robert C. Martin (Uncle Bob) that relate to packages.
Robert C. Miller defines the domain of design patterns to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.
- The RIGIDITY phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.
- The FRAGILITY phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.
- Software IMMOBILITY occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.
- VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.
The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.