Как не нарушить принцип единой ответственности?
Я новичок в программировании и изучаю дизайн.
Меня учили, что SRP очень важен, так что каждый класс должен иметь одну ответственность. Таким образом, я хотел унаследовать обязанности других классов. Но потом я понял, что Java не допускает множественного наследования, а только интерфейсов. Я думаю, что проблема реализации нескольких интерфейсов заключается в том, что вам нужно писать методы внутри одного класса, который в любом случае реализует интерфейсы. Поэтому вам нужно перейти к классу, реализующему интерфейс, чтобы исправить метод. Тогда не считается ли это нарушением SRP?
Короче говоря, мне нужен класс A, скажем, собака, который конструирует объект и нуждается в методах B (лай), C (есть) и D (сон) относительно A. Как мне это сделать, не нарушая SRP?
Ответы 1
SRP обычно формулируется как «Каждый класс должен нести одну ответственность», но это неточно. Лучше сказать: «У модуля должна быть одна и только одна причина для изменения». Как я описываю в Принцип единственной ответственности: фундаментальная ошибка?, я могу думать о двух возможных осях изменения:
- Изменение бизнеса
- Технологические изменения
Сведение изменения бизнеса к «одной причине для изменения» означает, что в компании должен быть только один человек, который просит вас изменить конкретный модуль. Например, некоторые из людей, которые могут попросить об изменениях, являются руководителями продукта или дизайнерами. Это означает, что мы должны отделить то, как объект ведет себя от того, как он выглядит.
Пример технологических изменений - изменение способа хранения вещей. «Нам нужно перейти от базы данных SQL к плоскому хранилищу NoSQL».
Итак, что он делает, как выглядит, от какой инфраструктуры зависит - это вещи, которые следует разделить. Не твоя собака. Принцип разделения интерфейсов приводит к созданию тонких срезов интерфейсов, таких как «Лай» и «Еда». Это позволяет вызывающим абонентам полагаться на эти тонкие кусочки, а не на какой-то огромный интерфейс, такой как Animal, в котором есть много вещей, которые ему не нужны.
Так я бы сказал
class Dog: Barking & Eating & Sleeping
не обязательно нарушает SRP, особенно когда каждый интерфейс тонкий.
Тем не менее, я видел, как люди объединяют не связанные друг с другом интерфейсы, чтобы создать чудовищ. В основном это результат ленивого использования существующего класса в качестве свалки. Пока вы продолжаете спрашивать: «Можно ли это разделить?» и увидев, сможете ли вы снять с себя ответственность, у вас все получается лучше, чем у большинства людей.