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