Остарели ли са интерфейсите на етикети (или маркери)?

Опитвам се да помогна на колега да се примири с OO и откривам, че в някои случаи е трудно да се намерят солидни примери от реалния свят за концепцията за етикет (или маркер) интерфейс. (Интерфейс, който не съдържа методи; използва се само като етикет, маркер или етикет). Макар че наистина няма значение за нашите дискусии, ние използваме PHP като платформа зад дискусиите (защото това е общ език между нас). Вероятно не съм най-добрият човек за преподаване на OO, тъй като по-голямата част от моя опит е силно теоретичен и на около 15 години, но аз съм това, което той има.

Във всеки случай, недостигът на дискусии, които открих относно интерфейсите на таговете, ме кара да вярвам, че дори не се използва достатъчно, за да оправдае дискусия. Греша ли тук?


person markh    schedule 11.06.2009    source източник
comment
Може би би била полезна връзка към нещо, което обяснява какво имате предвид под интерфейс на тагове?   -  person    schedule 11.06.2009


Отговори (7)


Интерфейсите на етикети се използват в Java (Serializable е очевидният пример). C# и дори Java изглежда се отдалечават от това, но в полза на атрибутите, които могат да постигнат същото, но и много повече.

Все още мисля, че има място за тях в други езици, които нямат концепцията за атрибути, която имат .NET и Java.

ETA:

Обикновено бихте използвали това, когато имате интерфейс, който предполага реализация, но не искате класът, който имплементира интерфейса, действително да трябва да предоставя тази реализация.

Някои примери от реалния свят:

Serializable е добър пример - това предполага, че има имплементация (някъде), която може да сериализира данните на обекта, но тъй като е налична обща имплементация за това, няма нужда реално обектът да изпълнява самата тази функционалност.

Друг пример може да бъде система за кеширане на уеб страници. Да кажем, че имате обект "Page" и обект "RequestHandler". RequestHandler приема заявка за страница, намира/създава съответния обект Page, извиква метод Render() на обекта Page и изпраща резултатите до браузъра.

Сега кажете, че искате да приложите кеширане за изобразени страници. Но проблемът е, че някои страници са динамични, така че не могат да бъдат кеширани. Един от начините за прилагане на това би бил да накарате обектите на страница с възможност за кеширане да имплементират интерфейс на ICacheable "tag" (Или обратното, можете да имате интерфейс INotCacheable). След това RequestHandler ще провери дали страницата имплементира ICacheable и ако го направи, ще кешира резултатите след извикване на Render() и ще сервира тези кеширани резултати при последващи заявки за тази страница.

person Eric Petroelje    schedule 11.06.2009
comment
Бихте ли цитирали пример от реалния свят? - person Oorang; 12.06.2009
comment
@Oorang - добре, даде някои примери. Надяваме се, че това ще изясни малко нещата. - person Eric Petroelje; 12.06.2009
comment
Добър отговор и примери от реалния свят. Използвах празни интерфейси за реален случай на употреба (потребителите могат динамично да разширяват някои класове на обекти по време на изпълнение), но не знаех, че се нарича интерфейс за маркер/етикет. - person felipsmartins; 13.02.2016

Интерфейсите на .Net Tag могат да бъдат чудесни за използване с методи за отражение и разширение. Интерфейсите на етикети обикновено са интерфейси без никакви методи. Те ви позволяват да видите дали даден обект е от определен тип, без да имате наказанието да отразявате върху вашите обекти.

Примери в .Net Framework INamingContainer е част от ASP.Net

person Matthew Whited    schedule 11.06.2009
comment
Сладко... шофирайте с гласуване против. Изглежда, че те питат дали интерфейсите на таговете са от полза. И предполагам, че пример за тяхното използване е лошо нещо. - person Matthew Whited; 11.06.2009
comment
Други причини, поради които намирам Tag интерфейсите за полезни, е фалшифицирането на множествено и статично наследяване. - person Matthew Whited; 11.06.2009
comment
Гласуването против е, защото съветът, даден в този отговор, е в пряк конфликт с препоръчаните от MS насоки за проектиране. Насоките за проектиране на рамка казват: НЕ използвайте празни интерфейси; Използвайте атрибути. Не че не съм съгласен с отговора; това е, че мисля, че всъщност е вредно. - person Cheeso; 12.06.2009
comment
И кога е написано това ръководство. Бих помислил да се съглася с тази гледна точка, преди да излезе .Net 3.5. И ако общите филтри се актуализират, за да съответстват на атрибутите, може да обмисля промяна обратно. Но в същото време е по-лесно да видите дали даден обект е от определен тип, отколкото да изброите всички атрибути за този, който искате. - person Matthew Whited; 12.06.2009
comment
Този отговор stackoverflow.com/questions/1023068/ изброява някои много добри причини да се предпочитат маркерните интерфейси, а не атрибутите - person John Rasch; 21.09.2009

Бих се нарекъл OO програмист и никога не съм чувал за интерфейс на тагове.

person Scott Langham    schedule 11.06.2009
comment
добре, не сте запознати с термина, но сте видели идиома. Чувал съм ги по-често да се наричат ​​маркерни интерфейси. Празен интерфейс, без методи или свойства. Сериализиране в Java е едно. java.sun.com/javase/6/docs/ api/java/io/Serializable.html В .NET идиомът е неодобрен. - person Cheeso; 11.06.2009
comment
Да, сега го погледнах, знам какво е. Използвал съм Serializable в Java, без да знам, че се нарича интерфейс за тагове. Мисля, че това е малко трик, но наистина. Не мога да се сетя някога, когато съм искал да направя нещо подобно в моя код. - person Scott Langham; 12.06.2009

Мисля, че интерфейсите на таговете си струва да бъдат обсъдени, защото те са интересен ъглов случай на концепцията за интерфейс. Рядката им употреба обаче също си струва да се отбележи!

person Dan Davies Brackett    schedule 11.06.2009
comment
Съгласен съм, особено с последното твърдение. Честото използване на интерфейси на тагове вероятно е индикация за лошо проектиран обектен модел. - person Eric Petroelje; 11.06.2009
comment
@Eric... Трябва да не се съглася с теб. Интерфейсите на етикетите могат да бъдат много полезни. Друг начин за получаване на метаданни по време на компилиране без използване на атрибути. - person Matthew Whited; 11.06.2009

Използвал съм интерфейси на тагове няколко пъти в обектен модел, представляващ SQL база данни. В тези случаи това е подтип на основния интерфейс за определени типове обекти. По-лесно е да проверите за интерфейс на етикет, отколкото за атрибут („obj е IInterface“, вместо да използвате отражение)

person thecoop    schedule 11.06.2009

Ръководството за стил на .NET казва да се използват атрибути вместо интерфейси за тагове/маркери.

http://www.freeimagehosting.net/uploads/th.4528577db5.jpg
Щракнете за пълно изображение
източник: http://www.informit.com/articles/article.aspx?p=423349&seqNum=6
или произволен брой други точки на изложение от препоръките на Cwalina, като книгата.

person Cheeso    schedule 11.06.2009
comment
Атрибутите са безполезни за справяне с методите за разширение - person Matthew Whited; 11.06.2009
comment
Вярно - атрибутите не са интерфейси, ако това имате предвид. - person Cheeso; 12.06.2009
comment
Ето защо интерфейсите за маркиране могат да бъдат полезни. (не бъди марионетка 8o) - person Matthew Whited; 12.06.2009
comment
Не разбирам коментара ви или защо ме наричате марионетка. Искате да кажете, че интерфейсите за маркиране са полезни, защото това използване противоречи на препоръчителната практика? Защото е изненадващо за разработчиците? Защото това е творчески начин да се направи нещо, което атрибутите се справят по-добре? - person Cheeso; 12.06.2009
comment
Казах го като удар, че ме отхвърлиха. Има причина това да са насоки. Това е точно като използването на goto. Ако кажете, че работят, това ще ви накара да не гласувате, но истината е, че работят. - person Matthew Whited; 12.06.2009
comment
Освен това тази книга е от преди .Net 3.5 (И отвъд това моят пример като интерфейс от рамката. Така че те не могат да бъдат твърде отвратени от тях) - person Matthew Whited; 12.06.2009

Използвах интерфейс за тагове два пъти през последния месец. Те могат да преодолеят някои неприятни проблеми при рефакторинг, за да направят функцията по-генерична.

Въпреки това, друго нещо, което току-що открих, е използването на интерфейс на тагове като родителски клас към куп свързани интерфейси с методи. Обектът може да се предава и различни препроцесори могат да проверят дали трябва да се справят с конкретен обект. Начин за запазване на обработката в отделен обект, където й е мястото, но подробностите за изпълнение на обработените обекти в техните дефиниции, където им е мястото.

person orbfish    schedule 15.03.2011