Является ли принцип единой ответственности правилом ООП?[закрыто]

Question

Ан ответ на вопрос о переполнении стека указывалось, что конкретный фреймворк нарушает простое правило ООП:Принцип единой ответственности (SRP).

Является Принципом Единой ответственности в самом деле правило ООП?

Мое понимание определения объектно-ориентированного программирования - это "парадигма, в которой объекты и их поведение используются для создания программного обеспечения".Это включает в себя следующие методы:Инкапсуляция, полиморфизм и наследование.

Теперь не поймите меня неправильно - я считаю, что SRP является ключом к большинству хороших OO-проектов, но я чувствую, что есть случаи, когда этот принцип можно и нужно нарушать (точно так же, как правила нормализации базы данных).Я настойчиво продвигаю преимущества SRP, и подавляющее большинство моего кода следует этому принципу.

Но является ли это правилом и, следовательно, подразумевает, что его не следует нарушать?

Answer 1

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

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

Классическая идея ООП заключается в том, что сообщения отправляются непрозрачным объектам, и объекты интерпретируют сообщение, зная о своих собственных внутренностях, а затем выполняют какую-то функцию.

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

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

Но я нахожу, что проще корректировать SRP, чем делать что-то более сложное, столь же надежное.

Answer 2

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

Не бойтесь делать то, что вы считаете правильным.Возможно, вы действительно придумаете новые и лучшие правила.

Answer 3

Процитирую капитана Барбоссу:

-...А во-вторых, ты должен быть пиратом, чтобы действовал пиратский кодекс, а ты им не являешься.И в-третьих, код - это скорее то, что вы бы назвали "руководящими принципами", чем фактические правила ...."

Процитирую Джека Воробья и Гиббса."Я думал, ты должен был придерживаться кодекса". МистерГиббс:"Мы решили, что это более актуальные рекомендации."

Очевидно, что пираты это прекрасно понимают.

"Правила" могут быть поняты через движение паттернов как "Силы".

Таким образом, существует сила, пытающаяся возложить на класс единую ответственность.(сплоченность)

Но есть также сила, пытающаяся снизить связь с другими классами.

Как и во всем дизайне (а не только в коде), ответ заключается в том, что это зависит.

Answer 4

Ах, я думаю, это относится к ответу, который я дал.:)

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

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

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

Answer 5

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

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

Answer 6

SRP - это просто еще одно выражение ISP :-) .

И буква "Р" означает "принцип", а не "правило" :D