Поддерживаемость кода можно косвенно представить как время, требуемое для понимания кода. Чем больше времени уходит на понимание того, что делает код, тем ниже его “поддерживаемость” (см. Две ценности ПО - поведение и структура, внутренняя оценка качества кода программистами).
В связи с этим возникает некоторая субъективность в оценке качества кода, потому что в команде “процедурных” программистов время на понимание императивного процедурного кода будет скорее всего меньше, чем на понимание объектно-ориентированного. Таким образом, для этой команды процедурный код лучше объектного. Более того, весьма вероятно, что в такой команде и время на написание прямолинейного процедурного кода будет меньше, и качество такого кода будет выше, чем попытки изобразить что-то в объектно-ориентированной парадигме.
- ЕТ
1. Рождение объекта
Объекты можно рассматривать как живые организмы, каждый со своей средой обитания (областью видимости).
1.1 Не используйте имена классов, оканчивающиеся на -er / -or
Суть в том, что классы, которым их клиенты явно указывают выполнить такую-то операцию, живут в “процедурном мире”, а не в объектно-ориентированном. По сути, для декларативного ООП характерны запросы на получение какого-то результата (в виде объекта), а не на выполнение операции. Тот факт, что результат получается в ходе операции, сокрыт в объекте, возвращающем результат. Поэтому рекомендуется называть классы в соответствии с получаемым результатом, а не с выполняемой операцией.
Более того, имена типа Manager говорят о том, что управляемые сущности - это
простые структуры данных, а Manager - это “умная” процедура, выполняющая
реальную работу. Это процедурный, а не ООП подход.