Класс против интерфейса

• Прочтите статью в Википедии

• Прочтите книгу, затем снова прочтите главы о ООП

• В вашем примере, Человек должен быть классом, потому что он содержит детали реализации , которые являются общими для Доктора и Клиента .

• интерфейсы не имеют (и не нуждаются) в деталях реализации - они только указывают , что объекты, которые их реализуют, делают. Не как . Почему это полезно? Потому что, когда вы используете объект, вам все равно , как он будет выполнять свою работу.

Давайте посмотрим на простой пример - есть интерфейсы Comparable (по крайней мере, на Java). Он означает , что его разработчики могут сравниваться друг с другом. Таким образом, у вас может быть два класса:

class Doctor implements Comparable {..}

class Customer implements Comparable {..}

Теперь у вас может быть общий метод, который принимает любой набор объектов , реализующих Comparable и вызывающий сопоставимый1 .compareTo (сопоставимый2) , потому что вы знаете , что они могут выполнять сравнение - это обозначается их интерфейсом .

Интерфейсы используются для обеспечения соблюдения определенных методов / свойств. В двух словах, интерфейс - это набор правил.

Класс может использоваться для наследования / переопределения базовой функциональности.

Посмотрите на

• Разницу между классом и интерфейсом в C #?
• C #: Интерфейс против класса
• Абстрактный класс против интерфейса
• Интерфейс (Справочник по C #)

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

Во-вторых, класс может расширять только ОДИН класс. Интерфейсы этим не ограничиваются, поэтому мы можем иметь множественное наследование, например,

public class foo extends Person implements Man, Mammal

foo - это Person. Это также Человек и Млекопитающее;

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

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

Проще говоря, вы используете классы, когда задействован код / ​​реализация и интерфейсы, когда это просто описания интерфейсов. Обращаясь к объектам в вашем коде, предпочитайте ссылаться на интерфейсы, так как это упрощает замену фактической реализации (или добавление дополнительных и различных реализаций).

И да, и Docor, и Клиент / Пациент могут внедрить или расширить Person.

При использовании Maven 2 можно просто создать несколько родительских уровней. Первые pom.xml ( pom1 ) определяют основные свойства (например, репозитории). Вторая pom.xml ( pom2 ), которая имеет pom1 в качестве < родителя > , определяет отчетную информацию. И так далее... Наконец, «real» pom.xml наследует от pom2 и определит его собственные свойства.

Можно создать сколько угодно родительских уровней (конечно, будет труднее поддерживать, если у вас есть 5 родительских уровней).

Обратите внимание, что Maven 3 говорил о введении mixin концепции , которая позволит вам разделить ваш pom.xml на несколько файлов, но это выглядит как , что не происходит сейчас, пока maven 4

Бен Райан имеет регки вы ищете в его блоге:

• http://blogs.msdn.com/benryan/archive/2007/12/12/when-and-how-does-my-solution-go-offline.aspx
• http://blogs.msdn.com/benryan/archive/2007/12/12/how-to-make-tfs-offline-strictly-solution-based.aspx

Большинство этих элементов управления также встроено в новейшие силовые инструменты :

C:\Users\Richard> tfpt tweakui /?
tfpt tweakui - Enhance how client connects to Team Foundation Server

Allows configuration of how and when the client connects to a 
Team Foundation Server.  This includes client certificates, auto
reconnect, offline, compression, maximum connections, timeouts, 
and bypassing the proxy.

В C # множественное наследование может быть получено только через интерфейс. Основываясь на бизнес-требовании, если требуется, чтобы класс нуждался в множественном наследовании fwd, используйте Interface else use class.

Также все члены интерфейсов должны быть определены в классе, т.е. Члены интерфейсов должны быть реализованы членами.

Думайте об интерфейсе как о контракте. Класс может зафиксировать контракт (реализовать интерфейс)

Предположим, у вас есть класс Person с подклассами Doctor и Patient. Тогда у вас будет интерфейс Treatable с методом getSymptoms (), реализованным пациентом, и интерфейс Treating с методом cure (Treatable), реализованным Doctor. Скорее всего, cure (Treatable) в какой-то момент вызовет getSymptoms () ...

Родительский класс - это тот, который будет обладать минимальными свойствами, общими для всех его подклассов.

Но интерфейс - это контракт, который говорит его имплантации, что она должна предоставить, если она не является абстрактным классом.

И одно важное различие между классом и интерфейсом заключается в том, что

наследование класса дает связь между двумя общими подклассами.

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

класс предполагает, что объект, который наследует базовый класс - это своего рода этот класс

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

• Интерфейс - описать поведение
• Класс - выполнить поведение

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

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

Итак, настоящий ответ: это зависит от вашего дизайна.

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