DesignPatternsBook
DesignPatternsBook copied to clipboard
SergeyTeplyakov
[Part2, Ch1] SRP & complexity
Принцип единой обязанности (SRP - The Single Responsibility Principle: у класса/модуля должна быть лишь одна причина для изменения. Данный принцип говорит о борьбе с изменениями, но на самом деле суть его сводится к борьбе со сложностью (tackling the complexity).
Вот понятие сложности является неформальным. Даже "священные 7±2" четко не определены, для кого-то метод/класс будет выглядеть сложным, кому то он будет достаточно простым. Поэтому сводить принцип SRP к борьбе со сложностью, я бы не стал, потому как, теряется его первоначальная ценность заключенная в простоте оценки. Метод/класс имеет больше одной обязанности/причины для изменений? Если да, то он не соответствует SRP. Как по мне, так, вся мощь и красота SOLID принципов заключается в простоте оценки.
Саня, тут ведь разные моменты: да, SRP сводится к уменьшению числа обязанностей. Но для чего он это делает? В чем проблема, когда у класса много обзяанностей и причин для изменения? Смысл ведь как раз в том и заключается, чтобы сделать код более сопровождаемым путем его ... упрощения. Фишка борьбы со сложностью в том, что любой дизайн сводится именно к ней. Если задача не сложная, дизайн вообще не нужен!
Серег, а что если задача сложная, но не предвидит никаких изменений? В общем я хотел высказать идею, что не только борьба со сложностью, должна быть драйвером дизайна, но и некая предсказуемость/контролируемость изменений. Иногда легче понять критерии дизайна и архитектуры в терминах конкретных изменений.
Ну, если код работает и в него никто никогда не собирается вносить изменения, то тогда изменения в дизайне ведь тоже не нужны.
Просто борьба со сложностью - это универсальная и самая общая штука. Если что-то простое, то изменения будут предсказуемыми и контролируемыми:)