Принципы SOLID

07.07.2023

Введение.

Принципы SOLID являются фундаментальными принципами разработки программного обеспечения, которые помогают нам создавать гибкий, поддерживаемый и расширяемый код. Если вы только начинаете свой путь в разработке программного обеспечения, то понимание и применение этих принципов может оказаться весьма полезным для вашего профессионального роста.

Часто мы сталкиваемся с кодом, который становится трудным для понимания, изменения и расширения. Проблема заключается в том, что такой код часто нарушает принципы SOLID. Принципы SOLID дают нам набор правил, которые позволяют создавать более структурированный и модульный код.

В этой статье мы рассмотрим пять основных принципов SOLID и их применение на языке PHP, который является одним из самых популярных языков программирования для веб-разработки.

Для лучшего понимания каждого принципа SOLID мы будем использовать простые примеры на PHP. Даже если вы только начинаете изучать PHP, эти примеры помогут вам лучше усвоить идеи и принципы, которые стоят за SOLID.

Готовы узнать, как применять эти принципы в вашем коде? Давайте начнем с первого принципа SOLID – принципа единственной ответственности (Single Responsibility Principle).

Принцип единственной ответственности (Single Responsibility Principle)

Принцип единственной ответственности (Single Responsibility Principle) – это первый принцип SOLID, который гласит, что каждый класс или модуль должен иметь только одну ответственность. Это означает, что класс должен быть специализированным на выполнении конкретной задачи и отвечать только за неё. Если у класса есть более одной ответственности, это может привести к сложностям в понимании, изменении и тестировании кода.

Давайте рассмотрим пример на языке PHP, чтобы лучше понять этот принцип. Представим, у нас есть класс User, который отвечает за хранение информации о пользователе и взаимодействие с базой данных:

class User {
   private $name;
   private $email;
   private $password;
   
   public function getName() {
      return $this->name;
   }
   
   public function getEmail() {
      return $this->email;
   }
   
   public function setPassword($password) {
      $this->password = $password;
   }
   
   public function save() {
      // Логика сохранения пользователя в базу данных
   }
   
   public function sendEmail($message) {
      // Логика отправки электронной почты
   }
   
   public function authenticate($password) {
      // Логика аутентификации пользователя
   }
}

В этом примере класс User имеет несколько ответственностей – хранение информации о пользователе, взаимодействие с базой данных, отправка электронной почты и аутентификация пользователя. Такой подход делает класс громоздким и сложным для поддержки.

Чтобы следовать принципу единственной ответственности, мы можем разделить этот класс на несколько более специализированных классов. Например, класс User может отвечать только за хранение информации о пользователе, а отдельные классы могут быть созданы для работы с базой данных, отправки электронной почты и аутентификации.

class User {
   private $name;
   private $email;
   private $password;
   
   public function getName() {
      return $this->name;
   }
   
   public function getEmail() {
      return $this->email;
   }
   
   public function setPassword($password) {
      $this->password = $password;
   }
}

class UserRepository {
   public function save(User $user) {
      // Логика сохранения пользователя в базу данных
   }
}

class EmailService {
   public function sendEmail(User $user, $message) {
      // Логика отправки электронной почты
   }
}

class AuthenticationService {
   public function authenticate(User $user, $password) {
      // Логика аутентификации пользователя
   }
}

Теперь каждый класс выполняет только одну конкретную задачу, что делает код более модульным, легким для понимания и поддержки. Класс User отвечает только за хранение информации о пользователе, класс UserRepository занимается сохранением пользователей в базу данных, класс EmailService отвечает за отправку электронной почты, а класс AuthenticationService занимается аутентификацией пользователей.

Применение принципа единственной ответственности позволяет нам создавать более модульный и гибкий код. Если у нас возникают изменения или расширения в одной из ответственностей, мы можем вносить изменения только в соответствующем классе, минимизируя влияние на другие части системы.

Соблюдение принципа единственной ответственности помогает создавать чистый и понятный код, что упрощает его поддержку и сопровождение. Помните, что каждый класс должен иметь только одну ответственность и быть специализированным в выполнении своих задач.

Принцип открытости/закрытости (Open/Closed Principle)

Принцип открытости/закрытости (Open/Closed Principle) является важным принципом SOLID, который гласит, что программные сущности, такие как классы, модули или функции, должны быть открыты для расширения, но закрыты для модификации. Это означает, что мы должны строить систему таким образом, чтобы изменение поведения сущностей осуществлялось путем добавления нового кода, а не путем изменения существующего.

Давайте рассмотрим пример на языке PHP, чтобы проиллюстрировать этот принцип. Представим, у нас есть система, которая обрабатывает различные типы оплат, например, оплату через кредитную карту и оплату через PayPal:

class PaymentProcessor {
   public function processPayment($paymentType) {
      if ($paymentType === 'creditCard') {
         // Логика обработки платежа через кредитную карту
      } elseif ($paymentType === 'paypal') {
         // Логика обработки платежа через PayPal
      } else {
         // Обработка других типов оплаты
      }
   }
}

В этом примере класс PaymentProcessor имеет условные операторы, которые проверяют тип оплаты и выполняют соответствующую логику обработки платежа. Если в будущем появится новый тип оплаты, нам придется изменять этот класс, добавляя новые условные операторы. Это нарушает принцип открытости/закрытости, так как класс должен быть закрыт для изменений после его создания.

Чтобы следовать принципу открытости/закрытости, мы можем использовать паттерн проектирования “Стратегия” (Strategy). Вместо условных операторов мы создаем отдельные классы для каждого типа оплаты, которые реализуют общий интерфейс:

interface PaymentMethod {
   public function processPayment();
}

class CreditCardPayment implements PaymentMethod {
   public function processPayment() {
      // Логика обработки платежа через кредитную карту
   }
}

class PayPalPayment implements PaymentMethod {
   public function processPayment() {
      // Логика обработки платежа через PayPal
   }
}

class PaymentProcessor {
   public function processPayment(PaymentMethod $paymentMethod) {
      $paymentMethod->processPayment();
   }
}

Теперь каждый тип оплаты представлен отдельным классом, который реализует интерфейс PaymentMethod. Класс PaymentProcessor принимает объект типа PaymentMethod и вызывает метод processPayment(). Если нам нужно добавить новый тип оплаты, мы можем просто создать новый класс, реализующий интерфейс PaymentMethod, без необходимости изменения класса PaymentProcessor. Это позволяет нам расширять функциональность системы, добавляя новые типы оплаты, не внося изменения в существующий код.

Применение принципа открытости/закрытости делает код более гибким, поддерживаемым и переиспользуемым. Мы можем добавлять новую функциональность, не нарушая работу уже существующих компонентов системы. Это также способствует легкому тестированию и разработке модульного кода.

Помните, что принцип открытости/закрытости говорит о том, что классы и модули должны быть открыты для расширения новым функционалом, но закрыты для изменения существующего кода. Используйте паттерны проектирования и абстракции, чтобы достичь этой цели и создать гибкую систему, которая может легко адаптироваться к изменениям требований.

Принцип подстановки Барбары Лисков (Liskov Substitution Principle)

Принцип подстановки Барбары Лисков (Liskov Substitution Principle) – это принцип SOLID, который определяет, что объекты должны быть заменяемыми своими подтипами без изменения правильности программы. Иными словами, если у нас есть класс и его подкласс, то мы должны иметь возможность использовать подкласс вместо класса-родителя, не нарушая корректность работы программы.

Для лучшего понимания этого принципа, рассмотрим пример на языке PHP. Предположим, у нас есть класс Rectangle (прямоугольник) и его подкласс Square (квадрат):

class Rectangle {
   protected $width;
   protected $height;

   public function setWidth($width) {
      $this->width = $width;
   }

   public function setHeight($height) {
      $this->height = $height;
   }

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

class Square extends Rectangle {
   public function setWidth($width) {
      $this->width = $width;
      $this->height = $width;
   }

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

В этом примере класс Rectangle представляет прямоугольник с заданными шириной и высотой. Класс Square является подклассом Rectangle и переопределяет методы setWidth() и setHeight(), чтобы обеспечить, чтобы ширина и высота квадрата всегда были одинаковыми.

Однако, принцип подстановки Барбары Лисков нарушается в этом примере. Рассмотрим следующий код:

function printRectangleArea(Rectangle $rectangle) {
   $rectangle->setWidth(5);
   $rectangle->setHeight(4);
   echo 'Area: ' . $rectangle->getArea();
}

$rectangle = new Rectangle();
printRectangleArea($rectangle); // Output: Area: 20

$square = new Square();
printRectangleArea($square); // Output: Area: 16

Мы ожидаем, что метод printRectangleArea() будет выводить площадь прямоугольника. Однако, когда мы передаем объект Square вместо объекта Rectangle, результат неправильный. Принцип подстановки Барбары Лисков нарушается, так как подкласс Square не может полностью заменить класс Rectangle, сохраняя корректность программы.

Чтобы соблюдать принцип подстановки Барбары Лисков, мы должны пересмотреть иерархию классов и использовать композицию вместо наследования. Вместо того, чтобы делать Square подклассом Rectangle, мы можем создать отдельный класс Shape (фигура), который будет иметь метод getArea() и использовать его как базовый класс для Rectangle и Square:

interface Shape {
   public function getArea();
}

class Rectangle implements Shape {
   protected $width;
   protected $height;

   public function setWidth($width) {
      $this->width = $width;
   }

   public function setHeight($height) {
      $this->height = $height;
   }

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

class Square implements Shape {
   protected $side;

   public function setSide($side) {
      $this->side = $side;
   }

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

Теперь классы Rectangle и Square реализуют общий интерфейс Shape, который определяет метод getArea(). Метод printRectangleArea() теперь будет принимать объект типа Shape, и мы можем передать в него и объекты Rectangle, и объекты Square:

function printShapeArea(Shape $shape) {
   echo 'Area: ' . $shape->getArea();
}

$rectangle = new Rectangle();
$rectangle->setWidth(5);
$rectangle->setHeight(4);
printShapeArea($rectangle); // Output: Area: 20

$square = new Square();
$square->setSide(4);
printShapeArea($square); // Output: Area: 16

Теперь принцип подстановки Барбары Лисков соблюдается, поскольку объекты Rectangle и Square могут быть заменены объектом типа Shape без нарушения корректности программы.

Соблюдение принципа подстановки Барбары Лисков позволяет нам создавать гибкую и расширяемую систему, где объекты-подтипы могут заменять объекты-родители без изменения логики программы. Это важно для разработки поддерживаемого и расширяемого кода, где мы можем легко добавлять новые типы объектов или изменять поведение существующих, не нарушая целостность системы.

Принцип разделения интерфейса (Interface Segregation Principle)

Принцип разделения интерфейса (Interface Segregation Principle) гласит, что клиенты не должны зависеть от интерфейсов, которые они не используют. Это означает, что интерфейсы должны быть специализированными и содержать только те методы, которые необходимы клиентам. Это позволяет избежать накладных расходов и избыточности взаимодействия клиентов с интерфейсами.

Для лучшего понимания этого принципа, рассмотрим пример на языке PHP. Предположим, у нас есть интерфейс User (пользователь), который определяет методы для работы с пользователем:

interface User {
   public function setName($name);
   public function setEmail($email);
   public function setPassword($password);
   public function save();
   public function sendEmail($message);
}

В этом примере интерфейс User определяет методы для установки имени, электронной почты, пароля, сохранения пользователя и отправки электронной почты. Однако, не все клиенты, которые работают с пользователем, могут использовать все эти методы. Например, некоторым клиентам могут понадобиться только методы для установки имени и электронной почты.

Следуя принципу разделения интерфейса, мы можем разделить этот интерфейс на несколько более специализированных интерфейсов:

interface Nameable {
   public function setName($name);
}

interface Emailable {
   public function setEmail($email);
}

interface User {
   public function setPassword($password);
   public function save();
   public function sendEmail($message);
}

Теперь мы создали интерфейсы Nameable (с возможностью установки имени) и Emailable (с возможностью установки электронной почты). Клиенты могут реализовывать только те интерфейсы, которые им необходимы:

class BasicUser implements Nameable, Emailable {
   public function setName($name) {
      // Логика установки имени
   }
   
   public function setEmail($email) {
      // Логика установки электронной почты
   }
}

class AdminUser implements Nameable, Emailable, User {
   public function setName($name) {
      // Логика установки имени
   }
   
   public function setEmail($email) {
      // Логика установки электронной почты
   }
   
   public function setPassword($password) {
      // Логика установки пароля
   }
   
   public function save() {
      // Логика сохранения пользователя
   }
   
   public function sendEmail($message) {
      // Логика отправки электронной почты
   }
}

Теперь классы BasicUser и AdminUser могут реализовывать только те интерфейсы, которые им необходимы. BasicUser реализует интерфейсы Nameable и Emailable, тогда как AdminUser реализует эти интерфейсы плюс интерфейс User. Это позволяет клиентам использовать только те методы, которые им действительно нужны, избегая избыточности и накладных расходов.

Соблюдение принципа разделения интерфейса помогает создавать гибкие и модульные системы, где клиенты зависят только от необходимых им интерфейсов. Это позволяет упростить разработку и поддержку кода, улучшить его переиспользуемость и уменьшить влияние изменений на другие части системы.

Принцип инверсии зависимостей (Dependency Inversion Principle)

Принцип инверсии зависимостей (Dependency Inversion Principle) является одним из ключевых принципов SOLID и гласит, что высокоуровневые модули не должны зависеть от низкоуровневых модулей. Вместо этого оба типа модулей должны зависеть от абстракций. Это помогает достичь слабой связанности между компонентами системы и повышает их гибкость и переиспользуемость.

Для лучшего понимания этого принципа, рассмотрим пример на языке PHP. Предположим, у нас есть класс UserController, который отвечает за управление пользователями и использует объект UserRepository для доступа к данным пользователей:

class UserController {
   private $userRepository;
   
   public function __construct() {
      $this->userRepository = new UserRepository();
   }
   
   public function createUser($userData) {
      // Логика создания нового пользователя
      $this->userRepository->save($userData);
   }
}

В этом примере класс UserController явно зависит от класса UserRepository. Это нарушает принцип инверсии зависимостей, так как высокоуровневый модуль (UserController) зависит от низкоуровневого модуля (UserRepository), и изменения в UserRepository могут повлиять на UserController.

Чтобы соблюдать принцип инверсии зависимостей, мы можем внедрить зависимость через интерфейс. Вместо создания объекта UserRepository внутри класса UserController, мы передадим его через конструктор или метод:

interface UserRepository {
   public function save($userData);
}

class UserController {
   private $userRepository;
   
   public function __construct(UserRepository $userRepository) {
      $this->userRepository = $userRepository;
   }
   
   public function createUser($userData) {
      // Логика создания нового пользователя
      $this->userRepository->save($userData);
   }
}

Теперь UserController зависит от абстракции (UserRepository), а не от конкретной реализации. Это позволяет нам легко заменить UserRepository другой реализацией, не внося изменений в UserController.

class DatabaseUserRepository implements UserRepository {
   public function save($userData) {
      // Логика сохранения пользователя в базе данных
   }
}

class FileUserRepository implements UserRepository {
   public function save($userData) {
      // Логика сохранения пользователя в файловой системе
   }
}

Теперь мы можем использовать разные реализации UserRepository, передавая их в UserController:

$userRepository = new DatabaseUserRepository();
$userController = new UserController($userRepository);
$userController->createUser($userData);

Принцип инверсии зависимостей помогает создавать слабосвязанные компоненты системы и делает их более гибкими и переиспользуемыми. Зависимости внедряются через абстракции, что позволяет нам легко заменять реализации и вносить изменения, минимизируя влияние на остальные компоненты системы. Это способствует созданию расширяемого и легко тестируемого кода.

Заключение

В этом заключительном разделе мы резюмируем основные принципы SOLID и их значение для разработчиков программного обеспечения. SOLID – это набор принципов, которые помогают нам создавать гибкий, поддерживаемый и расширяемый код. Давайте кратко вспомним каждый из принципов:

Принцип единственной ответственности (Single Responsibility Principle) – класс или модуль должен иметь только одну ответственность. Это позволяет нам создавать более структурированный и модульный код.
Принцип открытости/закрытости (Open/Closed Principle) – классы и модули должны быть открыты для расширения новым функционалом, но закрыты для изменения существующего кода. Это позволяет нам легко добавлять новую функциональность, минимизируя влияние на существующий код.
Принцип подстановки Барбары Лисков (Liskov Substitution Principle) – объекты должны быть заменяемыми своими подтипами без изменения правильности программы. Это помогает нам создавать гибкие и переиспользуемые системы.
Принцип разделения интерфейса (Interface Segregation Principle) – клиенты не должны зависеть от интерфейсов, которые они не используют. Интерфейсы должны быть специализированными и содержать только необходимые методы.
Принцип инверсии зависимостей (Dependency Inversion Principle) – высокоуровневые модули не должны зависеть от низкоуровневых модулей. Зависимости должны внедряться через абстракции, что позволяет легко заменять реализации и улучшать гибкость системы.

При соблюдении этих принципов SOLID мы создаем код, который легко поддерживать, расширять и тестировать. Мы достигаем слабой связанности между компонентами системы, что позволяет нам создавать гибкие и модульные приложения. Эти принципы являются основой разработки высококачественного программного обеспечения и являются важным инструментом для профессионального роста в области разработки.

Теги:php, solid, ооп

Автор

ZxKill

Web Developer/Techlead, 35 years. Channel author https://t.me/SamuraisGoal

ZxKill.ru

Принципы SOLID

Введение.

Принцип единственной ответственности (Single Responsibility Principle)

Принцип открытости/закрытости (Open/Closed Principle)

Принцип подстановки Барбары Лисков (Liskov Substitution Principle)

Принцип разделения интерфейса (Interface Segregation Principle)

Принцип инверсии зависимостей (Dependency Inversion Principle)

Заключение

Автор

ZxKill

Оставить комментарий

Введение.

Принцип единственной ответственности (Single Responsibility Principle)

Принцип открытости/закрытости (Open/Closed Principle)

Принцип подстановки Барбары Лисков (Liskov Substitution Principle)

Принцип разделения интерфейса (Interface Segregation Principle)

Принцип инверсии зависимостей (Dependency Inversion Principle)

Заключение

Похожие

Автор

ZxKill

Оставить комментарий