Как не нарушать принцип единой ответственности?

Question

Я новичок в программировании и изучаю дизайн.

Меня учили, что SRP очень важен, так что у каждого класса должна быть одна ответственность. Таким образом, я хотел унаследовать обязанности от других классов. Но потом я понял, что Java не допускает множественное наследование, а только интерфейсы. Я думаю, что проблема реализации нескольких интерфейсов состоит в том, что вы должны написать методы внутри одного класса, который в любом случае реализует интерфейсы. Таким образом, вы должны перейти к классу, который реализует интерфейс, чтобы исправить метод. Тогда не считается ли это нарушением ПСП?

Короче говоря, я хочу класс A, скажем, собаку, который строит вещь и нуждается в методах B (кора), C ​​(есть) и D (спать) о A. Как мне это сделать, не нарушая SRP?

Answer 1

SRP обычно обозначается как "Каждый класс должен иметь одну ответственность", но это неточно. Лучшее утверждение: "Модуль должен иметь одну-единственную причину для изменения". Как я описываю в " Принципе единой ответственности": это фундаментальная ошибка? Я могу думать о двух возможных осях изменения:

1. Изменение бизнеса
2. Технологические изменения

Сокращение бизнес-изменений до "одной причины для изменения" означает, что в бизнесе должен быть только один человек, который попросит вас изменить конкретный модуль. Например, некоторые люди, которые могут попросить об изменении, являются главой продукта или руководителем дизайна. Таким образом, это означает, что мы должны отделить, как вещь ведет себя от того, как она выглядит.

Примером технологических изменений является изменение способа хранения вещи. "Нам нужно перейти с базы данных SQL на плоскую систему хранения NoSQL".

Итак, что он делает, как он выглядит, от инфраструктуры, от которой он зависит - это то, что должно быть отделено. Не твой пёс. Принцип разделения интерфейсов приводит к тонким слоям интерфейсов, таким как лай и питание. Это позволяет вызывающим абонентам зависеть от этих тонких кусочков, а не от какого-то огромного интерфейса, такого как Animal, который имеет множество вещей, в которых он не нуждается.

Так что я бы сказал,

class Dog: Barking & Eating & Sleeping

не обязательно нарушать SRP, особенно когда каждый интерфейс тонкий.

Тем не менее, я видел, как люди соединяли несвязанные интерфейсы, чтобы создать чудовищ. Это в основном результат ленивого использования существующего класса в качестве свалки. Пока вы продолжаете спрашивать: "Можно ли это отделить?" и, видя, можете ли вы взять на себя ответственность, вы справляетесь лучше, чем большинство людей.