Open Berezovskiy opened 10 years ago
SergeyTeplyakov
commented
10 years ago Саня, тут ведь разные моменты: да, SRP сводится к уменьшению числа обязанностей. Но для чего он это делает? В чем проблема, когда у класса много обзяанностей и причин для изменения? Смысл ведь как раз в том и заключается, чтобы сделать код более сопровождаемым путем его ... упрощения. Фишка борьбы со сложностью в том, что любой дизайн сводится именно к ней. Если задача не сложная, дизайн вообще не нужен!
Berezovskiy
commented
10 years ago Серег, а что если задача сложная, но не предвидит никаких изменений? В общем я хотел высказать идею, что не только борьба со сложностью, должна быть драйвером дизайна, но и некая предсказуемость/контролируемость изменений. Иногда легче понять критерии дизайна и архитектуры в терминах конкретных изменений.
SergeyTeplyakov
commented
10 years ago Ну, если код работает и в него никто никогда не собирается вносить изменения, то тогда изменения в дизайне ведь тоже не нужны.
Просто борьба со сложностью - это универсальная и самая общая штука. Если что-то простое, то изменения будут предсказуемыми и контролируемыми:)
Вот понятие сложности является неформальным. Даже "священные 7±2" четко не определены, для кого-то метод/класс будет выглядеть сложным, кому то он будет достаточно простым. Поэтому сводить принцип SRP к борьбе со сложностью, я бы не стал, потому как, теряется его первоначальная ценность заключенная в простоте оценки. Метод/класс имеет больше одной обязанности/причины для изменений? Если да, то он не соответствует SRP. Как по мне, так, вся мощь и красота SOLID принципов заключается в простоте оценки.