Антропоморфизирующие интерфейсы - хорошая или плохая идея?

Question

Антропоморфизирующие интерфейсы - хорошая или плохая идея?

2

Я какое-то время пытался антропоморфизировать (что означает читаемый человеком) имена, которые я даю интерфейсам, для меня это то же самое, что дать интерфейсу имя на основе роли - попытка захватить цель интерфейса в названии.

У меня была дискуссия с другими разработчиками, которые считают, что это немного странно и по-детски.

Что думают люди SO?

Примеры (синтаксис С#):

public interface IShowMessages
{
    void Show(string message);
    void Show(string title, string message);
}

public class TraceMessenger : IShowMessages
{
}

public interface IHaveMessageParameters
{
    IList<string> Parameters { get; }
}

public class SomeClass : IHaveMessageParameters
{
}

AwkwardCoder 27 авг. 2009, в 16:23

Источник

0

public interface IHazTehCodez{IList<Codez> Codez{get;}}
P Daddy 27 авг. 2009, в 14:04
0

Так IDisposable должен был быть IAmDisposable? Но как это применяется в Java, где не принято префиксировать интерфейсы с помощью «I»?
Cecil Has a Name 27 авг. 2009, в 14:08
0

Я не предполагал, что IDisposable является неправильным, я просто предлагаю подумать о роли \ readabliltiy интерфейса при именовании интерфейсов, которые Я ОПРЕДЕЛЯЮ.
AwkwardCoder 27 авг. 2009, в 14:36

Показать ещё 1 комментарий

Теги:

c#

design

interface

9 ответов

10

IThinkItsATerribleIdea

LukeH 27 авг. 2009, в 11:34

0

Жаль, что нет отдельного голосования за самый смешной ответ. ;)
Judge Maygarden 27 авг. 2009, в 13:44
3

Мнения хорошие. Оправдания лучше.
Philip Kelley 27 авг. 2009, в 13:47
0

+1 публичная классовая граната: IThinkItsATerribleIdea {публичная граната () {throw new GoesAgainstTheGrainException (); }}
grenade 27 авг. 2009, в 13:48
2

@Philip: Здесь вы идете: «Назовите интерфейсы с существительными или именными фразами, или прилагательными, которые описывают поведение». msdn.microsoft.com/en-us/library/8bc1fexb(VS.71).aspx
LukeH 27 авг. 2009, в 13:57
0

Показывает, что есть даже программисты Ludite;)
AwkwardCoder 27 авг. 2009, в 14:02
0

-1: довольно бесполезный ответ (и, к сожалению, шутка слишком стара, чтобы я мог опустить голосование, хотя и бесполезно)
Frerich Raabe 27 авг. 2009, в 14:25
0

@Frerich: Вопрос задает вопрос: «Что думают люди из SO?» и я искренне думаю, что это плохая идея. IShowMessages , IHaveMessageParameters , ICanReadAndWriteStuffToAndFromFiles или IThinkItsATerribleIdea одинаково бесполезны в том смысле, что они передают свою цель с меньшей читаемостью / ясностью, чем их более традиционные эквиваленты.
LukeH 27 авг. 2009, в 14:45
0

@ Люк: Да. Жаль, что в вашем ответе нет этого выражения, поэтому мой комментарий остается верным: ответ бесполезен. Это не имеет никакого значения для ОП, который, очевидно, был бы более заинтересован в том, ПОЧЕМУ вы думаете, это ужасная идея.
Frerich Raabe 27 авг. 2009, в 15:20
0

@Frerich: Ответ связан с рекомендациями по присвоению имен интерфейсу MSDN: «Назовите интерфейсы именами существительными или именами или прилагательными, описывающими поведение». msdn.microsoft.com/en-us/library/8bc1fexb(VS.71).aspx
LukeH 27 авг. 2009, в 15:55
0

Очень забавно, но бесполезно. И, я думаю, ссылка на msdn, безусловно, является авторитетной, но я думаю, что это неправильно (или, по крайней мере, устарело), так как это потребовало бы создания интерфейсов, которые отражают (соответствуют) каждое поведение в некотором определенном классе, и очевидно, что это понятие нарушает то, для чего интерфейсы фактически используются в подавляющем большинстве случаев, то есть для отражения «как можно более узкого» логического подмножества поведений, которые реализует класс.
Charles Bretana 08 июнь 2011, в 22:56

Показать ещё 8 комментариев

4

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

Однако использование длинных идентификаторов не делает ваши идентификаторы более "читаемыми". Для любого разумно опытного программиста "tmp" передает столько информации, сколько "временная переменная". То же самое касается "i" и "dummyCounter" и т.д.

В вашем конкретном примере имена интерфейсов на самом деле очень раздражают, так как кто-то, кто использовал для разработки объектно-ориентированных систем, будет читать наследование как "is a". И "SomeClass - это IHaveMessageParameters" звучит глупо.

Попробуйте вместо этого использовать IMessagePrinter и IMessageParameterProvider.

Frerich Raabe 27 авг. 2009, в 11:15

3

Да, это звучит неплохо.

Какая альтернатива?

Код должен быть удобочитаемым для человека. Любой дурак может написать код, который компьютер может понять. Трудная часть - это код, который человек может понять.

Люди должны поддерживать код, поэтому очень важно, чтобы он был максимально прост в обслуживании - это включает в себя, что код должен быть максимально читабельным.

Mark Seemann 27 авг. 2009, в 12:36

1

В примерах OP антропоморфный способ хорошо сопоставляется с альтернативами - например: IShowMessages против чего-то типа IMessageShower. Но - это не всегда так. Интерфейсы, которые я использовал при программировании игровых объектов: IOpenClosable и ILockable. Альтернативы, такие как ICanBeOpenedAndClosed и ICanBeLocked, будут более подробными. Или вы можете просто сделать IAmOpenClosable и IAmLockable, но тогда вы бы добавили "Am" только для антропоморфного эффекта без реальной информационной выгоды. Я все свожу к минимуму многословия, если передано такое же количество информации.

Anon 27 авг. 2009, в 12:11

1

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

AnthonyWJones 27 авг. 2009, в 11:29

1

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

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

Adam Bellaire 27 авг. 2009, в 10:58

0

Вот почему я упомянул синтаксис C #, Исторически я пришел из Windows C ++ \ COM фона, и это обозначение застрял JSUT. Я знаю, что многие люди не используют синтаксис «я» ...
AwkwardCoder 27 авг. 2009, в 13:52

0

Умышленное использование соглашения "Я для интерфейса" у первого лица кажется немного глупым, чтобы быть честным. То, что начинается, как милый каламбур, становится невозможным последовательно следовать, и в конечном итоге заканчивается смысловым смыслом. Тем не менее, ваш отдельный пример читается достаточно ясно, и у меня не было бы проблем с ним.

Chris Hatton 09 июнь 2014, в 23:36

0

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

Rushyo 27 авг. 2009, в 11:21

Ещё вопросы

Так IDisposable должен был быть IAmDisposable? Но как это применяется в Java, где не принято префиксировать интерфейсы с помощью «I»?
Я не предполагал, что IDisposable является неправильным, я просто предлагаю подумать о роли \ readabliltiy интерфейса при именовании интерфейсов, которые Я ОПРЕДЕЛЯЮ.
Жаль, что нет отдельного голосования за самый смешной ответ. ;)
Мнения хорошие. Оправдания лучше.
+1 публичная классовая граната: IThinkItsATerribleIdea {публичная граната () {throw new GoesAgainstTheGrainException (); }}
@Philip: Здесь вы идете: «Назовите интерфейсы с существительными или именными фразами, или прилагательными, которые описывают поведение». msdn.microsoft.com/en-us/library/8bc1fexb(VS.71).aspx
Показывает, что есть даже программисты Ludite;)
-1: довольно бесполезный ответ (и, к сожалению, шутка слишком стара, чтобы я мог опустить голосование, хотя и бесполезно)
@Frerich: Вопрос задает вопрос: «Что думают люди из SO?» и я искренне думаю, что это плохая идея. IShowMessages , IHaveMessageParameters , ICanReadAndWriteStuffToAndFromFiles или IThinkItsATerribleIdea одинаково бесполезны в том смысле, что они передают свою цель с меньшей читаемостью / ясностью, чем их более традиционные эквиваленты.
@ Люк: Да. Жаль, что в вашем ответе нет этого выражения, поэтому мой комментарий остается верным: ответ бесполезен. Это не имеет никакого значения для ОП, который, очевидно, был бы более заинтересован в том, ПОЧЕМУ вы думаете, это ужасная идея.
@Frerich: Ответ связан с рекомендациями по присвоению имен интерфейсу MSDN: «Назовите интерфейсы именами существительными или именами или прилагательными, описывающими поведение». msdn.microsoft.com/en-us/library/8bc1fexb(VS.71).aspx
Очень забавно, но бесполезно. И, я думаю, ссылка на msdn, безусловно, является авторитетной, но я думаю, что это неправильно (или, по крайней мере, устарело), так как это потребовало бы создания интерфейсов, которые отражают (соответствуют) каждое поведение в некотором определенном классе, и очевидно, что это понятие нарушает то, для чего интерфейсы фактически используются в подавляющем большинстве случаев, то есть для отражения «как можно более узкого» логического подмножества поведений, которые реализует класс.
Вот почему я упомянул синтаксис C #, Исторически я пришел из Windows C ++ \ COM фона, и это обозначение застрял JSUT. Я знаю, что многие люди не используют синтаксис «я» ...

Charles Bretana · Accepted Answer · 2009-08-27T11-17-00.000Z

Интерфейсы описывают поведение, поэтому я называю их так, чтобы сообщать о поведении, которое они выполняют. Это "обычно" означает, что имя - это глагол (или наречие) или некоторая форма описания действия. В сочетании с интерфейсом "I" для интерфейса это похоже на то, что вы делаете...

ICanMove, IControllable, ICanPrint, ISendMesssages и т.д.

используя наречия, как в IControllable, IDisposable, IEnumerable и т.д., передает ту же мысль, что и глагольная форма, и является термином, поэтому я также использую эту форму...

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

+1 Это также известно как принцип разделения интерфейса или просто как интерфейс роли . Было бы интересно, если бы у нас был какой-то код в этих «ролях» .