Принцип S.O.L.I.D (Серия из 2 частей)
В объектно-ориентированном компьютерном программировании SOLID – это мнемоническая аббревиатура пяти принципов проектирования, призванная сделать дизайн программного обеспечения более понятным, гибким и ремонтопригодным.
SOLID – это аббревиатура 5 важных принципов проектирования при выполнении ООП. Впервые он был представлен Робертом К. Мартином ( Дядя Боб ) в его статье 2000 года Принципы проектирования и шаблоны проектирования .
ТВЕРДЫЙ обозначает –
- S – Принцип Единой Ответственности
- O – Принцип открытия/Закрытия
- L – Принцип замещения Лискова
- I – Принцип разделения Интерфейсов
- D – Принцип Инверсии Зависимостей
В этой статье я буду освещать S – Принцип единой ответственности . Примечание – Примеры будут на Java, но применимы к любому языку ООП.
У класса должна быть одна и только одна причина для изменения.
В программировании Принцип единой ответственности гласит, что каждый модуль или класс должен отвечать за отдельную часть функциональности, предоставляемой программным обеспечением.
Действие действие/ | пример говорит громче, чем голос
package app.singleResponsibility;
public class Employee {
private String name;
private int perHourRate;
public Employee(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPerHourRate(int rate) {
this.perHourRate = rate;
}
public int getPerDayRate() {
return perHourRate * 8;
}
public String markAttendance() {
return String.format("%s is present", name);
}
}
А вот и UML-диаграмма для гиков –
Итак, у нас есть очень простой класс Employee с двумя частными атрибутами и несколькими общедоступными методами. На первый взгляд, это выглядит нормально, но на самом деле это нарушение SRP .
Класс Employee имеет дело не только с деталями сотрудника, но также связан с реализацией метода markAttendence . Сейчас у него есть две причины измениться.
Предыдущий пример нарушает закон SRP о единой ответственности. Давайте копнем немного дальше и попробуем исправить класс Сотрудник .
// Employee.java
package app.singleResponsibility;
public class Employee {
private String name;
private int perHourRate;
public Employee(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPerHourRate(int rate) {
this.perHourRate = rate;
}
public int getPerDayRate() {
return perHourRate * 8;
}
}
Обновленная диаграмма UML для Сотрудника класса –
Мы удалили метод отметить посещаемость из класса Сотрудник , чтобы сделать его совместимым с SRP.
Давайте пойдем дальше и создадим класс Отслеживание посещаемости для работы с посещаемостью.
// AttendanceTracker.java
package app.singleResponsibility;
public class AttendanceTracker {
private Employee emp;
public AttendanceTracker(Employee emp) {
this.emp = emp;
}
public String markAttendance() {
return String.format("%s is present", emp.getName());
}
}
UML-диаграмма для Отслеживания посещаемости класса
Отслеживание посещаемости класс принимает объект сотрудника в качестве зависимости и отмечает посещаемость этого сотрудника.
Теперь оба класса придерживаются Принципа единой ответственности и это облегчает техническое обслуживание и тестирование.
Чем больше обязанностей (причин для изменения) у класса, тем сложнее будет реализовать некоторые новые функции, а техническое обслуживание станет растущей проблемой, которая будет занимать больше времени по мере роста проекта, усложняя и делая обязанности классов тесно связанными друг с другом.
Поэтому всегда проводите небольшие занятия с одной ответственностью.
Мир! Если у вас есть какие-либо вопросы или отзывы, пожалуйста, не стесняйтесь оставлять комментарии ниже.
Принцип S.O.L.I.D (Серия из 2 частей)
Оригинал: “https://dev.to/linuxnerd/s-o-l-i-d-single-responsibility-principle-3m4g”