Software design principles represent a set of guidelines that helps us to avoid having a bad design.
The open –closed principle:
A module should be open for extension but closed for modification, can be extended, without requiring them to be modified. => able to change to module without changing source code, 2 ways:
a. Meyer’s Open/Closed Principle: the first principle, implementation of a class could only be modified to correct errors; new or changed features would require that a different class be created
b. Polymorphic Open/Closed Principle: the implementations can be changed and multiple implementations could be created and polymorphically substituted for each other.
The Liskov Substitution Principle
Subclasses should be substitutable for their base classes. Derived classes should be substitutable for their base classes. That is, a user of a base class should continue to function properly if a derivative of that base class is passed to it.
Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions, Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.
The Interface Segregation Principle:
Many client specific interfaces are better than one general purpose interface. The essence of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.
Release Reuse Equivalency Principle
The unit of reuse is the unit of release. Effective reuse requires tracking of releases from a change control system. The package is the effective unit of reuse and release.
Common Reuse Principle
Classes that aren’t reused together should not be grouped together.
Stable Dependencies Principle
depend on the direction of stability
Information hiding and encapsulation
Information hiding is the principle of segregation of design decisions
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements, Clear boundaries between tiers, program against interfaces, not classes.
High Cohesion attempts to keep objects appropriately focused, manageable and understandable. High Cohesion is generally used in support of Low Coupling, High cohesion means that the responsibilities of a given element are strongly related and highly focused.
The Acyclic Dependencies Principle
The dependencies between packages must not form cycles.