É uma má prática usar uma interface apenas para categorização?

Por exemplo:

Digamos que eu tenha aulas A, B, C. Eu tenho duas interfaces, vamos chamá-los IAnimale IDog. IDogherda de IAnimal. Ae Bsão IDogs, enquanto Cnão é, mas é um IAnimal.

A parte importante é que IDognão fornece funcionalidade adicional. É usado apenas para permitir Ae B, mas não C, ser passado como argumento para certos métodos.

Isso é uma prática ruim?

Interface que não possui nenhum membro ou tem exatamente os mesmos membros com outra interface herdada da mesma interface chamada Interface do Marcador e você a está usando como marcador.

Não é uma prática recomendada, mas a interface pode ser substituída por atributos (anotações) se o idioma que você estiver usando o suportar.

Posso dizer com confiança que não é uma prática ruim, porque eu vi o padrão "Marker Interface" de uso pesado no Orchard Project

Aqui está um exemplo do projeto 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 {}

Por favor, consulte a Interface do Marcador .

Sim, é uma prática ruim em quase todos os idiomas.

Os tipos não existem para codificar dados; eles são uma ajuda para provar que seus dados vão para onde precisam e se comportam como precisam. A única razão para subtipo é se um comportamento polimórfico muda (e nem sempre então).

Como não há digitação, o que um IDog pode fazer está implícito. Um programador pensa uma coisa, outro pensa outra e as coisas quebram. Ou as coisas que ele representa aumentam à medida que você precisa de um controle mais refinado.

[editar: esclarecimentos]

O que quero dizer é que você está fazendo alguma lógica com base na interface. Por que alguns métodos só funcionam com cães e outros com qualquer animal? Essa diferença é um contrato implícito, pois não há um membro real que forneça a diferença; nenhum dado real no sistema. A única diferença é a interface (daí o comentário 'no digitando'), e o que isso significa será diferente entre os programadores. [/editar]

Certos idiomas fornecem mecanismos de características em que isso não é muito ruim, mas tendem a se concentrar nos recursos, não no refinamento. Tenho pouca experiência com eles, por isso não posso falar com as melhores práticas lá. Em C ++ / Java / C # embora ... não é bom.

Eu só conheço bem C #, então não posso dizer isso para programação OO em geral, mas como um exemplo C #, se você precisar categorizar classes, as opções óbvias são interfaces, propriedade enum ou atributos personalizados. Normalmente eu escolheria a interface, não importa o que os outros pensem.

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.");
    }
}

Não há nada de errado em ter uma interface que herda outra interface sem adicionar novos membros, se for esperado que todas as implementações dessa última interface possam fazer coisas úteis que algumas implementações da anterior podem não ter. De fato, é um bom padrão que o IMHO deveria ter sido usado mais em coisas como o .net Framework, especialmente porque um implementador cuja classe naturalmente satisfaria as restrições implícitas na interface mais derivada pode indicar que simplesmente implementando a interface mais derivada , sem precisar alterar nenhum código ou declaração de implementação de membro.

Por exemplo, suponha que eu tenha as interfaces:

interface IMaybeMutableFoo {
  Bar Thing {get; set;} // E outras propriedades também
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
interface IImmutableFoo: IMaybeMutableFoo {};

IImmutableFoo.AsImmutable()Espera-se que uma implementação de retorne a si mesma; IMaybeMutableFoo.AsImmutable()seria esperado que uma implementação de classe mutável retornasse um novo objeto profundamente imutável contendo um instantâneo dos dados. Uma rotina que deseja armazenar uma captura instantânea dos dados mantidos em um IMaybeMutableFoopode oferecer sobrecargas:

public void StoreData (IImmutableFoo ThingToStore)
{
  // Armazenar a referência será suficiente, pois ThingToStore é conhecido por ser imutável
}
publicDados públicos StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Chame a sobrecarga mais específica
}

Nos casos em que o compilador não sabe que o objeto a ser armazenado é um IImmutableFoo, ele chamará AsImmutable(). A função deve retornar rapidamente se o item já estiver imutável, mas uma chamada de função através de uma interface ainda leva tempo. Se o compilador souber que o item já é um IImmutableFoo, poderá ignorar a chamada de função desnecessária.