Czy złym zwyczajem jest używanie interfejsu wyłącznie do kategoryzacji?

Na przykład:

Że mam zajęcia A, B, C. Mam dwa interfejsy, nazwijmy je IAnimali IDog. IDogdziedziczy po IAnimal. Ai Bsą IDog, chociaż Cnie jest, ale jest IAnimal.

Ważną częścią jest to, że IDognie zapewnia żadnej dodatkowej funkcjonalności. Służy wyłącznie do zezwalania Ai przekazywania B, ale nie Cdo przekazania, jako argumentu dla niektórych metod.

Czy to zła praktyka?

Interfejs, który nie ma żadnego członka lub ma dokładnie takie same elementy z innym interfejsem, który jest dziedziczony z tego samego interfejsu o nazwie Interfejs znaczników i używasz go jako znacznika.

Nie jest to zła praktyka, ale interfejs można zastąpić atrybutami (adnotacjami), jeśli używany język go obsługuje.

Mogę śmiało powiedzieć, że nie jest to zła praktyka, ponieważ widziałem intensywne użycie wzoru „Interfejs znacznika” w Orchard Project

Oto próbka z projektu 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 {}

Proszę zapoznać się z interfejsem znacznika .

Tak, to zła praktyka w prawie każdym języku.

Nie ma typów do kodowania danych; pomagają udowodnić, że Twoje dane idą tam, gdzie powinny, i zachowują się tak, jak powinny. Jedynym powodem podtypu jest zmiana zachowania polimorficznego (i nie zawsze wtedy).

Ponieważ nie ma potrzeby pisania, implikowane jest to, co może zrobić IDog. Jeden programista myśli jedną rzecz, inny myśli inną i wszystko się psuje. Lub rzeczy, które reprezentuje, zwiększają się, ponieważ potrzebujesz bardziej precyzyjnej kontroli.

[edytuj: wyjaśnienie]

Chodzi mi o to, że robisz jakąś logikę opartą na interfejsie. Dlaczego niektóre metody mogą działać tylko z psami, a inne z jakimkolwiek zwierzęciem? Ta różnica jest umową dorozumianą, ponieważ nie ma rzeczywistego członka, który zapewniłby różnicę; brak rzeczywistych danych w systemie. Jedyną różnicą jest interfejs (stąd komentarz „bez pisania na klawiaturze”), co oznacza, że różni się on między programistami. [/edytować]

Niektóre języki zapewniają mechanizmy cech, które nie są takie złe, ale te zwykle koncentrują się na możliwościach, a nie na wyrafinowaniu. Mam z nimi niewielkie doświadczenie, więc nie mogę porozmawiać z najlepszymi praktykami. W C ++ / Java / C # jednak ... nie dobrze.

Znam tylko język C #, więc nie mogę tego powiedzieć ogólnie o programowaniu OO, ale jako przykład w języku C #, jeśli chcesz sklasyfikować klasy, oczywistymi opcjami są interfejsy, właściwość enum lub niestandardowe atrybuty. Zwykle wybieram interfejs bez względu na to, co myślą inni.

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

Nie ma nic złego w posiadaniu interfejsu, który dziedziczy inny interfejs bez dodawania nowych członków, jeśli można oczekiwać, że wszystkie implementacje tego drugiego interfejsu będą w stanie użytecznie robić rzeczy, których niektóre implementacje pierwszego nie mogą. Rzeczywiście, jest to dobry wzorzec, który IMHO powinien był być bardziej używany w takich rzeczach, jak .NET Framework, zwłaszcza że implementator, którego klasa naturalnie spełniałaby ograniczenia wynikające z bardziej pochodnego interfejsu, może to wskazać po prostu przez implementację bardziej pochodnego interfejsu , bez konieczności zmiany kodu implementacyjnego członka ani deklaracji.

Załóżmy na przykład, że mam interfejsy:

interfejs IMaybeMutableFoo {
  Bar Thing {get; set;} // Oraz inne właściwości
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
interfejs IImmutableFoo: IMaybeMutableFoo {};

IImmutableFoo.AsImmutable()Oczekuje się, że wdrożenie się zwróci; IMaybeMutableFoo.AsImmutable()oczekuje się, że implementacja klasy mutable zwróci nowy głęboko niezmienny obiekt zawierający migawkę danych. Procedura, która chce przechowywać migawkę danych przechowywanych w, IMaybeMutableFoomoże oferować przeciążenia:

public void StoreData (IImmutableFoo ThingToStore)
{
  // Przechowywanie referencji wystarczy, ponieważ ThingToStore jest znany jako niezmienny
}
public void StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Wywołaj bardziej szczegółowe przeciążenie
}

W przypadkach, w których kompilator nie wie, że rzeczą do zapisania jest IImmutableFoo, wywoła AsImmutable(). Funkcja powinna szybko wrócić, jeśli element jest już niezmienny, ale wywołanie funkcji przez interfejs nadal zajmuje trochę czasu. Jeśli kompilator wie, że element jest już IImmutableFoo, może pominąć niepotrzebne wywołanie funkcji.