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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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