SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)

SOLID (object-oriented design) - Wikipedia, the free encyclopedia:

In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronymintroduced by Michael Feathers for the "first five principles" identified by Robert C. Martin^[1][2] in the early 2000s^[3] that stands for five basic principles of object-oriented programmingand design. The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.^[3] The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with test-driven development, and is part of an overall strategy of agile and adaptive programming.^[3][4]

Single responsibility principle

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

The term was introduced by Robert C. Martin in an article by the same name as part of his Principles of Object Oriented Design,^[1] made popular by his book Agile Software Development, Principles, Patterns, and Practices^[2]. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification^[3].

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

The reason it is important to keep a class focused on a single concern is that it makes the class more robust. Continuing with the foregoing example, if there is a change to the report compilation process, there is greater danger that the printing code will break if it is part of the same class.

Open/closed principle

In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";^[1] that is, such an entity can allow its behaviour to be modified without altering its source code. This is especially valuable in a production environment, where changes to source code may necessitate code reviews, unit tests, and other such procedures to qualify it for use in a product: code obeying the principle doesn't change when it is extended, and therefore needs no such effort.

The name Open/Closed Principle has been used in two ways. Both ways use inheritance to resolve the apparent dilemma, but the goals, techniques, and results are different.

Liskov substitution principle

My comments: 

Behaviorial Subtyping (Allows behavior to be subtyped) 

Program to an Interface or Design by contract

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. Liskov and Jeannette Wing formulated the principle succinctly in a 1994 paper as follows:

Let  be a property provable about objects  of type . Then  should be provable for objects  of type  where  is a subtype of .

In the same paper, Liskov and Wing detailed their notion of behavioral subtyping in an extension of Hoare logic, which bears a certain resemblance with Bertrand Meyer's Design by Contract in that it considers the interaction of subtyping with pre- and postconditions.

Interface segregation principle

My comments: 

•  Break complex interfaces into fundamental simpler ones that are more cohesive. 
• Clients programmed to those interfaces will also be broken and smaller and hence the entire system is more modular, highly cohesive and further strengthens the Single Responsibility principle.
• This makes the software pieces easily plauggable (in or out) and maintained.

The interface-segregation principle (ISP) is one of the five SOLID principles of Object-Oriented Design.^[1] similar to the High Cohesion Principle of GRASP.^[2] It is a software development principle used for clean development and intends to make software easy-to-change. ISP keeps a system decoupled and thus easier to refactor, change, and redeploy. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. In a nutshell, no client should be forced to depend on methods it does not use.^[1] Such shrunken interfaces are also called role interfaces

Dependency inversion principle

My comments:

• This is similar to the inversion of control design pattern/Spring
• Spring is a glue framework that provides specific implementation (classes) with different more cohesive functionality based packages and enables your application to be divided in to similar implementations and packages along with the capability to specify the dependencies among them in a declarative fashion. It offers component equality to all the different (and cohesive) components of the application, by the virtue of which, the components lose the essence of being qualified as either High Level component or low level component. All components (services/beans) are treated equal (in terms of service-ability or providing services in an application). 

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

The principle inverts the way some people may think about object-oriented design, as both high- and low-level objects depend on the same abstraction.^[1]

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

The principle inverts the way some people may think about object-oriented design, as both high- and low-level objects depend on the same abstraction.^[1]