Чи погана практика використовувати інтерфейс лише для категоризації?

Наприклад:

Скажімо , у мене є класи A, B, C. У мене два інтерфейси, давайте можемо їх називати IAnimalі IDog. IDogуспадковує від IAnimal. Aі Bє IDogs, хоча Cце не так, але це IAnimal.

Важлива частина полягає в тому, що вона IDogне забезпечує додаткової функціональності. Він використовується лише для того, щоб дозволити Aі B, але ні C, бути переданим як аргумент певним методам.

Це погана практика?

Інтерфейс, який не має жодного учасника або має абсолютно однакові члени з іншим інтерфейсом, який успадковується від того ж інтерфейсу, який називається Marker Interface, і ви використовуєте його як маркер.

Це не погана практика, але інтерфейс можна замінити атрибутами (анотаціями), якщо мова, яку ви використовуєте, підтримує його.

Я з упевненістю можу сказати, що це не погана практика, тому що я бачив схему "Маркерний інтерфейс" в Orchard Project.

Ось зразок проекту «Орчард».

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 {
  Річ бар {get; set;} // та інші властивості
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
інтерфейс IImmutableFoo: IMaybeMutableFoo {};

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

public void StoreData (IImmutableFoo ThingToStore)
{
  // Збереження посилання буде достатньо, оскільки, як відомо, ThingToStore є незмінним
}
публічна недійсна StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Виклик більш конкретного перевантаження
}

У випадках, коли компілятор не знає, що річ, яку потрібно зберігати, є IImmutableFoo, вона зателефонує AsImmutable(). Функція повинна швидко повернутися, якщо елемент вже незмінний, але виклик функції через інтерфейс все-таки потребує часу. Якщо компілятор знає, що елемент вже є IImmutableFoo, він може пропустити непотрібний виклик функції.