Принцип единой ответственности: гранулярность причины изменения

Question

При применении принципа единой ответственности и взгляде на причину изменения класса, как вы определяете, является ли эта причина слишком гранулированной или недостаточно гранулированной?

Answer 1

1. Я бы не слишком беспокоился о гранулярности изначально. Я просто пойду с разделением проблем на начальном этапе. Основным моментом является то, что мы должны избегать чрезмерного проектирования здесь. Но достаточно. Я согласен с Лукасом здесь, что этот первый шаг улучшится с опытом.
2. По мере того, как меняются требования, когда я начинаю ощущать «запахи», по мере того, как мое понимание проблемы улучшается, я реорганизую дизайн, выделяя отдельные проблемы, когда они становятся очевидными. По сути, разделение интересов также должно быть эволюционным, как и в случае общего дизайна.

Answer 2

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

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

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