SOLID

• S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob.
• These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend
• They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
• S - Single-responsiblity principle
• O - Open-closed principle
• L - Liskov substitution principle
• I - Interface segregation principle
• D - Dependency Inversion Principle
• Single-responsibility Principle(like Encapsulation)
• A class should have one and only one reason to change, meaning that a class should have only one job.
• SOLID Principles and Design Patterns plays a key role in achieving all of the above points.
• Each class and module should focus on a single task at a time
• Everything in the class should be related to that single purpose
• There can be many members in the class as long as they related to the single responsibility
• With SRP, classes become smaller and cleaner
• Code is less fragile
class Circle { public $radius; public function **construct($radius) { $this->radius = $radius; } } class Square { public $length; public function **construct($length) { $this->length = $length; } }
• Open-closed Principle(like Abstraction)
• Objects or entities should be open for extension, but closed for modification.
• This simply means that a class should be easily extendable without modifying the class itself. 
• Implementation
•  The simplest way to apply OCP is to implement the new functionality on new derived (sub) classes that inherit the original class implementation.
• Another way is to allow client  to access the original class with an abstract interface
• Liskov substitution principle(like Aggregation)
• Substitutability is a principle in object-oriented programming and 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
•  This principle is just an extension of the Open Close Principle 
• Interface segregation principle(avoid unused methods from interface)
• The interface-segregation principle (ISP) states that "no client should be forced to depend on methods it does not use".
• Which means, Instead of one fat interface many small interfaces are preferred based on groups of methods with each one serving one submodule 
• Dependency Inversion principle
• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on concrete. Concrete should depend on abstractions.
• Exmaple:
• The PasswordReminder class should not care what database your application uses, to fix this again we "code to an interface", since high level and low level modules should depend on abstraction, we can create an interface: