Какова цель интерфейса маркера?

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

Интерфейс и .NET Type Design Guidelines - Interface Design не поощряют использование интерфейсов-маркеров в пользу использования атрибутов в C #, но, как указывает @Jay Bazuzi, это легче проверить интерфейсы маркеров, чем атрибуты: o is I

Итак, вместо этого:

public interface IFooAssignable {} 

public class FooAssignableAttribute : IFooAssignable 
{
    ...
}

В рекомендациях .NET рекомендуется сделать следующее:

public class FooAssignableAttribute : Attribute 
{
    ...
}

[FooAssignable]
public class Foo 
{    
   ...
} 

Это немного касательная, основанная на ответе "Mitch Wheat".

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

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

Это не из-за каких-либо проблем с руководящие принципы проектирования каркаса. Я считаю, что .NET framework - фантастическая библиотека классов. Большая часть этой фантастики проистекает из руководящих принципов разработки фреймворка.

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

Многие содержащиеся в нем предложения могут помочь вам сделать что-то, что:

1. Возможно, это не самый простой способ реализации чего-либо
2. Может привести к дополнительному дублированию кода
3. Может иметь дополнительные накладные расходы во время выполнения

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

В этом случае основными задачами разработчика API являются:

1. Обеспечение согласованности с остальной частью фреймворк
2. Устранение ненужной сложности на поверхности API

Руководящие принципы проектирования фреймворка подталкивают разработчиков к созданию кода, который выполняет эти цели.

Это означает, что нужно делать такие вещи, как избегать слоев наследования, даже если это означает дублирование кода, или выталкивание всего кода, генерирующего исключения, в «точки входа» вместо использования общих помощников (чтобы трассировки стека имели больше смысла в отладчике) и многие другие подобные вещи.

Основная причина того, что эти рекомендации предлагают использовать атрибуты вместо интерфейсов маркеров, потому что удаление интерфейсов маркеров делает структуру наследования библиотеки классов намного более доступной. Диаграмма классов с 30 типами и 6 уровнями иерархии наследования очень сложна по сравнению с диаграммой с 15 типами и 2 уровнями иерархии.

Если действительно миллионы разработчиков используют ваши API или ваша база кода действительно велика (скажем, более 100 000 LOC), то следование этим рекомендациям может очень помочь.

Если 5 миллионов разработчиков потратят 15 минут на изучение API. чем потратить 60 минут на его изучение, в результате чистая экономия составляет 428 человеко-лет. Это много времени.

Однако в большинстве проектов не задействованы миллионы разработчиков или более 100 тыс. Человек. В типичном проекте, состоящем, скажем, из 4 разработчиков и около 50 000 локальных сетей, набор предположений сильно отличается. Разработчики в команде будут лучше понимать, как работает код. Это означает, что гораздо больше смысла оптимизировать для быстрого создания высококачественного кода, а также для уменьшения количества ошибок и усилий, необходимых для внесения изменений.

Если вы потратите 1 неделю на разработку кода, совместимого со средой .net, против 8 часов на написание кода, который легко изменить и в котором меньше ошибок, это может привести к:

1. Поздним проектам
2. Меньшим бонусам
3. Увеличение количества ошибок в счет
4. Больше времени, проведенного в офисе, и меньше времени на пляже, пьющем маргариту.

Без 4, 999 999 других разработчиков, чтобы покрыть расходы, которые обычно не окупаются.

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

Итак, мой совет:

1. Неукоснительно следуйте руководящим принципам фреймворка, если вы разрабатываете библиотеки классов (или виджеты пользовательского интерфейса), предназначенные для широкого использования.
2. Рассмотрите возможность принятия некоторых из них, если у вас более 100K LOC в вашем проекте
3. В противном случае игнорируйте их полностью.

Интерфейс маркера - это просто пустой интерфейс. Класс будет реализовывать этот интерфейс как метаданные, которые по какой-то причине будут использоваться. В C # вы бы чаще использовали атрибуты для разметки класса по тем же причинам, по которым вы использовали бы интерфейс маркера в других языках.