Интерфейс против Базового класса

В целом необходимо одобрить интерфейсы по абстрактным классам. Одна причина использовать абстрактный класс состоит в том, если у Вас есть общая реализация среди реальных классов. Конечно, необходимо все еще объявить интерфейс (IPet) и иметь абстрактный класс (PetBase) реализация тот интерфейс. Используя маленькие, отличные интерфейсы, можно использовать кратные числа для дальнейшего улучшения гибкости. Интерфейсы позволяют максимальное количество гибкости и мобильность типов через границы. Когда передающие ссылки через границы, всегда передавайте интерфейс а не конкретный тип. Это позволяет принимающему концу определять конкретную реализацию и обеспечивает максимальную гибкость. Это абсолютно верно при программировании способом TDD/BDD.

Банда Четырех указанных в их книге, "Поскольку наследование представляет подкласс деталям реализации его родителя, часто говорится, что 'наследование повреждает инкапсуляцию". Я полагаю, что это верно.

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

Это не может иметь столько же смысла логически, чтобы сказать, что у Собаки и CAT оба "есть" Домашнее животное, но это избегает ловушек наследования общего множителя:

public class Pet
{
    void Bathe();
    void Train(Trick t);
}

public class Dog
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

public class Cat
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

Да, этот пример показывает, что существует много дублирования кода и отсутствие элегантности, вовлеченной в выполнение вещей этот путь. Но нужно также ценить, что это помогает сохранить Собаку и CAT разъединенными от Любимого класса (у той Собаки, и CAT не имеют доступа к членам парламента, не занимающим официального поста Домашнего животного), и это оставляет комнату для Собаки и CAT для наследования чему-то еще - возможно класс Млекопитающего.

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

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

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

Krzysztof Cwalina говорит на странице 81:

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

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

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

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

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

Так вместо IPet или PetBase, Вы могли бы закончить с Домашним животным, которое имеет параметр IFurBehavior. Параметр IFurBehavior устанавливается CreateDog () метод PetFactory. Именно этот параметр называют для сарая () методом.

, Если Вы делаете это, Вы найдете, что Ваш код намного более гибок и большая часть Вашего соглашения о простых объектах с очень простыми поведениями в масштабе всей системы.

я рекомендую этот шаблон даже на нескольких-inheritence языков.

Вот основное и простое определение интерфейсного и базового класса:

• Базовый класс = возражают наследованию.
• Интерфейс = функциональное наследование.

аплодисменты

Juan,

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

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

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

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

Поэтому, если бы Вы думаете как я, что определенно сказали бы, что CAT и Собака являются IPettable. Это - характеристика, которая соответствует им обоим.

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

Говорят, что я хочу собрать все классы Животных и поместить их в мой контейнер Ковчега.

Или они должны быть Млекопитающими? Возможно, нам нужно некоторое перекрестное животное, доящее фабрику?

они должны даже быть соединены вообще? Достаточно просто знать, что они - оба IPettable?

я часто чувствую требование получить целую иерархию классов, когда мне действительно просто нужен один класс. Я делаю это в ожидании когда-нибудь, мне, возможно, понадобился бы он, и обычно я никогда не делаю. Даже когда я делаю, я обычно нахожу, что должен сделать много для фиксации его. That’s, потому что первый класс я создаю, не является Собакой, я не настолько удачлив, это - вместо этого Утконос. Теперь моя вся иерархия классов основана на причудливом случае, и у меня есть много потраченного впустую кода.

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

Также имейте в виду, чтобы не быть отметенными в OO (, видят блог ), и всегда объекты модели на основе требуемого поведения, если бы Вы разрабатывали приложение, где единственное поведение, которого Вы потребовали, было родовым названием и разновидностями для животного тогда, то Вам только был бы нужен один класс Животное со свойством для имени вместо миллионов классов для каждого возможного животного в мире.

Интерфейсы должны быть маленькими. Действительно маленький. Если Вы действительно сломаете свои объекты, то Ваши интерфейсы будут, вероятно, только содержать несколько очень определенных методов и свойств.

Абстрактные классы являются ярлыками. Есть ли вещи, что все производные доли PetBase, которую можно кодировать однажды и быть сделаны с? Если да, то время для абстрактного класса.

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

Абстрактные классы могут содержать несколько интерфейсов. Ваш абстрактный класс PetBase может реализовать IPet (у домашних животных есть владельцы), и IDigestion (домашние животные едят, или по крайней мере они должны). Однако PetBase, вероятно, не реализует IMammal, с тех пор не, все домашние животные являются млекопитающими, и не все млекопитающие домашние животные. Можно добавить MammalPetBase, который расширяет PetBase, и добавьте IMammal. FishBase мог иметь PetBase и добавить IFish. IFish имел бы ISwim и IUnderwaterBreather как интерфейсы.

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

Случай для Базовых классов по Интерфейсам был объяснен хорошо в Подосновных Инструкциях по Кодированию.NET:

Базовые классы по сравнению с Интерфейсами интерфейсный тип является частичным описанием значения, потенциально поддерживаемого многими типами объектов. Используйте базовые классы вместо интерфейсов, когда это возможно. С точки зрения управления версиями классы более гибки, чем интерфейсы. С классом можно поставить Версию 1.0, и затем в Версии 2.0 добавляют новый метод к классу. Пока метод не абстрактен, любые существующие производные классы продолжают функционировать неизменные.

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

1. Несколько несвязанных классов хотят поддерживать протокол.
2. Эти классы уже установили базовые классы (например, некоторые - средства управления пользовательским интерфейсом (UI), и некоторые - веб-сервисы XML).
3. Агрегирование не является соответствующим или реальным. Во всех других ситуациях наследование классов является лучшей моделью.

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

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

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

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

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

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

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

Объясненный хорошо в этом статья

Java World Лично я склонен использовать интерфейсы для определения интерфейсов - т.е. части проектирования системы, которые определяют, как к чему-то нужно получить доступ.

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

Абстрактные классы я использую в качестве основания для чего-то еще.

следующее является выпиской из вышеупомянутой статьи JavaWorld.com статьи , автора Tony Sintes, <час> 04/20/01

, Интерфейс по сравнению с интерфейсами Выбора абстрактного класса

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

Абстрактные классы позволяют Вам определить некоторые поведения; они вынуждают Ваши подклассы предоставить другим. Например, если у Вас есть среда разработки приложения, абстрактный класс может предоставить услуги по умолчанию, такие как обработка событий и обработка сообщений. Те сервисы позволяют Вашему приложению включать к Вашей среде разработки приложения. Однако существует некоторая специализированная функциональность, которую только может выполнить Ваше приложение. Такая функциональность могла бы включать запуск и завершить работу задач, которые являются часто зависящими от приложения. Таким образом вместо того, чтобы пытаться определить то поведение само, абстрактный базовый класс может объявить абстрактное завершение работы и запустить методы. Базовый класс знает, что ему нужны те методы, но абстрактный класс позволяет Вашему классу признать, что он не знает, как выполнить те действия; это только знает, что должно инициировать действия. Когда пора запустить, абстрактный класс может назвать метод запуска. Когда базовый класс называет этот метод, Java называет метод определенным дочерним классом.

Многие разработчики забывают, что класс, который определяет абстрактный метод, может назвать тот метод также. Абстрактные классы являются отличным способом создать запланированные иерархии наследования. Они - также хороший выбор для нелистовых классов в иерархиях классов.

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

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

, Например, Стратегическая модель позволяет Вам подкачать новые алгоритмы и процессы в Вашу программу, не изменяя объекты, которые используют их. Медиаплеер мог бы знать, как играть CD, MP3s и wav файлы. Конечно, Вы не хотите к hardcode те алгоритмы воспроизведения в плеер; это будет мешать добавлять новый формат как AVI. Кроме того, Ваш код будет замусорен бесполезными операторами выбора. И добавить оскорбление травмы, необходимо будет обновить те операторы выбора каждый раз, когда Вы добавляете новый алгоритм. В целом, это не очень объектно-ориентированный способ программировать.

Со Стратегической моделью, можно просто инкапсулировать алгоритм позади объекта. Если Вы делаете это, можно обеспечить новые плагины медиа в любое время. Давайте назовем сменный класс MediaStrategy. Тот объект имел бы один метод: playStream (Поток s). Таким образом для добавления нового алгоритма мы просто расширяем наш класс алгоритма. Теперь, когда программа встречается с новым типом среды, она просто делегирует игру потока к нашей стратегии медиа. Конечно, Вам будет нужна некоторая инфраструктура для надлежащего инстанцирования стратегий алгоритма, в которых Вы будете нуждаться.

Это - превосходное место для использования интерфейса. Мы использовали Стратегическую модель, которая ясно указывает на место в дизайне, который изменится. Таким образом необходимо определить стратегию как интерфейс. Необходимо обычно одобрять интерфейсы по наследованию, когда Вы хотите объект иметь определенный тип; в этом случае, MediaStrategy. Доверие наследованию для идентификационных данных типа опасно; это блокирует Вас в конкретную иерархию наследования. Java не позволяет множественное наследование, таким образом, Вы не можете расширить что-то, что дает Вам полезную реализацию или больше идентификационных данных типа.