Сторона. В отличие от многих других видов интерфейсов , интерфейс в ООП является строго формализованным элементом объектно-ориентированного языка и, в качестве семантической конструкции, широко используется кодом программы.
Описание ООП-интерфейса, если отвлечься от деталей синтаксиса конкретных языков, состоит из двух частей:
Использование интерфейсов возможно двумя способами:
Как правило, в объектно-ориентированных языках программирования интерфейсы, как и классы, могут наследоваться друг от друга. В этом случае интерфейс-потомок включает все методы интерфейса-предка и, возможно, добавляет к ним свои собственные.
Таким образом, с одной стороны, интерфейс - это контракт, который обязуется выполнить класс , реализующий его, с другой стороны, интерфейс - это тип данных, потому что его описание достаточно четко определяет свойства объектов, чтобы наравне с классом типизировать переменные. Следует, однако, подчеркнуть, что интерфейс не является полноценным типом данных, так как он задаёт только внешнее поведение объектов. Внутреннюю структуру и реализацию заданного интерфейсом поведения обеспечивает класс, реализующий интерфейс; именно поэтому «экземпляров интерфейса» в чистом виде не бывает, и любая переменная типа «интерфейс» содержит экземпляры конкретных классов.
Использование интерфейсов - один из вариантов обеспечения полиморфизма в объектных языках и средах. Все классы, реализующие один и тот же интерфейс с точки зрения определяемого им поведения ведут себя внешне одинаково. Это позволяет писать обобщённые алгоритмы обработки данных, использующие в качестве типов параметров интерфейсы, и применять их к объектам различных типов, всякий раз получая требуемый результат.
Например, интерфейс «Cloneable» может описать абстракцию клонирования (создания точных копий) объектов, специфицировав метод «Clone», который должен выполнять копирование содержимого объекта в другой объект того же типа. Тогда любой класс, объекты которого может понадобиться копировать, должен реализовать интерфейс Cloneable и предоставить метод Clone, а в любом месте программы, где требуется клонирование объектов, для этой цели у объекта вызывается метод Clone. Причем использующему этот метод коду достаточно иметь только описание интерфейса, он может ничего не знать о фактическом классе, объекты которого копируются. Таким образом, интерфейсы позволяют разбить программную систему на модули без взаимной зависимости кода.
Можно заметить, что интерфейс, с точки зрения реализации - это просто чистый абстрактный класс , то есть класс, в котором не определено ничего, кроме абстрактных методов . Если язык программирования поддерживает множественное наследование и абстрактные методы (как, например, C++), то необходимости во введении в синтаксис языка, отдельного понятия «интерфейс» не возникает. Данные сущности описываются с помощью абстрактных классов и наследуются классами для реализации абстрактных методов.
Однако поддержка множественного наследования в полном объёме достаточно сложна и вызывает множество проблем, как на уровне реализации языка, так и на уровне архитектуры приложений. Введение понятия интерфейсов является компромиссом, позволяющим получить многие преимущества множественного наследования (в частности, возможность удобно определять логически связанные наборы методов в виде сущностей, подобных классам и допускающим наследование и реализацию), не реализуя его в полном объёме и не сталкиваясь, таким образом, с большинством вызванных им трудностей.
Как правило, языки программирования разрешают наследовать интерфейс от нескольких интерфейсов-предков. Все методы, объявленные в интерфейсах-предках, становятся частью объявления интерфейса-потомка. В отличие от наследования классов, множественное наследование интерфейсов гораздо проще реализуется и не вызывает существенных затруднений.
Тем не менее, одна коллизия при множественном наследовании интерфейсов и при реализации нескольких интерфейсов одним классом всё-таки возможна. Она возникает, когда в двух или более интерфейсах, наследуемых новым интерфейсом или реализуемых классом, имеются методы с одинаковыми сигнатурами. Разработчики языков программирования вынуждены выбирать для таких случаев те или иные способы разрешения противоречий. Вариантов здесь несколько:
Реализация интерфейсов во многом определяется исходными возможностями языка и целью, с которой интерфейсы введены в него. Очень показательны особенности использования интерфейсов в языках C++, D, Java и Object Pascal системы Delphi, поскольку они демонстрируют три принципиально разные ситуации:
Объявление интерфейсов очень похоже на упрощенное объявление классов.
Оно начинается с заголовка. Сначала указываются модификаторы. Интерфейс может быть объявлен как public и тогда он будет доступен для общего использования, либо модификатор доступа может не указываться, в этом случае интерфейс доступен только для типов своего пакета . Модификатор abstract для интерфейса не требуется, поскольку все интерфейсы являются абстрактными . Его можно указать, но делать этого не рекомендуется, чтобы не загромождать код .
После этого может следовать ключевое слово extends и список интерфейсов, от которых будет наследоваться объявляемый интерфейс. Родительских типов может быть много, главное, чтобы не было повторений и чтобы отношение наследования не образовывало циклической зависимости.
Наследование интерфейсов действительно очень гибкое. Так, если есть два интерфейса, A и B , причем B наследуется от A , то новый интерфейс C может наследоваться от них обоих. Впрочем, понятно, что указание наследования от A является избыточным, все элементы этого интерфейса и так будут получены по наследству через интерфейс B.
Int RIGHT=1; int LEFT=2; int UP=3; int DOWN=4;
Все методы интерфейса являются public abstract и эти модификаторы также необязательны.
Обсуждая с различными людьми - в большинстве своём опытными разработчиками - классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП - различия классов и интерфейсов.
Авторам книги этот вопрос кажется настолько прозрачным, что они посвящают ему едва две страницы, предполагая, что читателям всё это и так должно быть очевидно. И, действительно, это не вызвало у меня никаких вопросов - это казалось настолько само собой разумеющимся , что, когда я некоторое время назад встретил у сразу нескольких программистов откровенное непонимание концепции, я даже не смог найти слов, чтобы объяснить её суть.
Поэтому я попытался систематизировать своё понимание вопроса в этой заметке.
Главное отличие класса от интерфейса - в том, что класс состоит из интерфейса и реализации .
Любой класс всегда неявно объявляет свой интерфейс - то, что доступно при использовании класса извне. Если у нас есть класс Ключ и у него публичный метод Открыть, который вызывает приватные методы Вставить, Повернуть и Вынуть, то интерфейс класса Ключ состоит из метода Открыть. Когда мы унаследуем какой-то класс от класса Ключ, он унаследует этот интерфейс.
Кроме этого интерфейса, у класса есть также реализация - методы Вставить, Повернуть, Вынуть и их вызов в методе Открыть. Наследники Ключа наследуют вместе с интерфейсом и реализацию.
И вот здесь таятся проблемы. Предположим, у нас есть некая модель, которая предполагает использование ключа для открытия двери. Она знает интерфейс Ключа и поэтому вызывает метод Открыть.
Но, предположим, некоторые двери открываются не таким вот поворотным ключом, а магнитной карточкой - которая ведь тоже по своей сути ключ! Интерфейс этой карточки никак принципиально не отличается от интерфейса обычного ключа - можно Открыть ключом, а можно Открыть карточкой.
И мы хотим сделать класс Магнитную Карточку, который тоже будет содержать интерфейс Ключа. Для этого мы унаследуем Магнитную Карточку от Ключа. Но вместе с интерфейсом унаследовалась и реализация, которая в методе Открыть вызывает методы Вставить, Повернуть и Вынуть - а это совершенно не подходит для Магнитной Карточки.
Нам придётся самое меньшее перегружать в Магнитной Карточке реализацию метода Открыть, используя уже последовательность Вставить, Провести и Вынуть. Это уже плохо, потому что мы не знаем детали реализации класса Ключ - вдруг мы упустили какое-то очень важное изменение данных, которое должно было быть сделано - и было сделано в методе Ключ:: Открыть? Нам придётся лезть во внутреннюю реализацию Ключа и смотреть, что и как - даже если у нас есть такая техническая возможность (open source навсегда и так далее), это грубое нарушение инкапсуляции, которое ни к чему хорошему не приведёт.
Именно так и пишут Гамма и др.: наследование является нарушением инкапсуляции .
Можете попробовать самостоятельно поразмышлять над такими вопросами:
- Что делать с тем фактом, что Ключ вставляется просто в скважину, а Магнитная Карточка - обязательно сверху (не посередине и не снизу)?
- Что делать, когда нам понадобиться сделать Бесконтактную Карточку, которую надо не вставлять, а подносить?
Правильный подход к данному вопросу - отделить интерфейс от реализации . Во многих современных языках для этого предусмотрен специальный синтаксис. В отсталых языках можно использовать хаки, например, в Цэ-два-креста - чисто абстрактные классы и множественное наследование (извините за обсценную лексику - из песни слова не выкинешь).
Мы должны опираться на интерфейсы, а не классы.
Объявим интерфейс Ключ, содержащий метод Открыть.
Объявим класс Поворотный Ключ, реализующий интерфейс Ключ при помощи своих методов Вставить, Повернуть и Вынуть.
Объявим класс Магнитная Карточка, тоже реализующий интерфейс Ключ, но уже по-своему - и без каких-либо неприятных пересечений с реализацией Поворотного Ключа. Этого помогло нам достичь отделение интерфейса от реализации.
Всегда помните об общем принципе: нам нужно использовать не класс, а интерфейс. Нам не важно, что это за штука - поворотный ключ или магнитная карточка, - нам важно, что им можно открыть дверь. То есть, вместо того, чтобы задумываться о природе объекта, мы задумываемся о способах его использования.
Вам может показаться странным, но это именно то, что отличает человека от животного - использование интерфейсов вместо классов. Вы наверняка помните классический опыт с обезьяной, которую приучили гасить огонь водой из ведёрка; а потом поставили ведёрко на плот посреди бассейна, но обезьяна всё равно бегала по мостику на плот и черпала воду из ведёрка, вместо того, чтобы черпать воду прямо из бассейна. То есть обезьянка использовала класс Вода-в-Ведёрке вместо интерфейса Вода (и даже больше, скажу по секрету: вместо интерфейса Средство-для-Тушения).
Когда мы мыслим классами - уподобляемся животным. Люди мыслят (и программируют) интерфейсами.
Использование интерфейсов даёт большие возможности. Например, класс может реализовывать несколько интерфейсов: класс Ключ-от-Домофона может содержать интерфейсы Ключ и Брелок.
Что касается наследования классов, которое, как вы помните, нарушает инкапсуляцию - часто вместо наследования лучше использовать делегирование и композицию . Не забыли Бесконтактную Карточку? Так хочется сделать её родственной Магнитной Карточке! (Например, чтобы знать, что их обе можно положить в Отделение-для-Карточек в Бумажнике.) Однако у них, кажется, нет ничего общего: интерфейс Ключ их роднит в той же мере, что и Поворотный Ключ с Ключом-от-Домофона.
Решение? Делаем класс (а может, и интерфейс - подумайте, что здесь подойдёт лучше) Карточка, реализующий интерфейс Ключ за счёт делегирования Магнитной Карточке либо же Бесконтактной Карточке. А чтобы узнать, что такое делегирование и композиция, а так же при чём тут абстрактная фабрика - обратитесь к книгам, посвящённым паттернам проектирования.
У использования интерфейсов вместо классов есть ещё много преимуществ. Вы сами сможете увидеть их на практике. Оставайтесь людьми!
P.S. К моему удивлению, я не смог найти на «Хабрахабре» ни блога, посвящённого ООП, ни блога, посвящённого программированию в целом. Если они есть - укажите, пожалуйста, а пока за неимением лучших вариантов размещаю в персональном блоге.
В процессе поиска новой работы столкнулся с тем, что все работодатели хотят, чтобы было отличное знание ООП в ПХП. Чем я хуже других, подумал я, и решил перечитать главу про объектно-ориентированное программирование. И вот на очередном собеседовании мне задают вопрос — чем абстрактный класс отличается от интерфейса.
Единственное отличие, которое я знал было в том, что один класс может реализовать несколько различных интерфейсов. Но обо всем по порядку.
Абстрактные классы
Абстрактные классы используются в PHP для определения абстрактных объектов. Чтобы понять, что определяет абстрактный объект, давайте рассмотрим такое понятие, как “пища”. Все мы знаем, что такое “пища”, но не всегда смотрим на то, из чего конкретно она приготовлена. Вы видели самые разнообразные виды пищи (бифштексы, цыпленок и тому подобное), однако само по себе понятие пищи является абстрактным - оно существует только как обобщение более конкретных вещей. Подобная идея справедлива также и для абстрактных классов.
В ООП абстрактные классы предназначены для того, чтобы создать суперкласс, который будет определять абстрактные характеристики его классов-наследников. На самом деле абстрактные классы могут содержать в себе какой-либо код, а могут быть вообще без кода; кроме этого, на их основе нельзя создать экземпляр напрямую. Рассмотрим пример:
value = NULL; } } class Integer extends Number { private $value; public function value() { return (int)$this->value; } } $num = new Integer; /* Все в порядке */ $num2 = new Number; /* Возникнет ошибка */ ?>
abstract class Number { private $value ; abstract public function value () ; public function reset () { $this -> value = NULL ; class Integer extends Number { private $value ; public function value () { return (int ) $this -> value ; $num = new Integer ; /* Все в порядке */ $num2 = new Number ; /* Возникнет ошибка */ |
Тут мы создали абстрактный класс Number, который является расширением класса Integer. Поскольку класс Number объявлен как abstract, на его основе нельзя создавать экземпляры. Если посмотреть на класс Number, то можно увидеть, что в нем определены две функции: value() и reset(). Абстрактный класс может не содержать код для методов, хотя при необходимости его можно добавить. Что же касается класса Number, то поскольку функция value() является специфической для конкретного типа числа, она реализуется в классе-наследнике. Чтобы разработчик мог реализовать такое поведение в своем коде, используется ключевое слово abstract, указывающее на то, что это просто заполнитель в классе Number. Однако это не относится к методу reset(), который остается неизменным для любого конкретного типа числа.
Интерфейсы
В отличие от абстрактных классов, посредством которых можно выражать абстрактные понятия в программах, интерфейсы предназначены для того, чтобы обеспечить определенную функциональность внутри класса. Если выражаться точнее, то интерфейс представляет собой средство для определения набора методов, которые должен иметь класс, реализующий данный интерфейс. Чтобы использовать интерфейс, его необходимо объявить с указанием ключевого слова interface:
interface printable { public function printme () ; |
Чтобы интерфейс приносил определенную пользу, он должен быть реализован с помощью одного или нескольких классов. Далее будет определен интерфейс printable, который заявляет, что любой класс, реализующий этот интерфейс, должен реализовать метод printme(). Чтобы создать класс, реализующий подобный интерфейс, в определении класса используется ключевое слово implements, за которым следует список реализованных интерфейсов:
value; } public function printme() { echo (int)$this->value; } } ?>
class Integer implements printable { echo (int ) $this -> value ; |
Здесь определен исходный класс Integer, чтобы реализовать интерфейс printable. Как класс, реализующий этот интерфейс, он гарантирует, что класс Integer предложит все методы, которые определены в интерфейсе.
Теперь, когда определено, что класс реализует заданный интерфейс, можно гарантировать, что любые функции или методы, для которых требуются некоторые действия со стороны класса, получат их, и для этого нет необходимости проверять экземпляр с помощью операции instanceof.
P.S. — Большая часть статьи — не моя, а взята из книги, где, на мой взгляд, наиболее понятно описана разница между абстрактными классами и интерфейсами.
P.P.S. — Так же, не особо понятно зачем вообще нужно ООП в PHP, т.к. прям явных преимуществ я не вижу, а все это можно реализовать с помощью простых функций… Единственный раз, когда я за свою жизнь использовал ООП — это для реализации класса, работающего с базами данных.
Для начала нужно сразу понять, что интерфейс это частный случай класса. Но в Java оно имеет отдельное ключевое слово, а в C++ это просто класс без реализации. Поэтому интерфейс просто задает некий стандарт для работы с кучей разнообразных реализаций.
Например, интерфейс Iterable говорит, что классы реализующие данный интерфейс имеют элементы и их можно перебирать в цикле вызывая метод next(). А значит, если создаете какой-то контейнер или коллекцию, то можно реализовать Iterable. Не выдумывая свои методы для работы с контейнером. Тем самым появляется некий общий стандарт - интерфейс для работы с контейнерами.
А если вы делаете игру, то можете создать интерфейс Unit, тем самым задав классам определенное поведение. Например, unit должен обязательно иметь метод atack(), isDead() и т.д.
Ну и конечно Unit может быть и просто классом или абстрактным классом, в котором реализованы atack и isDead, а может быть только isDead, потому что attack у каждого типа юнита индивидуально и требует собственной реализации. Т.е. приходим к тому, что интерфейс это также частный случай абстрактного класса.
Т.е. тут уже вступает в действие полиформизм, т.е. интерфейсы по сути дают полиформизм. Ну, а в Java они еще позволяют делать множественное наследование или другими словами задать классу несколько свойств поведения, например Unit может быть также и Iterable, тем самым можно дать юнитам инвентарь и перебирать элементы в нем.
И соответсвенно если Unit у вас будет классом или абстрактным классом, то унаследовав Unit в Java, вы просто не сможете дать наследнику еще и Iterable поведение, если Iterable будет тоже классом.
OrcWarrior implements Unit, Iterable - так можно
OrcWarrior extends Unit, Iterable - так в Java нельзя, но можно в С++, а Unit и Iterable тогда всегда будут объявляться как class...
Из-за этого, в Java приветствуется не наследование, а композиция. Т.е. нафига каждый раз реализовывать Unit.isDead, если он стандартный? Поэтому, создается скажем класс UnitAI и делается следующее:
Class OrcWarrior implements Unit, Iterable {
UnitAI ai;
UnitAI getAI(){
return ai;
}
}
Boolean isDead() {
....
}
}
Interface Unit {
void attack();
UnitAI getAI();
}
Вот это называется композиция, т.е. в OrcWarrior, HumanWarrior вы подмешиваете UnitAI, в котором уже реализовано isDead, и тем самым не нужно каждый раз его реализовывать одним и тем же кодом. В С++ такого можно не делать, там есть поддержка множественного наследование, но оно имеет свои минусы. Впрочем, как и композиция имеет плюсы/минусы.
Интерфейс (иногда так же контракт , interface ) в объектно-ориентированной парадигме программирования - частный случай абстрактного класса.
В отличие от абстрактного класса, который может содержать в себе почти всё то же, что и обычный класса, интерфейс может содержать в себе только константы и абстрактные методы. Все элементы интерфейса являются публичными (public) так как это заложено самой природой интерфейса, поэтому модификатор доступа к элементам интерфейса можно и не писать, там по умолчанию всё public . В Java в интерфейсах можно декларировать и обычные переменные, что может запутать так как компилятор хоть и разрешает это делать, но всё равно все переменные интерфейса превращаются в константы.
Интерфейсы нужны для стандартизации взаимодействий объектов. Интерфейсы не предназначены для хранения данных, они определяют именно общие принципы взаимодействия с классами реализовывающие их.
Интерфейсы выполняют всё ту же роль абстрактных элементов, то есть заставляют реализующие классы реализовывать описанные абстрактные методы. По этому интерфейсы реализовывают (не расширяют/наследуют), а именно реализовывают в классах. Разумеется, создать объект интерфейса нельзя. Использовать напрямую абстрактные классы и интерфейсы нельзя, их надо расширять/наследовать и реализовывать.
Интерфейсы могут наследоваться только друг от друга и даже множественно. При этом обычно наследование одного интерфейса от другого, как и в случае наследования классов, именуется расширением, ключевое слово extends .
В отличие от классов интерфейсы не расширяют или наследуют а реализуют (ключевое слово implements). Так же большинстве языков программирования разрешено множественное наследование интерфейсов в отличие от классов, которые можно наследовать только по одному.
Поскольку интерфейс содержит только абстрактные методы, то во многих языках не требуется принудительно объявлять методы интерфейса абстрактными, то есть писать ключевое слово abstract .
Интерфейсы присущи современным ленивым объектно-ориентированным языкам программирования таким как Java и C#. В том же хардкорном C++ интерфейсов нет так как там для этого есть абстрактные классы и разрешённое множественное наследование классов.
По правилам хорошего тона написания программного кода первая буква названия интерфейса так же как и в названиях классов пишется в верхнем регистре, часто так же добавляют префикс - буква «I», что бы явно можно было отличить интерфейс от класса по названию, хотя часто и к названиям классов добавляют префикс «C» но встречается это реже чем подобная же практика у интерфейсов.
Интерфейсы можут быть и пустыми и при этом всё равно использоваться. В этом случае они являются некими маркерами позволяющими группировать классы по каким-нибудь категориям. Поэтому наследование пустых интерфейсов это частая практика.
Отличительной особенностью интерфейса от абстрактного класса является то, что интерфейс состоит исключительно лишь из констант и абстрактных методов в то время как абстрактный класс может состоять из любых доступных членов класса, а так же может вообще не иметь абстрактных элементов и при этом быть абстрактным, однако если класс имеет хотя бы один абстрактный элемент, то он абстрактный.
Пример описания интерфейса на PHP:
interface IHand { function useKeyboard(); function touchNose(); } interface IFoot { function runFast(); function playFootball(); } class Human implements Hand, Foot { function useKeyboard() {echo "Use keyboard!"}; function touchNose() {echo "Touch nose!"}; function runFast() {echo "Run fast!"}; function playFootball() {echo "Play football!"}; }
