SOLID principles examples using PHP

Here are some examples of how the SOLID principles can be applied in PHP:

1. Single Responsibility Principle:

For example, consider a class that is responsible for sending email notifications to users. The class might look like this:

class EmailNotification {
  public function send($to, $subject, $body) {
    // code to send email
  }
}

This class has a single responsibility: sending email notifications. It is focused on a specific task and does not take on any other responsibilities.

2. Open-Closed Principle:

For example, consider a class that is responsible for validating user input. The class might look like this:

class InputValidator {
  public function validate($input) {
    // code to validate input
  }
}

This class has a single responsibility: validating input. To follow the Open-Closed Principle, the class should be designed in a way that allows it to be extended to add new types of validation without requiring changes to its existing code. For example, the class might include a set of validation rules that can be added or removed as needed:

class InputValidator {
  private $rules = [];

  public function addRule($rule) {
    $this->rules[] = $rule;
  }

  public function validate($input) {
    foreach ($this->rules as $rule) {
      if (!$rule->validate($input)) {
        return false;
      }
    }
    return true;
  }
}

In this example, the InputValidator class is open for extension (through the addRule method) but closed for modification (the validate method does.

3. Liskov Substitution Principle:

For example, consider a class hierarchy for representing shapes. The Shape class might define an abstract method for calculating the area of a shape:

abstract class Shape {
  abstract public function getArea();
}

Subclasses of Shape, such as Circle and Rectangle, can then implement this method to calculate the area for their respective shapes:

class Circle extends Shape {
  private $radius;

  public function __construct($radius) {
    $this->radius = $radius;
  }

  public function getArea() {
    return pi() * pow($this->radius, 2);
  }
}

class Rectangle extends Shape {
  private $width;
  private $height;

  public function __construct($width, $height) {
    $this->width = $width;
    $this->height = $height;
  }

  public function getArea() {
    return $this->width * $this->height;
  }
}

To follow the Liskov Substitution Principle, objects of the Shape class should be able to be replaced with objects of any of its subclasses without affecting the correctness of the program. For example, the following code should work correctly:

$shapes = [new Circle(1), new Rectangle(2, 3)];

foreach ($shapes as $shape) {
  echo $shape->getArea() . "\n";
}

4. Interface Segregation Principle:

For example, consider an interface for a logger that has methods for logging different types of messages:

interface Logger {
  public function logError($message);
  public function logWarning($message);
  public function logInfo($message);
  public function logDebug($message);
}

To follow the Interface Segregation Principle, it is important to ensure that clients are not required to depend on methods that they do not use. For example, if a client only needs to log errors and warnings, it should not be required to implement the logInfo and logDebug methods:

class ErrorWarningLogger implements Logger {
  public function logError($message) {
    // code to log error
  }

  public function logWarning($message) {
    // code to log warning
  }
}

5. Dependency Inversion Principle:

For example, consider a class that is responsible for generating reports. The class might depend on a data source to retrieve the data for the report:

class ReportGenerator {
  private $dataSource;

  public function __construct(DataSource $dataSource) {
    $this->dataSource = $dataSource;
  }

  public function generate() {
    $data = $this->dataSource->getData();
    // code to generate report using $data
  }
}

To follow the Dependency Inversion Principle, the ReportGenerator class should depend on an abstraction (in this case, the DataSource interface) rather than a concrete implementation (such as a specific implementation of DataSource). This helps to decouple the ReportGenerator class from the specific details