Что дядя Боб подразумевает под «именами именных»?

Я читаю Чистый код от дяди Боба. Поскольку я не являюсь носителем английского языка, я не мог понять следующее утверждение:

Классы и объекты должны иметь существительное или словосочетание имена , как Customer, WikiPage, Accountи AddressParser. Избегайте таких слов , как Manager, Processor, Dataили Infoво имя класса. Имя класса не должно быть глаголом.

Как я не знаю, ни один из Manager, Processor, Data, и Infoэто глагол, не так ли? Какой факт он хочет подчеркнуть?

— mmdemirbas
источник

возможно, дядя Боб принимает RESTful мышление, чтобы превозносить достоинства ресурсов как объектов.

— Rwong

Ответы:

Три пункта являются отдельными:

Имена классов должны быть существительными или именными фразами . Это означает, что имя класса должно быть чем-то, что будет предметом глагола. В случае объектно-ориентированного проектирования методы - это глаголы, которые имеют место в том, что представляет собой класс.
Некоторые слова следует избегать. Managerуказывает на возможный класс бога . Infoи Dataможет указывать на фиктивный контейнер данных. Такие слова могут указывать на плохое моделирование проблемного пространства.
Глаголы никогда не должны быть именами классов. Смотрите первый пункт - классы моделируют вещи, методы моделируют действия.

— Томас Оуэнс
источник

Такие слова могут указывать на плохое моделирование проблемного пространства. - Ну, можно подумать, что проблемное пространство моделируется плохо или нет, независимо от выбранных имен. Хорошее имя не помогает плохому дизайну; и хороший дизайн только незначительно поврежден плохим именем.

— Инго

И вы могли бы сделать это на шаг ниже, рассматривая, как вы на самом деле строите свой класс и как он взаимодействует с внешним миром - свойства класса, как правило, будут существительными, в то время как методы класса, как правило, будут глаголами

— PeteH

Если в вашем проекте есть класс, который вы бы назвали «Менеджером», «Инфо» или «Данными», то он, вероятно, имеет дюжину таких классов, что означает, что вы не будете использовать эти имена. Вы бы имели ThisManager и ThatManager и AnotherManger и так далее.

— gnasher729

Он говорит, что глаголы никогда не должны быть в именах классов, но я просто перечитывал Добавление значимого контекста, и в своем примере на странице 29 он называет класс GuessStatisticMessage. Теперь я запутался в правиле, потому что я интерпретирую его использование Guess как глагол, а не существительное. dictionary.com/browse/guess?s=t

— Девин Глисон Ламберт

@DevinGleasonLambert Но это не думаю. Это догадывающееся статистическое сообщение. Сообщение является существительным. Guess Statistic просто описывает тип сообщения, которое оно представляет, - сообщения о статистике догадок.

— Томас Оуэнс

Он пытается провести различие между вещами (существительными) и действиями (глаголами). В традиционном объектно-ориентированном дизайне мы рассматриваем классы как вещи, а их методы - как действия, которые эти вещи могут выполнять. Для того, чтобы управлять , чтобы заботиться о или координировать, в то время как менеджер это человек или вещь , которая управляет.

Вступительные книги обычно сводят это к самым простым и очевидным терминам, таким как класс с именем Dog , с методами Bark и Bite . В классах реального мира различие часто немного более тонкое, но оно все еще там. Я полагаю, что смысл, который делает дядя Боб, заключается в том, что хотя менеджер является существительным, но он уделяет большое внимание тому, что делает менеджер, а не тому, чем он является - это слишком расплывчатое слово для описания того, что именно быть управляемым или как.

— PSWG
источник

К сожалению, такое мышление может привести к неправильному замыслу. Одним из главных примеров является классический вводный пример банковского счета. Практически во всех ОО учебниках Accountесть объект, balanceполе и transferметод. Но правильный дизайн будет таким: Transferэто объект, accountполе и balanceметод. Вот как на самом деле внедряются банковские системы и как на самом деле работали банковские системы до компьютеров.

— Йорг Миттаг

@ JörgWMittag: эта поучительная история стоит того, чтобы ее опубликовать в качестве ответа; что это общие рекомендации, и в некоторых редких случаях они могут привести к плохому разложению.

— smci