Введение
SOLID — это мнемонический акроним для пяти принципов объектно-ориентированного проектирования, которые были представлены Робертом С. Мартином, также известным как Uncle Bob. Эти принципы призваны помочь проектировщикам ПО, архитекторам, инженерам и разработчикам создавать более гибкое, поддерживаемое и масштабируемое программное обеспечение. Следуя этим принципам, вы сможете проектировать классы, которые проще тестировать, рефакторить, повторно использовать и расширять.
Акроним SOLID расшифровывается как:
S – Принцип единственной ответственности
O – Принцип открытости/закрытости
L – Принцип подстановки Барбары Лисков
I – Принцип разделения интерфейса
D – Принцип инверсии зависимостей
В этой статье мы подробно разберем каждый принцип, чтобы понять, как он помогает писать более качественный код. Кроме того, мы добавим фрагменты кода для каждого принципа, чтобы показать, как применять их на практике, а также чего следует избегать в архитектуре чистого кода. Для демонстрации концепций мы будем использовать Kotlin programming язык, разработанный JetBrains и участниками сообщества Open-source.
Принцип единственной ответственности
Принцип единственной ответственности (SRP) — это принцип проектирования ПО, который гласит, что каждый класс или модуль в программе должен иметь одну четко определенную обязанность. Это означает, что у класса должна быть только одна причина для изменения, и он должен отвечать только за одну часть функциональности программы.
Рассмотрим следующий фрагмент кода в качестве примера того, как этот принцип можно применить в Kotlin:
|
1 2 3 4 5 6 7 8 9 |
data class User( val firstName: String, val lastName: String, val email: String ) |
Ключевое слово data в Kotlin указывает на то, что этот класс является классом данных, а это значит, что он предназначен для хранения данных и не содержит сложной логики. Используя этот класс данных, мы можем создать класс UserService для управления пользователями, как показано ниже:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
class UserService { fun createUser(user: User) { // код для создания пользователя в базе данных } fun deleteUser(user: User) { // код для удаления пользователя из базы данных } fun updateUser(user: User) { // код для обновления пользователя в базе данных } fun getUser(id: Int): User { // код для получения пользователя из базы данных } } |
В этом примере класс UserService имеет одну обязанность: управление пользователями в базе данных. Каждый пользователь представлен кодом data class User , представленным ранее. Все методы в классе UserService связаны с этой обязанностью и, следовательно, согласованы. Это упрощает понимание и поддержку класса, поскольку очевидно, что все его методы связаны с одной четко определенной задачей.
Метод, нарушающий принцип единственной ответственности (SRP) в классе UserService , — это метод, не связанный с основной обязанностью класса, то есть с управлением пользователями в базе данных. Например, рассмотрим следующий вариант класса UserService :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
class UserService { fun createUser(user: User) { // код для создания пользователя в базе данных } fun deleteUser(user: User) { // код для удаления пользователя из базы данных } fun updateUser(user: User) { // код для обновления пользователя в базе данных } fun getUser(id: Int): User { // код для получения пользователя из базы данных } fun sendEmail(user: User, subject: String, message: String) { // код для отправки электронного письма пользователю } } |
В этом примере метод sendEmail не связан с основной обязанностью класса UserService, который заключается в управлении пользователями в базе данных. Этот метод отвечает за отправку электронных писем, что является отдельной задачей, не связанной с управлением пользователями. В результате этот метод нарушает принцип SRP, так как он вводит вторую причину для изменения класса UserService.
Чтобы соответствовать принципу единственной ответственности, было бы лучше выделить функциональность отправки электронной почты в отдельный класс, например EmailService . Это позволило бы классу UserService сосредоточиться на своей основной обязанности по управлению пользователями, а классу EmailService — сосредоточиться на своей обязанности по отправке писем.
Следует отметить, что принцип единственной ответственности заключается не в количестве методов в классе, а в связности этих методов и четком разделении обязанностей внутри класса.
Принцип открытости-закрытости
Принцип открытости-закрытости (Open-Closed Principle, OCP) — это принцип проектирования программного обеспечения, который гласит, что программные сущности (такие как классы, модули или функции) должны быть открыты для расширения, но закрыты для изменения. Это означает, что должна быть возможность добавлять новую функциональность в класс или модуль без изменения его существующего кода.
Рассмотрим класс UserService из предыдущего примера. Предположим, мы хотим добавить новую функцию в класс UserService, которая позволит нам искать пользователей по адресу электронной почты. Один из способов сделать это — добавить новый метод в класс UserService, как показано в коде ниже:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
class UserService { fun createUser(user: User) { // код для создания пользователя в базе данных } fun deleteUser(user: User) { // код для удаления пользователя из базы данных } fun updateUser(user: User) { // код для обновления пользователя в базе данных } fun getUser(id: Int): User { // код для получения пользователя из базы данных } fun searchUsersByEmail(email: String): List<User> { // код для поиска пользователей по адресу электронной почты } } |
Этот подход работает, но он нарушает принцип открытости-закрытости, так как нам пришлось изменить существующий класс UserService, чтобы добавить новую функцию. Лучшим подходом было бы использовать наследование или композицию для расширения функциональности класса UserService без изменения его кода.
Чтобы добиться этого, мы могли бы создать новый класс с именем UserSearchService , который расширяет класс UserService и добавляет функцию поиска по электронной почте:
|
1 2 3 4 5 6 7 8 9 |
class UserSearchService(private val userService: UserService) : UserService() { fun searchUsersByEmail(email: String): List<User> { // код для поиска пользователей по адресу электронной почты } } |
В этом примере класс UserSearchService открыт для расширения, так как он предоставляет дополнительную функциональность помимо той, которую предлагает UserService класса. В то же время, UserService класс остается закрытым для модификации, так как нам не потребовалось изменять его код для добавления функции поиска по email.
Принцип подстановки Барбары Лисков
Принцип подстановки Барбары Лисков (LSP) — это принцип проектирования программного обеспечения, который утверждает, что объекты суперкласса должны иметь возможность заменяться объектами подкласса без влияния на корректность программы. Это означает, что подкласс должен быть допустимой заменой своего суперкласса и должен вести себя так же, как суперкласс, при использовании в том же контексте.
Мы продолжим демонстрацию, используя User и UserService классы из предыдущих примеров. Чтобы разрешить расширение класса User, мы используем ключевое слово open в Kotlin:
|
1 2 3 4 5 6 7 8 9 |
open class User( val firstName: String, val lastName: String, val email: String ) |
Вот исходный класс UserService, который использует класс данных User выше:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
class UserService { fun createUser(user: User) { // код для создания пользователя в базе данных } fun deleteUser(user: User) { // код для удаления пользователя из базы данных } fun updateUser(user: User) { // код для обновления пользователя в базе данных } fun getUser(id: Int): User { // код для получения пользователя из базы данных } } |
Предположим, мы хотим создать подкласс User под названием AdminUser, который представляет пользователей с административными привилегиями. Мы можем сделать это следующим образом:
|
1 2 3 4 5 6 7 8 9 |
class AdminUser( firstName: String, lastName: String, email: String, ) : User(firstName, lastName, email) |
В этом примере класс AdminUser является допустимой заменой класса User, так как он ведет себя так же, как класс User, и может использоваться везде, где ожидается объект User. Например, мы можем использовать класс AdminUser с классом UserService следующим образом:
|
1 2 3 4 5 6 7 8 9 |
fun main() { val userService = UserService() val adminUser = AdminUser("John", "Doe", "john.doe@example.com") userService.createUser(adminUser) } |
Этот код корректен, так как класс AdminUser является допустимой заменой класса User и может использоваться так же, как объект User.
Важно отметить, что принцип подстановки Барбары Лисков касается не только наследования. Речь идет о том, чтобы объекты подкласса вели себя так же, как объекты суперкласса, независимо от того, как реализован подкласс. Например, если бы класс AdminUser вел себя как-то иначе, чем класс User, это нарушило бы принцип подстановки Барбары Лисков, так как он не был бы допустимой заменой класса User.
Принцип разделения интерфейса
Принцип разделения интерфейса (ISP) — это принцип проектирования программного обеспечения, который утверждает, что клиенты не должны зависеть от интерфейсов, которые они не используют. Это означает, что в целом рекомендуется создавать небольшие, специализированные интерфейсы, которые хорошо выполняют одну задачу, вместо создания больших универсальных интерфейсов, которые пытаются делать много вещей сразу.
Вот пример того, как можно применить этот принцип, переписав классы User и UserService из предыдущих примеров:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
interface UserService { fun createUser(user: User) fun deleteUser(user: User) fun updateUser(user: User) fun getUser(id: Int): User } class DatabaseUserService : UserService { override fun createUser(user: User) { // код для создания пользователя в базе данных } override fun deleteUser(user: User) { // код для удаления пользователя из базы данных } override fun updateUser(user: User) { // код для обновления пользователя в базе данных } override fun getUser(id: Int): User { // код для получения пользователя из базы данных } } |
В этом примере UserService интерфейс определяет четыре метода, связанных с управлением пользователями в базе данных. DatabaseUserService класс реализует этот интерфейс и предоставляет конкретные реализации для этих методов.
Предположим, мы хотим добавить новую функцию в UserService интерфейс, которая позволит нам искать пользователей по адресу электронной почты. Один из способов сделать это — добавить новый метод в UserService интерфейс:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
interface UserService { fun createUser(user: User) fun deleteUser(user: User) fun updateUser(user: User) fun getUser(id: Int): User fun searchUsersByEmail(email: String): List<User> } |
Ваш код не будет работать, если вы также не реализуете этот метод во всех классах, реализующих UserService интерфейс:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
class DatabaseUserService : UserService { override fun createUser(user: User) { // код для создания пользователя в базе данных } override fun deleteUser(user: User) { // код для удаления пользователя из базы данных } override fun updateUser(user: User) { // код для обновления пользователя в базе данных } override fun getUser(id: Int): User { // код для получения пользователя из базы данных } override fun searchUsersByEmail(email: String): List<User> { // код для поиска пользователей по адресу электронной почты } } |
Хотя этот подход работает, он нарушает принцип разделения интерфейса (Interface Segregation Principle), так как заставляет DatabaseUserService класс реализовывать метод ( searchUsersByEmail ) который ему может быть не нужен или который он не использует.
Более правильным подходом было бы создать отдельный интерфейс для функции поиска по электронной почте:
|
1 2 3 4 5 |
interface UserSearchService { fun searchUsersByEmail(email: String): List<User> } |
Теперь у нас есть отдельные, небольшие и специализированные интерфейсы, а именно UserService и UserSearchServiceкоторые имеют одну обязанность. Класс, которому требуются все функции этих интерфейсов, может реализовать их, как показано во фрагменте кода ниже:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
class DatabaseUserService : UserService, UserSearchService { override fun createUser(user: User) { // код для создания пользователя в базе данных } override fun deleteUser(user: User) { // код для удаления пользователя из базы данных } override fun updateUser(user: User) { // код для обновления пользователя в базе данных } override fun getUser(id: Int): User { // код для получения пользователя из базы данных } override fun searchUsersByEmail(email: String): List<User> { // код для поиска пользователей по адресу электронной почты } } |
Это соответствует принципу разделения интерфейса (Interface Segregation Principle), так как гарантирует, что клиенты (такие как класс DatabaseUserService) не вынуждены зависеть от интерфейсов, которые они не используют.
Чтобы лучше понять эту концепцию, предположим, что у нас есть другой класс с именем MemoryUserService который реализует интерфейс UserService, но не нуждается в функции поиска по электронной почте. Мы можем написать код следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
class MemoryUserService : UserService { private val users = mutableListOf<User>() override fun createUser(user: User) { users.add(user) } override fun deleteUser(user: User) { users.remove(user) } override fun updateUser(user: User) { val index = users.indexOf(user) if (index >= 0) { users[index] = user } } override fun getUser(id: Int): User { return users[id] } } |
В этом примере класс MemoryUserService должен реализовывать только методы, определенные в интерфейсе UserService, и ему не нужно беспокоиться о функции поиска по электронной почте. Это позволяет классу MemoryUserService сосредоточиться на своей основной обязанности по управлению пользователями в памяти, вместо того чтобы быть вынужденным реализовывать несвязанную функциональность.
Принцип инверсии зависимостей (Dependency Inversion Principle)
Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) — это принцип проектирования программного обеспечения, который гласит, что модули верхнего уровня не должны зависеть от модулей нижнего уровня; оба типа модулей должны зависеть от абстракций. Это означает, что в целом рекомендуется проектировать программное обеспечение таким образом, чтобы компоненты верхнего уровня не были привязаны к конкретным реализациям компонентов нижнего уровня, а зависели от абстракций (таких как интерфейсы или абстрактные классы), которые могут быть реализованы различными способами.
Давайте рассмотрим пример того, как этот принцип можно применить к классам User и UserService, использовавшимся в предыдущих фрагментах кода:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
interface UserRepository { fun create(user: User) fun delete(user: User) fun update(user: User) fun get(id: Int): User } class UserService(private val repository: UserRepository) { fun createUser(user: User) { repository.create(user) } fun deleteUser(user: User) { repository.delete(user) } fun updateUser(user: User) { repository.update(user) } fun getUser(id: Int): User { return repository.get(id) } } |
В этом примере класс UserService зависит от абстракции под названием интерфейс UserRepository, а не от конкретной реализации репозитория пользователей. Это позволяет нам реализовать интерфейс UserRepository различными способами, например, с помощью базы данных или хранилища в памяти, не затрагивая класс UserService.
Например, вот реализация интерфейса UserRepository, которая использует базу данных:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
class DatabaseUserRepository: UserRepository { override fun create(user: User) { // код для создания пользователя в базе данных } override fun delete(user: User) { // код для удаления пользователя из базы данных } override fun update(user: User) { // код для обновления пользователя в базе данных } override fun get(id: Int): User { // код для получения пользователя из базы данных } } |
Вот еще одна реализация интерфейса UserRepository, которая использует хранилище в памяти:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
class MemoryUserRepository : UserRepository { private val users = mutableListOf<User>() override fun create(user: User) { users.add(user) } override fun delete(user: User) { users.remove(user) } override fun update(user: User) { val index = users.indexOf(user) if (index >= 0) { users[index] = user } } override fun get(id: Int): User { return users[id] } } |
Это делает систему более гибкой и простой в поддержке, так как позволяет нам изменять реализацию репозитория, не затрагивая остальную часть системы. Это также упрощает тестирование класса UserService, поскольку мы можем имитировать зависимость UserRepository в наших тестах.
Заключение
В этой статье мы поговорили о пяти принципах SOLID код и готовые фрагменты кода, соответствующие каждому принципу. Соблюдение этих принципов поможет вам проектировать программные системы, которые будут более гибкими, поддерживаемыми и масштабируемыми. Однако важно помнить, что эти принципы являются рекомендациями, а не жесткими правилами, и разработчик сам решает, когда и как применять их в контексте своего конкретного проекта. Продолжайте обучение, заглядывая в наш блог, где вы найдете более подробные и актуальные статьи и руководства по облачным вычислениям и DevOps, проектированию и разработке программного обеспечения, технологическим трендам, за которыми стоит следить, и многому другому.
Приятного программирования!
Комментарии
Комментариев пока нет. Будьте первым.