Накопилось несколько вопросов на тему модульности и компонентности:

degor>Ну и чем вам Windows не модульная система?

mdw>А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)

S>Допустим, написал я свой драйвер файловой системы — реализация никуда не
S>экспортируется, интерфейс к новой файловой системе предоставляется все теми
S>же CreateFile/WriteFile/ReadFile. Чем не компонента?

SG>> Таким образом, модули общаются между собой передавая друг другу не сами
SG>> объекты, а полиморфные переменные связанные с этими объектами.

Sergey>Этому условию замечательно соответсвуют оконная подсистема виндов, API
Sergey>работы с файлами и куча всего еще. В роли "полиморфной переменной" в этом
Sergey>случае выступают HWND и HANDLE.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...

Думаю, что лучше будет завести новую ветку форума для обсуждения этих вопросов.

Итак, что же такое модульная/компонентная система с точки зрения научного программирования? В обычном житейском смысле любая система состоящая из частей может быть названа модульной или компонентной, а любая ее часть, стало быть, будет модулем или компонентом. В обычном житейском смысле модуль или компонент это какая-то часть целого. Колесо — часть автомобиля, то есть в житейском смысле это его компонент. Руки и ноги — часть человека, в житейском смысле, значит, компоненты. Если, по аналогии с житейским смыслом, любую часть большой программы называть модулем или компонентом, то получится бардак. Все будут говорить что их системы являются модульными или компонентными, но все под этими терминами будут понимать что-то свое, например, всего лишь то что их системы состоят из частей. В программировании нужны более точные понятия модульности и компонентности.

Попытаюсь дать понятие модульной системы.

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

Почему Виндос с Юниксом не модульные — да потому что разные их части выполняются в разных средах исполнения — это не гомогенные, а гетерогенные системы. В тоже самое время Оберон системы являются именно модульными потому что они устроены "гомогенным способом": поверх железа работает среда исполнения в которой выполняются модули системы, причем между модулями, собственно, самой операционки и модулями приложений пользователя, с точки зрения среды исполнения, нет никакой разницы. В Виндосе же, поверх железа стоит ядро операционки, а среды исполнения Win32, DOS, COM и т.д. стоят поверх ядра. Драйверы работают в режиме ядра практически не имея никакой среды исполнения (именно отсутствие среды исполнения заставляет писать драйверы под Виндос на Си, а не на Си++ т.к. для работы программ написанных на Си++, как и для работы любых других программ написанных на объектно ориентированных языках, неоходима среда исполнения Runtime system).

Теперь попытаюсь дать понятие компонентной системы.

Компонентная система — это объектно ориентированная модульная система.

Компонентная система = Модульная система + ООП.

Компонентная система состоит только из модулей и больше не из чего не состоит. Объекты создаются внутри модулей. Модули общаются друг с другом передавая друг другу объекты, но не просто сами объекты, а полиморфные переменные ассоциированные с объектами. Модули компонентной системы называются компонентами.

Виндос с Юниксом — не компонентные еще и потому что мало того что они не модульные, но они еще и не объектно ориентированные. Оберон системы — компонентные — они модульные и целиком и полностью объектно ориентированные, собственно из-за этого среда исполнения (Runtime system) в оберонах располагается прямо поверх железа — чтобы все остальное (все что будет сверху) было модульным и объектно ориентированным, то есть компонентным.

На этом можно было бы и закончить, но дело в том что скрещивание модульности и ООП не проходит без последствий. Есть несколько ограничений накладываемых на компонентные системы:

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

Следствие 2
В общем случае в динамической компонентной системе задача удаления более не нужных объектов может быть решена только во время исполнения, а не во время написания компонента. Таким образом, компонентные системы в общем случае не могут функционировать без встроенного в среду исполнения сборщика мусора. (В частных конкретных случаях могут, но в общем случае — нет)

Следствие 3
Поскольку между модулями операционной системы и модулями пользователя с точки зрения среды исполнения нет ни какой разницы, то вся ответственность за безопасность и надежность системы накладывается именно на среду исполнения. Это означает что среда исполнения всегда должна проверять индексы массивов на предмет выхода за границы массива, всегда проверять арифметические переполнения, разрешать только "правильные" приведения типов объектов и т.д.

Следствия из следствия 3
3.1 Программы должны быть написаны на безопасных модульных языках программирования. Так как в опасных, например на Си или Си++ невозможно заставить среду исполнения пресекать ошибки переполнения буфера или некорректного приведения типов или разыменования повисших или каких либо других не корректных указателей. Компонентные программы, например, можно писать на Оберонах.
3.2 Поскольку безопасность системы гарантируется самой средой исполнения, то можно использовать всего лишь одно единственное адресное пространство. Это очень сильно повышает производительность. Повышает гораздо сильнее чем ее снижает постоянные проверки индексов... Например, в Aos BlueBottle написанной на Active Oberon скорость переключения между процессами примерно в 40 раз выше чем скорость переключения между процессами в Юниксе. Вызов системной функции для пользователя не является долгим, так как не надо долго ожидать переключения в режим ядра, а является таким же быстрым как вызов любой другой функции — вспомните, что для среды исполнения нет разницы между модулями самой операционки и модулями пользователя.

Принимая во внимание вышеизложенное, десяток лет назад (Клеменсом Шиперски) была сформулирована Компонентно ориентированная парадигма программирования:

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

http://www.inr.ac.ru/~info21/info/qtocop.htm