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

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

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

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

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

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

Ответов (6)

Решение

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

As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.

The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.

SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.

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

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

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

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

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

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

That being said, SRP is not a rule of OOP per se, but are considered best practices to create OOP applications that are both easily extensible and unit-testable.

Both are characteristics that I consider as of utmost importance in enterprise application development, where maintenance of existing applications occupies more time than new development does.

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

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

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

Итак, пираты прекрасно это понимают.

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

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

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

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

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

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

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

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