Плохо ли использовать интерфейс только для категоризации?

Например:

Скажем , у меня есть классы A, B, C. У меня есть два интерфейса, давайте называть их IAnimalи IDog. IDogнаследует от IAnimal. Aи Bесть IDog, а Cнет, но это IAnimal.

Важной частью является то, что не IDogпредоставляет никаких дополнительных функций. Он используется только для разрешения Aи B, но не Cдля передачи в качестве аргумента определенным методам.

Это плохая практика?

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

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

Я могу с уверенностью сказать, что это неплохая практика, потому что я видел интенсивное использование шаблона «Маркерный интерфейс» в Orchard Project.

Вот пример из проекта Orchard.

public interface ISingletonDependency : IDependency {}

/// <summary>
/// Base interface for services that may *only* be instantiated in a unit of work.
/// This interface is used to guarantee they are not accidentally referenced by a singleton dependency.
/// </summary>
public interface IUnitOfWorkDependency : IDependency {}

/// <summary>
/// Base interface for services that are instantiated per usage.
/// </summary>
public interface ITransientDependency : IDependency {}

Пожалуйста, обратитесь к интерфейсу маркера .

Да, это плохая практика почти на каждом языке.

Типы не существуют для кодирования данных; они помогают доказать, что ваши данные идут туда, куда им нужно, и ведут себя так, как они должны себя вести. Единственная причина для подтипа - изменение полиморфного поведения (и не всегда).

Поскольку здесь нет возможности печатать, подразумевается то, что может сделать IDog. Один программист думает одно, другой думает другое, и все рушится. Или вещи, которые он представляет, увеличиваются, поскольку вам нужен более точный контроль.

[править: уточнение]

Я имею в виду, что вы делаете некоторую логику на основе интерфейса. Почему некоторые методы могут работать только с собаками, а другие - с животными? Эта разница является подразумеваемым договором, поскольку нет фактического члена, который обеспечивает разницу; нет фактических данных в системе. Единственное отличие - это интерфейс (отсюда и комментарий «не печатать»), и то, что это значит, будет отличаться у разных программистов. [/редактировать]

Некоторые языки предоставляют механизмы черт, где это не так уж и плохо, но они, как правило, фокусируются на возможностях, а не на совершенствовании. У меня мало опыта с ними, поэтому я не могу говорить о лучших практиках там. В C ++ / Java / C # хотя ... не хорошо.

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

if(animal is IDog)
{
}
if(animal.Type == AnimalType.Dog)
{
}
if(animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
{
}


var dogs1 = animals.OfType<IDog>();
var dogs2 = animals.Where(a => a.Type == AnimalType.Dog);
var dogs3 = animals.Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any());


var dogsFromDb1 = session.Query<IDog>();
var dogsFromDb2 = session.Query<Animal>().Where(a => a.Type == AnimalType.Dog);
var dogsFromDb3 = session.Query<Animal>().Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute),false).Any());


public void DoSomething(IDog dog)
{
}
public void DoSomething(Animal animal)
{
    if(animal.Type != AnimalType.Dog)
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}
public void DoSomething(Animal animal)
{
    if(!animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}

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

Например, предположим, у меня есть интерфейсы:

интерфейс IMaybeMutableFoo {
  Bar Thing {get; set;} // И другие свойства
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
интерфейс IImmutableFoo: IMaybeMutableFoo {};

Ожидается, что реализация IImmutableFoo.AsImmutable()вернется сама; IMaybeMutableFoo.AsImmutable()ожидается, что реализация изменяемого класса вернет новый глубоко неизменяемый объект, содержащий моментальный снимок данных. Подпрограмма, которая хочет сохранить снимок данных, хранящихся в, IMaybeMutableFooможет предложить перегрузки:

public void StoreData (IImmutableFoo ThingToStore)
{
  // Достаточно сохранить ссылку, поскольку известно, что ThingToStore является неизменным
}
public void StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Вызываем более конкретную перегрузку
}

В тех случаях, когда компилятор не знает, что нужно сохранить IImmutableFoo, он будет вызывать AsImmutable(). Функция должна быстро вернуться, если элемент уже неизменен, но вызов функции через интерфейс все еще занимает время. Если компилятор знает, что элемент уже есть IImmutableFoo, он может пропустить ненужный вызов функции.