Достаточно часто требуется совмещать в объекте поведение, характерное для двух или более независимых иерархий. Но ещё чаще требуется писать единый полиморфный код для объектов из таких иерархий в случае, когда эти объекты обладают схожим поведением. Как мы знаем, за поведение объектов отвечают методы. Это значит, что в полиморфном коде требуется для объектов из разных классов вызывать методы, имеющие одинаковую сигнатуру, но разную реализацию. Унарное наследование, которое мы изучали до сих пор, и при котором у класса может быть только один прародитель, не обеспечивает такой возможности. При унарном наследовании нельзя ввести переменную, которая бы могла ссылаться на экземпляры из разных иерархий, так как она должна иметь тип, совместимый с базовыми классами этих иерархий.
В C++ для решения данных проблем используется множественное наследование. Оно означает, что у класса может быть не один непосредственный прародитель, а два или более. В этом случае проблема совместимости с классами из разных иерархий решается путём создания класса, наследующего от необходимого числа классов-прародителей.
Но при множественном наследовании классов возникает ряд трудно разрешимых проблем, поэтому в Java оно не поддерживается. Основные причины, по которым произошёл отказ от использования множественного наследования классов: наследование ненужных полей и методов, конфликты совпадающих имён из разных ветвей наследования.
В частности, так называемое ромбовидное наследование, когда у класса A наследники B и C, а от них наследуется класс D. Поэтому класс D получает поля и методы, имеющиеся в классе A, в удвоенном количестве – один комплект по линии родителя B, другой – по линии родителя C.
Конечно, в C++ имеются средства решать указанные проблемы. Например, проблемы ромбовидного наследования снимаются использованием так называемых виртуальных классов, благодаря чему при ромбовидном наследовании потомкам достаётся только один комплект членов класса A, и различения имён из разных ветвей класса с помощью имён классов. Но в результате получается заметное усложнение логики работы с классами и объектами, вызывающее логические ошибки, не отслеживаемые компилятором. Поэтому в Java используется множественное наследование с помощью интерфейсов, лишённое практически всех указанных проблем.
Интерфейсы являются важнейшими элементами языков программирования, применяемых как для написания полиморфного кода, так и для межпрограммного обмена. Концепция интерфейсов Java была первоначально заимствована из языка Objective-C, но в дальнейшем развивалась и дополнялась. В настоящее время она, фактически, стала основой объектного программирования в Java, заменив концепцию множественного наследования, используемую в C++.
Интерфейсы являются специальной разновидностью полностью абстрактных классов. То есть таких классов, в которых вообще нет реализованных методов - все методы абстрактные. Полей данных в них также нет, но можно задавать константы (неизменяемые переменные класса). Класс в Java должен быть наследником одного класса-родителя, и может быть наследником произвольного числа интерфейсов. Сами интерфейсы также могут наследоваться от интерфейсов, причём также с разрешением на множественное наследование.
Отсутствие в интерфейсах полей данных и реализованных методов снимает почти все проблемы множественного наследования и обеспечивает изящный инструмент для написания полиморфного кода. Например, то, что все коллекции обладают методами, перечисленными в разделе о коллекциях, обеспечивается тем, что их классы являются наследниками интерфейса Collection. Аналогично, все классы итераторов являются наследниками интерфейса Iterator, и т.д.
Декларация интерфейса очень похожа на декларацию класса:
МодификаторВидимости interface ИмяИнтерфейса
extends ИмяИнтерфейса1, ИмяИнтерфейса2,..., ИмяИнтерфейсаN {
декларация констант;
декларация заголовков методов;
}
В качестве модификатора видимости может использоваться либо слово public – общая видимость, либо модификатор должен отсутствовать, в этом случае обеспечивается видимость по умолчанию - пакетная. В списке прародителей, расширением которых является данный интерфейс, указываются прародительские интерфейсы ИмяИнтерфейса1, ИмяИнтерфейса2 и так далее. Если список прародителей пуст, в отличие от классов, интерфейс не имеет прародителя.
Для имён интерфейсов в Java нет специальных правил, за исключением того, что для них, как и для других объектных типов, имя принято начинать с заглавной буквы. Мы будем использовать для имён интерфейсов префикс I (от слова Interface), чтобы их имена легко отличать от имён классов.
Объявление константы осуществляется почти так же, как в классе:
МодификаторВидимости Тип ИмяКонстанты = значение;
В качестве необязательного модификатора видимости может использоваться слово public. Либо модификатор должен отсутствовать - но при этом видимость также считается public, а не пакетной. Ещё одним отличием от декларации в классе является то, что при задании в интерфейсе все поля автоматически считаются окончательными (модификатор final), т.е. без права изменения, и к тому же являющимися переменными класса (модификатор static). Сами модификаторы static и final при этом ставить не надо.
Декларация метода в интерфейсе осуществляется очень похоже на декларацию абстрактного метода в классе – указывается только заголовок метода:
МодификаторВидимости Тип ИмяМетода(списокПараметров)
throws списокИсключений;
В качестве модификатора видимости, как и в предыдущем случае, может использоваться либо слово public, либо модификатор должен отсутствовать. При этом видимость также считается public, а не пакетной. В списке исключений через запятую перечисляются типы проверяемых исключений (потомки Exception), которые может возбуждать метод. Часть throws списокИсключений является необязательной. При задании в интерфейсе все методы автоматически считаются общедоступными (public) абстрактными (abstract) методами объектов.
Пример задания интерфейса:
package figures_pkg;
public interface IScalable {
public int getSize();
public void setSize(int newSize);
}
Класс можно наследовать от одного родительского класса и от произвольного количества интерфейсов. Но вместо слова extends используется зарезервированное слово implements - реализует. Говорят, что класс-наследник интерфейса реализует соответствующий интерфейс, так как он обязан реализовать все его методы. Это гарантирует, что объекты для любых классов, наследующих некий интерфейс, могут вызывать методы этого интерфейса. Что позволяет писать полиморфный код для объектов из разных иерархий классов. При реализации возможно добавление новых полей и методов, как и при обычном наследовании. Поэтому можно считать, что это просто один из вариантов наследования, обладающий некоторыми особенностями.
Уточнение: в абстрактных классах, реализующих интерфейс, реализации методов может не быть – наследуется декларация абстрактного метода из интерфейса.
Замечание: Интерфейс также может реализовывать (implements) другой интерфейс, если в том при задании типа использовался шаблон (generics, template). Но эта тема выходит за пределы данного учебного пособия.
В наследнике класса, реализующего интерфейс, можно переопределить методы этого интерфейса. Повторное указание в списке родителей интерфейса, который уже был унаследован кем-то из прародителей, запрещено.
Реализации у сущности типа интерфейс не бывает, как и для абстрактных классов. То есть экземпляров интерфейсов не бывает. Но, как и для абстрактных классов, можно вводить переменные типа интерфейс. Эти переменные могут ссылаться на объекты, принадлежащие классам, реализующим соответствующий интерфейс. То есть классам-наследникам этого интерфейса.
Правила совместимости таковы: переменной типа интерфейс можно присваивать ссылку на объект любого класса, реализующего этот интерфейс.
С помощью переменной типа интерфейс разрешается вызывать только методы, декларированные в данном интерфейсе, а не любые методы данного объекта. Если, конечно, не использовать приведение типа.
Основное назначение переменных интерфейсного типа – вызов с их помощью методов, продекларированных в соответствующем интерфейсе. Если такой переменной назначена ссылка на объект, можно гарантировать, что из этого объекта разрешено вызывать эти методы, независимо от того, какому классу принадлежит объект. Ситуация очень похожа с полиморфизмом на основе виртуальных и динамических методов объектов. Но гарантией работоспособности служит не одинаковость сигнатуры методов в одной иерархии, а одинаковость сигнатуры методов в разных иерархиях – благодаря совпадению с декларацией одного и того же интерфейса. Обязательно, чтобы методы были методами объектов – полиморфизм на основе методов класса невозможен, так как для вызовов этих методов используется статическое связывание (на этапе компиляции).
