Есть ли какая-либо стратегия разделения ответственности для применения SRP?

Question

Есть ли какая-либо стратегия разделения классов для применения принципа единой ответственности?

В команде среднего размера мы разрабатываем переносное приложение-менеджер, которое может подключаться к различным типам носимых устройств, скажем, Wearable1 а также Wearable2(одно соединение за раз). Каждое носимое устройство имеет разные типы возможностей для обмена данными. Поэтому я решил разделить ответственность по типам носимых устройств. т.е.

interface Manager {
    // common functionalities
}

class Wearable1manager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable1 related capabilities
}

class Wearable2manager implements Manager {
    // Manages wearable2 specific functionalities
    // as well as wearable2 related capabilities
}

Один из моих коллег отрицает мой дизайн, говоря, что он нарушает Single Responsibility Principle(SRP), потому что функции, связанные с возможностями, должны обрабатываться единым диспетчером возможностей. Его предложение похоже,

interface Manager {
    // common functionalities
}

class WearableManager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable2 specific functionalities
}

class CapabilityManager implements Manager {
    // Manages wearable1 related capabilities
    // as well as wearable2 related capabilities
}

По сути, я обнаружил, что мы оба делаем упор на применение принципа единой ответственности, но наша мысль о разделении ответственности основана на разных аспектах. Я часто попадаю в такую ​​критическую ситуацию, когда мне нужно решить, на основании какой ответственности я должен разделить классы. Итак, мой вопрос:

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

Answer 1

Определение принципа единственной ответственности:

Принцип единой ответственности - это принцип компьютерного программирования, который гласит, что каждый модуль, класс или функция [1] должен нести ответственность за отдельную часть функциональности, предоставляемой программным обеспечением, и эта ответственность должна быть полностью инкапсулирована классом, модулем или функция. Все его услуги должны строго соответствовать этой ответственности. Роберт С. Мартин выражает этот принцип следующим образом: "У класса должна быть только одна причина для изменения"[1], хотя из-за путаницы вокруг слова "причина" он недавно заявил: "Этот принцип касается людей.(Актер)". [2]

Как мы видим, у нас есть определение ответственности в приведенном выше определении, давайте сформулируем его словами:

Ответственность приравнивается к логически связанной части функции, обеспечиваемой программным обеспечением.

Итак, если у вас есть функции, связанные с возможностями, вы должны реализовать их внутри одного класса / модуля, следовательно, ваш коллега прав, ваш исходный код делит реализацию возможностей на два разных класса Wearable Manager, что нарушает принцип, потому что возможности -связанная функциональность - это ответственность.

Тем не менее, вы также можете сказать, что разные носимые устройства управления имеют разные возможности. Чтобы справиться с этим, вам понадобится атрибут для экземпляров носимого менеджера, который будет определять, какими возможностями он обладает. Это может быть массив, String или даже экземпляр третьего менеджера, работающего с возможностями носимых устройств, поскольку вы можете определить связь между возможностями и носимыми устройствами как отдельную ответственность.

SRP зависит от ваших обязанностей. Вам необходимо определить, каковы обязанности в вашем случае. Для этого вам необходимо разделить свои функциональные возможности на логически связанные разделы (обязанности), и оттуда все встанет на свои места. Однако, если вы и ваш коллега выполнили разное разделение, тогда у вас двоих в уме разные сущности ответственности, и было бы разумно обсудить это.

Очевидно, что ответственность как понятие можно определить, однако определение ваших обязанностей - это ваша работа и работа ваших коллег. Чем больше опыта и понимания проблемы, тем лучше будут перегородки.

Answer 2

Нет определения "ответственности". Как следствие, такой стратегии нет. Однако есть: 1) едва ли можно определить здравый смысл, 2) чувство контекста, в котором вы работаете.

Согласно моему личному опыту, правильный вопрос - "зачем мне вообще нужно менять этот код?". Если есть более одной (деловой?) Причины, это побуждает думать больше.