Отношения Реализации Интерфейса C# просто, “Может - Делать” Отношения?

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

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

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

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

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

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

буквально возвращает true. Можно также сказать,

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

Или, если метод требует IBar, можно передать Нечто.

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, который наследовал класс Панель, есть банка - делает отношения, а также - отношения, таким же образом как интерфейс делает. Это просто, что его реализация была предварительно создана для него.

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

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

HTH, Jon

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

IComparable, ITestable, IEnumerable

и

Человек, Животное, Собака, и т.д.

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

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

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

Объяснение для этого может быть найдено в разделе Choosing Between Classes и Interfaces Руководства Разработчика инфраструктуры.NET:

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

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