Program to the interface not the implementation
From CSSEMediaWiki
(Difference between revisions)
(→See also) |
JaninaVoigt (Talk | contribs) m |
||
| (One intermediate revision by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | This idea says that objects should depend on the abstractions of a class instead of | + | This idea says that objects should depend on the abstractions of a class instead of its concrete implementations. This reduces coupling from implementations, and increases flexibility. It means that clients are unaware of the specific types of objects they use, it only matters that the objects adhere to the abstract interface. If you wish to add another concrete subclass to the abstract class, the rest of the code will not be affected. The client can be given any implementation of the abstract class that it depends on and be able to use it. |
This is closely related to the [[Dependency inversion principle]]. | This is closely related to the [[Dependency inversion principle]]. | ||
| Line 5: | Line 5: | ||
== See also == | == See also == | ||
* [[Dependency inversion principle]] | * [[Dependency inversion principle]] | ||
| − | * [[ | + | * [[Liskov substitution principle]] |
* [[Design by contract]] | * [[Design by contract]] | ||
Latest revision as of 05:34, 14 October 2009
This idea says that objects should depend on the abstractions of a class instead of its concrete implementations. This reduces coupling from implementations, and increases flexibility. It means that clients are unaware of the specific types of objects they use, it only matters that the objects adhere to the abstract interface. If you wish to add another concrete subclass to the abstract class, the rest of the code will not be affected. The client can be given any implementation of the abstract class that it depends on and be able to use it.
This is closely related to the Dependency inversion principle.
