Отношение реализации интерфейса C# - это просто отношение «может-сделать»?

Я склонен думать об интерфейсах как о контракте поведения. Такие интерфейсы, как IComparable и IEnumerable, являются классическими примерами.

В приведенном вами примере IHuman и IEngineer на самом деле не являются поведениями.

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

Иногда интерфейсы могут использоваться как возможности, а иногда они могут представлять собой более нормальные отношения «есть-а». Я бы не стал слишком зацикливаться на этом - просто убедитесь, что вы понимаете, что они могут делать, а что нет.

Разработчики платформы .NET используют интерфейсы для обозначения отношения «имеет» (или «может делать»), тогда как «является» реализуется с помощью наследования.

Обоснование этого можно найти в разделе Выбор между классами и интерфейсами Руководства разработчика .NET Framework:

An interface defines the signatures for a set of members that implementers must provide. Interfaces cannot provide implementation details for the members.

Итак, поскольку классы-примеры «Программист» и «Инженер», скорее всего, будут иметь свои собственные специфические функции, их было бы более подходящим образом реализовать с использованием наследования.

Собственно, поэтому большая часть интерфейса - это возможности, а не имена, поэтому у вас есть

IComparable, ITestable, IEnumerable

и

Человек, животное, собака и т. д.

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

Так что, если вы уверены, что интерфейсы действительно лучше подходят вашему дизайну, дерзайте, не беспокойтесь о таких вопросах, как этот.

Нашел этот вопрос довольно поздно, но я хотел вмешаться.

Интерфейсы в C# имеют отношение «есть-объект», но не «объект-объект». Скорее это реализация.

Другими словами, для класса Foo, реализующего IBar, следующий тест:

Foo myFoo = new Foo(); 
return myFoo is IBar;

буквально возвращает истину. Вы также можете сказать,

IBar bar = myArrayList[3] as IBar;
Foo foo = bar as Foo;

Или, если для метода требуется IBar, вы можете передать Foo.

void DoSomething(IBar bar) {
}

static void Main() {
    Foo myFoo = new Foo();
    DoSomething(myFoo);
}

Очевидно, что IBar сам по себе не имеет реализации, поэтому отношение «можно сделать» также применимо.

interface IBar { void happy(); }
class Foo : IBar
{
    void happy()
    {
        Console.Write("OH MAN I AM SO HAPPY!");
    }
}
class Program
{
    static void Main()
    {
        IBar myBar = new Foo();
        myBar.happy();
    }
}

Но в этом отношении то же самое верно и для наследования объектов; объект класса Foo, который наследует класс Bar, имеет отношение «можно сделать», а также отношение «есть-есть», точно так же, как и интерфейс. Просто его реализация была заранее построена для этого.

Настоящий вопрос: а-какие, может-сделать-какие? Унаследованный объект класса - это -a-[родительский экземпляр] и can-do-[поведение родителей], тогда как реализация интерфейса-an-[реализация интерфейса] и, следовательно, can-do-[поведение интерфейса].

В большинстве случаев, когда используются программные отношения is-a, такие как перечисленные выше, оценивается только интерфейс, поэтому и унаследованный класс, и реализованный интерфейс имеют одинаковые качества is-a и can-do.

HTH, Джон