Поддерживаемость кода можно косвенно представить как время, требуемое для понимания кода. Чем больше времени уходит на понимание того, что делает код, тем ниже его “поддерживаемость” (см. Две ценности ПО - поведение и структура, внутренняя оценка качества кода программистами).

В связи с этим возникает некоторая субъективность в оценке качества кода, потому что в команде “процедурных” программистов время на понимание императивного процедурного кода будет скорее всего меньше, чем на понимание объектно-ориентированного. Таким образом, для этой команды процедурный код лучше объектного. Более того, весьма вероятно, что в такой команде и время на написание прямолинейного процедурного кода будет меньше, и качество такого кода будет выше, чем попытки изобразить что-то в объектно-ориентированной парадигме.

• ЕТ

1. Рождение объекта

Объекты можно рассматривать как живые организмы, каждый со своей средой обитания (областью видимости).

1.1 Не используйте имена классов, оканчивающиеся на -er / -or

Суть в том, что классы, которым их клиенты явно указывают выполнить такую-то операцию, живут в “процедурном мире”, а не в объектно-ориентированном. По сути, для декларативного ООП характерны запросы на получение какого-то результата (в виде объекта), а не на выполнение операции. Тот факт, что результат получается в ходе операции, сокрыт в объекте, возвращающем результат. Поэтому рекомендуется называть классы в соответствии с получаемым результатом, а не с выполняемой операцией.

Более того, имена типа Manager говорят о том, что управляемые сущности - это простые структуры данных, а Manager - это “умная” процедура, выполняющая реальную работу. Это процедурный, а не ООП подход.