Как не нарушать принцип единой ответственности? - PullRequest
Новая
       51

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

0 голосов
/ 04 декабря 2018

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

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

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

1 Ответ

0 голосов
/ 03 февраля 2019

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

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

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

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

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

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

class Dog: Barking & Eating & Sleeping

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

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

...