Принцип единой ответственности (SRP) гласит, что у класса или модуля должна быть одна и только одна причина для изменения. Этот принцип дает нам как определение ответственности, так и руководство по размеру класса. У классов должна быть одна ответственность - одна причина для изменения.

всех сил пытаюсь понять, как Принцип Единой Ответственности может заставить меня работать с ООП.

Если мы хотим следовать принципу тройника, то разве у нас не осталось много классов, у многих из которых может быть только один метод?

Если мы не будем точно следовать принципу, то какой смысл в этом принципе?

 Mike Barlotta03 окт. 2017 г., 23:28
Вот тот, кто писал о борьбе с СРПsklivvz.com/posts/...
 Mike Barlotta03 окт. 2017 г., 23:37
точка на фундаментальном уровне поощряет написание объектов с высокой связностью (включенные «части» тесно связаны между собой)

Ответы на вопрос(1)

Решение Вопроса

щим образом: «Каждая вещь, которую вы пишете - каждый модуль, класс, интерфейс или метод должен иметьодин работа. Это должно сделатьвсе работа итолько эта работа.

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

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

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

 bic05 окт. 2017 г., 17:24
Это именно то, что меня смутило - разные размеры обязанностей на разных рабочих местах. Есть ли конкретный момент, когда вы должны прекратить разлагать обязанности или просто делать то, что кажется правильным?
 Matt Timmermans05 окт. 2017 г., 18:57
Существует компромисс: разделение работы на меньшие рабочие места облегчает понимание большой работы, но увеличивает количество рабочих мест, что может сделать систему в целом более сложной. Есть приятное место, где решение для каждой работы удобно вписывается в вашу голову, и если разбить его еще больше, с ним будет труднее работать, потому что изменения, которые вам нужно внести, будут мешать большему количеству вещей. Останавливаться на достигнутом. Это немного другое место для всех.
 EngineeredBrain09 окт. 2017 г., 20:26
Абсолютно. Я считаю, что в идеале нужно делить большие задачи на более мелкие, которые ограничивали бы каждую функцию только одной работой. Каждая работа атомарного значения логически изолированы и завершены. Это был бы идеальный сценарий, но на практике мы стараемся максимально приблизиться к этому.
 bic08 нояб. 2017 г., 17:48
@atreat Возвращаясь, чтобы сказать, что видео отличное! Хотя я наткнулся на некоторые из методов, упомянутых методом проб и ошибок, это действительно хороший ресурс для TDD и разработки в целом.
 atreat11 окт. 2017 г., 15:46
Одно из лучших упражнений на мысли, которые я делаю, чтобы помочь с этим, - попытаться предсказать, какие изменения могут произойти в системе. Затем я пытаюсь понять, как разделить обязанности, поэтому, если что-то меняется, мне не нужно реорганизовывать существующий код, но я могу удалить существующие задания и заменить их новыми, сохраняя интерфейсы между ними как можно более неповрежденными. Это напоминает мне о выступлении Джастина Сирлса на RailsConf в этом году,youtube.com/watch?v=V4fnzHxHXMI, Не все это имеет непосредственное отношение, но может помочь в принятии решений

Ваш ответ на вопрос