Сущность технологии СОМ. Библиотека программиста
Добавить в закладки К обложке
- Предисловие Чарли Киндела - Страница 1
- Предисловие Грэйди Буча - Страница 4
- От автора - Страница 5
- Благодарности - Страница 7
- От издательства - Страница 9
- Глава 1. СОМ как улучшенный C++ - Страница 10
- Распространение программного обеспечения и язык С++ - Страница 11
- Динамическая компоновка и С++ - Страница 12
- C++ и мобильность - Страница 13
- Инкапсуляция и С++ - Страница 14
- Отделение интерфейса от реализации - Страница 17
- Абстрактные базы как двоичные интерфейсы - Страница 19
- Полиморфизм на этапе выполнения - Страница 23
- Расширяемость объекта - Страница 25
- Управление ресурсами - Страница 28
- Где мы находимся? - Страница 30
- Глава 2. Интерфейсы - Страница 31
- Снова об интерфейсах и реализациях - Страница 32
- IDL - Страница 33
- Методы и их результаты - Страница 35
- Интерфейсы и IDL - Страница 37
- Интерфейс IUnknown - Страница 39
- Управление ресурсами и IUnknown - Страница 42
- Приведение типов и IUnknown - Страница 45
- Реализация IUnknown - Страница 47
- Использование указателей интерфейса СОМ - Страница 50
- Оптимизация QueryInterface - Страница 52
- Типы данных - Страница 55
- Атрибуты и свойства - Страница 61
- Исключения - Страница 62
- Где мы находимся? - Страница 65
- Глава 3. Классы - Страница 66
- Снова об интерфейсе и реализации - Страница 67
- Объекты классов - Страница 69
- Активация - Страница 71
- Использование SCM - Страница 73
- Классы и серверы - Страница 76
- Обобщения - Страница 81
- Оптимизации - Страница 83
- Снова интерфейс и реализация - Страница 86
- Моникеры и композиция - Страница 89
- Моникеры и сохраняемость - Страница 91
- Время жизни сервера - Страница 93
- Классы и IDL - Страница 95
- Эмуляция классов - Страница 97
- Категории компонентов - Страница 98
- Где мы находимся? - Страница 102
- Глава 4. Объекты - Страница 103
- Снова IUnknown - Страница 104
- QueryInterface симметрична - Страница 105
- QueryInterface транзитивна - Страница 106
- QueryInterface рефлективна - Страница 107
- Объекты имеют статический тип - Страница 108
- Единственность и идентификация - Страница 110
- QueryInterface и IUnknown - Страница 111
- Множественные интерфейсы и имена методов - Страница 113
- Динамическая композиция - Страница 118
- Двоичная композиция - Страница 122
- Включение - Страница 128
- Где мы находимся? - Страница 129
- Глава 5. Апартаменты - Страница 130
- Снова интерфейс и реализация - Страница 131
- Объекты, интерфейсы и апартаменты - Страница 134
- Межапартаментный доступ - Страница 136
- Вспомогательные средства для внутрипроцессного маршалинга - Страница 141
- Архитектура стандартного маршалинга - Страница 144
- Реализация интерфейсных маршалеров - Страница 148
- Стандартный маршалинг, потоки и протоколы - Страница 150
- Управление жизненным циклом и маршалинг - Страница 154
- Специальный маршалинг - Страница 159
- Маршалер свободной поточной обработки (FreeThreaded Marshaler) - Страница 162
- Где мы находимся? - Страница 168
- Глава 6. Приложения - Страница 169
- Подводные камни внутрипроцессной активации - Страница 170
- Активация и SCM - Страница 171
- Снова о времени жизни сервера - Страница 174
- Снова о времени жизни сервера - Страница 178
- Идентификаторы приложений - Страница 182
- COM и защита - Страница 185
- Программируемая защита - Страница 191
- Контроль доступа - Страница 196
- Управление маркерами - Страница 200
- Где мы находимся? - Страница 204
- Разное - Страница 205
- Основы указателей - Страница 206
- Указатели и память - Страница 208
- Массивы - Страница 213
- Управление потоками данных - Страница 221
- Динамический вызов в сравнении со статическим - Страница 224
- Двунаправленные интерфейсные контракты - Страница 227
- Совмещение имен в IDL - Страница 233
- Асинхронные методы - Страница 236
- Где мы находимся? - Страница 237
- Проиложение А. Эволюция объектов - Страница 238
- Приложение Б. Избранный код - Страница 242
Посвящается Юдит С., которая помогла мне одолеть одну вещь, более устрашающую, чем СОМ, и сделала возможной написание этой книги, и Барбаре, которая оставалась со мной достаточно долго для того, чтобы увидеть, чем все это кончилось.
Предисловие Чарли Киндела
Когда я сел писать это предисловие, мне не давали покоя следующие мысли:
Будет ли портрет Дона на четвертой стороне обложки, и если да, то какой длины будут его волосы?
Осознают ли читатели этой книги, что у Дона есть индивидуализированные (personalized) лицензионные платы, способные читать интерфейс «IUNKNOWN»?
Что за чертовщину нужно писать в предисловии к книге?
У меня было две идеи насчет того, что написать в этом предисловии. Первая – высказать несколько мыслей о конструировании СОМ, которые я уже давно собираюсь записать. Вторая идея – польстить Дону Боксу в той же мере, в какой он польстил мне обращением с просьбой написать предисловие к своей книге. В конце концов я решил осуществить обе идеи.
Что есть СОМ? Зачем его придумали? Дон кратко осветил эти вопросы в первой главе. Вводная часть заканчивается словами «…в этой главе показана архитектура для повторного использования модулей, которая позволяет динамично и эффективно строить системы из независимо сконструированных двоичных компонентов». Остальная часть этой главы ведет вас шаг за шагом сквозь мыслительный процесс, происходивший в умах разработчиков СОМ с 1988 по 1993 годы, когда была выпущена первая версия СОМ.
Я думаю, что существует несколько аспектов конструирования СОМ, которые обеспечили его длительный успех. Первое и основное – это практичность, второе – простота, из которой проистекает его гибкость, или податливость.
ПрактичностьСОМ относится к разработке программного обеспечения весьма прагматично. Вместо того чтобы искать решение на основе почти религиозной академической догмы объектно-ориентированного программирования, СОМ-конструирование принимает во внимание как человеческую природу, так и капитализм. Команда разработчиков выделила лучшие, наиболее коммерчески убедительные аспекты классического объектного ориентирования (ОО) и объединила их с тем, чему она научилась при попытках добиться повторного использования предыдущих программных разработок – как внутри, так и вне Microsoft.
Большинство классических текстов, посвященных ОО, описывают систему или язык как ориентированный объект, если он поддерживает инкапсуляцию (сокрытие информации), полиморфизм и наследование. Часто подчеркивается, что главной движущей силой повторного использования является наследование. Разработчики СОМ не согласились с таким акцентом. Они поняли, что это слишком упрощенное представление и что в действительности существуют два вида наследования. Наследование реализации предполагает, что наследуется фактическая реализация (поведение). Наследование интерфейсов предполагает, что наследуется только определение (спецификация) поведения. Именно второй вид наследования обеспечивает полиморфизм, и этот вид полностью поддерживается моделью СОМ. С другой стороны, наследование реализации – это просто один из механизмов для повторного использования существующей реализации. Тем не менее, если конечной целью является повторное использование, тогда наследование реализации является просто средством для достижения этой цели, но не является самоцелью.
Как в исследовательских, так и в коммерческих кругах разработчиков программного обеспечения считалось общепринятым, что наследование реализации – полезный и мощный инструмент, хотя он может привести к чрезмерной связи между базовым и производным классами. Поскольку наследование реализации часто вызывает «утечку» некоторых элементов реализации базового класса, нарушая инкапсуляцию этого класса, разработчики СОМ понимали, что наследование реализации должно быть ограничено программированием внутри компонентов. Поэтому СОМ не поддерживает наследование реализации между компонентами, но поддерживает ее внутри компонентов. Наследование же интерфейсов СОМ поддерживает полностью (по сути, она полагается на это).
Разработчики СОМ развенчали миф о том, что главную роль при достижении повторного использования играет наследование. Фундаментальное понятие, использующееся в СОМ при моделировании повторного использования, – это инкапсуляция, а не наследование. А принцип наследования СОМ использует при моделировании взаимоотношения типов между объектами, выполняющими сходные функции. Построением СОМ-модели повторного использования на основе инкапсуляции разработчики поддерживали повторное использование в форме черного ящика, устраивающее ожидаемый рынок компонентов. Идея состоит в том, что клиенты должны иметь дело с объектами как с непрозрачными компонентами в смысле того, что находится у них внутри и как они реализованы. Разработчики СОМ полагали, что для проведения этой идеи в жизнь должна быть разработана архитектура. С какой стати любой может разрабатывать систему с другой моделью для повторного использования? Хороший вопрос. Дело, однако, в том, что мир полон «объектно-ориентированных» систем, которые не только не поддерживают инкапсуляцию в стиле черного ящика, но даже затрудняют ее достижение. Классическим примером этого является C++. В первой главе своей книги Дон очень понятно объясняет то, что я подразумеваю под этим.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248
- 249
- 250
- 251
- 252
- 253