Что такое хорошая (естественная) схема именования для интерфейсов принадлежности или свойств

Question

ПРИМЕЧАНИЕ. Это , а не популярный вопрос об именах интерфейса. используя или не используя "I" в начале.

Я часто сталкиваюсь с проблемой, чтобы назвать интерфейс, который указывает принадлежность или свойство класса.
(см. Следующий список)

Давайте подумаем, какие бывают интерфейсы?

• Укажите «вид» класса
  DataStructure, Number, Thing

• Укажите «профессию» класса
  Компаратор, Исполнитель, Слушатель

• Укажите возможное действие , выполненное с классом
  Сравнимый, Исполняемый, Закрываемый

Все вышесказанное всем понятно, но давайте перейдем к моей проблеме:

• Укажите принадлежность или свойство класса
  HasListener, LinksToRoot, BelongsToParent, Knowsibling, ContainsChildren, Named, WithDescription, ...?

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

Это еще больший дискомфорт в C #, где ожидаются интерфейсы начать с 'I' :
IHasListener, IKnowsSibling, ...
Звучит для меня как LOLSPEAK "Я могу рисковать kitteh , с огромным удовольствием милашка, боже мой! @ #! "

Итак, как мне назвать интерфейс, который указывает на принадлежность или свойство класса?

Answer 1

Проблема в том, как вы решаете описать «принадлежность собственности».

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

Всего несколько, например:

HasListener => реализует Слушаемо

ContainsChildren => реализует Родительский

WithDescription => реализует Descriptable

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

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

Answer 2

В некоторых проблемных случаях, которые вы наметили, я думаю, что можно найти ответ, посмотрев «с другой стороны»:

HasListener -> Speaker
LinksToRoot, HasParent -> Child (or perhaps Node)
ContainsChildren -> Parent

Конечно, разные случаи будут более или менее очевидными.

Answer 3

Мне на самом деле очень нравится подход "IHasListener".

В .NET Framework вы найдете это в таких интерфейсах, как:

• IRaiseListChangedEvents
• IHasXmlNode

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

Answer 4

HasListener в порядке, а также Слушаемо . Я ничего против этого не имею.

Но IHasListener ужасен: во-первых, потому что нам действительно не нужен префикс I, чтобы сказать, что это интерфейс (посмотрите на сигнатуру класса!), А во-вторых, потому что он звучит как «я не знаю». не говорю по-английски ".

Единственный интерфейс в Java, который я создал с префиксом I, был IRule . :)

Answer 5

Это звучит как ужасные имена интерфейсов для меня, я согласен. «HasListener» больше напоминает вызов метода, который должен возвращать логическое значение, чем имя интерфейса.

Интерфейсы не должны существовать для хранения / хранения свойств класса. Их следует использовать для описания отношений, которым должны следовать все классы, которые его реализуют. Я лично придерживаюсь отношений "есть". Если существует прямая связь, то есть кошка «является (n)» животным, тогда я создам для нее интерфейс и назову ее «Животное», дав ему разумное имя.

Мне было бы очень интересно узнать, что описывает интерфейс "HasListener". Что именно это делает? Почему он не может быть назван MyProjectListeners (заменяя MyProject именем проекта), который описывает, что слушатели, определенные для этого проекта, должны придерживаться?

Answer 6

Я думаю, вы можете взять кое-что из того, что вы делаете, и превратить их в интерфейсы типа "профессия":

• HasListener -> ListenerContainer
• WithDescription -> DescriptionContainer (Describable также может работать, в зависимости от того, что именно является «описанием» в данном контексте)

Многие другие ваши интерфейсы имеют отношение к древовидной структуре. Я бы предложил назвать их в соответствии с их функциями в дереве.

• ContainsChildren -> Parent или Collection
• BelongsToParent -> Child

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