SOLID — от нуля до картошки

Все мы очень хорошо знакомы с ключевыми словами « SOLID » в наших работах и ​​вопросах интервью, поэтому действительно ли мы понимаем, что такое «SOLID», если мы хотим быть солидными, должны знать о «SOLID» в глубине.

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

1. Принцип единой ответственности (SRP) : у класса должна быть только одна причина для изменения.
2. Принцип открытости/закрытости (OCP) : класс должен быть открыт для расширения, но закрыт для модификации.
3. Принцип замещения Лискова (LSP) : подтипы должны заменять свои базовые типы.
4. Принцип разделения интерфейсов (ISP) : клиент не должен зависеть от интерфейсов, которые он не использует.
5. Принцип инверсии зависимостей (DIP) : модули высокого уровня не должны зависеть от модулей низкого уровня; оба должны зависеть от абстракций.

Принцип единой ответственности (SRP) : Допустим, у нас есть Studentкласс, который не только хранит информацию об ученике, но и выполняет различные операции, связанные с учеником, такие как вычисление его среднего балла, печать его табеля успеваемости и отправка электронных писем родителям:

class Student(val name: String, val grades: List<Double>) {
    fun calculateGPA(): Double {
        // calculate the GPA based on the grades
    }

    fun printReportCard() {
        // print the report card for the student
    }

    fun sendEmailToParents() {
        // send an email to the parents of the student
    }
}

Если вы считаете, что приведенный выше пример в порядке и какие-либо проблемы, не беспокойтесь, вы не тот, я тоже так думал раньше. В этом примере класс Studentотвечает за несколько задач, нарушая принцип единой ответственности . Это может затруднить поддержку и изменение класса с течением времени.

Чтобы придерживаться SRP, мы можем разделить обязанности класса Student, создав отдельные классы для каждой обязанности. Например, мы можем создать класс GPACalculator, который отвечает за расчет среднего балла студента, ReportCardPrinterкласс, который отвечает за печать отчета. card и EmailSenderкласс, отвечающий за отправку электронных писем родителям:

class Student(val name: String, val grades: List<Double>)

class GPACalculator(val student: Student) {
    fun calculateGPA(): Double {
        // calculate the GPA based on the grades of the student
    }
}

class ReportCardPrinter(val student: Student) {
    fun printReportCard() {
        // print the report card for the student
    }
}

class EmailSender(val student: Student) {
    fun sendEmailToParents() {
        // send an email to the parents of the student
    }
}

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

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