Single Responsibility Principle

The Single Responsibility Principle (SRP) asserts that every code entity should be responsible for a single function. Entities can include functions, classes, packages, or modules. SRP is rooted in the concept of separation of concerns.

Responsibility is defined as a reason to change, and each entity should ideally have only one reason to change. While implementing SRP can sometimes complicate the codebase due to the need for low coupling, it ultimately results in a more flexible and maintainable code structure.

Open/Closed Principle

The Open/Closed Principle posits that software entities should be open for extension but closed for modification. While modifications are often necessary for software evolution, they can compromise the stability of the codebase. Therefore, entities should avoid direct modifications; instead, evolution should occur through extensions.

As classes are compiled and stored in libraries, they should resist modifications to prevent errors during code restructuring and recompilation. Extensions can be achieved through inheritance or composition.

Utilizing interfaces is advisable for adhering to this principle, as they naturally resist modification while permitting high degrees of extension and promoting low coupling. Existing classes can be inherited with new functionality without requiring recompilation or alteration of the original classes.

Liskov Substitution Principle

Introduced by Barbara Liskov in 1987, the Liskov Substitution Principle asserts that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This principle hinges on behavioral sub-typing.

Achieving proper substitution is challenging, and the following six rules guide valid LSP implementation:

• Pre-condition Rule: A subtype must not impose more restrictive conditions than its supertype.
• Post-condition Rule: A subtype must not have less restrictive conditions than its supertype.
• Covariance of Return Types: Return types of the supertype should be more general than those of the subtype.
• Contravariance of Method Arguments: Method arguments in the subtype should be more general than those in the supertype.
• Invariance: The same type should be consistently used where applicable.
• No Exceptions Allowed: New exceptions must not be introduced in the subtype that are absent in the supertype.

Interface Segregation Principle

The Interface Segregation Principle advocates that no client should be forced to rely on interfaces that are unnecessary for their purpose. It suggests breaking down composite interfaces into smaller, context-specific interfaces so that a class only implements the interfaces it requires.

In my experience, this principle is often overlooked, not out of negligence, but due to enhancement requests from clients or stakeholders that were not considered during the initial design. Adhering to this principle fosters the development of robust and maintainable applications.

Dependency Inversion Principle

Complex modules, like business logic handlers, can be adversely affected by updates in lower-level modules, such as utility classes. This can pose challenges for developers, especially when frequent changes are needed.

The Dependency Inversion Principle addresses this by ensuring that high-level and low-level modules do not directly depend on one another. According to renowned author Robert Martin, the principle is founded on two key tenets:

• High-level modules should not depend on low-level modules; both should depend on abstractions.
• Abstractions should not depend on details; details should depend on abstractions.

This can be accomplished through effective use of interfaces, allowing high-level and low-level components to evolve independently without disrupting the application.

Adopting this principle significantly reduces coupling between modules, enhancing flexibility such that updates at one level can occur without impacting others.

Reuse Release Equivalence Principle (REP)

The Reuse Release Equivalence Principle (REP) posits that any component designed for reuse should also be designed for release. If components are reused by creating multiple copies, there is a risk of divergence over time as all copies share the responsibility for updates.

Designing a component for release mitigates the issue of asymmetrical copies, ensuring that the source code of a functionality exists in one location. For instance, creating a module with an effective caching algorithm and reusing it through imports exemplifies this principle.

Common Reuse Component Principle (CRP)

The Common Reuse Component Principle (CRP) asserts that if any class within a component is reused, all classes within that component should also be reused either directly or indirectly. Highly cohesive components naturally support this principle.

Common Closure Principle (CCP)

The Common Closure Principle (CCP) states that if a change affects a component, it should impact all classes within that component and no others. This prevents components from becoming inconsistent, where some classes are outdated while others evolve.

Stable Abstraction Principle (SAP)

Abstraction, a key tenet of many software patterns, entails concealing sensitive information while revealing only the necessary details. Robust abstraction provides access protection, dependency inversion, standardization, and variation protection. It also enhances stability by ensuring that code depends on abstracted concepts rather than concrete data.

The Stable Abstraction Principle (SAP) asserts that the stability of a package or component is directly proportional to its degree of abstraction. A more stable package should be better protected from the side effects of extensions, achievable through effective abstraction.

Stable Dependency Principle (SDP)

The Stable Dependency Principle (SDP) states that dependencies should always be directed towards higher stability. Simply put, a component should depend on another that is equally or more stable than itself.

By adhering to the Stable Dependency Principle, we ensure that modules designed for easy modification are not dependent on modules that are more complex to change.