Перейти к основному содержимому

4.07. Основы SOLID

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Разработчику Архитектору Инженеру

Основы SOLID​

SOLID — это набор из пяти фундаментальных принципов объектно-ориентированного проектирования и программирования. Эти принципы были сформулированы Робертом Мартином (также известным как «Дядя Боб») в начале 2000-х годов и призваны помочь разработчикам создавать гибкие, поддерживаемые и расширяемые программные системы. Каждая буква в аббревиатуре SOLID обозначает отдельный принцип:

  • S — Принцип единственной ответственности (Single Responsibility Principle)
  • O — Принцип открытости/закрытости (Open/Closed Principle)
  • L — Принцип подстановки Барбары Лисков (Liskov Substitution Principle)
  • I — Принцип разделения интерфейса (Interface Segregation Principle)
  • D — Принцип инверсии зависимостей (Dependency Inversion Principle)

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

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

S — Принцип единственной ответственности​

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

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

Пример нарушения​

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

# Python (плохой пример)
class UserManager:
    def save_user(self, user_data):
        with open("users.txt", "a") as f:
            f.write(f"{user_data}\n")
    
    def send_email(self, email, message):
        # Логика отправки email
        print(f"Sending email to {email}: {message}")

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

Корректная реализация​

Разделим обязанности на два отдельных класса:

# Python (хороший пример)
class UserRepository:
    def save(self, user_data):
        with open("users.txt", "a") as f:
            f.write(f"{user_data}\n")

class EmailService:
    def send(self, email, message):
        print(f"Sending email to {email}: {message}")

class UserManager:
    def __init__(self, user_repo, email_service):
        self.user_repo = user_repo
        self.email_service = email_service
    
    def register_user(self, user_data, email):
        self.user_repo.save(user_data)
        self.email_service.send(email, "Welcome!")

Теперь каждый класс имеет чёткую зону ответственности. Изменение одного аспекта не затрагивает другие.

Аналог на Java​

// Java (плохой пример)
public class UserManager {
    public void saveUser(String userData) {
        // запись в файл
    }
    public void sendEmail(String email, String message) {
        // отправка email
    }
}
// Java (хороший пример)
public class UserRepository {
    public void save(String userData) {
        // запись в файл
    }
}

public class EmailService {
    public void send(String email, String message) {
        // отправка email
    }
}

public class UserManager {
    private UserRepository repo;
    private EmailService mailer;

    public UserManager(UserRepository repo, EmailService mailer) {
        this.repo = repo;
        this.mailer = mailer;
    }

    public void registerUser(String userData, String email) {
        repo.save(userData);
        mailer.send(email, "Welcome!");
    }
}

Аналог на C#​

// C# (хороший пример)
public class UserRepository
{
    public void Save(string userData)
    {
        File.AppendAllText("users.txt", userData + Environment.NewLine);
    }
}

public class EmailService
{
    public void Send(string email, string message)
    {
        Console.WriteLine($"Sending email to {email}: {message}");
    }
}

public class UserManager
{
    private readonly UserRepository _repo;
    private readonly EmailService _mailer;

    public UserManager(UserRepository repo, EmailService mailer)
    {
        _repo = repo;
        _mailer = mailer;
    }

    public void RegisterUser(string userData, string email)
    {
        _repo.Save(userData);
        _mailer.Send(email, "Welcome!");
    }
}

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

O — Принцип открытости/закрытости​

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

Цель этого принципа — обеспечить стабильность уже протестированного и работающего кода. Вместо того чтобы вносить правки в старые классы, разработчик создаёт новые, которые расширяют или реализуют нужное поведение через наследование или композицию.

Пример нарушения​

Рассмотрим функцию, которая рассчитывает общую стоимость заказа с учётом типа скидки:

# Python (плохой пример)
def calculate_total(items, discount_type):
    total = sum(item.price for item in items)
    if discount_type == "seasonal":
        return total * 0.9
    elif discount_type == "vip":
        return total * 0.8
    elif discount_type == "promo":
        return total * 0.85
    return total

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

Корректная реализация через полиморфизм​

Создадим абстракцию для скидок:

# Python (хороший пример)
from abc import ABC, abstractmethod

class Discount(ABC):
    @abstractmethod
    def apply(self, amount):
        pass

class SeasonalDiscount(Discount):
    def apply(self, amount):
        return amount * 0.9

class VipDiscount(Discount):
    def apply(self, amount):
        return amount * 0.8

class PromoDiscount(Discount):
    def apply(self, amount):
        return amount * 0.85

def calculate_total(items, discount: Discount):
    total = sum(item.price for item in items)
    return discount.apply(total)

Теперь для добавления новой скидки достаточно создать новый класс, реализующий интерфейс Discount. Функция calculate_total не требует изменений.

Аналог на Java​

// Java (хороший пример)
interface Discount {
    double apply(double amount);
}

class SeasonalDiscount implements Discount {
    public double apply(double amount) {
        return amount * 0.9;
    }
}

class VipDiscount implements Discount {
    public double apply(double amount) {
        return amount * 0.8;
    }
}

public class OrderCalculator {
    public double calculateTotal(List<Item> items, Discount discount) {
        double total = items.stream().mapToDouble(Item::getPrice).sum();
        return discount.apply(total);
    }
}

Аналог на C#​

// C# (хороший пример)
public interface IDiscount
{
    decimal Apply(decimal amount);
}

public class SeasonalDiscount : IDiscount
{
    public decimal Apply(decimal amount) => amount * 0.9m;
}

public class VipDiscount : IDiscount
{
    public decimal Apply(decimal amount) => amount * 0.8m;
}

public class OrderCalculator
{
    public decimal CalculateTotal(IEnumerable<Item> items, IDiscount discount)
    {
        var total = items.Sum(item => item.Price);
        return discount.Apply(total);
    }
}

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

L — Принцип подстановки Барбары Лисков​

Принцип подстановки Барбары Лисков утверждает, что объекты в программе должны быть заменяемы на экземпляры их подтипов без изменения корректности работы программы. Другими словами, если класс B является подклассом класса A, то любой объект типа A можно заменить объектом типа B, и программа продолжит работать так, как ожидалось.

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

Классический пример нарушения​

Рассмотрим геометрические фигуры. Интуитивно кажется, что квадрат — это частный случай прямоугольника, поэтому можно создать иерархию:

# Python (плохой пример)
class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.height = height

    def area(self):
        return self.width * self.height

class Square(Rectangle):
    def __init__(self, side):
        super().__init__(side, side)

    def set_width(self, width):
        self.width = width
        self.height = width  # Поддерживаем свойство квадрата

    def set_height(self, height):
        self.width = height
        self.height = height

Теперь представим функцию, которая ожидает прямоугольник:

def double_width(rect: Rectangle):
    rect.set_width(rect.width * 2)
    return rect.area()

Если передать в неё Rectangle(3, 4), результат будет 24 (ширина стала 6, высота осталась 4).
Если передать Square(3), ширина станет 6, но высота тоже станет 6, и площадь будет 36. Это нарушает ожидаемое поведение: функция предполагает, что только ширина изменится, а высота останется прежней.

Таким образом, Square не может корректно заменить Rectangle, несмотря на кажущуюся логичность наследования.

Корректный подход​

Вместо наследования лучше использовать композицию или общий интерфейс:

# Python (хороший пример)
from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self):
        pass

class Rectangle(Shape):
    def __init__(self, width, height):
        self._width = width
        self._height = height

    @property
    def width(self):
        return self._width

    @property
    def height(self):
        return self._height

    def area(self):
        return self._width * self._height

class Square(Shape):
    def __init__(self, side):
        self._side = side

    @property
    def side(self):
        return self._side

    def area(self):
        return self._side ** 2

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

Аналог на Java​

// Java (хороший пример)
interface Shape {
    double area();
}

class Rectangle implements Shape {
    private final double width;
    private final double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    public double area() {
        return width * height;
    }
}

class Square implements Shape {
    private final double side;

    public Square(double side) {
        this.side = side;
    }

    public double area() {
        return side * side;
    }
}

Здесь нет методов изменения размеров, что устраняет проблему. Если изменяемость необходима, следует проектировать интерфейсы так, чтобы подтипы не нарушали контракты.

Аналог на C#​

// C# (хороший пример)
public interface IShape
{
    double Area();
}

public class Rectangle : IShape
{
    public double Width { get; }
    public double Height { get; }

    public Rectangle(double width, double height)
    {
        Width = width;
        Height = height;
    }

    public double Area() => Width * Height;
}

public class Square : IShape
{
    public double Side { get; }

    public Square(double side)
    {
        Side = side;
    }

    public double Area() => Side * Side;
}

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

I — Принцип разделения интерфейса​

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

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

Пример нарушения​

Представим универсальный интерфейс для устройства:

# Python (плохой пример)
class IMultiFunctionDevice:
    def print(self, document):
        pass

    def scan(self, document):
        pass

    def fax(self, document):
        pass

    def copy(self, document):
        pass

Теперь реализуем простой принтер:

class SimplePrinter(IMultiFunctionDevice):
    def print(self, document):
        print(f"Printing: {document}")

    def scan(self, document):
        raise NotImplementedError("This device cannot scan")

    def fax(self, document):
        raise NotImplementedError("This device cannot fax")

    def copy(self, document):
        raise NotImplementedError("This device cannot copy")

Каждый вызов неподдерживаемого метода приведёт к ошибке. Это нарушает принцип: класс зависит от методов, которые не использует.

Корректная реализация​

Разделим интерфейс на части:

# Python (хороший пример)
class IPrinter:
    def print(self, document):
        pass

class IScanner:
    def scan(self, document):
        pass

class IFax:
    def fax(self, document):
        pass

class ICopy:
    def copy(self, document):
        pass

class SimplePrinter(IPrinter):
    def print(self, document):
        print(f"Printing: {document}")

class AllInOneDevice(IPrinter, IScanner, IFax, ICopy):
    def print(self, document):
        print(f"Printing: {document}")

    def scan(self, document):
        print(f"Scanning: {document}")

    def fax(self, document):
        print(f"Faxing: {document}")

    def copy(self, document):
        print(f"Copying: {document}")

Теперь каждый класс реализует только те интерфейсы, которые ему действительно нужны. Клиенты могут запрашивать только необходимые возможности.

Аналог на Java​

// Java (хороший пример)
interface Printer {
    void print(String document);
}

interface Scanner {
    String scan(String document);
}

interface Fax {
    void fax(String document);
}

class SimplePrinter implements Printer {
    public void print(String document) {
        System.out.println("Printing: " + document);
    }
}

class AllInOne implements Printer, Scanner, Fax {
    public void print(String document) {
        System.out.println("Printing: " + document);
    }

    public String scan(String document) {
        return "Scanned: " + document;
    }

    public void fax(String document) {
        System.out.println("Faxing: " + document);
    }
}

Аналог на C#​

// C# (хороший пример)
public interface IPrinter
{
    void Print(string document);
}

public interface IScanner
{
    string Scan(string document);
}

public interface IFax
{
    void Fax(string document);
}

public class SimplePrinter : IPrinter
{
    public void Print(string document)
    {
        Console.WriteLine($"Printing: {document}");
    }
}

public class AllInOneDevice : IPrinter, IScanner, IFax
{
    public void Print(string document) => Console.WriteLine($"Printing: {document}");
    public string Scan(string document) => $"Scanned: {document}";
    public void Fax(string document) => Console.WriteLine($"Faxing: {document}");
}

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

D — Принцип инверсии зависимостей​

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

Этот принцип лежит в основе многих современных архитектурных подходов, таких как архитектура с чистыми слоями (Clean Architecture) или гексагональная архитектура. Его цель — разорвать жёсткую связанность между компонентами системы, чтобы изменения в одной части не вызывали каскадных правок в других.

В традиционном подходе высокоуровневый компонент (например, бизнес-логика) напрямую использует низкоуровневый (например, базу данных или внешний API). Это создаёт зависимость от конкретной реализации. При замене базы данных на другую приходится переписывать бизнес-логику. Принцип инверсии зависимостей предлагает ввести абстракцию (интерфейс), через которую высокоуровневый компонент взаимодействует с низкоуровневым. Сама же реализация этой абстракции внедряется извне, часто с помощью механизма внедрения зависимостей (Dependency Injection).

Пример нарушения​

Рассмотрим сервис уведомлений, который напрямую зависит от конкретного провайдера:

# Python (плохой пример)
class EmailNotificationService:
    def send(self, message):
        # Реализация отправки через SMTP
        print(f"Sending email via SMTP: {message}")

class OrderService:
    def __init__(self):
        self.notifier = EmailNotificationService()  # Жёсткая зависимость

    def place_order(self, order):
        # Логика оформления заказа
        self.notifier.send("Order placed!")

Если потребуется добавить поддержку SMS или мессенджеров, придётся изменять OrderService. Бизнес-логика привязана к конкретной технологии доставки уведомлений.

Корректная реализация​

Введём абстракцию и передадим реализацию извне:

# Python (хороший пример)
from abc import ABC, abstractmethod

class NotificationService(ABC):
    @abstractmethod
    def send(self, message):
        pass

class EmailNotificationService(NotificationService):
    def send(self, message):
        print(f"Sending email: {message}")

class SmsNotificationService(NotificationService):
    def send(self, message):
        print(f"Sending SMS: {message}")

class OrderService:
    def __init__(self, notifier: NotificationService):
        self.notifier = notifier  # Зависимость от абстракции

    def place_order(self, order):
        # Логика оформления заказа
        self.notifier.send("Order placed!")

Теперь OrderService не знает, какой именно способ уведомления используется. Можно легко подменить реализацию без изменения самого сервиса заказов.

Аналог на Java​

// Java (хороший пример)
interface NotificationService {
    void send(String message);
}

class EmailNotificationService implements NotificationService {
    public void send(String message) {
        System.out.println("Sending email: " + message);
    }
}

class SmsNotificationService implements NotificationService {
    public void send(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

class OrderService {
    private final NotificationService notifier;

    public OrderService(NotificationService notifier) {
        this.notifier = notifier;
    }

    public void placeOrder(Order order) {
        // бизнес-логика
        notifier.send("Order placed!");
    }
}

В реальных приложениях объект OrderService создаётся с помощью контейнера внедрения зависимостей (например, Spring), который автоматически подставляет нужную реализацию.

Аналог на C#​

// C# (хороший пример)
public interface INotificationService
{
    void Send(string message);
}

public class EmailNotificationService : INotificationService
{
    public void Send(string message)
    {
        Console.WriteLine($"Sending email: {message}");
    }
}

public class SmsNotificationService : INotificationService
{
    public void Send(string message)
    {
        Console.WriteLine($"Sending SMS: {message}");
    }
}

public class OrderService
{
    private readonly INotificationService _notifier;

    public OrderService(INotificationService notifier)
    {
        _notifier = notifier;
    }

    public void PlaceOrder(Order order)
    {
        // бизнес-логика
        _notifier.Send("Order placed!");
    }
}

В .NET такие зависимости обычно регистрируются в DI-контейнере при старте приложения:

// В методе ConfigureServices или аналогичном
services.AddScoped<INotificationService, EmailNotificationService>();
// или
services.AddScoped<INotificationService, SmsNotificationService>();

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