Хорошая практика оставила пустой интерфейс? - PullRequest
2 голосов
/ 28 января 2012

На этот раз я создам математические задачи.Я планирую иметь словарь, в котором ключом является Levels enum {Easy, Medium, Hard}, а значение должно содержать некоторую конфигурацию о том, как создавать проблемы.

Например:

BinaryProblemConfiguration
    + Bound1 : Bound<int>
    + Bound2 : Bound<int>

У Bound есть два свойства: min и max.

Для других типов задач Bounds не нужны, но нужны другие данные.

Итак, я подумал создать интерфейс под названием IConfiguration.

public interface IConfiguration {}

И конкретные конфигурации должны быть:

public class BinaryProblemConfiguration : IConfiguration
{
    public Bound Bound1 {get;set;}
    public Bound Bound2 {get;set;}
}

public class AnotherProblemConfiguration : IConfiguration
{
    // other stuff
}

Идея состоит в том, чтобы иметь словарь с именем ConfigurationLevels,Является ли это хорошей практикой, оставляя интерфейс пустым, или это означает, что мой дизайн не так?

Ответы [ 3 ]

8 голосов
/ 28 января 2012

Руководство по проектированию .NET Framework называет этот интерфейс «маркерным» и однозначно говорит, что это плохая идея.Вместо этого они рекомендовали использовать пользовательский атрибут.

Избегайте использования маркерных интерфейсов (интерфейсов без элементов).

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

http://msdn.microsoft.com/en-us/library/ms229022.aspx

public sealed class ConfigurationAttribute : Attribute {

}


[ConfigurationAttribute]
public class AnotherProblemConfiguration : IConfiguration 
{ 
    // other stuff 
} 
2 голосов
/ 28 января 2012

Где бы вы использовали экземпляр IConfiguration сам по себе?Если есть такой пример использования:

void Something(IConfiguration configuration) { ... }

Тогда да, это нормально.Но с пустым интерфейсом это будет интересный вариант использования.Случайно на ум приходит сериализация объектов, когда вы знаете, что сериализуемый с помощью этого метода объект должен быть IConfiguration, но на самом деле вас не волнует, как выглядит IConfiguration:

void SerializeConfiguration(IConfiguration configuration) { ... }

Теперь, с чисто функциональной точки зрения, это будет работать так же хорошо с Object, но я думаю, что это разумный способ предоставить механизм времени компиляции, чтобы настоятельно рекомендовать, чтобы кто-то не сериализировал ничего, кроме конфигурации, используя этот метод.1008 *

Другое распространенное использование этих интерфейсов - маркерные интерфейсы, где вы используете отражение, чтобы найти типы, «помеченные» путем реализации общего интерфейса.

1 голос
/ 28 января 2012

Определенно может быть полезно иметь интерфейс, который расширяет другой интерфейс, но ничего не добавляет к нему. Например, можно легко представить варианты использования для IImmutableEnumerable<T>, который наследуется от IEnumerable<T>, но обещает, что последовательность возвращаемых им элементов никогда не изменится ни по какой причине. Процедура, которая должна иметь список элементов, которые не будут изменены, может иметь перегрузки для IEnumerable<T> и IImmutableEnumerable<T>. Первая перегрузка может проверить, реализует ли предоставленный экземпляр объекта IImmutableEnumerable<T> и, если нет, создать новый неизменный список путем копирования элементов в оригинале; вторая перегрузка может просто напрямую использовать переданный список, поскольку известно, что он реализует IImmutableEnumerable<T>.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...