Single Responsibility и тупые объекты?

Question

[Владимир]

Подскажите, где проходит грань между между Single Responsibility и тупыми классами объектами у которых практически Zero responsibility. А то у нас "архитектор" опираясь на single Responsibility вырождает все в тупиц и плодит код... Абстракция и обобщение курят в сторонке

Comments

[heartdevil]

Привет. А на куски кода можно глянуть с вашими комментариями?

[AtomKrieg]

Не думаю, что есть единое мнение где проходит граница. Если архитектор упоротый устройте ему "темную". Иначе вводите метрики вроде "от 7 методов на класс только если это не паттерн "команда"". Или "до 10 классов на подсистему". Аргументация простая - мозг помнит 7+-2 обьекта в один момент времени, если больше, то идут ошибки.

Answer 1

[Oxoron]

Читай про закон Деметры. Если в проекте куча вызовов типа

SomeClass.SomeField.SomeMethodWhichReturnsOtherObject().AnyOtherField = 15;

или
a.b.c().d = e.f.h().g; - вполне возможно, в архитектуре перебор с SR.
Хотя возможна ситуация, когда архитектор пытается подготовиться ко всем возможным изменениям; SR в таком случае лишь следствие (одно из), и разумные аргументы будут лежать вне SOLID принципов.

Answer 2

[angru]

Если у класса один метод и нет состояния, то что-то не так.

Т.е. простые вещи лучше делать функциями, а если вещь простая, но ей нужно хранить состояние, то тогда уже использовать классы.

А вообще многое от языка зависит, если какой-то из динамических, то там, грубо говоря, всего два паттерна: DRY и KISS, а классы лучше как можно реже использовать.

Comments

[Viktor Vsk]

Какое отношение DRY и KISS имеют к паттернам?
И почему это в динамических языках, где и так типов нет - еще и классы нужно редко использовать?

[angru]

1. Хорошо: "принцип".
2. Для многих целей вполне себе подходят словари.