S.O.L.I.D. is an acronym of acronyms. The principles are: - Single Responsibility Principle – SRP - Open / Closed Principle – SRP - Liskov Substitution Principle – LSP - Interface Segregation Principle – ISP - Dependency Inversion Principle – DIP There is a sixth principle that is commonly associated with the SOLID collection called: - Don’t Repeat Yourself – DRY View our “What is S.O.L.I.D in Best Practices Design Principles?” video to see a practical application. ~ SOLID Motivational Posters by Derick Bailey  

The Single Responsibility Principle – SRP states that there should never be more than one reason for a class to change. When creating Classes, a Seasoned Developer will look at the Responsibility requirements of the Class. Dependencies requirements are defined as resources supporting those Responsibilities. Many times developers will be given tasks to solve a problem that are business outcome based. These requirements generally need to be designed using an Object Oriented Programming Best Practice approach rather than a defined Business deliverable approach. View our “What is the Single Responsibility Principle?” video to see a practical application.  

The Open / Closed Principle – OCP states that Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. By using Interfaces and Abstract Classes a developer can design to the “What”, abstractions and not the “How” concretes. The attitude of a developer to protect the core code, the consuming Client Class, through the separation of the behavior of its dependencies Types is OCP. View our “What is the Open / Closed Principle??” video to see a practical application. ~ SOLID Motivational Posters by Derick Bailey  

Barbra Liskov introduced the concept of subclass substitution as a mathematical statement comparing Objects and Types and their substitutability in the 1980s. The Liskov Substitution Principle – LSP translates into today’s OOP world by stating that Base Classes must be able to use Derived classes without knowing it. The substitution should not cause runtime or compile time errors or create unexpected results. The fundamental principle in LSP is to make sure that the Abstraction, Interface or Abstract Class, truly represents the Concrete Type implementation. View our “Liskov Substitution Principle?” video to see a practical application. ~ SOLID Motivational Posters by Derick Bailey  

The Interface Segregation Principle – ISP states that Clients should not be forced to depend upon interfaces that they do not use. Applications that ignore the Single Responsibility Principle tend to create what are called “Fat Classes”. They emulate procedural programming and build to the Business Cases not to an Object oriented model. These Fat Classes are tightly coupled to their dependencies and manage sometimes dozens of responsibilities in hundreds and possible thousands of lines of code. View our “Interface Segregation Principle?” video to see a practical application. ~ SOLID Motivational Posters by Derick Bailey