При разработке модуля CRM я столкнулся с тем, что нужно было сохранять его независимость. В этой статье я приведу два случая, когда мне пришлось применить новые для себя подходы в разработке.
Принцип единственной ответственности (Single Responsibility Principle, SRP) — это один из пяти принципов SOLID, которые являются основами объектно-ориентированного программирования и проектирования. Принцип SRP гласит, что у каждого модуля или класса должна быть только одна причина для изменения, то есть он должен иметь только одну ответственность.
Сохранение независимости модуля подразумевает, что модули должны быть спроектированы так, чтобы изменения в одном модуле не влияли на другие модули. Это достигается путем четкого определения границ ответственности и минимизации зависимостей между модулями. Если модуль отвечает только за одну задачу, то его можно изменять или заменять, не затрагивая другие части системы.
В данном случае на вкладке отображается StateView с контактами проекта. StateView формируется в серверной функции модуля CRM. В Проекте, который располагается в другом модуле, происходит только вызов функции. Таким образом сохраняется независимость модуля, формирование StateView вынесено в модуль CRM.
Некорректный вариант выглядел бы так:
В этом случае StateView формируется в Проекте, хотя это ответственность модуля CRM. Это нарушает принцип единой ответственности.
Независимость сохраняется за счет того, что передается project не из перекрытия, а из базового решения. Свойства проекта передаются отдельно, для этого созданы методы с соответствующей сигнатурой. В методе присваиваются свойства.
Таким образом выполняется принцип единственной ответственности SOLID, SRP. Весь функционал инкапсулирован в модуль. Сохраняется независимость модуля, что было проверено при публикации отдельно от других решений.
Неправильное применение выглядело бы так:
Функционал CRM содержится в Проекте.
Или так
В аргументе передается перекрытие Project, что нарушает независимость модуля.
Следование принципу SRP помогает:
Соблюдение принципа единственной ответственности способствует созданию более чистого, гибкого и поддерживаемого кода.
Авторизуйтесь, чтобы написать комментарий