Single Responsibility Principe достаточно прост для понимания и его несложно придерживаться.
Но в работе я достаточно часто сталкиваюсь с нарушением этого принципа. В этой статье я собрал самые больные из тех способов нарушить SPR, что я встречал.
Singleton — подразумевает, что помимо своих основных обязанностей класс занимается еще и контролированием количества своих экземпляров, чем нарушает Single Responsibility Principle.
Очень просто создать Singleton. Достаточно скопировать из википедии пару строк кода в вашу любимую IDE. Singleton есть везде, не нужно заморачиваться с передачей объекта в нужное место и управлять памятью тоже не обязательно, экземпляр один, к тому же он вечный. Эта легкость, возможно, и является причиной применения Singleton-а не по назначению.
Зависимость от Singleton-а не видна в публичном интерфейсе. Достать и использовать экземпляр можно в любом месте, независимо ни от чего.
Сложные зависимости, а тем более скрытые (те, что не видны в публичном интерфейсе), приводят к появлению неожиданных эффектов в частях приложения, на первый взгляд не связанных с теми частями, где производится изменение кода. Это приводит к неожиданным багам. К тому же, такие баги могут быть не найдены сразу после внесения изменений, из-за неочевидной области функциональности, на которую повлияло изменение.
Singleton делает невозможным полиморфизм в отношении себя. А значит, невозможны автотесты. Изменение поведения Singleton-а во время исполнение затрудняется. Необходимость перевести компонент в особый режим, требующий другого поведения Singleton-а, вызывает боль и страдания.
Это приводит к изменению поведения при изменении порядка вызовов методов класса. Так как Singleton есть везде, то контролировать порядок вызовов практически невозможно. Это может приводить к разнообразным артефактам. Эта проблема усугубляет негативные эффекты увеличения связности кода и порождает еще более изощренные баги.
Повышение связности кода и невозможность подмены его экземпляра успешно решает IoC. Реализация этого принципа, например с помощью Dependency Injection, забирает обязанность контролирования количества экземпляров класса и делает зависимости более явными.
Singleton уместен в тех случаях, когда не может логически существовать более одного экземпляра объекта. Например, NSApplication.
В готовых библиотеках использование Singleton-а оправданно в ситуациях, когда незачем или дорого что-то кастомить или подменять.
Есть огромное количество способов смешать архитектурные слои. Каждый из способов раскладывает свои грабли.
Помещая бизнес-логику в объект модели, мы добавляем в него, помимо основной ответственности — хранения данных, дополнительные ответственности, связанные с обработкой этих данных. Как правило, при таком подходе в объекте модели скапливается большая часть операций, которые можно выполнить с этим объектом. Что является многократным нарушением SRP.
Наличие бизнес-логики в объектах модели приводит к невозможности переиспользовать часть бизнес-логики для другого объекта модели, затрудняет расширение модели, предрасполагает к реализации полиморфизма через copy-paste. При создании похожего объекта копируется с небольшими изменениям часть кода с бизнес логикой. Такой подход делает практически невозможным безопасное изменение той части логики, которая находится в модели.
Обнаружить такое нарушение достаточно просто, по наличию любых методов в объекте модели.
Часто встречаются методы по сохранению объекта модели в память устройства или методы для обновления данных из удаленного ресурса.
Все эти паттерны достаточно схожи, это видно даже по аббревиатурам. У каждого есть View и Model. Различаются они способом взаимодействия View с Model-ю через промежуточный слой.
Но у каждого из этих паттернов один общий недостаток — разрастание Controller-а, Presenter-а или View-Model-и. Суть проблемы кроется в неправильном понимании компонента View и компонента хранящего бизнес-логику (Controller, Presenter или View-Model).
View должна содержать логику для отображения пользовательского интерфейса Controller, Presenter или View-Model должны содержать бизнес-логику. Отдельных слов заслуживает MVC iOS SDK навязывает использование MVC. Но UIViewController не является MVC-шным Controller-ом, так как в большинстве случаев он содержит логику для отображения пользовательского интерфейса.
Этот факт делает практически невозможным реализацию правильного MVC. В лучшем случае UIViewController становится частью View, бизнес логика выносится в другие слои.
С другой стороны, после отделения логики, необходимой для отображения интерфейса, в Controller-е, Presenter-е или View-Model-и все равно может остаться слишком много кода. Это очень часто связано с тем, что для одного экрана создается один объект, содержащий бизнес-логику, при этом он может реализовывать несколько пользовательских сценариев, что опять нарушает SRP.
Каждый объект, содержащий бизнес логику, должен реализовывать не больше одного пользовательского сценария.
Как правило, многие пользовательские сценарии могут состоять из одних и тех же операций, сохранение и получение данных из локального хранилища, запросы к удаленному серверу и т.д.
В этом случае всю логику, которая не относится к пользовательскому сценарию необходимо вынести в инфраструктурный слой.
Решением проблемы “разрастающегося контроллера” будет грамотное использование архитектурных паттернов. Если придерживаться SRP при написании кода и выносить из Controller-а, Presenter-а или View-Model-и весь код, не относящийся к его основной ответственности, логика станет прозрачнее, пользовательские сценарии понятнее, и их будет проще читать.
Нотификации в iOS — отличный способ связать все со всем!
NSNotificationCenter является частным, но достаточно ярким представителем Singleton-а. Несмотря на то, что нотификации — паттерн взаимодействия (Communication Pattern), а Singleton — порождающий паттерн (Creational Pattern), нотификации сохранюет все недостатки Singleton-а.
Начиная обсервить нотификацию, не связанную с основными обязанностями класса мы нарушаем SRP.
Основные проблемы, возникающие при использовании нотификаций:
Повышение связности кода достигается за счет того, что отправить нотификацию и получить ее может абсолютно любой класс в абсолютно любой части приложения.
Если нотификация отправлена, мы уже не можем ни перехватить, ни подменить ее.
Если несколько объектов подписаны на одну нотификацию, то невозможно управлять порядком получения нотификации.
Решение описанных проблем — отказаться от использования нотификаций в пользу более удобных механизмов.
Исключением может являться использование нотификаций для оповещения об изменении глобального состояния приложения, например, изменение состояния сетевого подключения или уход приложения в фон и выход из фона.
Формальные признаки нарушения SRP:
Но в работе я достаточно часто сталкиваюсь с нарушением этого принципа. В этой статье я собрал самые больные из тех способов нарушить SPR, что я встречал.
Первый способ: Singleton
Singleton — подразумевает, что помимо своих основных обязанностей класс занимается еще и контролированием количества своих экземпляров, чем нарушает Single Responsibility Principle.
Очень просто создать Singleton. Достаточно скопировать из википедии пару строк кода в вашу любимую IDE. Singleton есть везде, не нужно заморачиваться с передачей объекта в нужное место и управлять памятью тоже не обязательно, экземпляр один, к тому же он вечный. Эта легкость, возможно, и является причиной применения Singleton-а не по назначению.
Singleton повышает связность кода
Зависимость от Singleton-а не видна в публичном интерфейсе. Достать и использовать экземпляр можно в любом месте, независимо ни от чего.
Сложные зависимости, а тем более скрытые (те, что не видны в публичном интерфейсе), приводят к появлению неожиданных эффектов в частях приложения, на первый взгляд не связанных с теми частями, где производится изменение кода. Это приводит к неожиданным багам. К тому же, такие баги могут быть не найдены сразу после внесения изменений, из-за неочевидной области функциональности, на которую повлияло изменение.
Экземпляр Singleton-а невозможно подменить без танца с бубном
Singleton делает невозможным полиморфизм в отношении себя. А значит, невозможны автотесты. Изменение поведения Singleton-а во время исполнение затрудняется. Необходимость перевести компонент в особый режим, требующий другого поведения Singleton-а, вызывает боль и страдания.
Singleton может хранить свое состояние
Это приводит к изменению поведения при изменении порядка вызовов методов класса. Так как Singleton есть везде, то контролировать порядок вызовов практически невозможно. Это может приводить к разнообразным артефактам. Эта проблема усугубляет негативные эффекты увеличения связности кода и порождает еще более изощренные баги.
Есть более безопасные порождающие паттерны
Повышение связности кода и невозможность подмены его экземпляра успешно решает IoC. Реализация этого принципа, например с помощью Dependency Injection, забирает обязанность контролирования количества экземпляров класса и делает зависимости более явными.
Несмотря на все описанные выше ужасы, есть места, где уместно использовать Singleton
Singleton уместен в тех случаях, когда не может логически существовать более одного экземпляра объекта. Например, NSApplication.
В готовых библиотеках использование Singleton-а оправданно в ситуациях, когда незачем или дорого что-то кастомить или подменять.
Второй способ: смешение архитектурных слоев
Есть огромное количество способов смешать архитектурные слои. Каждый из способов раскладывает свои грабли.
Бизнес-логика в модели.
Помещая бизнес-логику в объект модели, мы добавляем в него, помимо основной ответственности — хранения данных, дополнительные ответственности, связанные с обработкой этих данных. Как правило, при таком подходе в объекте модели скапливается большая часть операций, которые можно выполнить с этим объектом. Что является многократным нарушением SRP.
Наличие бизнес-логики в объектах модели приводит к невозможности переиспользовать часть бизнес-логики для другого объекта модели, затрудняет расширение модели, предрасполагает к реализации полиморфизма через copy-paste. При создании похожего объекта копируется с небольшими изменениям часть кода с бизнес логикой. Такой подход делает практически невозможным безопасное изменение той части логики, которая находится в модели.
Обнаружить такое нарушение достаточно просто, по наличию любых методов в объекте модели.
Часто встречаются методы по сохранению объекта модели в память устройства или методы для обновления данных из удаленного ресурса.
Неправильное использование паттернов MVC, MVP, MVVM
Все эти паттерны достаточно схожи, это видно даже по аббревиатурам. У каждого есть View и Model. Различаются они способом взаимодействия View с Model-ю через промежуточный слой.
Но у каждого из этих паттернов один общий недостаток — разрастание Controller-а, Presenter-а или View-Model-и. Суть проблемы кроется в неправильном понимании компонента View и компонента хранящего бизнес-логику (Controller, Presenter или View-Model).
View должна содержать логику для отображения пользовательского интерфейса Controller, Presenter или View-Model должны содержать бизнес-логику. Отдельных слов заслуживает MVC iOS SDK навязывает использование MVC. Но UIViewController не является MVC-шным Controller-ом, так как в большинстве случаев он содержит логику для отображения пользовательского интерфейса.
Этот факт делает практически невозможным реализацию правильного MVC. В лучшем случае UIViewController становится частью View, бизнес логика выносится в другие слои.
С другой стороны, после отделения логики, необходимой для отображения интерфейса, в Controller-е, Presenter-е или View-Model-и все равно может остаться слишком много кода. Это очень часто связано с тем, что для одного экрана создается один объект, содержащий бизнес-логику, при этом он может реализовывать несколько пользовательских сценариев, что опять нарушает SRP.
Каждый объект, содержащий бизнес логику, должен реализовывать не больше одного пользовательского сценария.
Как правило, многие пользовательские сценарии могут состоять из одних и тех же операций, сохранение и получение данных из локального хранилища, запросы к удаленному серверу и т.д.
В этом случае всю логику, которая не относится к пользовательскому сценарию необходимо вынести в инфраструктурный слой.
Решением проблемы “разрастающегося контроллера” будет грамотное использование архитектурных паттернов. Если придерживаться SRP при написании кода и выносить из Controller-а, Presenter-а или View-Model-и весь код, не относящийся к его основной ответственности, логика станет прозрачнее, пользовательские сценарии понятнее, и их будет проще читать.
Третий способ: NSNotificationCenter
Нотификации в iOS — отличный способ связать все со всем!
NSNotificationCenter является частным, но достаточно ярким представителем Singleton-а. Несмотря на то, что нотификации — паттерн взаимодействия (Communication Pattern), а Singleton — порождающий паттерн (Creational Pattern), нотификации сохранюет все недостатки Singleton-а.
Начиная обсервить нотификацию, не связанную с основными обязанностями класса мы нарушаем SRP.
Основные проблемы, возникающие при использовании нотификаций:
Повышение связности кода достигается за счет того, что отправить нотификацию и получить ее может абсолютно любой класс в абсолютно любой части приложения.
Если нотификация отправлена, мы уже не можем ни перехватить, ни подменить ее.
Если несколько объектов подписаны на одну нотификацию, то невозможно управлять порядком получения нотификации.
Решение описанных проблем — отказаться от использования нотификаций в пользу более удобных механизмов.
Исключением может являться использование нотификаций для оповещения об изменении глобального состояния приложения, например, изменение состояния сетевого подключения или уход приложения в фон и выход из фона.
Формальные признаки нарушения SRP:
- Одним из самых заметных признаков является разрастание размера класса или метода.
- Наследование класса от большего количества протоколов (при условии соблюдения ISP).
- Использование Singleton-ов может свидетельствовать о нарушении SRP.
- Передача информации об изменении состояния конкретного объекта с использованием NSNotificationCenter (можно нотификациями сообщать об изменении глобального состояния)
- Скапливание в объектах утилитных методов.
- Большее количество публичных методов класса, также может свидетельствовать о нарушении SRP.
- Большее количество приватных методов, которые можно разбить на группы. В этом случае каждая группа, скорее всего, имеет свою зону ответственности.
