2009-02-18 13 views
27

В своем опыте, каковы некоторые «вонючие» ключевые слова в именах классов или функций, которые могут быть предупреждением о плохом объектно-ориентированном дизайне?Злые названия классов?

Я обнаружил, что классы, содержащие слово Manager или Base, часто являются подозреваемыми. Например, FooManger часто указывает на плохое инкапсулирование или одноэлементный дизайн, который трудно повторно использовать.

A FooBase класс обычно является абстрактным базовым классом, который, как ожидается, не будет напрямую привязан к коду вызывающего абонента. Он используется только для обмена некоторой реализацией кода без истинного отношения IS-A. И имя класса Base раскрывает внутренние детали реализации и не отражает объект «реального мира» в модели домена.

Функции, которые включают в себя слово And или Or (например DoThisAndThat() или DoThisOrThat()) вонючий. Вероятно, функция не хватает сплоченности и пытается сделать слишком много. И имя раскрывает детали внутренней реализации.

+1

Для базовых классов у вас есть проблема только с словом Base в названии или понятие абстрактных базовых классов в целом? Вы говорите, что «никогда не ожидали, что вы будете напрямую ссылаться на код вызывающего абонента», но его можно использовать, вызывая код так же, как используется интерфейс. – Davy8

+0

-1. Я согласен с вами в вопросе наименования функций, но что, если у меня есть пользовательский элемент управления, который просто координирует взаимодействие между некоторыми дочерними элементами управления? Разве это не кандидат на имя класса, включая «менеджер»? И я сразу знаю, что такое класс, если его имя заканчивается «Базой». –

+1

Чтобы быть справедливым, он сказал, что классы, содержащие «Менеджер» или «База», являются НЕЗАВИСИМЫМИ подозреваемыми, а не всегда. Я также считаю, что это верно на протяжении многих лет. – markh44

ответ

15

Я нашел, что это будет полезно одно:

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

(От Clean Code Роберт Мартин, p25)

+6

Я (ИМХО) не согласен с разочарованием суффикса менеджера. Это существительное, которое удовлетворяет первой части цитаты. Возьмите пример HardCode ConfigurationManager. Я не могу придумать подходящую замену, которая не звучит ухищренно и неудобно.(Я согласен повторно: данные, информация и т. Д.) – JMD

+7

Имена имеют значение. Имя вашего класса должно не только указывать вам, что делает класс, но и то, что он не делает. Использование слова «Менеджер» не ограничивает того, что может сделать класс. Это затрудняет понимание дизайна и обычно приводит к процедурным стилям кодирования, которые заражают остальную часть системы. – Dunk

+1

Иногда ушло какое-то время, чтобы придумать хорошее имя, но я не могу вспомнить в любое время, что я не придумал лучшего имени и дизайна, как только я избавился от слова Manager от имени класса. – Dunk

7

Я не согласен с вами по вопросу Base. Например, в ASP.NET (как WebForms, так и MVC) это совсем не редкость с базовыми классами для множества разных вещей - наиболее распространенное использование, которое я видел, - это методы, которые вы хотите запускать каждый раз, когда страница загружается или каждый раз, когда загружается конкретная группа страниц. Затем вы создаете класс PageBase, который наследует от System.Web.UI.Page, содержащий метод, который вы хотите скопировать, и сделайте все страницы, которые вы хотите запустить, наследуете ваш PageBase вместо стандартного . Это не обязательно плохой дизайн - это один из многих инструментов, чтобы попытаться следовать СУХОЙ принцип ("Не повторяйте Yourself)

+5

Я бы сделал Страница в качестве имени класса в в этом случае; вы специализируетесь на странице, для данного проекта. «PageBase» будет базовым классом UNDER «Страница». – mjfgates

14

Цитирую Роуди Грина How To Write Unmaintainable Code:.

Be Аннотация

называя функции и переменные, широко используют абстрактные слова, как это, все данные, обрабатывать, материал, делать, рутинных, выполнять и цифры например routineX48, PerformDataFunction, DoIt, HandleStuff и doargs_method.

5

Полезные классы могут быть весьма полезными, но если имя, если оно равно «Util» или «Utils», оно довольно неописано.

+0

Утилиты или инструменты - это разработка Сорняк;) –

17

Худшее имя функции я сталкивался в реальной жизни:

DoTheLogic(); 
+6

Лучше, чем DoSomeMagic ... – Wiren

+0

Когда-либо видел запутанный c? –

+1

еще хуже: DoIt(); –

10

как о «ЦБС» префикс или суффикс «класс»? Этот запах

0

Слово «материал» в любом виде имени класса/функции будет очень плохой знак (при условии, что это не глагольная форма). DoStuff(), ValidateStuff(), FetchStuffFromDatabase(), заберите свой яд.

19

Самый распространенный «запах», который я нашел, - это путаница концепций числа. Вы не хотите, чтобы класс назывался Contacts, если один экземпляр ссылается на один «контакт». Вместо этого вы называете это Contact.

1

DoThisAndThat() или DoThisOrThat() по сути нарушают Принцип единственной ответственности.Метод должен сделать одну вещь, и только (даже если это одна вещь звонит кучу других методов)

+0

Но могут быть исключения. Симулятор Хэллоуина прекрасно справляется с классом «TrickOrTreat». – DarenW

+0

@DarenW: всегда есть исключения для всего перечисленного здесь. –

0

Я думаю, что все, что начинается с class foo, вероятно, будет нечитаемым.

Да, я имею в виду это буквально. Я склоняюсь к чрезмерному использованию «foo» ...

+0

Ick. Я никогда не использую имена заполнителей для чего угодно, кроме интерактивного тестирования. Хорошо, поэтому они появляются в некоторых модульных тестах (особенно в догмах python), но не так много. – SingleNegationElimination

+1

В колледже у меня был друг, который в своем классе компиляторов добавил предупреждение своему компилятору «Предупреждение: чрезмерное использование метасинтактической переменной« foo »« B-) –

2

Названия классов в основном произвольны, поэтому выбирайте то, что работает для вас и потребителей вашего кода. Но некоторые виды имен классов могут указывать на большую проблему.

Чтобы проиллюстрировать точку:

ClassName 
    LongClassName 
    VeryLongClassName 
     VeryLongClassNameThatIsIndicativeOfExcessiveUseOfInheritance 
     VeryLongClassNameThatIsNotIndicativeOfExcessiveUseOfInheritance 
    SomewhatLongClassName 
    ShortClassName 
    ShortNameOfVeryLargeClass 
    ShortClassNameThatAlsoHasTheWordShortInTheName 

Не волнуйтесь так много об именах. Беспокоитесь о дизайне. Там, где я работаю, мы регулярно общаемся с классами с именами, такими как F, P, V и $, и это ни для кого не проблема.

-1

Я не согласен с «Менеджером», и, видимо, и Microsoft не то, что они всегда правы!) Рассмотрим класс ConfigurationManager. Это законное использование «Менеджера», потому что этот класс управляет файлами app.config/web.config. «ConfigurationReaderWriter» будет иметь bizzare, и иметь два класса (ConfigurationReader и ConfigurationWriter) не имеет большого смысла.

+1

I 100% не согласен с использованием слова «Менеджер» в имя класса, если вы не моделируете реального Менеджера (как у человека). Что делает класс менеджера? Все, что вы хотите. ConfigurationManager не является примером допустимого использования, он показывает, что не так ... – Dunk

+0

Класс ConfigurationManager делает многое, гораздо больше, чем предполагает ваш фрагмент. Разработчикам не удалось найти лучшее место для размещения функций, поэтому они просто бросали материал в класс менеджера, потому что он был удаленно связан. Чья сказать, что менеджер не может все это делать. – Dunk

+0

django также использует класс 'Manager'. Это область очень узкая, она собирает фрагменты SQL в запросы для конкретного контура. Я не слишком люблю это имя, потому что от имени это не очевидно, что он это делает. – SingleNegationElimination

1

Singleton.

+1

Если это базовый или декоратор? Если есть проблема с проблемой? –

+1

Singleton - это деталь реализации, выполненная как шаблон дизайна. В качестве детали реализации это серьезное препятствие для масштабируемости. – MSN

1

Слова «Данные», «Информация», «Строй», «Запись» и т. Д. В имени класса означают, что кто-то не думал. Охххх, это класс с ДАННЫМИ в нем! Таким образом, все эти другие классы, они не имеют какой-либо? ...

(Да, я знаю, интерфейсы. Но даже тогда, назвав реализацию интерфейса «InterfaceData» будет довольно тусклым.)

0

Названия классов, которые не указывают на то, что они делают. Есть много вещей, которые просто называются «Менеджером» или «Интерфейсом», скрытыми внутри библиотек, над которыми я работал в прошлом. Вы никогда не должны называть их напрямую, поскольку они являются внутренними структурами для управления своими функциями.

Непонятно, к каким интерфейсам «Интерфейс»; это программный интерфейс, работает ли он в сети или на оборудовании? Чтобы узнать, что вам нужно пойти и прочитать код/​​документы для класса Interface.

Конечно, когда я говорю «интерфейс», я имею в виду любое разумно неопределенное однословное имя.

5

"* Помощник *". Если класс не может выполнять свою работу, кто может?

+3

Проделал это раньше, и, вероятно, сделает это снова, но человек, которого я видел, использовал для зла – johnc

+6

Класс может быть окончательным/запечатанным. Подумайте о StringHelper ... – EricSchaefer

2

Я видел интерфейсы InterfaceNameImpl. Что может быть хуже?

+2

Подождите, * интерфейсы * названы ...? –

-1

Object oriented Login functionality

Менеджер отвечает за многих, непосредственно связанных лиц. Менеджер отвечает за взаимодействие этих объектов с клиентом. Некоторые классы менеджера не имеют четко определенных имен, таких как массив, стек и очередь.

1

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

6

менеджер, Handler, Вещь, Dingus, штучка, Entity, Gizmo, Object, Helper, виджет, гаджет

->http://journal.stuffwithstuff.com/2009/06/05/naming-things-in-code/

+0

«Объект», да? Не говорите об этом толпе Java. :) «NSObject» в порядке, я думаю, поэтому люди Mac/iPhone/Cocoa отключены ... –

+0

Ну, они не должны идти без каких-либо украшений (суффикс и постфикс) –

0

Называя все зависит от контекста, в приложении он используется. Нет жестких правил.

Если вы отправитесь в проект, который уже запущен, и они используют глаголы для имен классов повсюду, почему вы путаете программистов по очереди и применяете другой подход к именованию?

Подумайте о большой картине.

+0

Потому что продолжение плохой практики бесполезно, конечно, новым людям, которые приходят и пытаются расшифровать всю существующую ерунду. – Gareth

1

Мое самое большое домашнее животное - это тот, с которым я столкнулся с большим реалистичным проектом: Helper. Иногда это куча статических методов утилиты, иногда это объект стратегии, обычно это всего лишь блок кода, который не имеет хорошо продуманного места в дизайне.

Также, Strategy - это плохой знак, похожий на Singleton как MSN. Поздравляем! Вы используете шаблон дизайна!

Мне никогда не нравилось Util для служебных помещений, но это скорее вопрос вкуса. (Я предпочитаю плюрализованное существительное, например Arrays или Collections от JDK, за кучу статических методов, связанных с одним видом объекта.)

+0

Да, я имею дело со многими классами «Помощник» в моем текущем проекте. Они ничего не делают, кроме помощи! – DarenW