Как класс может иметь несколько методов, не нарушая принцип единой ответственности

Принцип единой ответственности определяется в Википедии как

Принцип единой ответственности - это принцип компьютерного программирования, который гласит, что каждый модуль, класс или функция должны нести ответственность за одну часть функциональности, предоставляемой программным обеспечением, и эта ответственность должна быть полностью заключена в класс

Если у класса должна быть только одна ответственность, как он может иметь более одного метода? Не будет ли у каждого метода разная ответственность, что будет означать, что у класса будет более 1 ответственности.

Каждый пример, который я видел, демонстрируя принцип единственной ответственности, использует пример класса, который имеет только один метод. Это может помочь увидеть пример или получить объяснение класса с несколькими методами, которые все еще можно считать ответственными.

Единственная ответственность не может быть чем-то, что может выполнять отдельная функция.

 class Location { 
     public int getX() { 
         return x;
     } 
     public int getY() { 
         return y; 
     } 
 }

Этот класс может нарушить принцип единственной ответственности. Не потому, что он имеет две функции, а если код getX()и getY()должен удовлетворять различные заинтересованные стороны, которые могут потребовать изменения. Если вице-президент г-н Х разослает памятку о том, что все числа должны быть выражены в виде чисел с плавающей запятой, а директор по бухгалтерскому учету г-жа Y настаивает на том, чтобы все числа, которые рассматривает ее отдел, оставались целыми числами независимо от того, что г-н Х считает хорошим, тогда этот класс лучше иметь единственное представление о том, перед кем он несет ответственность, потому что все может запутаться.

Если бы следовали SRP, было бы ясно, если класс Location влияет на то, что мистер X и его группа подвергаются воздействию. Выясните, за что отвечает класс, и вы знаете, какая директива влияет на этот класс. Если они оба влияют на этот класс, тогда он плохо спроектирован, чтобы минимизировать влияние изменений. «У класса должна быть только одна причина для изменения» не означает, что весь класс может сделать только одну маленькую вещь. Это значит, что я не должен смотреть на класс и говорить, что и мистер X, и миссис Y заинтересованы в этом классе.

Кроме таких вещей. Нет, несколько методов в порядке. Просто дайте ему имя, которое прояснит, какие методы принадлежат классу, а какие нет.

SRP дяди Боба больше касается закона Конвея, чем закона Керли . Дядя Боб выступает за применение закона Керли (делать одно) для функций, а не классов. SRP предостерегает от смешения причин для изменения вместе. Закон Конвея гласит, что система будет следовать тому, как информационные потоки организации. Это приводит к следованию SRP, потому что вас не волнует то, о чем вы никогда не слышали.

«Модуль должен отвечать за одного и только одного актера»

Роберт С. Мартин - Чистая архитектура

Люди продолжают хотеть, чтобы SRP был о каждой причине, чтобы ограничить область. Есть больше причин для ограничения объема, чем SRP. Кроме того , я ограничить сферу, настаивая класс абстракция , которая может взять имя , которое гарантирует , глядя внутрь вас не удивит .

Вы можете применить закон Керли к классам. Вы вне того, о чем говорит дядя Боб, но вы можете сделать это. Когда вы ошибаетесь, вы начинаете думать, что это означает одну функцию. Это все равно что думать, что в семье должен быть только один ребенок. Наличие более одного ребенка не мешает ему быть семьей.

Если вы применяете закон Керли к классу, все в классе должно быть об одной объединяющей идее. Эта идея может быть широкой. Идея может быть постоянством. Если там есть некоторые служебные функции регистрации, то они явно неуместны. Не имеет значения, является ли мистер X единственным, кто заботится об этом коде.

Классический принцип, применяемый здесь, называется разделением интересов . Если вы разделяете все свои проблемы, можно утверждать, что то, что осталось в каком-то одном месте, является одной проблемой. Это то, что мы называли этой идеей до того, как фильм 1991 года «Городские пижоны» познакомил нас с персонажем Керли.

Это отлично. Просто то, что дядя Боб называет ответственностью, не является проблемой. Ответственность перед ним - это не то, на чем вы сосредоточены. Это то, что может заставить вас измениться. Вы можете сосредоточиться на одной проблеме и по-прежнему создавать код, который отвечает за разные группы людей с разными повестками дня.

Может быть, вы не заботитесь об этом. Хорошо. Мысль о том, что удержание «сделать что-то» решит все ваши проблемы с дизайном, демонстрирует недостаток фантазии о том, чем может быть «одна вещь». Другая причина ограничить сферу - организация. Вы можете вкладывать много «одного» в другое «одно», пока у вас не появится ящик для мусора, полный всего. Я говорил об этом раньше

Конечно, классическая причина ООП для ограничения области действия состоит в том, что у класса есть закрытые поля, и вместо того, чтобы использовать геттеры для совместного использования этих данных, мы помещаем каждый метод, которому нужны эти данные, в класс, где они могут использовать эти данные конфиденциально. Многие считают это слишком ограничительным для использования в качестве ограничителя области, потому что не каждый метод, который принадлежит друг другу, использует абсолютно одинаковые поля. Мне нравится следить за тем, чтобы любая идея, которая объединила данные, была той же идеей, что и методы.

Функциональный способ смотреть на это , что a.f(x)и a.g(x)просто е _с (х) и г (х). Не две функции, а континуум пар функций, которые изменяются вместе. Даже не иметь в нем данные. Это может быть просто , как вы знаете , какие и реализации вы собираетесь использовать. Функции, которые меняются вместе, принадлежат друг другу. Это старый добрый полиморфизм.afg

SRP - только одна из многих причин ограничить область применения. Это хорошо. Но не единственный.

Ключевым моментом здесь является объем или, если вы предпочитаете, гранулярность . Часть функциональности, представленная классом, может быть дополнительно разделена на части функциональности, каждая из которых является методом.

Вот пример. Представьте, что вам нужно создать CSV из последовательности. Если вы хотите быть совместимым с RFC 4180, для реализации алгоритма и обработки всех крайних случаев потребуется довольно много времени.

Выполнение этого в одном методе привело бы к коду, который не будет особенно читабельным, и особенно, метод будет делать несколько вещей одновременно. Поэтому вы разделите его на несколько методов; например, один из них может отвечать за генерацию заголовка, то есть самой первой строки CSV, тогда как другой метод преобразует значение любого типа в его строковое представление, подходящее для формата CSV, тогда как другой будет определять, является ли значение должно быть заключено в двойные кавычки.

Эти методы имеют свою ответственность. Метод, который проверяет, есть ли необходимость добавлять двойные кавычки или нет, имеет свой собственный, и метод, который генерирует заголовок, имеет один. Это SRP применяется к методам .

Теперь все эти методы имеют одну общую цель: взять последовательность и создать CSV. Это единственная ответственность класса .

Пабло Н прокомментировал:

Хороший пример, но я чувствую, что он все еще не отвечает, почему SRP позволяет классу иметь более одного открытого метода.

На самом деле. Пример CSV, который я привел, имеет в идеале один публичный метод, а все остальные методы являются частными. Лучшим примером будет очередь, реализованная Queueклассом. Этот класс будет содержать, в основном, два метода: push(также называемый enqueue) и pop(также вызываемый dequeue).

• Ответственность Queue.pushзаключается в добавлении объекта в хвост очереди.

• Ответственность Queue.popзаключается в том, чтобы удалить объект из головы очереди и обработать случай, когда очередь пуста.

• Ответственность Queueкласса заключается в предоставлении логики очереди.

Функция есть функция.

Ответственность есть ответственность.

Механик несет ответственность за починку автомобилей, что включает диагностику, некоторые простые задачи по техническому обслуживанию, некоторые фактические ремонтные работы, некоторые делегирование задач другим и т. Д.

Контейнерный класс (список, массив, словарь, карта и т. Д.) Отвечает за хранение объектов, что включает их хранение, возможность вставки, предоставления доступа, некоторый порядок упорядочения и т. Д.

Отдельная ответственность не означает, что кода / функциональности очень мало, это означает, что любая имеющаяся функциональность «принадлежит вместе» под одной и той же ответственностью.

Отдельная ответственность не обязательно означает, что она делает только одно.

Возьмем, например, класс обслуживания пользователя:

class UserService {
    public User Get(int id) { /* ... */ }
    public User[] List() { /* ... */ }

    public bool Create(User u) { /* ... */ }
    public bool Exists(int id) { /* ... */ }
    public bool Update(User u) { /* ... */ }
}

Этот класс имеет несколько методов, но его ответственность ясна. Предоставляет доступ к пользовательским записям в хранилище данных. Его единственными зависимостями являются модель User и хранилище данных. Он слабо связан и очень сплочен, и это действительно то, о чем SRP пытается заставить вас задуматься.

SRP не следует путать с «принципом разделения интерфейса» (см. SOLID ). Принцип сегрегации интерфейса (ISP) говорит, что меньшие, легкие интерфейсы предпочтительнее, чем большие, более обобщенные интерфейсы. Go широко использует ISP в своей стандартной библиотеке:

// Interface to read bytes from a stream
type Reader interface {
    Read(p []byte) (n int, err error)
}

// Interface to write bytes to a stream
type Writer interface {
    Write(p []byte) (n int, err error)
}

// Interface to convert an object into JSON
type Marshaler interface {
    MarshalJSON() ([]byte, error)
}

SRP и ISP, безусловно, связаны между собой, но одно не подразумевает другого. Интернет-провайдер находится на уровне интерфейса, а SRP - на уровне класса. Если класс реализует несколько простых интерфейсов, он может перестать иметь только одну ответственность.

Спасибо Луаану за то, что он указал на разницу между ISP и SRP.

В ресторане есть шеф-повар. Его единственная обязанность - готовить. Тем не менее, он может готовить стейки, картофель, брокколи и сотни других вещей. Вы бы наняли одного шеф-повара на блюдо в вашем меню? Или один шеф-повар для каждого компонента каждого блюда? Или один повар, который может выполнить свою единственную обязанность: готовить?

Если вы попросите этого повара также выполнить платежную ведомость, тогда вы нарушите SRP.

Контрпример: хранение изменяемого состояния.

Предположим, у вас был самый простой класс, чья единственная работа - хранить int.

public class State {
    private int i;


    public State(int i) { this.i = i; }
}

Если вы ограничены только одним методом, вы можете использовать либо a setState(), либо a getState(), если вы не нарушите инкапсуляцию и не сделаете iобщедоступным.

• Установщик бесполезен без получателя (вы никогда не сможете прочитать информацию)
• Получатель бесполезен без установщика (вы никогда не можете изменить информацию).

Очевидно, что эта единственная ответственность требует наличия как минимум двух методов для этого класса. QED.

Вы неверно истолковываете принцип единственной ответственности.

Единственная ответственность не равняется единственному методу. Они имеют в виду разные вещи. В разработке программного обеспечения мы говорим о сплоченности . Функции (методы), которые имеют высокую степень сцепления, «принадлежат» друг другу и могут рассматриваться как выполняющие одну ответственность.

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

Часто полезно (на любом языке, но особенно на ОО-языках) смотреть на вещи и упорядочивать их с точки зрения данных, а не функций.

Таким образом, рассмотрим ответственность класса за поддержание целостности и предоставление помощи в правильном использовании данных, которыми он владеет. Очевидно, что это легче сделать, если весь код находится в одном классе, а не распределен по нескольким классам. Добавление двух пунктов выполняется более надежно, и код легче поддерживать с помощью Point add(Point p)метода в Pointклассе, чем в другом месте.

И, в частности, класс не должен предоставлять ничего, что могло бы привести к противоречивым или неправильным данным. Например, если a Pointдолжно лежать в плоскости (0,0) - (127,127), конструктор и любые методы, которые модифицируют или производят новое, Pointнесут ответственность за проверку заданных им значений и отклонение любых изменений, которые нарушают это. требование. (Часто что-то вроде a Pointбудет неизменным, и обеспечение того, что нет никаких способов изменить a Pointпосле его создания, также будет ответственностью класса)

Обратите внимание, что расслоение здесь вполне приемлемо. У вас может быть Pointкласс для работы с отдельными точками и Polygonкласс для работы с набором Points; у них все еще есть отдельные обязанности, потому что Polygonделегирует всю ответственность за то, чтобы иметь дело с чем-либо, имеющим исключительно отношение к классу Point(например, обеспечение точки имеет xи yзначение, и ценность) Point.