Краткий обзор по сравнению с Интерфейсом - разделение определения и implemention в Delphi

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

• Наследование классов отвечает на вопрос: "Что это за объект?"
• Реализация интерфейса отвечает на вопрос: "Что я могу сделать с этим объектом?"

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

type
    TMaterial = (mtPlastic, mtSteel, mtSilver);

    TUtensil = class
    public
        function GetWeight : Integer; virtual; abstract;
        procedure Wash; virtual; // Yes, it's self-cleaning
    published
        property Material : TMaterial read FMaterial write FMaterial;
    end;

Все это описывает данные и функциональность, общие для любой посуды - из чего она сделана, сколько весит (что зависит от конкретного типа) и т. д. Но вы заметите, что абстрактный класс на самом деле не делает ничего. У TFork и TKnife на самом деле нет ничего общего, что можно было бы поместить в базовый класс. Технически вы можете Резать с помощью TFork, но TSpoon может быть натяжкой, так как же отразить тот факт, что только некоторые предметы посуды могут делать определенные вещи?

Ну, мы можем начать расширять иерархию, но это становится запутанным:

type
    TSharpUtensil = class
    public
        procedure Cut(food : TFood); virtual; abstract;
    end;

Это позаботится об острых, но что, если мы хотим сгруппировать вот так?

type
    TLiftingUtensil = class
    public
        procedure Lift(food : TFood); virtual; abstract;
    end;

TFork и TKnife подойдут под TSharpUtensil, но TKnife довольно паршиво подходит для поднятия куска курицы. В итоге нам придется либо выбрать одну из этих иерархий, либо просто запихнуть всю эту функциональность в общий TUtensil и заставить производные классы просто отказаться реализовывать методы, которые не имеют смысла. С точки зрения дизайна, это не та ситуация, в которой мы хотим оказаться.

Конечно, настоящая проблема заключается в том, что мы используем наследование для описания того, что объект делает, а не того, чем он является. Для первого у нас есть интерфейсы. Мы можем значительно очистить эту конструкцию:

type
    IPointy = interface
        procedure Pierce(food : TFood);
    end;

    IScoop = interface
        procedure Scoop(food : TFood);
    end;

Теперь мы можем разобраться с тем, что делают конкретные типы:

type
    TFork = class(TUtensil, IPointy, IScoop)
        ...
    end;

    TKnife = class(TUtensil, IPointy)
        ...
    end;

    TSpoon = class(TUtensil, IScoop)
        ...
    end;

    TSkewer = class(TStick, IPointy)
        ...
    end;

    TShovel = class(TGardenTool, IScoop)
        ...
    end;

Я думаю, все поняли идею. Суть (без каламбура) в том, что мы имеем очень тонкий контроль над всем процессом, и нам не приходится идти на компромиссы. Мы используем здесь и наследование и интерфейсы, эти варианты не являются взаимоисключающими, просто мы включаем в абстрактный класс только ту функциональность, которая действительно есть, действительно общие для всех производных типов.

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

type
    TDishwasher = class
        procedure Wash(utensils : Array of TUtensil);
    end;

Это имеет смысл, потому что в посудомоечную машину попадает только посуда, по крайней мере, на нашей очень ограниченной кухне, которая не включает такие предметы роскоши, как тарелки или чашки. TSkewer и TShovel, вероятно, туда не попадают, хотя технически они могут участвовать в процессе еды.

С другой стороны:

type
    THungryMan = class
        procedure EatChicken(food : TFood; utensil : TUtensil);
    end;

Это может быть не очень хорошо. Он не может есть только TKnife (ну, не легко). И требование наличия TFork и TKnife тоже не имеет смысла; что если это куриное крылышко?

Это имеет гораздо больше смысла:

type
    THungryMan = class
        procedure EatPudding(food : TFood; scoop : IScoop);
    end;

Теперь мы можем дать ему TFork, TSpoon или TShovel, и он будет счастлив, но не TKnife, который все еще является утварью, но не очень-то здесь помогает.

Вы также заметите, что вторая версия менее чувствительна к изменениям в иерархии классов. Если мы решим изменить TFork, чтобы он наследовался от TWeapon, наш человек будет счастлив, пока он по-прежнему реализует IScoop.

Я также немного упустил вопрос подсчета ссылок, и я думаю, что @Deltics сказал это лучше всего; только потому, что у вас есть AddRef, не значит, что вам нужно делать с ним то же самое, что делает TInterfacedObject. Счетчик интерфейсных ссылок - это как бы случайная функция, это полезный инструмент для тех случаев, когда он вам нужен, но если вы собираетесь смешивать семантику интерфейса с семантикой класса (а очень часто так и происходит), то не всегда имеет смысл использовать функцию счетчика ссылок как форму управления памятью.

На самом деле, я бы даже сказал, что в большинстве случаев семантика подсчета ссылок вам, вероятно, не нужна. Да, вот, я сказал это. Я всегда считал, что вся эта история с подсчетом ссылок нужна только для поддержки автоматизации OLE и тому подобного (IDispatch). Если у вас нет веских причин желать автоматического уничтожения вашего интерфейса, просто забудьте об этом, не используйте TInterfacedObject вообще. Вы всегда сможете изменить его, когда он вам понадобится - в этом смысл использования интерфейса! Думайте об интерфейсах с точки зрения высокоуровневого проектирования, а не с точки зрения управления памятью/временем жизни.

Итак, мораль истории такова:

• Когда вам требуется, чтобы объект поддерживал определенную функциональность, старайтесь использовать интерфейс.

• Когда объекты относятся к одному семейству и вы хотите, чтобы они имели общие функции, наследуйте от общего базового класса.

• И если обе ситуации применимы, то используйте обе!