Какие существуют анти-паттерны именования? [закрыто]

35

Есть некоторые имена, где, если вы обнаружите, что пытаетесь найти эти имена, вы знаете, что уже что-то напутали.

Например:

XxxManager
Это плохо, потому что класс должен описывать, что класс делает. Если самое конкретное слово, которое вы можете придумать для того, что делает класс, это «управлять», то класс слишком велик.

Какие еще существуют анти-паттерны именования?

Чтобы уточнить, я не спрашиваю «какие имена плохие» - этот вопрос является полностью субъективным, и нет никакого способа ответить на него. Я спрашиваю: «Какие имена указывают на общие проблемы проектирования системы». То есть, если вы хотите вызвать компонент Xyz, это, вероятно, указывает на то, что компонент неверен. Также обратите внимание, что здесь есть исключения из каждого правила - я просто ищу предупреждающие флаги, когда мне действительно нужно остановиться и переосмыслить дизайн.

Billy ONeal
источник
1
Как насчет Smurf Naming Convention ?
back2dos
4
Для тех, кто голосует за закрытие как «неконструктивно» - не могли бы вы объяснить причину? Единственное, с чем это не очень хорошо справляется, так это то, что ответы могут быть короткими, но это, безусловно, отвечает остальным пяти принципам ...
Билли ONeal
1
о, кстати c2.com/cgi/wiki?DontNameClassesObjectManagerHandlerOrData
джоккинг
2
@Aaronaught: есть предложения? Я сформулировал это так же хорошо, как я могу в редактировании ....
Билли ONeal
1
@jhocking - я согласен с некоторыми из этих ссылок - особенно с тем, что «Менеджер» и «Обработчик» слишком ценны, чтобы их отпустить. И я не так продан на основе шаблонов дизайна и других альтернатив, которые во многих случаях кажутся, по крайней мере, расплывчатыми. Иногда «Очередь» или что-то еще может быть уместным, но часто тот факт, что менеджер хранит (или ссылается) элементы в очереди, является лишь одним аспектом управления этими элементами. Так же, как что-то полезное выражается «менеджером» в качестве названия должности, IMO то же самое применяется в ООП.
Steve314

Ответы:

22

Следующие анти-шаблоны именования относятся к .NET и, особенно, к C #:

  • Несоответствия . Если вы решили начать каждое имя поля с начального подчеркивания, придерживайтесь его .
  • Двусмысленные сокращения с пропущенными гласными . Я серьезно видел названия полей, такие как cxtCtrlMngr. Вы вряд ли можете догадаться, что это означает.
  • Слишком длинные и подробные имена переменных . ILoginAttemptRepositoryхорошо и описательно - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingописательно, но определенно не хорошо.
Мариус Шульц
источник
7
Имеется Iв виду interfaceздесь implementer, или от первого лица единственного числа? Поскольку в большинстве классов реализован интерфейс, слишком большое количество классов / взаимодействий, начинающихся с заглавной Iбуквы, раздражает, мешает удобочитаемости и запаху кода сам по себе.
пользователь неизвестен
3
+1 за "Ambiguos сокращений с отсутствующими гласными", которые сводят меня с ума!
FrustratedWithFormsDesigner
6
@Billy ONeal: C ++ имеет интерфейсы; они просто не искусственно отделены от классов. ;)
Джон Перди
4
@Billy ONeal: Это была моя точка зрения.
Джон Перди
2
@MariusSchulz: о да, я с тобой согласен :) Просто подумал, что это не такая уж непрозрачная аббревиатура.
Амара
9

Я часто сталкиваюсь с тем, что просто не использую какой-либо шаблон именования. Обычно указывает на незнание разработчиком (что шаблоны именования - хорошая вещь ), а также этот анти-шаблон имеет тенденцию грубо нарушать SRP, вставляя все виды методов, которые своего рода / своего рода связаны с классом, в сам этот класс, например, Customer класс имеет свойства, методы CRUD, все, что удаленно связано с клиентом, в чем нуждается некоторая часть приложения.

Я также добавлю, что использование «Engine» в качестве суффикса примерно то же, что и «Manager». Это очень расплывчато, и класс с именем XxxEngineимеет тенденцию быть тем, что представляет собой модуль в стиле VB, содержащий множество методов, поэтому он находится в одном «простом в использовании» месте, без каких-либо знаний или идеи объектно-ориентированного программирования.

Уэйн Молина
источник
7

Ну, сначала простые ответы: наберите венгерский ( http://mindprod.com/jgloss/unmainnaming.html , также есть несколько отличных идей. Более сбалансированный взгляд на то, когда венгер не злой, http://www.joelonsoftware.com /articles/Wrong.html )

инка
источник
7
Венгерская нотация - ВСЕГДА зло :)
Уэйн Молина
12
@Wayne: На самом деле, это не всегда зло. Я работал на Чарльза в Xerox в конце 70-х, и оригинальная система именования спасла меня. Мы работали в BCPL, который имеет 1 тип: целое число. Все остальное о типе было передано в соответствии с соглашением об использовании и именовании. У нас было 7 программистов + Чарльз, и любой из нас мог войти в чужой код и сразу же стать продуктивным. Нельзя сказать, что это не может быть ужасно искажено / неправильно использовано (даже Чарльзом), просто в правильном контексте это было правильное решение.
Питер Роуэлл
3
@Marius: прочитайте статью Джоэла. Система типов не всегда может обеспечить соблюдение всех семантических различий между переменными. Intellisense тоже не помогает в таких случаях.
Билли Онил
4
Тип легче вывести, чем использовать, особенно с современными редакторами. Однако это требует дисциплины. Вам не нужно префикс все . Я работаю на Java, и в большинстве случаев венгерские приложения не нужны, но когда я делаю что-либо, требующее нескольких переменных одного типа (например, fromX и toX) в системах координат, это спасает жизнь.
Майкл К
3
Что было бы хорошо, так это общая способность легко создавать новые типы. «Это похоже на int, за исключением того, что оно применяется к номерам строк».
Дэвид Торнли
6

Префикс «I» к имени интерфейса или «Абстрактный» к имени абстрактного класса. Это может быть оправдано в языках, которые не имеют понятия абстрактных классов или не различают интерфейсы и абстрактные классы - но в Java, например, это всегда плохая идея.

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

Майк Баранчак
источник
@Mike: я полностью не согласен с твоим заявлением, извини. На мой взгляд, XxxxManagerэто худшее имя, которое может иметь класс. Конечно, это что-то удается! Вот почему это было написано для. Managerявляется бессмысленным словом-наполнителем, которое не добавляет ценности пониманию - по его названию - того, за что отвечает класс.
Мариус Шульц
1
Как насчет, скажем TabManager,? Получил лучшее имя для класса, который управляет механизмом вкладок JSP? Или задыхаться TabController ... Что касается префикса с Abstract, я чувствую, что он чрезмерно используется, но часто действителен (примеры см. В библиотеках Java). Я думаю, что могу с уверенностью сказать, что я никогда не видел Iинтерфейсов в любом месте, где кто-то не пытался программировать на интерфейс, который не должен был быть там. Мол, только один класс реализует интерфейс.
Майкл К
1
@Darien (и другие): В любом случае - это не имеет значения. Ни одно из этих имен не является анти-паттернами (и поэтому они не по теме для этого вопроса). Я не думаю, что вы можете что-то сказать о дизайне системы, независимо от того, используют они IXxxили нет XxxImpl.
Билли ONEAL
2
Это просто совершенно, совершенно неправильно. Есть очень веские причины визуально отличать интерфейсы от классов: (а) они не могут быть созданы, (б) они не могут быть освобождены / удалены, (в) они не могут быть сериализованы, (г) они могут быть Прокси / перехват и т. д. и т. д. и т. д. Вы только что выбросили что-то, что вам лично не нравится (по какой-то причудливой и необъяснимой причине), в качестве примера анти-паттерна без какого-либо обоснования вообще.
Ааронаут
1
По возможности интерфейсы должны быть предпочтительнее конкретных классов для типов аргументов и типов возвращаемых данных. Следовательно, для интерфейсов имеет смысл получать «чистые» имена и конкретные реализации (фактический тип, о котором вызывающая сторона может даже не знать или не заботиться), чтобы получить бородавки.
Кевин Крумвиде
6

Speeling:

У меня отклоняющаяся склонность и я не могу записать. Без проверки орфографии я бессильна, я пытаюсь скопировать все имена, которые я создаю, в текстовый процессор для проверки, но я всегда скучаю по некоторым. В моем последнем проекте я написал большую часть API, и я полагаю, что я не проверял орфографию в первый раз, когда использовал слово «ответ», и предположил, что это правильно, потому что никто не сказал мне. У нас было как минимум 50 функций с откликом в нем. В команду пришел новый человек и спросил, почему мы используем реакцию, я чувствовал себя очень глупо.

повторный показ
источник
2
Я кратко использовал плагин jQuery, где был один из параметров affect(вместо эффекта). Это сводило меня с ума, и я быстро нашел другой плагин, чтобы сделать то же самое.
zzzzBov
4
Худшая проблема, с которой я столкнулся, заключается в том, что, когда я вижу имя с орфографической ошибкой, это действительно вредит моей способности помнить, что это за имена.
Дэвид Торнли
1
Хуже, когда одно и то же пишется по-разному в разных частях кода. Например, когда у вас есть поле класса Srtength, доступ к которому осуществляется методом getStrenth ().
Ева
5

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

Что касается меня, я должен согласиться с Майком Баранчаком, такие имена, как XxxController, XxxHandler - это то, что мы действительно часто используем. Для нас контроллер - это что-то вроде точки входа для чего-то «инкапсулированного», например, для управления транзакциями, обработки неожиданных ошибок, вызова XxxHandler для выполнения реальной работы. Я бы сказал, что XxxManager - это синоним контроллера. Я думаю, что важно не использовать Manager в одном случае и Controller в другом. Быть последовательным очень важно, если вы работаете в команде.

Было бы очень сложно или, возможно, даже невозможно найти более подходящие названия для подобных вещей. Ххх должен быть хорошо выбран, чтобы прояснить ситуацию.

Что мне лично не нравится, так это то, что метод get ... или set ... - это больше, чем просто метод доступа. Мне нравится дет ... для определения.

Еще одна вещь, которая приходит мне в голову: по словам дяди Боба. «И» в имени метода является признаком того, что нужно много делать. Но жизнь не всегда только черно-белая - есть ситуации, когда я думаю, что это нормально - например. из-за проблем с производительностью (когда у вас уже есть данные из-за проверки, почему бы не обработать их) ...

Лично я также большой поклонник системной венгерской нотации - в большинстве случаев вы имеете дело с исходным кодом в IDE. Но часто вы используете только редактор или просматриваете репозиторий в браузере. Одним из недостатков может быть поддержка инструментов из-за префиксов типов ...

Я думаю, что самая важная вещь - быть созвучным - субоптимальное соглашение - для меня - лучше, чем отсутствие соглашения ...

фаланга
источник
1
«Контроллер» имеет другую семантику, чем «Менеджер». Лично мне тоже не нравится, но «Контроллер» обходится, потому что это общий компонент многих шаблонов, особенно MVC. XxxHandler такой же плохой. Если класс просто «обрабатывает» что-то - либо класс слишком велик, либо его следует просто назвать частью «Ххх».
Билли ONEAL
3
«Было бы очень сложно или, возможно, даже невозможно найти более подходящие имена для подобных вещей», - если вы правильно спроектировали иерархию типов с четко определенными зависимостями и обязанностями. Конечно, если вы используете «Контроллер» как часть MVC или «Обработчик» для универсального обработчика событий / сообщений, тогда все по-другому - это примеры жаргона - но если они просто используются как общие имена для определенные классы, то это главный красный флаг.
Ааронаут
5

Возможно, худший анти-шаблон именования это:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

У нас есть трехэлементный список пар [foo, bar]. Если нам нужен четвертый, нам нужно будет добавить новые столбцы в таблицу.

Ведущий к коду, как это:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Отдельная таблица должна быть создана с колонками foo и bar и связана с таблицей материала:

create table fubar(foo string, bar string, stuff_id long)

Второе худшее это:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Здесь у нас есть шесть полей вместо двух экземпляров класса Address.

Этот анти-шаблон помечен серией имен из двух частей, в которой перечислены все комбинации двух наборов, например [foo, bar] x [1,2,3] или [home, perm] x [улица, город, штат]

кевин клин
источник
-1 - это вообще не касается именования.
Билли ONEAL
Анти-шаблон имен не может содержать более одного имени?
Кевин Клайн
Как слишком много аргументов ==называет антипаттерн? Я запутался.
Билли ОНил
1
насколько я понимаю его, это соглашение, которое допускает числа, где должно быть взято реальное имя. Эти цифры приводят к ложному впечатлению, что элементы представляют собой некий список или массив
keppla
3
@ Билли ONEAL: Да, они делают. Проблема проектирования заключается в отсутствии нормализации, а числовые суффиксы являются шаблоном именования, указывающим на него.
фоторепортаж
3

Любое имя класса или интерфейса, являющееся тавтологией, является плохим не только в Java, о котором говорится в ссылке, но и на любом языке.

Тавтология (риторика), используя разные слова, чтобы сказать то же самое, даже если повторение не дает ясности.

оборота user7519
источник
2
Интересный. Есть примеры?
Майк Баранчак
2
Я прочитал ссылку, там написано "тавтология" ...;)
Бенджол
10
Первое правило тавтологического клуба - это первое правило тавтологического клуба.
Cercerilla
Я прочитал ссылку (хорошо, содержание ссылки) и не нашел примеров
barjak
Хорошо, так что по этой ссылке мы должны прекратить использовать I <InterfaceName> ... правильно.
Даль
3

Я часто сталкиваюсь с библиотеками программного обеспечения с общими именами, такими как Libraryили Common. Они указывают на неоптимальный дизайн: разработчики прилагают усилия, чтобы избежать дублирования кода, но без какой-либо попытки создать дизайн, разложенный на основе функциональности.

reinierpost
источник
+1 - я вижу "Общее" все время.
Морган Херлокер
1

От Microsoft по именованию я могу предоставить этот список для плохих имен:

  1. Они не являются семантическими, что означает, что у них есть имена, которые вместо того, чтобы акцентировать внимание на том, что они делают, делают акцент на технологии, которую они используют, или шаблон, на котором они основаны .
  2. Они не следуют синтаксической последовательности. Например, часть имен имеет верблюжий корпус, а другая часть - паскаль.
  3. Это аббревиатуры, которые трудно понять, например ScrollableX вместо CanScrollHorizontally
  4. Они выбраны так, что они связываются с ключевыми словами этой среды.
Саид Нямати
источник
2
Я на самом деле люблю "ScrollableX" по крайней мере так же, как "CanScrollHorizontally". «Х» на самом деле не аббревиатура.
user1172763