Каковы некоторые имена классов, которые будут сигнализировать о необходимости рефакторинга?

Я столкнулся с несколькими статьями, такими как этот, которые предполагают, что некоторые слова никогда не должны использоваться как часть имени класса. Когда класс имеет одно из этих слов в имени, это означает, что код должен быть реорганизован или переработан.

Пример:

Менеджер

Причина. Поскольку почти все классы "управляют" чем-то, а смысл "Менеджера" очень широк, люди могут возлагать много обязанностей на класс "Менеджер", все еще имея возможность требовать, чтобы класс "только одно" ". В результате, присвоение имени классу с помощью "Менеджера" не говорит о том, что действительно делает класс. Ранее упоминавшаяся статья " Именование классов Java без "Менеджера" показала:

Например, возьмите класс с именем "UrlManager" - вы не можете определить, объединяет ли он URL-адреса, манипулирует URL-адресами или проверяет их использование. Все имя говорит вам, что это не URL-адрес, но он как-то работает с ними. С другой стороны, имя "UrlBuilder" дает гораздо лучшее представление о том, что делает класс.

Другой пример:

Помощник

Причина: Имя класса, например "ThreadHelper", заставляет людей задаться вопросом, зачем он нужен, и почему он не может просто быть частью класса "Тема". Это на самом деле адаптер или декоратор? Если это так, назовите его именно так. Является ли класс "Thread" уже слишком большой ответственностью? Если да, рефакторинг и дать новому классу значащее имя. "Помощник" ничего не говорит о том, что он делает или как это помогает.

Каковы другие слова в имени класса, которые будут сигнализировать о необходимости рефакторинга или редизайна, и их следует избегать? Почему?

Edit: Я бы подумал, что эти слова используются очень часто, поскольку

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

В книге Clean Code указано больше, но не было причин:

Избегайте слов, таких как "Менеджер", "Процессор", "Данные" или "Информация" в имени класса.

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

Похожие вопросы:

Каков наилучший подход к классу именования?

ОТВЕТЫ

Ответ 1

Utils. Проверьте это сообщение Chris Missal в блоге, почему.

Ответ 2

Любое имя, содержащее символы, не содержащие 7 бит ascii.

Я действительно не могу понять или даже отредактировать символы хинди.

class हिन्दी:হিন্দী ঠার
{
  // argh.. 
}

Ответ 3

Мои наименее любимые идентификаторы в целом:

  • Слова с ошибками. GEM имела палитру, записанную как "pallete" во всех своих вызовах API. Maddening.
  • Идентификаторы, где я не могу определить, является ли символ 1 или l, или 0 или O.
  • Джордж Карлин семь грязных слов.

Ответ 4

Статьи (The, A, An)

Местоимения и имена (My, Their, John)

Числа, за исключением версий спецификаций (2, 3, 5000)

Пушистые прилагательные (Fast, Smart, Good, Better)

Иностранный язык, который большая часть команды не понимает (Ελληνικά)

Ответ 5

1) Все, что меньше 3-х символов, действительно нервничает. Это действительно больно читаемость, поскольку 3 символа, по крайней мере, обычно дают вам хотя бы одну гласную. Лично я стараюсь использовать не менее 5 символов.

2) Одно домашнее животное. У меня есть имена классов, заканчивающиеся на классе (например: personClass или buttonClass), так как это отвлекает от того факта, что вы создаете объект, а не класс. Создавая экземпляры класса аналогично, я нахожу ok (например: blueButton, redLabel), поскольку его легче читать, но класс может стать действительно раздражающим.

Ответ 6

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

Возможно, объекты моего класса создают кнопки, так почему бы не назвать его ButtonFactory? Возможно, этот объект управляет временем жизни временных файлов, поэтому позвоните ему в TemporaryFileManager.

Проблема возникает, когда у вас недостаточно контекстной информации. Это особенно сложно при создании повторно используемых компонентов: мой TemporaryFileManager может быть подклассом общего класса Manager, а мой ButtonFactory может быть особым случаем WidgetFactory.

Пока имя описывает то, что вещь делает в своем контексте, я в порядке. И это то, о чем упоминается в этой статье.

Ответ 7

Список неудачных идей может занять некоторое время, просто с моей головы я мог бы думать о многих плохих именах: Reader, Writer, Factory, Item, Timer, Reciever, Sender и т.д. и т.д.

В принципе, избегайте имен, которые не дают вам никакого контекста для того, что класс или его роль в большей картине. Это не должно быть когда-то сверху, как IHelpToSendXMLDataToTheServer, но, возможно, XMLBroadcastUtil не было бы ужасно. Некоторые люди даже доходят до добавления определенного prefex, суффикса к именам классов, чтобы определить, с каким модулем он работает. Однако я бы сказал, что это часть роли пространства имен/пакета.

Ответ 9

что всегда плохой вызов.

Ответ 10

Абстрактный шаблон Модель Factory Объект

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

Ответ 11

Все, что может переопределять стандартные классы (например: Comparator, Iterable & c. в Java), если вы не понимаете и специально не намереваетесь вызывать подобное поведение.