Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Важной целью любой объектной модели является возможность повторного использования и расширения объектов, предоставляемых другими пользователями в виде фрагментов собственных реализаций. Один из способов сделать это в Microsoft Visual C++ и других языках заключается в использовании наследования реализации, которая позволяет объекту наследовать (подкласс) некоторые из его функций от другого объекта при переопределении других функций.
Проблема взаимодействия с системным объектом с использованием традиционного наследования реализации заключается в том, что контракт (интерфейс) между объектами в иерархии реализации не определен четко. На самом деле, это неявно и неоднозначно. Когда родительский или дочерний объект изменяет реализацию, поведение связанных компонентов может стать неопределенным или неустойчивым. В любом отдельном приложении, где реализация может управляться одной группой инженеров, которая обновляет все компоненты одновременно, это не всегда является основной проблемой. В среде, в которой компоненты одной команды создаются путем повторного использования других компонентов, созданных другими командами, этот тип нестабильности ставит под угрозу повторное использование. Кроме того, наследование реализации обычно работает только в пределах границ процесса. Это делает традиционное наследование реализации непрактичным для крупных, развивающихся систем, состоящих из компонентов программного обеспечения, созданных многими инженерными командами.
Ключом к созданию повторно используемых компонентов является возможность рассматривать объект как непрозрачный прямоугольник. Это означает, что фрагмент кода, пытающийся повторно использовать другой объект, ничего не знает и не должен знать ничего, о внутренней структуре или реализации используемого компонента. Другими словами, код, пытающийся повторно использовать компонент, зависит от поведения объекта, а не от его точной реализации.
Для обеспечения повторного использования черного ящика COM принимает другие установленные механизмы повторного использования, такие как сдерживание или делегирование и агрегирование.
Примечание.
Для удобства повторно используемый объект называется внутренним объектом , а объект, используюющий этот внутренний объект, является внешним объектом.
Важно помнить в обоих этих механизмах, как внешний объект представляется своим клиентам. Что касается клиентов, оба объекта реализуют любые интерфейсы, на которые клиент может получить указатель. Клиент обрабатывает внешний объект как непрозрачный прямоугольник и поэтому не заботится, и не нуждается в этом, о внутренней структуре внешнего объекта "клиент заботится только о поведении.
Дополнительные сведения см. в следующих разделах: