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

В ответе на вопрос переполнения стека говорится, что конкретная структура нарушает простое и простое правило ООП: принцип единой ответственности (SRP).

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

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

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

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

21 oop
19.08.2008 00:11:00
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что это так.
Luuklag 13.11.2018 19:20:05
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

Но я считаю, что легче получить правильный SRP, чем сделать что-то более сложное, столь же надежное.

22
19.08.2008 00:32:41
«Проблема», которую я пытаюсь решить в отношении СРП, заключается в том, «сколько стоит далеко»? Вы можете довести его до смешного уровня, и при этом генерировать сотни классов для каждой сущности.
Prisoner ZERO 26.05.2011 12:51:41
@ ЗАКОНЧЕННЫЙ НОЛЬ: прочитайте ответ на этот вопрос: « Как ты определишь, как грубый или мелкозернистый-ответственность-должно-быть-когда-то», когда он делает хорошее замечание.
User 22.07.2011 23:34:07

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

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

5
19.08.2008 01:19:32

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

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

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

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

1
19.08.2008 01:53:07
(Правка - перенесено из «ответа» в «комментарий») Действительно, Джон, ваш ответ в другой ветке действительно вызвал этот вопрос. Формулировка ответа (умышленная или нет) вызвала в моей голове довольно интересную мысль. Когда я нажимал «SRP» на своем рабочем месте, я задумался на более глубоком уровне, как я должен формулировать такие вещи. Отсюда и этот вопрос. Спасибо за запуск такой интересной для меня мысли. :-)
Brad Leach 30.04.2009 03:41:11

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

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

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

Пираты ясно понимают это очень хорошо.

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

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

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

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

5
5.09.2008 07:43:48

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

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

0
25.11.2008 09:39:52

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

И «Р» означает «принцип», а не «правило»: D

-1
25.11.2008 14:48:26