У ваших классов должна быть единственная ответственность и утверждения если побуждают вас увеличить их ответственность.
Допустим, вам нужен ключ от каждой запертой двери вашего дома, поэтому вы пишете класс с именем KeyChain для генерации каждого ключа. Посмотрите на этот плохой пример:
Этот класс использует множество операторов if, у него множество обязанностей, и трудно понять, что делает этот класс, поэтому давайте удалим условные выражения. Однажды моей первой мыслью было использовать метапрограммирование, например:
Мы удалили все операторы if, и каждый метод достаточно мал, чтобы быстро понять, что он делает, но класс по-прежнему несет более одной ответственности, как вы можете видеть в списке ниже:
- выбрать алгоритм открытия двери
- сгенерируйте ключ от двери спальни
- сгенерируйте ключ от входной двери
- создать ключ от двери в ванную
Все равно плохо.
У класса должна быть только одна причина для изменения. - Дядя Боб
Если у нас есть четыре обязанности, нам понадобится четыре класса.
Мы можем перенести генерацию каждого ключа на небольшие классы и сохранить тот же интерфейс, чтобы следовать принципу полиморфизма.
Кроме того, было бы справедливо оставить в классе KeyChain только ответственность за выбор одного из генераторов ключей на основе имени двери.
Замечательно, у каждого класса одна обязанность, и это легко понять.
Каждый класс скрывает детали того, что он делает, и один и тот же интерфейс позволяет нам использовать их, не заботясь о том, кто это.
Преимущества принципа единой ответственности:
- улучшает читаемость
- более многоразовый
- снижает сложность кода
- увеличивает изменчивость
- легко проверить
Я хотел бы воспользоваться возможностью и порекомендовать замечательную книгу об объектно-ориентированном программировании тем, кто хочет углубиться в эту тему: Практический объектно-ориентированный дизайн в Ruby от Sandi Metz
Спасибо, что прочитали, не могли бы вы порекомендовать этот пост?
