Используя Единственный Принцип Ответственности в [закрытом] “реальном мире”

Передача анонимного метода в фильтр javascript, который возвращает метод true или false, позволяет уменьшить объект за один раз:

var done = new Set()
transactions.filter(obj => {
  if (!done.has(obj.id)) {
    done.add(obj.id)
    return true
  } else {
    return false
  }
})
19
задан Dave Schweisguth 6 September 2014 в 13:30
поделиться

9 ответов

У меня был некоторый опыт при применении ТЕЛО , принципы и мой опыт были главным образом хороши. Я также слышал подкаст, и он не походит ни на Jeff, ни на Joel, попробовал любую из вещей, о которых они говорят достаточно долго действительно задницам преимущества. Основной аргумент против как обычно, "Вы пишете больше кода". Если я смотрю на то, что я делаю я пишу 10, возможно, на 20% больше кода (обычно интерфейсные определения), но потому что все высоко отделяется, это намного более удобно в сопровождении. У меня почти никогда нет ситуаций, где изменения в одной части моего приложения повреждают другие части. Так 20%-й дополнительный код я должен поддержать платежи за себя.

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

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

25
ответ дан 30 November 2019 в 02:48
поделиться

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

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

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

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

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

8
ответ дан 30 November 2019 в 02:48
поделиться

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

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

4
ответ дан 30 November 2019 в 02:48
поделиться

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

Поэтому AOP был задуман. Используя его Вы ничего не должны изменять кроме регистрирующихся классов для изменения входа.

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

я понятия не имею, является ли это, каково обоснование Joel, но это - то, как я приблизился бы к идее.

4
ответ дан 30 November 2019 в 02:48
поделиться

Я думаю, что ТВЕРДЫЕ принципы иногда не выполняют естественный / бизнес-логика, которую каждый обычно применяет при разработке классов. Robert C. Martin поднял пример классов Rectange и Square (Квадрат не должен быть потомком Прямоугольника).

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

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

мне 'инструкции' более соответствующее имя, чем 'принципы'.

1
ответ дан 30 November 2019 в 02:48
поделиться

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

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

Paul.

4
ответ дан 30 November 2019 в 02:48
поделиться

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

1
ответ дан 30 November 2019 в 02:48
поделиться

В целом я соглашаюсь с ТВЕРДЫМИ принципами, но также необходимо взять их в контекст. Если Вы пишете Подтверждение концепции, то ТВЕРДЫЕ принципы менее применимы.

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

В отношении Joel и его комментариев, у него есть актуальный вопрос. Иногда продукт должен поставляться или сбои компании. Это - просто способ, которым это.

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

0
ответ дан 30 November 2019 в 02:48
поделиться

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

GUI около классов имеют тенденцию отражать GUI и нести единственную ответственность "того, чтобы быть gui для XXXX". Решение труса..

0
ответ дан 30 November 2019 в 02:48
поделиться