C++ General: What are the principles of Object-Oriented Design?
Q: What are the OOD principles and paradigms?
A: Here is a comprehensive list of the main OOD principles with links to articles.
Open Close Principle (OCP)
Description Software entities should be open for extension, but closed for modification. B. Meyer, 1988 / quoted by Robert Martin, 1996 No significant program can be 100% closed. R. Martin, The Open-Closed Principle, 1996
Heuristics
Make all object-data private! No Global Variables!
Description Inheritance should ensure that any property proved about super-type objects also holds for subtype objects. Barbara Liskov, 1987 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. Robert Martin, 1996
Heuristics
It is illegal for a derived class, to override a base-class method with a method that does nothing.
Description When redefining a method in a derivate class, you may only replace its precondition by a weaker one, and its post condition by a stronger one. B. Meyer, 1988
Description I. High-level modules should not depend on low-level modules. Both should depend on abstractions.
II. Abstractions should not depend on details. Details should depend on abstractions. R. Martin, 1996
Description Any object receiving a message in a given method must be one of a restricted set of objects. Strict Form: Every supplier class or object to a method must be a preferred supplier. Minimization Form: Minimize the number of acquaintance classes / objects of each method. Lieberherr and Holland
Description The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused. R. Martin, 1996
Description All classes in a package [library] should be reused together. If you reuse one of the classes in the package, you reuse them all. R. Martin, Granularity 1996
Description The classes in a package should be closed against the same kinds of changes.
A change that affects a package affects all the classes in that package. R. Martin, 1996
Description The dependencies between components in a design should be in the direction of stability.
A component should only depend upon components that are more stable than it is. R. Martin, 1996
Description The abstraction of a package should be proportional to its stability! Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. R. Martin, 1996
Reply With Quote
Bookmarks