Использование принципа единой ответственности в «реальном мире»

Question

Я в основном хочу получить представление о проценте людей, которые считают разумным использовать принцип единой ответственности в реальном коде и, сколько на самом деле. В Podcast #38 Джоэл рассказывает о том, как бесполезно этот принцип ООП - это реальный мир; и далее, что это демонстрирует, как люди, подобные дяде Бобу, скорее всего, не писали нетривиальные системы.

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

Что думает сообщество?

Answer 1

У меня был некоторый опыт применения принципов SOLID, и мой опыт был в основном хорош. Я также слышал подкаст, и похоже, что ни Джефф, ни Джоэл не пробовали ни одной из вещей, о которых они говорят достаточно долго, чтобы действительно осмыслить преимущества.Главный аргумент против - это, как правило, «вы пишете больше кода». Если я посмотрю, что я делаю, я напишу 10, возможно, на 20% больше кода (обычно определения интерфейсов), но поскольку все сильно развязано, оно намного более удобно. У меня почти никогда не бывает ситуаций, когда изменения в одной части моего приложения ломают другие части. Таким образом, 20% -ный дополнительный код, который я должен поддерживать, оплачивает сам.

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

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

Answer 2

Я не читал или не слушал комментарии Джоэла, поэтому не могу комментировать их конкретно.

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

Answer 3

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

Именно поэтому АОП был задуман. Используя его, вам не нужно ничего менять, кроме классов ведения журнала, для изменения ведения журнала.

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

Я понятия не имею, если это то, что рассуждает Джоэл, но вот как я подхожу к идее.

Answer 4

В целом я согласен с принципами SOLID, но вы также должны учитывать их в контексте. Если вы пишете «Доказательство концепции», то принципы SOLID менее применимы.

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

Что касается Джоэля и его комментариев, он имеет действительную точку. Иногда продукт должен быть отправлен или компания терпит неудачу. Так оно и есть.

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

Answer 5

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

Сначала занятия были большими и делали несколько вещей. Чтобы изменить эти поведения, вам пришлось расширить эти классы. Все методы были виртуальными и не меняли состояние объекта, поэтому было довольно легко сделать это.

Но по мере того, как система росла, стало ясно, что рамки будут в конечном итоге состоять из серии монолитных объектов, каждая из которых имеет цепи наследования looooong. Это также привело к неожиданным зависимостям - абстрактному методу, берущему коллекцию класса X, чтобы создать объект Y, определенный в базовом классе, продиктовало, что EVERYBODY должен был сделать это таким образом, даже если это не имело смысла для половины дерева наследования. Это также привело к массовым классам, которые потребовали десятков единичных тестов, чтобы охватить код более чем на 80%, и сложность была такой, что вы не были уверены, правильно ли вы все охватили. Было очевидно, что этот дизайн может стать очень жестким и негибким.

Итак, мы перепроектировали все по линиям SRP. У вас будет свой интерфейс, базовый класс и, возможно, один или несколько классов реализации. Каждый из них был составлен различных объектов, которые выполняли ключевые функции всего процесса. Если вы хотите изменить одну часть, вы не переопределили метод, вы бы создали другой объект, который расширил требуемый интерфейс/базовый класс и выполнил свою работу по-разному. SRP даже сбрасывался в аргументы и возвращал значения методов класса. Для тех частей системы, которые должны быть гибкими, а не передавать коллекции класса X, которые используются для создания объектов Y, был создан класс для инкапсуляции процесса создания объектов Y. Компоненты системы затем передают этих производителей, объединяют их с другими (ответственность производителей) и в конечном итоге используют их для производства Y. Это позволило создать различные типы производителей, и все это можно было бы рассматривать точно то же самое, хотя они и делали совершенно разные вещи. Этот шаг также резко сократил базу кода каждого класса и сделал их намного проще для тестирования.

Я бы сказал, что, как новый разработчик, ОЧЕНЬ ТРУДНО разбить все до этого уровня. Вам почти нужно написать большой шар грязи, понять, как это работает, а затем перепроектировать его как несколько разных компонентов, каждый из которых несет ответственность за часть целого.

Answer 6

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

GUI вблизи классов, как правило, отражают GUI и несут единую ответственность за «быть gui для XXXX». Трусливое решение ..

Answer 7

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

Answer 8

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

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

Paul.

Answer 9

Я думаю, что принципы SOLID иногда не соответствуют естественной/бизнес-логике, которую обычно применяют при проектировании классов. Роберт К. Мартин привел пример классов Rectange и Square (квадрат не должен быть потомком Rectangle).

http://www.hanselminutes.com/default.aspx?showID=163

Я не уверен, что это было относительно SRP, но идея та же. СОВРЕМЕННЫЕ принципы могут привести к противоречивым решениям, и трудно преодолеть этот барьер.

Мне «руководящие принципы» являются более подходящим названием, чем «принципы».