Единственная ответственность не может быть чем-то, что может выполнять отдельная функция.
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 - только одна из многих причин ограничить область применения. Это хорошо. Но не единственный.