В ответе на вопрос переполнения стека говорится, что конкретная структура нарушает простое и простое правило ООП: принцип единой ответственности (SRP).
Является ли принцип единой ответственности действительно правилом ООП?
Мое понимание определения объектно-ориентированного программирования - «парадигма, в которой объекты и их поведение используются для создания программного обеспечения». Это включает в себя следующие методы: инкапсуляция, полиморфизм и наследование.
Не поймите меня неправильно - я считаю, что SRP является ключом к большинству хороших проектов ОО, но я чувствую, что есть случаи, когда этот принцип можно и нужно нарушать (как правила нормализации базы данных). Я настойчиво использую преимущества SRP, и большая часть моего кода следует этому принципу.
Но является ли это правилом и, следовательно, подразумевает, что оно не должно быть нарушено?
Очень немногие правила, если таковые имеются, в разработке программного обеспечения без исключения. Некоторые люди думают, что нет места для goto, но они ошибаются.
Что касается ООП, то здесь нет единого определения объектно-ориентированного подхода, поэтому в зависимости от того, кого вы спросите, вы получите различный набор жестких и мягких принципов, шаблонов и практик.
Классическая идея ООП состоит в том, что сообщения отправляются непрозрачным в противном случае объектам, и объекты интерпретируют сообщение со знанием своих собственных внутренних функций, а затем выполняют какую-то функцию.
SRP - это принцип разработки программного обеспечения, который может применяться к роли класса, или функции, или модуля. Это способствует сплоченности чего-либо, так что оно ведет себя хорошо вместе, без каких-либо связанных с ним кусочков или с несколькими ролями, которые переплетаются и усложняют вещи.
Даже с одной ответственностью, она может варьироваться от одной функции до группы слабо связанных функций, которые являются частью общей темы. Пока вы избегаете фальсификации присяжных элементов, чтобы взять на себя ответственность за что-то, для чего он изначально не предназначен, или делать какие-то другие специальные вещи, которые ослабляют простоту объекта, а затем нарушаете любой принцип, который вы хотите.
Но я считаю, что легче получить правильный SRP, чем сделать что-то более сложное, столь же надежное.
Ни одно из этих правил не является законом. Это больше рекомендаций и лучших практик. Есть моменты, когда не имеет смысла следовать «правилам», и вам нужно делать то, что лучше для вашей ситуации.
Не бойтесь делать то, что считаете правильным. Вы могли бы на самом деле придумать новые и лучшие правила.
Ах, я думаю, это относится к ответу, который я дал. :)
Как и в большинстве правил и законов, существуют основополагающие мотивы, по которым эти правила применимы - если базовый мотив не присутствует или не применим к вашему делу, вы можете изменить или нарушить правила в соответствии с вашими потребностями.
Тем не менее, SRP не является правилом ООП как таковым, но считается наилучшей практикой для создания ООП-приложений, которые легко расширяются и тестируются модулем.
Обе эти характеристики я считаю крайне важными в разработке корпоративных приложений, где обслуживание существующих приложений занимает больше времени, чем новая разработка.
Процитирую капитана Барбоссу:
«И, во-вторых, вы должны быть пиратом для применения кода пирата, и это не так. И в-третьих, код - это больше, чем вы бы назвали« руководящие принципы », чем настоящие правила…»
По словам Джека Воробья и Гиббса. «Я думал, что вы должны соблюдать код». Мистер Гиббс: «Мы полагали, что они были более актуальными рекомендациями».
Пираты ясно понимают это очень хорошо.
«Правила» могут быть поняты через движение моделей как «Силы».
Таким образом, есть сила, которая пытается заставить класс нести единственную ответственность. (Когезия)
Но есть также сила, пытающаяся подавить связь с другими классами.
Как и во всем дизайне (не только код), ответ заключается в том, что это зависит.
Как говорилось во многих других постерах, все правила созданы для того, чтобы их нарушать.
При этом я считаю, что SRP является одним из наиболее важных правил написания хорошего кода. Он не специфичен для объектно-ориентированного программирования, но часть «инкапсуляции» ООП очень трудно сделать правильно, если у класса нет единой ответственности.
В конце концов, как вы правильно и просто инкапсулируете класс с множеством обязанностей? Обычно ответ заключается в нескольких интерфейсах и во многих языках, которые могут помочь совсем немного, но пользователи вашего класса все еще смущают, что они могут применяться совершенно по-разному в разных ситуациях.
SRP - это еще одно выражение ISP :-).
И «Р» означает «принцип», а не «правило»: D