Сущность технологии СОМ. Библиотека программиста   ::   Бокс Дональд

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

Как в исследовательских, так и в коммерческих кругах разработчиков программного обеспечения считалось общепринятым, что наследование реализации – полезный и мощный инструмент, хотя он может привести к чрезмерной связи между базовым и производным классами. Поскольку наследование реализации часто вызывает «утечку» некоторых элементов реализации базового класса, нарушая инкапсуляцию этого класса, разработчики СОМ понимали, что наследование реализации должно быть ограничено программированием внутри компонентов. Поэтому СОМ не поддерживает наследование реализации между компонентами, но поддерживает ее внутри компонентов. Наследование же интерфейсов СОМ поддерживает полностью (по сути, она полагается на это).

Разработчики СОМ развенчали миф о том, что главную роль при достижении повторного использования играет наследование. Фундаментальное понятие, использующееся в СОМ при моделировании повторного использования, – это инкапсуляция, а не наследование. А принцип наследования СОМ использует при моделировании взаимоотношения типов между объектами, выполняющими сходные функции. Построением СОМ-модели повторного использования на основе инкапсуляции разработчики поддерживали повторное использование в форме черного ящика , устраивающее ожидаемый рынок компонентов. Идея состоит в том, что клиенты должны иметь дело с объектами как с непрозрачными компонентами в смысле того, что находится у них внутри и как они реализованы. Разработчики СОМ полагали, что для проведения этой идеи в жизнь должна быть разработана архитектура. С какой стати любой может разрабатывать систему с другой моделью для повторного использования? Хороший вопрос. Дело, однако, в том, что мир полон «объектно-ориентированных» систем, которые не только не поддерживают инкапсуляцию в стиле черного ящика, но даже затрудняют ее достижение. Классическим примером этого является C++. В первой главе своей книги Дон очень понятно объясняет то, что я подразумеваю под этим.

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

Объектно-ориентированное программирование = полиморфизм + (немного) позднее связывание + (немного) инкапсуляции + наследование.

Компонентно-ориентированное программирование = полиморфизм + (истинно) позднее связывание + (действительная, принудительная) инкапсуляция + наследование интерфейсов + двоичное повторное использование.

Во всяком случае для меня эта дискуссия – род забавы. Борцы за чистоту OO, проживающие в comp.object и comp.object.corba, выбились из сил, тыча пальцами в СОМ и говоря: «Но он не по-настоящему объектно-ориентированный». Вы можете оспорить это двумя способами:

1. «Он-то как раз по-настоящему! Это ваше определение ОО неправильное».

2. «Ну и что!?! СОМ имеет феноменальный коммерческий успех и позволяет тысячам независимых разработчиков создавать потрясающее программное обеспечение, которое интерполирует и интегрирует. И они делают деньги. Много денег [1] . Программные компоненты, написанные ими, покупаются, используются и повторно используются.