Допустим в одном классе реализованы две группы методов — каждая группа методов относится к отдельной функциональности.
Если один разработчик что-то изменил в одной группе методов, то придется перекомпилировать весь класс. Этого можно было бы избежать если бы те две группы методов были разнесены по разным классам. Т.е. Single Responsibility Principle позволяет уменьшить compilation dependencies.
В этом и заключается польза от Single Responsibility Principle? Или еще какая-то польза есть?
Здравствуйте, Максим Рогожин, Вы писали:
МР>В этом и заключается польза от Single Responsibility Principle? Или еще какая-то польза есть?
Нет, основной смысл в том, что так понятнее, когда класс отвечает за что-то одно, можно тогда подобрать ему более точное название, и при его чтении в контексте конкретной функциональности не отвлекаться на несущественную для этой функциональности задачу. Также позволит избежать появления лишней зависимости между функциональностями.
Здравствуйте, Alexander G, Вы писали:
AG>Также позволит избежать появления лишней зависимости между функциональностями.
Спасибо, но не могли бы вы поподробнее вот этот момент пояснить? Если кому-то захочется использовать какую-то функциональность, то он ее и из другого класса возьмет.
SRP это практический принцип уменьшения связности вообще, не только во время компиляции. Связность в проекте стоит уменьшать для а) уменьшения количества побочных эффектов, б) повышения устойчивости к изменениям в коде. Соответственно, SRP помогает решить обе задачи.
Пример из runtime: допустим у вашего класса есть не только две группы методов, но и какое-то состояние, соответствующее каждой из групп (если мы говорим об ООП, а не о процедурном программировании, то скорее всего так оно и есть). Во-первых, у вас могут быть явные побочные эффекты, когда одна из групп меняет состояние второй группы. Во-вторых, у вас могут быть неявные побочные эффекты, связанные с жизненным циклом объекта. Объединяя два разных состояния в один объект, вы жестко связываете их ЖЦ друг с другом, от момента создания до момента освобождения памяти, что может быть плохо или даже очень плохо для вашей архитектуры (утечки памяти, утечки персональных данных и паролей через долгоживущие и, ужас-ужас, сериализуемые объекты и т.п.).
Пример, не связанный с ООП вообще: пусть у вас есть метод calculateAndPrint(Model m), который и вычисляет, и выводит результат в консоль. Очевидно, он объединяет сразу две роли — вычислительную и вывод информации в консоль. Если вы захотите по выбору пользователя записать результат вместо консоли в БД, то придется либо писать новый метод, либо-таки разбивать старый на два в соответствии с SRP.
Пример из Java c паттерном singleton. Почему класс, содержащий статическое поле с единственным своим экземпляром (self-contained singleton), безусловное зло и антипаттерн? Да ровно по той же самой причине: нарушает SRP, сочетая сразу две роли — основную бизнес-роль и роль, связанную с инициализацией, хранением и предоставлением доступа к единственному экземпляру. Это нарушение приводит к трудностям с написанием тестов и к значительному снижению гибкости кода. Исправляется тривиально введением класса-фабрики, например, из DI-фреймворка типа Spring или Guice.
Здравствуйте, Baudolino, Вы писали:
B>SRP это практический принцип уменьшения связности вообще, не только во время компиляции. Связность в проекте стоит уменьшать для а) уменьшения количества побочных эффектов, б) повышения устойчивости к изменениям в коде. Соответственно, SRP помогает решить обе задачи.
B>Пример из runtime B>Пример, не связанный с ООП вообще B>Пример из Java c паттерном singleton.
Большое спасибо! Еще вопрос — а не является ли Interface Segregation Principle просто частым случаем SRP? Т.е. ISP это просто "SRP для интерфейсов"?
Здравствуйте, Максим Рогожин, Вы писали:
МР>Большое спасибо! Еще вопрос — а не является ли Interface Segregation Principle просто частым случаем SRP? Т.е. ISP это просто "SRP для интерфейсов"?
Оба принципа решают одну задачу, но с различных точек зрения: я бы не назвал их связь частным случаем, скорее у них есть общая базовая идея.
ISP может быть нарушен, даже если SRP соблюдается. Например, вы реализуете алгоритм сортировки и в качестве параметра функции ожидаете массив учетных записей пользователя. Вообще-то алгоритму нужна только возможность сравнивать объекты, его не интересуют идентификаторы и имена учеток: было бы логично его обобщить, выделив интерфейс Comparable или разрешив дополнительно передавать функцию сразвнения объектов в коллекции. Соответственно реорганизация кода от простого класса Account к Account implements Comparable<Account> это и есть шаг в сторону ISP.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Допустим в одном классе реализованы две группы методов — каждая группа методов относится к отдельной функциональности.
Можно сделать отдельные интерфейсы для каждой группы методов.
Класс будет наследовать эти интерфейсы и реализовывать.
Клиенты класса работают с ним через интерфейсы.
?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Максим Рогожин, Вы писали:
МР>В этом и заключается польза от Single Responsibility Principle? Или еще какая-то польза есть?
Зачем вообще нужно деление программы на классы, функции, методы и т.п.? Почему бы не писать программу одним большим куском?
Ответ заключается в том, что человеку так проще понимать программу. Именно человеку, удобство компилятора, линкера, процессора и операционной системы в этом вопросе вторично.
Так вот, всякие Principle, их польза заключается в том, что они структурируют мысль программиста, и делают программу более понятной. Больше ни для чего они не нужны.
