My<cod/>.net
Является ли принцип единой ответственности правилом ООП?
В ответе на вопрос о переполнении стека говорилось, что определенная структура нарушает простое и ясное правило OOP: принцип единой ответственности (SRP).
Действительно ли принцип единой ответственности является правилом OOP?
Мое понимание определения объектно-ориентированного программирования - это "парадигма, в которой объекты и их поведение используются для создания программного обеспечения". Это включает в себя следующие методы: инкапсуляция, полиморфизм & наследование.
Теперь не поймите меня неправильно-я считаю, что SRP является ключом к большинству хороших конструкций OO, но я чувствую, что есть случаи, когда этот принцип может и должен быть нарушен (так же, как правила нормализации базы данных). Я настойчиво продвигаю преимущества SRP, и подавляющее большинство моего кода следует этому принципу.
Но является ли это правилом и, следовательно, подразумевает, что его нельзя нарушать?
Очень мало правил, если они вообще существуют, в разработке программного обеспечения являются без исключения. Некоторые люди думают, что здесь нет места для Гото , но они ошибаются.
Что касается OOP, то здесь нет единого определения объектно-ориентированности, поэтому в зависимости от того, кого вы спросите, вы получите различный набор жестких и мягких принципов, шаблонов и практик.
Классическая идея OOP состоит в том, что сообщения посылаются другим непрозрачным объектам, и объекты интерпретируют сообщение со знанием своих собственных внутренних органов, а затем выполняют какую-то функцию.
SRP-это принцип разработки программного обеспечения, который может применяться к роли класса, функции или модуля. Он способствует сплочению чего-то так, что оно ведет себя хорошо вместе, без несвязанных кусочков, свисающих с него или имеющих несколько ролей, которые переплетаются и усложняют вещи.
Даже при наличии только одной ответственности, это все равно может варьироваться от одной функции до группы слабо связанных функций, которые являются частью общей темы. До тех пор, пока вы избегаете подтасовки какого-либо элемента, чтобы взять на себя ответственность за то, для чего он изначально не был предназначен, или делать какие-то другие специальные вещи, которые разбавляют простоту объекта, а затем нарушают любой принцип, который вы хотите.
Но я нахожу, что легче получить SRP правильно, чем сделать что-то более сложное, что так же надежно.
Ни одно из этих правил не является законом. Это скорее рекомендации и лучшие практики. Бывают моменты, когда нет смысла следовать "the rules", и вам нужно делать то, что лучше всего подходит для вашей ситуации.
Не бойтесь делать то, что вы считаете правильным. Вы могли бы на самом деле придумать новые и лучшие правила.
Цитирую капитана Барбоссу:
"..А во-вторых, вы должны быть пиратом, чтобы применять пиратский кодекс, а вы им не являетесь. И в-третьих, код-это больше то, что вы называете "guidelines", чем реальные правила...."
Процитирую Джека Воробья & Гиббса. "I thought you were supposed to keep to the code." М-р Гиббс: "мы полагали, что они были более реальными руководящими принципами. "
Так что ясно, что пираты это прекрасно понимают.
"rules" может быть понято через движение паттернов как "Forces"
Таким образом, существует сила, пытающаяся заставить класс нести единственную ответственность. (сплоченность)
Но есть также сила, пытающаяся удержать связь с другими классами вниз.
Как и во всем дизайне (а не только в коде), ответ заключается в том, что он зависит.
Ах, я думаю, это относится к тому ответу, который я дал. :)
Как и в случае с большинством правил и законов, существуют основополагающие мотивы, по которым эти правила релевантны-если основной мотив отсутствует или применим к вашему случаю, то вы вольны сгибать/нарушать правила в соответствии с вашими собственными потребностями.
Тем не менее, SRP не является правилом OOP как таковым, но считается лучшей практикой для создания OOP приложений, которые легко расширяются и поддаются модульному тестированию.
Обе эти характеристики я считаю чрезвычайно важными при разработке корпоративных приложений, где обслуживание существующих приложений занимает больше времени, чем новая разработка.
Как говорят многие другие плакаты, все правила созданы для того, чтобы их нарушать.
Тем не менее, я действительно считаю, что SRP является одним из наиболее важных правил для написания хорошего кода. Это не относится конкретно к объектно-ориентированному программированию, но "encapsulation" часть OOP очень трудно сделать правильно, если класс не несет никакой ответственности.
В конце концов, как правильно и просто инкапсулировать класс с несколькими обязанностями? Обычно ответ заключается в нескольких интерфейсах и на многих языках, которые могут помочь совсем немного, но это все еще сбивает с толку пользователей вашего класса, что он может применяться совершенно по-разному в разных ситуациях.