SOLID 

WHAT IS SOLID? A set of principles specifically designed by the great uncle Bob to ensure that an application is maintainable, extensible, and easy to understand. 

THE PRINCIPLES ▸ Single Responsibility ▸ Open Closed ▸ Liskov Substitution ▸ Interface Segregation ▸ Dependency Inversion 

THE SINGLE RESPONSIBILITY PRINCIPLE All classes should have only 1 responsibility. No need to go hardcore purist with this though. An example of a class that still follows the single responsibility principle is an Auth class that handles things such as user login and registration. 

THE OPEN CLOSED PRINCIPLE Your code should be open to extension, but closed to modification. 

EXAMPLE OF VIOLATION function subtractDiscount($price, $months) { if ($months == 1) { $discount = 0; } else if ($months == 6) { $discount = $price * 0.15; } else if ($months == 12) { $discount = $price * 0.25; } return $price - $discount; } 

HOW TO FIX? Separate the extensible behaviour behind an interface and flip the dependencies. 

THE INTERFACE interface DiscountInterface { public function getDiscountedAmount($amount); } 

THE CLASS class AnnualDiscount implements DiscountInterface { const DISCOUNT_PERCENTAGE = 0.25; public function getDiscountedAmount($amount) { return $amount - ($amount * self::DISCOUNT_PERCENTAGE); } } 

USING IT function subtractDiscount($price, DiscountInterface $discount) { return $discount->getDiscountedAmount($price); } 

THE LISKOV SUBSTITUTION PRINCIPLE If a module is using a base class then that reference to the base class should be able to be replaced by a derived class without affecting any of the existing functionality. 

EXAMPLE OF VIOLATION: PART 1 class Rectangle { protected $width; protected $height; public function setWidth($width) { $this->width = $width; } ... } 

EXAMPLE OF VIOLATION: PART 2 class Square extends Rectangle { public function setWidth($width) { $this->width = $width; $this->height = $width; } } 

HOW TO FIX? To fix any classes that violate this principle find the base functionality present in all the classes, separate this in a new base class and use that instead. 

THE INTERFACE SEGREGATION PRINCIPLE A class should not be forced to implement methods that it does not use. Basically, your interfaces should not force additional and unnecessary methods on classes. 

HOW TO FIX This does take some planning and additional thought. You will have to separate your interfaces so that only the required methods are present. A class CAN implement multiple interfaces. 

THE DEPENDENCY INVERSION PRINCIPLE 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. 

WHY? Changes are risky. Depending on a concept is a lot safer than depending on an implementation. 

SCENARIO Logger class responsible of logging various bits of data. The original implementation was written in such a way that the logs are written to file. All of a sudden you change your mind and you want to log to a DB instead. 

HOW TO FIX? Ye olde Gateway Pattern to the rescue!!! 

CODE EXAMPLE: THE INTERFACE interface DataStoreInterface { public function log($data); } 

CODE EXAMPLE: THE CLASS class FileStore implements DataStoreInterface { public function log($data) { return $this->write($data); } private function write($data) { try { return file_put_contents('log.txt', $data, FILE_APPEND); } catch (Exception $e) { return false; } } } 

CODE EXAMPLE: THE GATEWAY class Logger { private $store; public function __construct(DateStoreInterface $store) { $this->store = $store; } public function log($data) { return $this->store->log($data); } } 

CODE EXAMPLE: USAGE $logger = new Logger(new FileStore()); $logger->log('Hello'); If we eventually implement a DB storage class: $logger = new Logger(new DBStore()); $logger->log('Hello DB');