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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

Процитировать Капитана Барбосс:

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

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

Так ясно пираты понимают это довольно хорошо.

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

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

И "P" означает "принцип", а не "правило": D