Есть 5 принципов SOLID, которые были введены Робертом Мартином по имени Майкл Фезерс. Я думаю, что эти пять принципов выделяются, когда код поддерживается кем-то, кроме исходного разработчика. В такое время читатель должен уделять больше времени написанию кода, а не разработчик. Это плохое качество разработчика. Кроме того, когда мы работаем над стартапом, для лучшего будущего лучше, если мы будем следовать этим шагам. Кстати, это не очень существенное понятие, но лучше, если мы будем следовать этим 5 принципам. Если мы выполняем групповой проект, это поможет команде завершить проект с меньшими затратами времени, сделает код удобным для сопровождения, упростит добавление новых функций или удаление функций и т. Д. Здесь мы собираемся изучить SOLID.
Каковы принципы проектирования SOLID?
«В объектно-ориентированном программировании SOLID - это мнемоническая аббревиатура пяти принципов проектирования, призванных сделать проекты программного обеспечения более понятными, гибкими и удобными в обслуживании».
S - Принцип единственной ответственности
O - Принцип открытости закрыт
L - Принцип замены Лискова
I - Принцип разделения интерфейса
D - Принцип инверсии зависимостей
Принцип единоначалия
«У класса должна быть одна и только одна причина для изменения, то есть у класса должна быть только одна работа».
Если мы реализуем несколько функций в одном классе, это усложнит наш код, и, если в будущем потребуются модификации, это повлияет на весь класс. Если мы будем использовать принцип единой ответственности, мы сможем легко поддерживать наш код.
В качестве примера рассмотрим класс сотрудника, который печатает сведения о сотруднике printEmDetails (), вычисляет их ежемесячный бонус к зарплате calculateBonus () и добавляет эти сведения в базу данных сотрудников addEmDetails ().
Employee.java
Employee.java нарушает принцип единой ответственности. Мы можем разделить три вышеуказанные функции на три отдельных класса, используя принцип единой ответственности.
Employee.java
Bonus.java
DbEmployee.java
Принцип открытости-закрытости
«Классы должны быть открыты для расширения, но закрыты для модификации».
В качестве примера рассмотрим класс гоночных автомобилей, у которого есть модель, цвет и обвес.
Но позже, если команда разработчиков захочет модернизировать нынешнюю гоночную машину со спойлером. Но в соответствии с принципом «открыто-закрыто» мы не можем вносить изменения в класс. Потому что, если мы так поступим, будут ошибки, и это повлияет на весь проект. Таким образом, вместо изменения одного и того же класса мы можем расширить класс гоночного автомобиля.
Принцип замещения Лискова
«Производные классы должны полностью заменять свои базовые классы »
Это означает, что если класс X является подтипом класса Y, тогда мы должны иметь возможность заменить Y на X, не нарушая поведения программы. Барбара Лисков ввела этот принцип.
Давайте рассмотрим простой пример, чтобы понять этот принцип. Предположим, существует интерфейс Car с методами engineOn () и accelerate ().
Согласно приведенному выше примеру водитель может включить двигатель и увеличить мощность за счет ускорения. Подождите, а что насчет электромобилей? У электромобилей нет двигателя, так как же они могут разогнать двигатель?
Это нарушает принцип подмены Лискова, поставив машину без двигателя. Следовательно, базовый класс не может быть заменен производным классом. Таким образом, замена базового класса производным классом может привести к неожиданному поведению.
Принцип разделения интерфейса
«Большие интерфейсы разделяются на более мелкие».
Классы реализации используют только необходимые методы.
В этом примере давайте представим, что нам нужно создать программу для преобразования Цельсия в градусы Фаренгейта cToF (), Цельсия в градусы Кельвина cToK () и Фаренгейта в градусы Кельвина fToK (). Итак, давайте создадим интерфейс с именем Convert, имеющий три метода.
Если мы хотим сначала использовать только методы cToF () и fToK (), нам нужно разделить наш интерфейс на 3 отдельных.
Теперь мы можем реализовать два метода, которые нам нужны.
Принцип инверсии зависимостей
«Принцип инверсии зависимостей относится к разделению программных модулей. Таким образом, вместо модулей высокого уровня, зависящих от модулей низкого уровня, оба будут зависеть от абстракций ».
Хорошо, давайте приведем пример, чтобы понять этот принцип. Можете ли вы представить себе Автомобиль без шины и сиденья?
Теперь добавим шины и сиденья для машины. Итак, давайте создадим конструктор класса и добавим экземпляры шины и сиденья.
Но, объявив шины и сиденья с помощью ключевого слова new, мы тесно связали 3 класса вместе. Так что тестировать класс машины сложно. Отцепим Машину от сидений.
Надеюсь, вы узнали кое-что о принципах SOLID из моего рассказа. Спасибо.
