Интерфейс без каких-либо участников - плохая практика? [дубликат]
Возможный дубликат:
Какова цель интерфейса маркера?Это плохая практика для создания абсолютно пустого интерфейса, такого как:
public interface ISomething { }Существует случай, где я хотел бы рассматривать определенные объекты по-другому, чем другие, но я не требую никакого нового поведения.
6 ответов
Я лично считаю, что пустые интерфейсы не являются хорошая вещь.
Интерфейсы предназначены для описания поведенческих контрактов.Пустой интерфейс не описывает никакого поведения - здесь вы не определяете какую-либо форму контракта.
В рекомендациях по проектированию интерфейсов конкретно говорится:
Избегайте использования интерфейсов-маркеров (интерфейсов без элементов).
Настраиваемые атрибуты позволяют отметить тип. Дополнительные сведения о настраиваемых атрибутах см. В разделе «Написание настраиваемых атрибутов». Настраиваемые атрибуты предпочтительнее, если вы можете отложить проверку атрибута до выполнения кода. Если ваш сценарий требует проверки во время компиляции, вы не можете соблюдать это руководство.
Рассматривали ли вы использование атрибута вместо интерфейса? Обычно таков мой подход. По общему признанию, проверить наличие атрибута немного сложнее, чем то, реализует ли объект интерфейс, но в целом кажется, что он лучше подходит.
Я бы сказал, что Attribute лучше, но в .Net есть примеры пустых интерфейсов (например, INamingContainer - http://msdn.microsoft.com/en-us/library/system.web.ui.inamingcontainer.aspx). Мне всегда было интересно, почему это было сделано именно так - кто-нибудь знает?
.Я согласен со всеми здесь. Я думаю, если бы мне дали код для поддержки и я увидел бы класс с интерфейсом, не имеющим свойств или методов, я был бы очень сбит с толку.
В приложении asp.net mvc, над которым я недавно работал, у меня была основная операция (код отслеживания), которую я хотел выполнить на почти каждый запрос (но не, скажем, запрос ajax или страницу администратора) . Я добавил операцию в базовый контроллер и выполнил ее в методе ExecuteCore. Для тех немногих ситуаций, когда я не хотел, чтобы он запускался, я установил флаг в производном контроллере, чтобы не запускать его.
Это не так чисто и элегантно, как атрибут, но его гораздо проще реализовать.
Конечно, это не поможет, если вы хотите создать общие операции для всех производных классов. Но в таком случае в объектах должны быть некоторые общие черты (например, общее свойство), что означало бы, что интерфейс не будет пустым.
Мне кажется, что реализация интерфейса маркера и присоединение атрибута без параметров различаются только синтаксисом, но первый проще использовать с информацией о типе времени выполнения.
Я не готов сделать жесткое и быстрое правило никогда не использовать интерфейсы маркеров лично, но я вижу потенциальный провал, если они используются не только для «маркировки» - в этом случае атрибуты могут быть более подходящими .
Тем не менее, если я сравниваю первый раз, когда я столкнулся с пустым интерфейсом (я помню, что это определенно была Java около 2000 года), с первым разом, когда я столкнулся с атрибутом (веб-службы C #) - я смог вывести цель одного, но другой вынудил меня перейти в режим обучения ...
Я так не делаю, но не вижу веских причин против этого. Я часто создаю базовый класс для общих типов, чтобы иметь возможность содержать коллекцию общих элементов. Интерфейс мог бы быть более чистым способом сделать это, но я обычно найду, что поместить в базовый класс, так что интерфейсное решение для этого не подходит.
Я думаю, вы можете думать об этом как об абстрактном базовом классе?