5 принципов объектно-ориентированного программирования, описывающих архитектуру программного обеспечения
SOLID - это аббревиатура пяти основных принципов дизайна классов в объектно-ориентированном проектировании. Аббревиатура была введена Робертом Мартином в начале 2000-х. Рекомендую почитать: Чистый код. Роберт Мартин
Класс или модуль должны иметь одну и только одну причину измениться. Все члены этого класса должны быть связаны одной целью. Наш класс не должен быть похож на швейцарский нож, в котором при изменении одного из членов нужно изменять весь инструментарий.
class Order { public void calculate(){... } public void addItem(Product product){... } public List<Product> getItems(){... } ... public void load(){... } public void save(){... } public void print(){... } }
class Order { public void calculate(); public void addItem(Product product){... } public List<Product> getItems(){... } } class OrderRepository { public Order load(int orderId){... } public void save(Order order){... } } class OrderPrintManager { public void print(Order order){... } }
Существует, например, паттерн Active Record, который нарушает принцип SRP Active Record может быть успешно использован в небольших проектах с простой бизнес-логикой. ActiveRecord post = Post.newRecord(); post.setData("title", "Happy Java Programming"); post.setData("body", "Java programming is fun."); post.create();
Объекты проектирования (классы, функции, модули и т.д.) должны быть открыты для расширения, но закрыты для модификации. Это означает, что новое поведение должно добавляться только добавлением новых сущностей, а не изменением старых.
class MessageSender { … public void send(String message, MessageType type) { if(type == MessageType.SMS) sendSMS(msg); else if(type == MessageType.EMAIL) sendEmail(msg); } }
Воспользуемся паттерном “Стратегия” interface SendingStrategy { void send(String message); } class MessageSender { private SendingStrategy strategy; public MessageSender(SendingStrategy strategy) { this.strategy = strategy; } public void send(String message) { this.strategy.send(message); } }
Конкретные стратегии отправки class EmailSendingStrategy implements SendingStrategy { @Override public void send(String message) { System.out.println("Sending Email: " + message); } } class SMSSendingStrategy implements SendingStrategy { @Override public void send(String message) { System.out.println("Sending SMS: " + message); } }
Данный принцип гласит, что «вы должны иметь возможность использовать любой производный класс вместо родительского класса и вести себя с ним таким же образом без внесения изменений».
T S Объекты типа T могут быть замещены объектами типа S без каких-либо изменений желательных свойств этой программы
Circle-ellipse problem Square-rectangle problem
Является ли класс Квадрат подклассом класса Прямоугольник? Rectangle Square ?
class Rectangle { private double width; private double height; public double getWidth() { return width; } public void setWidth(double width) { this.width = width; } public double getHeight() { return height; } public void setHeight(double height) { this.height = height; } public String toString() { return this.width + "x" + this.height; } }
class Square extends Rectangle { public void setWidth(double width) { this.setSide(width); } public void setHeight(double height) { this.setSide(height); } public void setSide(double side) { super.setWidth(side); super.setHeight(side); } }
public class LiskovViolation { public static void main(String[] args) { Rectangle rectangle = new Square(); rectangle.setWidth(10); System.out.println(rectangle); // 10.0x10.0 rectangle.setHeight(20); System.out.println(rectangle); // 20.0x20.0 !!!! Should be 10.0x20.0 } }
Если использовать концепцию неизменяемого объекта (immutable object), то принцип не будет нарушаться. Необходимо убрать возможность изменения объекта после его создания.
Слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе.
Если среди методов интерфейса можно выделить группы методов, которые нужны определенным пользователям интерфейса, то скорее всего интерфейс “толстый”. Такой интерфейс нужно разбить на более мелкие, которые будут выражать потребности конкретной группы пользователей интерфейса.
interface Person { void goToWork(); void withdrawSalary(); void eat(); } Если мы захотим сделать реализацию, в которой единственным необходимым методом будет eat() придется реализовывать и все остальные методы
public interface Person { void eat(); } public interface Worker { void goToWork(); void withdrawSalary(); }
Все взаимосвязи в программе должны поддерживаться с помощью абстракных классом или интерфейсов. Данный принцип гласит, что, во-первых, классы высокого уровня не должны зависеть от низкоуровневых классов. При этом оба должны зависеть от абстракций. Во-вторых, абстракции не должны зависеть от деталей, но детали должны зависеть от абстракций.
