Одним из ключевых преимуществ использования среды разработки, явно поддерживающей объектное ориентирование, была возможность применения полиморфизма для интерпретации групп сходных объектов как совместимых друг с другом по типу. С целью поддержки полиморфизма в объектном ориентировании были введены понятия наследования и динамического связывания, что позволило явно группировать сходные объекты в коллекции (collections) связанных абстракций. Рассмотрим следующую простейшую иерархию классов C++:
class Dog {
public:
virtual void Bark(void);
};
class Pug : public Dog {
public:
virtual void Bark(void);
};
class Collie : public Dog {
public:
virtual void Bark(void);
};
Поскольку классы Collie и Pug оба совместимы по типу с классом Dog , то клиенты могут написать групповой (generic ) код следующим образом:
void BarkLikeADog(Dog& rdog) {
rdog.Bark();
}
Поскольку метод Bark является виртуальным и динамически связанным, механизмы диспетчеризации методов C++ обеспечивают выполнение нужного кода. Это означает, что функция BarkLikeADog не полагается на точный тип объекта, на который она ссылается; ей достаточно, чтобы это был тип, совместимый с Dog. Данный пример может быть легко переделан для любого числа языков, поддерживающих объектно-ориентированное программирование.
Приведенная иерархия классов является типичным примером тех приемов, которые применялись во время первой волны развития объектного ориентирования. Одной из основных характеристик этой первой волны было наследование реализаций. Наследование реализаций является мощным приемом программирования, если применять его строго по правилам. Однако при его неправильном применении результирующая иерархия типов может стать образцом чрезмерной связи между базовым и производным классами. Типичным недостатком такой связи является то, что зачастую неясно, должна реализация метода базовым классом вызываться из версии порожденного класса или нет. Для примера рассмотрим реализацию Bark класса Pug :
void Pug::Bark(void) {
this->BreathIn();
this->ConstrictVocalChords();
this->BreathOut(); }
Что произойдет, если реализация Bark основным классом Dog не вызвана, как в случае приведенного выше фрагмента кода? Возможно, метод базового класса записывает для дальнейшего использования, сколько раз лает (barks) конкретная собака (dog)? Если это так, то класс Pug вторгся в соответствующую часть реализации базового класса Dog. Для правильного применения наследования реализаций необходимо нетривиальное количество внутреннего знания для обеспечения сохранности базового класса. Это количество детального знания превышает уровень, требующийся для того, чтобы просто быть клиентом базового класса. По этой причине наследование реализации часто рассматривается как повторное использование белого ящика.
Один из подходов к объектному ориентированию, сокращающий чрезмерную связь систем типов, но сохраняющий преимущества полиморфизма, заключается в том, чтобы наследовать только сигнатуры типов, но не код реализации. Это является фундаментальным принципом разработок на базе интерфейса, что можно рассматривать как вторую волну объектного ориентирования. Программирование на базе интерфейса является усовершенствованием классического объектного ориентирования, которое считает, что наследование является прежде всего механизмом для выражения отношений между типами, а не между иерархиями реализаций. В основе интерфейсно-ориентированных разработок лежит принцип отделения интерфейса от реализации. В этом направлении интерфейсы и реализации являются двумя различными понятиями. Интерфейсы моделируют абстрактные требования, которые могут предъявляться к объекту. Реализации моделируют конкретные обрабатываемые типы, которые могут поддерживать один или более интерфейсов. Многие из этих преимуществ интерфейсно-ориентированного развития могли быть достигнуты и традиционными средствами первой волны в рамках строгого стиля программирования. Однако широкое принятие этого направления произошло только тогда, когда была получена явная поддержка со стороны разработчиков языков и инструментальных средств программного обеспечения. В число программных сред, сыгравших главную роль в обеспечении успеха интерфейсно-ориентированного развития, входят модель компонентных объектов (Component Object Model – СОМ) фирмы Microsoft, программная среда Orbix Object Request Broker фирмы Iona и Digitalk, а также явная поддержка интерфейсно-ориентированной разработки в рамках языка Java.
Одним из основных преимуществ использования программной среды, поддерживающей интерфейсно– ориентированное развитие, являлась возможность смоделировать, «что» и «как» делает объект, как две различные концепции. Рассмотрим следующую простейшую иерархию типов для Java:
interface IDog {
public void Bark();
};
class Pug implements IDog {
public void Bark( ){…}
};
class Collie Implements IDog {
public void Bark( ){…}
};
Поскольку оба класса – Collie и Pug – совместимы с интерфейсом IDog , то клиенты могут написать групповой код следующим образом:
void BarkLikeADog(IDog dog) {
dog.Bark(); }
С точки зрения клиента, эта иерархия типов практически идентична предыдущему примеру на C++. В то же время, поскольку метод Bark интерфейса IDog не может иметь реализации, между определением интерфейса IDog и классами Pug или Collie не существует связи. Хотя из этого следует, что как Pug, так и Collie должны полностью определить свое собственное представление о том, что означает «лаять» (bark), конструкторы Pug и Collie не обязаны интересоваться, какие побочные эффекты окажут их производные классы на основной базовый тип IDog.
Поразительное подобие между первой и второй волной заключается в том, что каждая из них может быть охарактеризована с помощью простого понятия (класс и интерфейс, соответственно). В обоих случаях катализатором успеха послужило не само понятие. Для разжигания интереса со стороны индустрии программирования в целом потребовалась еще одна или несколько ключевых программных сред.
Интересной стороной систем второй волны является то, что реализация рассматривается как черный ящик. Это означает, что все детали реализации считаются непрозрачными (opaque) для клиентов объекта. Часто, когда разработчики начинают использовать такие основанные на интерфейсах технологии, как СОМ, то уровень свободы, которую дает эта непрозрачность, игнорируется, что побуждает неопытных разработчиков весьма упрощенно рассматривать отношения между интерфейсом, реализацией и объектом. Рассмотрим электронную таблицу Excel, которая выставляет свои функциональные возможности, используя СОМ. Реализация класса электронной таблицы Excel выставляет около 25 различных интерфейсов СОМ, что позволяет ей применять множество основанных на СОМ технологий (Linking, Embedding, Inplace Activation, Automation, Active Document Objects, Hyperlinking и т. д.). Поскольку каждому интерфейсу требуется по четырехбайтному указателю виртуальной функции (vptr) на объект, объекты электронной таблицы заполняют около 100 байт служебными данными, в добавление к любому конкретному состоянию электронной таблицы, которое может потребоваться для хранения пользовательских данных. Поскольку данный объект электронной таблицы может состоять из весьма большого количества ячеек, эти 100 байт служебных данных погашаются сотнями килобайт, которые может потребовать большая таблица для управления содержимым каждой используемой ячейки.
