Принципы объектно-ориентированного программирования

         

Объединение



Объединение

Каждый раз, когда вы берете объект, требующий детерминированного завершения, и сохраняете в объекте, который этого не требует, вы теряете детерминированность (так как детерминированность не передается). Эта проблема наносит удар в самое сердце иерархии классов. Как быть, например, с массивами? Если вам нужен массив детерминированных объектов, то сами массивы должны быть детерминированными. А как насчет коллекций и хэш-таблиц? Список продолжается: забегая вперед, скажу, что подсчет ссылок используется всей библиотекой классов, что делает невозможным выполнение поставлётгей-задачя.

Другой альтернативой была бифуркация (т. е. разделение на две ветви) библиотеки классов .NET Framework и появление двух версий многих типов классов, например, детерминированных и недетерминированных массивов. Однако стало ясно, что наличие двух копий всей модели приведет к путанице, производительность в этом случае будет ужасной, так как будут загружаться две копии класса, и в конце концов это будет непрактично.

Изучались специфические решения для специфических классов, но ни одно из них даже не приблизилось к тому, чтобы быть решением общего назначения, масштабируемым в рамках всей модели. Обдумывали вариант, в котором фундаментальная проблема — случай, когда система теряет детерминированность, если недетерминированный объект содержит ссылку на детерминированный, — рассматривалась как ошибочная ситуация. Однако был сделан вывод, что это ограничение затруднит написание реальных программ.



Содержание раздела