Сохранение независимости модуля, принцип SRP

5 0

При разработке модуля CRM я столкнулся с тем, что нужно было сохранять его независимость. В этой статье я приведу два случая, когда мне пришлось применить новые для себя подходы в разработке. 

Немного теории

Принцип единственной ответственности (Single Responsibility Principle, SRP) — это один из пяти принципов SOLID, которые являются основами объектно-ориентированного программирования и проектирования. Принцип SRP гласит, что у каждого модуля или класса должна быть только одна причина для изменения, то есть он должен иметь только одну ответственность.

Сохранение независимости модуля подразумевает, что модули должны быть спроектированы так, чтобы изменения в одном модуле не влияли на другие модули. Это достигается путем четкого определения границ ответственности и минимизации зависимостей между модулями. Если модуль отвечает только за одну задачу, то его можно изменять или заменять, не затрагивая другие части системы.

Применение принципа SRP

1. Формирование StateView

В данном случае на вкладке отображается StateView с контактами проекта. StateView формируется в серверной функции модуля CRM. В Проекте, который располагается в другом модуле, происходит только вызов функции. Таким образом сохраняется независимость модуля, формирование StateView вынесено в модуль CRM.

Некорректный вариант выглядел бы так:


В этом случае StateView формируется в Проекте, хотя это ответственность модуля CRM. Это нарушает принцип единой ответственности.

 

2. Создание сущности Контакт

Независимость сохраняется за счет того, что передается project не из перекрытия, а из базового решения. Свойства проекта передаются отдельно, для этого созданы методы с соответствующей сигнатурой. В методе присваиваются свойства. 

Таким образом выполняется принцип единственной ответственности SOLID,  SRP.  Весь функционал инкапсулирован в модуль. Сохраняется независимость модуля, что было проверено при публикации отдельно от других решений.

Как делать не нужно

Неправильное применение выглядело бы так:


Функционал CRM содержится в Проекте.

Или так

В аргументе передается перекрытие Project, что нарушает независимость модуля.

Выводы

Следование принципу SRP помогает:

  1. Упростить понимание и сопровождение кода.
  2. Уменьшить количество ошибок, так как изменения в одном месте не затрагивают другие функциональности.
  3. Облегчить тестирование, так как можно тестировать каждый модуль отдельно.

Соблюдение принципа единственной ответственности способствует созданию более чистого, гибкого и поддерживаемого кода.

Пока комментариев нет.

Авторизуйтесь, чтобы написать комментарий