Когда использовать интерфейс вместо абстрактного класса и наоборот?

Абстрактный класс может иметь реализации.

интерфейс не имеет реализаций, он просто определяет своего рода контракт.

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

Это может быть очень трудным вызовом для создания...

Один указатель я могу дать: объект может реализовать много интерфейсов, пока объект может только наследовать один базовый класс (на современном языке OO как c#, я знаю, что C++ имеет множественное наследование - но разве который не осужден?)

Используйте абстрактный класс, если Вы хотите обеспечить некоторые базовые внедрения.

в Java можно наследоваться одному (абстрактному) классу для "обеспечивания" функциональности, и можно реализовать много интерфейсов для "гарантирования" функциональности

Одно интересное местоположение, где тариф интерфейсов лучше, чем абстрактные классы - когда необходимо добавить дополнительную функциональность к группе (связанный или не связанный) объекты. Если Вы не можете дать им основной абстрактный класс (например, они - sealed или уже имеют родителя), можно дать им фиктивный (пустой) интерфейс и затем просто записать дополнительные методы для того интерфейса.

Просто на основе наследования, Вы использовали бы Краткий обзор, где Вы определяете ясно потомка, абстрактные отношения (т.е. животное-> кошка) и/или требуете наследования виртуальных или непубличных свойств, особенно общее состояние (который Интерфейсы не могут поддерживать).

необходимо попытаться одобрить состав (через внедрение зависимости) по наследованию, где Вы можете, хотя, и отмечают, что Интерфейсы, являющиеся контрактами, поддерживают поблочное тестирование, разделение проблем и (варьирование языка) множественное наследование способом, Краткие обзоры не могут.

Ответы варьируются между языками. Например, в Java класс может реализовать (наследуйтесь), несколько интерфейсов, но только наследовались одному абстрактному классу. Таким образом, интерфейсы дают Вам больше гибкости. Но это не верно в C++.

Абстрактный класс может иметь общее состояние или функциональность. Интерфейс является только обещанием обеспечить состояние или функциональность. Хороший абстрактный класс уменьшит объем кода, который должен быть переписан, потому что это - функциональность, или состояние может быть совместно использовано. Интерфейс не имеет никакой определенной информации, которая будет совместно использована

Когда сделать то, что является очень простой вещью, если у Вас есть понятие, ясное в Вашем уме.

Абстрактные классы могут быть Получены, тогда как Интерфейсы могут быть Реализованы. Существует некоторое различие между двумя. То, когда Вы получаете Абстрактный класс, отношения между производным классом и базовым классом, 'является' отношениями. например, Собака является Животным, Овца является Животным, что означает, что Производный класс наследовал некоторые свойства от базового класса.

принимая во внимание, что для реализации интерфейсов, отношения, "может быть". например, Собака может быть собакой шпиона. Собака может быть собакой цирка. Собака может быть собакой гонки. Что означает, что Вы реализуете определенные методы для получения чего-то.

я надеюсь, что я ясен.

Лично, у меня почти никогда нет потребности записать абстрактные классы.

Большинство раз я вижу, что абстрактные классы используемый (mis), это - потому что автор абстрактного класса использует "Шаблонный шаблон" метода.

проблема с "Шаблонным методом" состоит в том, что это почти всегда несколько повторно используемо - "полученный" класс знает о не только "абстрактный" метод его базового класса, который это реализует, но также и об открытых методах базового класса, даже при том, что большинство раз это не должно называть их.

(Чрезмерно упрощенный) пример:

abstract class QuickSorter
{
    public void Sort(object[] items)
    {
        // implementation code that somewhere along the way calls:
        bool less = compare(x,y);
        // ... more implementation code
    }
    abstract bool compare(object lhs, object rhs);
}

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

, Таким образом, намеченное использование - что-то вроде этого:

class NameSorter : QuickSorter
{
    public bool compare(object lhs, object rhs)
    {
        // etc.
    }
}

проблема с этим состоит в том, что Вы незаконно связали вместе два понятия:

1. А способ сравнить два объекта (какой объект должен пойти сначала)
2. метод А элементов сортировки (т.е. quicksort по сравнению с сортировкой слиянием и т.д.)

В вышеупомянутом коде, теоретически, авторе "сравнить" метода может повторно используемо , перезванивают в суперкласс метод "Вида"... даже при том, что в практике они никогда не будут хотеть или должны сделать это.

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

альтернативный метод должен использовать шаблон разработки "Стратегии" вместо этого:

interface IComparator
{
    bool compare(object lhs, object rhs);
}

class QuickSorter
{
    private readonly IComparator comparator;
    public QuickSorter(IComparator comparator)
    {
        this.comparator = comparator;
    }

    public void Sort(object[] items)
    {
        // usual code but call comparator.Compare();
    }
}

class NameComparator : IComparator
{
    bool compare(object lhs, object rhs)
    {
        // same code as before;
    }
}

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

Для "скрытия" того, что мы реализовали "сортировку имен" при помощи класса "QuickSort" и "NameComparator" мы могли бы все еще записать метод фабрики где-нибудь:

ISorter CreateNameSorter()
{
    return new QuickSorter(new NameComparator());
}

Любой время у Вас есть абстрактный класс, можно сделать это..., даже когда существуют естественные повторно используемые отношения между основой и производным классом, это обычно платит для создания их явными.

Одна последняя мысль: Все, что мы сделали выше, "составляют" функцию "NameSorting" при помощи функции "QuickSort" и функции "NameComparison"... на языке функционального программирования, этот стиль программирования становится еще более естественным с меньшим количеством кода.

Я написал статью того, когда использовать абстрактный класс и когда использовать интерфейс. Существует намного больше различия между ними кроме "одного ISA..., и один CAN - ДЕЛАЮТ...". Мне это - консервированные ответы. Я упоминаю несколько причин, когда использовать любого из них. Надежда это помогает.

http://codeofdoom.com/wordpress/2009/02/12/learn-this-when-to-use-an-abstract-class-and-an-interface/

OK, having just "grokked" this myself - here it is in layman's terms (feel free to correct me if I am wrong) - I know this topic is oooooold, but someone else might stumble across it one day...

Abstract classes allow you to create a blueprint, and allow you to additionally CONSTRUCT (implement) properties and methods you want ALL its descendants to possess.

An interface on the other hand only allows you to declare that you want properties and/or methods with a given name to exist in all classes that implement it - but doesn't specify how you should implement it. Also, a class can implement MANY interfaces, but can only extend ONE Abstract class. An Interface is more of a high level architectural tool (which becomes clearer if you start to grasp design patterns) - an Abstract has a foot in both camps and can perform some of the dirty work too.

Why use one over the other? The former allows for a more concrete definition of descendants - the latter allows for greater polymorphism. This last point is important to the end user/coder, who can utilise this information to implement the A.P.I(nterface) in a variety of combinations/shapes to suit their needs.

I think this was the "lightbulb" moment for me - think about interfaces less from the author's perpective and more from that of any coder coming later in the chain who is adding implementation to a project, or extending an API.