Архитектура ПО представляет собой скелет и многоуровневую инфраструктуру программы, тогда как проектирование ПО следует рассматривать на уровне кода. Но чтобы разработчику понимать, как лучше решать повседневные проблемы разработки, следует знать определенные принципы. Он них и поговорим.
Разумеется, речь пойдет о принципах SOLID. Это известная аббревиатура, которую можно расшифровать следующим образом:
- S -- Single Responsibility (единственная ответственность),
- O -- Open Closed (открытость/закрытость),
- L -- Liskov substitution (принцип подстановки Барбары Лисков),
- I -- Interface Segregation (принцип разделения интерфейсов),
- D -- Dependency Inversion Principles (принцип инверсии зависимостей).
Ну что же, давайте рассмотрим их более подробно, но максимально простыми словами.
Single Responsibility
Принцип единственной ответственности подразумевает, что каждый класс работает лишь над одной целью. Этот класс несет ответственность только в рамках достижения этой цели и изменяется лишь по одной причине.
Общий принцип можно сформулировать так: для каждого класса важно определить единственное назначение, а все ресурсы, которые нужны для имплементации, следует инкапсулировать в данный класс и подчинить только единственной задаче.
Open Closed
Класс должен быть открыт для расширения, однако закрыт для изменений. То есть мы можем добавить в класс новую функциональность, однако не можем редактировать существующие функции так, чтобы они противоречили используемому коду.
Таким образом, программные сущности должны быть открыты для расширения, однако закрыты для модификации.
Liskov substitution
Согласно данному принципу, программисту следует соблюдать наследственность так, чтобы логика программного приложения нигде не нарушалась. К примеру, если новый класс «X-Class» является дочерним для класса «A-Class», то новый класс должен повторять функции родителя таким образом, чтобы эти функции не меняли поведение родительского класса. В таком случае вы без проблем сможете применять объект X-Class вместо объекта A-Class, не нарушая при этом логики программного приложения.
Если кратко, то объекты в разрабатываемой программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.
Interface Segregation
По принципу разделения интерфейсов класс должен обладать способностью реализовывать множество интерфейсов. То есть код надо писать так, чтобы классу не надо было реализовывать функцию, которая не является важной для задач класса. Вывод тут прост: следует разделять свои интерфейсы на категории.
Или же: много интерфейсов, которые специально предназначены для клиентов, -- это лучше, чем 1 интерфейс общего назначения.
Dependency Inversion Principles
Любой, кто когда-нибудь применял для создания приложения TDD, знает, насколько важно расщеплять код перед тестированием и моделированием. Иными словами, когда определенный класс «ex:Purchase» имеет зависимость от класса «Users», то установка пользовательских объектов должна инициировать снаружи класс «Purchase».
Таким образом, можно говорить о зависимости на абстракциях, а точнее, об отсутствии зависимости на что-либо конкретное.
По материалам:
- https://nuancesprog.ru/;
- https://ru.wikipedia.org/wiki/SOLID_(объектно-ориентированное_программирование).
Что такое архитектор предприятия?
Узнайте 11 апреля на вебинаре в OTUS «Прошлое, настоящее и будущее роли архитектора предприятия». На открытом уроке у нас будет возможность обсудить роль архитектора предприятия: кем были, кем стали, кем должны быть в обозримом будущем и почему. Поговорим о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации.
Увидим, где начинается архитектурный подход, и куда нужно стремиться в профессиональном развитии.