OO design principles - 12 A good OO design must be: Loose coupling Each of its components has, or makes use of, little or no knowledge of definitions of other separate components. High cohesion How strongly-related the responsibilities of a single module are. If the methods that serve the given class tend to be similar in many aspects, then the class is said to have high cohesion.
OO design principles - 23 Single Responsibility Principle Every class only has single responsibility. The responsibility is the only reason to change class. Ex: A module that compiles and print the report. Such a module can be changed for two reasons. Thus, the module should be divided into two modules, one for compiles and one for print the report. Keeps each class/module has single responsibility.
OO design principles - 34 Dependency Inversion Principle High-level modules should not depends on low level modules. Both should depends on abstraction. Abstraction should not upon on details. Details should depends upon abstraction. Applying the dependency inversion principle can also be seen as applying the Adapter Pattern. Liskov Substitution Principle If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g. correctness).
OO design principles - 45 Open-Closed Principle Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. Code obey this rule needs no efforts on code review, unit tests, and other procedure to qualify it when it do extension.
OO design principles - 56 Open-Closed Principle It can be used in two ways: (both use inheritance) Meyer’s Open/Closed Principle (OLD) Reuse class through inheritance Derived subclass might or might not have the same interface as the original class The existing implementation is closed to modifications, and new implementations need not implement the existing interface Polymorphic Open/Closed Principle (NEW, Powerful) Inheritance from abstract base class Interface specifications can be reused through inheritance but implementation need not be The existing interface is closed to modifications and new implementations must, at a minimum, implement that interface
OO design principles - 67 Interface Separate Principle Clients should not forced to implement interfaces they don’t use Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub-module Similar to high cohesion
OO design principles - 78 Law of Demeter (Principle of Least Knowledge) A specific case of loose coupling. Use only one dot. (Don’t use a.getB().method()) Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Each unit should only talk to its friends; don’t talk to strangers. Only talk to your immediate friends.
OO design principles - 89 SOLID = 5 OO Design Principles Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Separate Principle Dependency Inversion Principle Law of Demeter (Opt)