Злые имена классов?

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

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

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

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

Ответы

Ответ 1

Я нашел это полезным:

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

(Из Очистить код от Robert Martin, p25)

Ответ 2

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

Ответ 3

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

DoTheLogic();

Ответ 4

Процитировать Roedy Green Как написать неподдающийся код код:

Быть абстрактным

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

Ответ 5

как насчет префикса "cls" или суффикса класса? Этот запах

Ответ 6

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

Ответ 7

Менеджер, обработчик, Thing, Dingus, Doodad, Entity, Gizmo, Object, Helper, Widget, Gadget

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

ClassName
  LongClassName
    VeryLongClassName
      VeryLongClassNameThatIsIndicativeOfExcessiveUseOfInheritance
      VeryLongClassNameThatIsNotIndicativeOfExcessiveUseOfInheritance
    SomewhatLongClassName
  ShortClassName
    ShortNameOfVeryLargeClass
    ShortClassNameThatAlsoHasTheWordShortInTheName

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

Ответ 11

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

Ответ 12

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

Ответ 13

Singleton.

Ответ 14

Слова "Данные", "Информация", "Строй", "Запись" и т.д. в имени класса означают, что кто-то не думал. Охххх, что класс с DATA в нем! Итак, все эти другие классы, у них их нет?...

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

Ответ 15

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

Ответ 16

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

Кроме того, Strategy является плохим знаком, как и t22, как отмечал MSN. Поздравления! Вы используете шаблон дизайна!

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

Ответ 17

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

Ответ 18

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

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

Ответ 19

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

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

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

Ответ 20

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

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

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

Ответ 21

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

Ответ 22

Объектно-ориентированная функция входа в систему

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