Single Responsibility
Тема дорожной карты · Software Architecture
Принцип единственной ответственности (Single Responsibility Principle, SRP) гласит: 'У класса должна быть одна и только одна причина для изменения' (Мартин). Часто этот принцип интерпретируется как 'делать одну вещь', но на самом деле он подразумевает, что класс должен обслуживать одну роль или стейкхолдера на уровне требований. Это означает, что если класс начинает меняться по разным причинам, это может свидетельствовать о нарушении принципа SRP.
Применение SRP важно для поддержания устойчивости и поддержки кода. Класс, который меняется только при изменении бухгалтерских правил, является примером соблюдения SRP. Однако класс, который изменяется из-за изменения бухгалтерских правил, пользовательского интерфейса и отчетности одновременно, является хрупким и подверженным конфликтам. Это происходит потому, что три различных источника изменений конкурируют друг с другом, что усложняет поддержку и изменение кода.
Как это работает
Принцип SRP применяется путем идентификации источника изменений для каждого класса. Это означает, что вы должны определить, чьи требования драйвят эволюцию класса. Например, класс InvoiceCalculator изменяется, когда меняются правила бухгалтерии, а класс InvoicePrinter изменяется при изменении формата вывода. Если эти классы объединены, они будут конкурировать друг с другом, когда бухгалтерия требует нового правила налогов, а пользовательский интерфейс требует обновления. В этом случае разные источники изменений требуют создания разных классов, чтобы избежать конфликтов.
Когда применять
Принцип SRP особенно полезен в области доменной логики, где классы эволюционируют вместе с бизнес-правилами. Он также легко применим к glue-коду, конфигурациям и инфраструктуре, где один класс может выполнять несколько небольших задач. В таких случаях изменения происходят редко и независимо друг от друга, что делает разделение классов на основе SRP менее критичным.
Типичные ошибки
- SRP как 'крошечные классы' — это ошибка, когда разработчики начинают создавать слишком маленькие классы, содержащие только один метод. Такое разделение может привести к избыточной абстракции, которая усложняет код и делает его менее поддерживаемым.
- Неправильная ось разделения — иногда разработчики делят классы по техническим слоям, таким как пользовательский интерфейс (UI), бизнес-логика и данные, вместо того чтобы разделить их на основе источников изменений, таких как бухгалтерия, биллинг и отчетность. Это может привести к тому, что изменения в одном слое будут влиять на другие слои, что нарушает цель SRP.
- SRP без измерения — это ошибка, когда разработчики предполагают, что класс нарушает SRP, без проверки, как часто он реально меняется по несвязанным причинам. Без такого измерения трудно точно определить, насколько класс соответствует принципу SRP.