Stable dependencies principle
(New page: The Stable dependencies principle focus on getting the dependencies right between classes and between packages. This enables high reusability and easier maintenance of software application...) |
|||
| Line 1: | Line 1: | ||
| − | + | In general a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, other packages can reliably depend on this stable package. Therefore dependencies between packages in a design should always be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than itself. This can be expanded on classes as well. Classes should only depend on more stable classes. | |
| + | |||
| + | It is important to identify stable packages and packages that change. The packages that are expected to changes should be designed to change. Most of the times, but not always, abstract classes and interfaces are not dependent on others and tend to be more stable as in contrast to concrete or implementation classes. This is because the abstract classes or interfaces typically represent a higher abstraction of a design and not the implementation. | ||
| + | |||
| + | ==See also== | ||
| + | *[[Dependency Inversion Principle]] | ||
Revision as of 05:00, 4 October 2008
In general a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, other packages can reliably depend on this stable package. Therefore dependencies between packages in a design should always be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than itself. This can be expanded on classes as well. Classes should only depend on more stable classes.
It is important to identify stable packages and packages that change. The packages that are expected to changes should be designed to change. Most of the times, but not always, abstract classes and interfaces are not dependent on others and tend to be more stable as in contrast to concrete or implementation classes. This is because the abstract classes or interfaces typically represent a higher abstraction of a design and not the implementation.
