Ответ на »сообщение 3789« (Руслан Богатырев)
___________________________

1.Присоединяюсь, пусть будет Java.
2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?

И маленькое отступление по поводу Java. Довелось переводить одну вещь с C++ на Java. В программе на C++ были классы, ссылающиеся друг на друга и в этом не было никаких проблем. Т.е. однопроходному компилятору достаточно предварительного объявления
class C; (здесь могут быть разночмения - объявление/определение и declartion/definition - что есть что). Эквивалент в Java - циклический импорт или выделение суперкласса/суперинтерфейса или использование класса-делегата, причем похоже лучший вариант - именно циклический импорт.

Вернемся к нашему разговору о модулях. Что же такое модуль?

Посмотрим еще раз на пятерки критериев, правил и принципов, сформулированных Бертраном Мейером. Что выявляем:
* декомпозиция;
* сокрытие информации (information hiding);
* интерфейсы.

Что такое декомпозиция (и композиция), наверное, обсуждать не нужно. Понятно, что разбивать систему на составные части (как в проекте, так и в реализации) следует, руководствуясь вполне определенными соображениями, не абы как.  Соображения могут быть разными, лишь бы было понятно, как осуществляется отображение на эти части. Плюс количество частей и связей между ними не было бы неконтролируемо большим.

Сокрытие информации. Важнейшая вещь. Намеренно употребляю слово "сокрытие", а не "скрытие" по следующим причинам:
1. При произнесении "скрытие" практически неотделимо от "вскрытия" (прямо противоположное значения)
2. В русском языке слово "сокрытие" более распространено (в том числе, применительно к понятию "информация").

В чем разница между сокрытием информации и инкапсуляцией (encapsulation) ? Часто между этими понятиями ставят знак равенства. На самом деле, сокрытие информации – это общий принцип (когда есть полная информация и есть ее частичный представитель). Инкапсуляция ("заключение в капсулу") -- это метод воплощения этой концепции. Является ли, например, полиморфизм, который мы обсуждали, методом воплощения концепции сокрытия информации? Вполне. Если есть запись вида x + y, в которой мы, например, не можем сказать, какая конкретно операция обозначена знаком "+" – это сокрытие. Если мы берем некие generic-вещи, то есть исходный текст, допускающий подстановку/параметризацию (пусть даже на уровне макросов) – это сокрытие информации. Но это не инкапсуляция!

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

Является ли процедура капсулой? Вопрос. Является ли тип капсулой? Вопрос. Является ли класс капсулой? Тоже вопрос.

Есть у процедуры интерфейс? Вроде есть. Есть у класса интерфейс? Да никаких вопросов, разумеется. Есть ли у типа интерфейс? Сложно сказать. Но если брать абстрактные типы данных (АТД, abstract data type), то тоже есть. Есть у модуля интерфейс? Так у него он чуть ли не самая главная вещь.

Чтобы выявлять разницу между классами и модулями не в абстрактном смысле (скажем так, не только), а по вполне конкретным, осязаемым вещам, которые можно пощупать руками,  считаю разумным выбрать двух представителей, два языка. Будет, на что ссылаться.

Кого можно выбрать? Из МП кандидатов упоминал -- Modula-2, Ada (Ada-83), Turbo Pascal (TP 5.0). Из ООП давайте смотреть -- Simula, Smalltalk, C++, Eiffel, Object Pascal/Delphi, Java, C# ?

В отношении МП: Turbo Pascal отвергаю (хотя вроде многим знаком). Причина -- уровень воплощения концепции модуля уступает той же Modula-2, внесена по цепочке Modula-2 --> UCSD Pascal --> Turbo Pascal. Ада в контексте данного форума несколько чужеродна, хотя использовать ее как второй язык для доп. пояснения вещей (напр., generic-модулей), вполне можно (плюс Мейер к ней регулярно отсылает, так что не забудем).

Получается Modula-2. Хотя, почему не взять чистый Оберон? Практически та же Modula-2 (с некоторыми нюансами). Да и форум посвящен ему. Хорошая идея. Давайте пока мысленно исключим из Оберона возможность расширения типа (путь к реализации ООП), хотя и это не обязательно.

За команду МП будет выступать Оберон. Есть возражения?

Теперь выберем представителя от ООП. Simula достаточно мало известен аудитории (как я представляю), его считают динозавром (напрасно, вполне достойный изучения язык). Smalltalk -- чистота концепций ООП налицо, но не уверен, что в данном форуме его можно брать за основу (в форуме по Smalltalk я бы ни секунды не сомневался). C++ ? Не думаю. В целях пропаганды пройтись по нему было бы замечательно. Но ведь мы пытаемся разобраться, а не размахивать лозунгами, не так ли? Есть более достойные для Оберона соперники. Delphi? В общем, можно брать его, почему нет. Смотрим дальше -- C# ? В сравнении с Java с точки зрения модулей и классов я бы ему не отдал предпочтение. Зачем же выбирать более слабого? Остаются еще Java и Eiffel. Ну Eiffel мы уж никак не забудем -- все-таки вести обсуждение вокруг конкретной книги Мейера попроще, чем вообще (есть, от чего отталкиваться). Значит, Delphi и Java? Если более понятным в данном форуме будет сопоставление с Delphi -- давайте Delphi. Я лично предпочел бы Java. Почему? Потому что считаю его более сильным соперником для Оберона. Плюс, не стоит забывать, куда пошли выходцы из Оберон-команды ETH. В основном в мир Java. Конъюктура конъюктурой (C# -- еще большая конъюктура, если разобраться), но из разных зол выбирают обычно меньшее. Я за Java.

Нужно ли устраивать состязание? А мы не будем его устраивать. Просто будем сопоставлять сильнейших и размышлять. Спокойно, взвешенно. В конце концов, почему, разобравшись, не поиспользовать выявленные плюсы другого языка?

Ответ на »сообщение 3787« (iZEN)
___________________________

Я старался достаточно внимательно читать его огромную книгу, и вот какие наблюдения в отношении концепции модуля и модульного программирования.

Давайте отделим понятие модульности системы (mudularity) от понятия модуля (module). Отделить важно, поскольку иначе модулями нам придется называть едва ли не все на свете (любую самостоятельную часть, из которой состоит система).

Что важно понимать -- Бертран Мейер пытается осмыслить мир с позиций той вершины, на которую он давно взобрался (около 20 лет назад) и имя которой язык Eiffel. Его точка зрения интересна, но не забывайте, откуда он смотрит.

Итак, "метод проектирования программного продукта является модульным, если он помогает проектировщикам создать систему, состоящую из автономных элементов с простыми и согласованными структурными связями между ними". (с.38). Выделение -- мое.

Звучит красиво, но что нам дает? Каков критерий простоты связей? Его нет. Может ли быть связь несогласованной, что тогда это означает? Пока это все достаточно общие слова.

Главное, качество модуля, однако здесь выделяется -- автономность (хотя и это надо бы подраскрыть, но не будем торопиться).

Далее Мейер приводит 5 критериев, 5 правил и 5 принципов модульности -- их уже здесь упомянули. Я не зря это подчеркиваю, ибо модульность -- это свойство, качество, а модуль -- это концепция, сущность. Нас-то как раз будет интересовать, как она выглядит, как отличается (и в чем схожа) с другими -- классами, типами, компонентами и т.п.

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

Итак, есть модульная категория, к которой относятся собственно модули, классы и др.

Чтобы понять, почему так подробно разбираю Мейера: в его языке Eiffel нет модулей, нет вообще. Как же так, скажете вы, ведь Design-by-Contract -- это же его теория, где интерфейсы поставлены во главу угла? Не спешите.

Для нас важно знать, что модулей нет. А что есть? Классы, классы и еще раз классы.

Расскажу занятный момент, который произошел во время пресс-конференции Вирта в Москве (что была в Политехническом сразу после лекции). Едва я передал слово проф. Владимиру Биллигу (Тверской гос. университет), отцу Ильи Биллига  (кто знает, тот раньше возглавлял российский Microsoft, а потом уехал на повышение, относительно недавно для попытки двинуть на американский рынок его к себе пригласил Luxoft).

Так вот проф. Биллиг спросил Вирта -- является ли с точки зрения Вирта модуль типом? Вирт сразу понял, в чем дело и ответил, что смешивать эти фундаментальные понятия он считает неправильным. Есть модули, есть типы. Их надо разделять. И это важно.

Почему был такой вопрос? Потому что здесь проходит основная граница, основное расхождение в воззрениях разных ученых. Класс совмещает в себе два эти понятия -- тип и модуль. Как только они слились в "безумном экстазе", как только слиплись, отодрать одно от другого уже очень тяжело. Это не значит, что классы надо вычеркивать сразу из нашей жизни. Конечно, нет. Просто нужно этот момент иметь в виду. Он нам попозже пригодится.

Причем тут Биллиг-старший, скажете вы? Притом, что он руководитель проекта (и редактор перевода) по изданию той самой гигантской книги Мейера "Объектно-ориентированное конструирование программных систем", которую сейчас и обсуждаем. Понятно, почему он задал именно этот вопрос? Более того, учение Мейера движется не просто в массы -- книга была издана "Русской редакцией" (придворной редакцией Microsoft) совместно с главным проповедником открытых знаний -- Интернет-университетом информационных технологий Анатолия Шкреда.

Можете быть уверены, что эти знания будут не просто внедрять в наших университетах, а вбивать в головы, вбивать настойчиво, пока не вобьют. Это очень сильное и влиятельное лобби. Говорю об этом, поскольку владею достаточной информацией.

Но Бог с ним, с лобби. Нас все же интересуют модули и взгляды Мейера (раз уж о них зашла речь). Почему еще нас будут интересовать взгляды Мейера? Потому что он пришел в ETH на место Вирта. И то, что сейчас там делает, иначе как ползучим переворотом я назвать не могу, Оберон выжигают каленым железом. Но хватит пропаганды. Он умный, грамотный, авторитетный. Достаточно, чтобы прислушаться к его мнению.

Небольшая цитата из той же книги: "Если вы знакомы с не ОО-методами, то, вероятно, вспомните о подрограммах, имеющихся в большинстве языков программирования и проектирования, или, быть может, о пакетах (packages) языка Ada и (правда, под другим названием) языка Modula". (с. 39)

Хорошо сказано! Что-то под другим названием в Modula и есть модуль. Язык собственно и получил такое название, от Modular Language! Это чисто модульный язык. Язык Вирта, пришедший на смену Паскалю. Берите, смотрите под лупой, критикуйте. Но нет -- едва мимолетное упоминание. Супер!

Понятие модуля в Modula-2 здесь это что-то, да еще под другим названием. Просто отлично.

Ссылки на Аду в отношении модуля (не на этой странице, а во всей книге) не так плохо, но в книге я не нашел упоминания о Mesa (пардон, модульное программирование по Мейеру началось, оказывается, с Ады?). Языки Вирта (Modula-2, Оберон) вообще упоминаются так, между делом. Причем контекст упоминания говорит либо о том, что Мейер вообще с ними плохо знаком, либо что намеренно умалчивает. Честно говоря, и то и другое предположение меня не радует.

На этом делаю паузу. Можно уже кое-что пообсуждать. К Мейеру еще вернемся и не раз.

Вкраце обозначу мысли Мейера на модульность.
Тезисы.
Модульность сочетает два основных фактора качества ПО: расширяемость и повторное  использование кода.

Модули самодостаточны и образуют устойчивые структуры. Т.о. метод проектирования является модульным, если помогает проектировщику создать систему, состоящую из автономных элементов с простыми и согласованными структурными связями между ними.

Далее он пробует рассмотреть модульость с различных точек зрения, вводя пять критериев, пять правил и пять принципов модульности.
Критерии
* декомпозиция
* композиция
* понятность
* непрерывность
* защищённость

Правила
* прямое отображение (Direct Mapping)
* минимум интерфейсов (Few Interfaces)
* слабая связность интерфейсоф (Small interfaces - weak coupling)
* явные интерфейсы (Explicit Interfaces)
* скрытие информации, инкапсуляция (Information Hiding)

из всех вытекают
Принципы
* принцип Лингвистических Модульных Единиц
* принцип Самодокументирования
* принцип Унифицированного Доступа
* принцип Открыт-Закрыт
* принцип Единственного выбора

Мне понравилась ситуация в конексте описания принципа Открыт-Закрыт, где показан явный провал чистого (без ООП) модульного проектирования системы на примере модификации "закрытого" модуля и вынужденной лавинообразной переделки всех клиентских модулей, использующих его.
(Здесь: "закрытый модуль" означает завершённый, с полностью определённым замороженным интерфейсом, который приходится "открывать" для внесения незначительных изменений.)
Впрочем рассмотрены два конкретных случая, оба из которых приводят к сизифову труду поголовной модификации зависимых от этого модуля других модулей. В первом случае вынужденно вводят версионность; во втором случае - делают вилку проекта, разветвляют проект на два.
В случае с ООП решением этой же проблемы было бы достаточно воспользоваться...наследованием и полиморфизмом типа (класса) объекта.

Далее приводятся другие  способы "приспособляемости под задачи проекта" в рамках принципа Открыт-Закрыт, в частности "организованного хакерства" как допускаемого в рамках ОО-метода изменения функциональности системы. ООП, господа, делает систему живой, эволюционирующей и модульной!

В конце главы приводяться библиографические замечания о модульности и его применимости в разных языках (работы Geschke 1975г., работы Вирта и Хоара 1966г., статьи Дэвида Парнаса 1972г., конфигурация UNIX make - Feldman 1975г., ОО-метрики Кристины Минджинс и Брайана Хендерсон-Селлерса 1995,1996гг.)

В общем читать и изучать.

Модульность. Модульность. Модульность...
Читать классиков.

У Бертрана Мейера в книжке "ОО конструирование программных систем" есть целая вводная глава на этот счёт, предваряющая главы "Повторное использование" и "Переход к объектной технологии".

(Уж не знаю, стоит ли давать здесь его соображения по вопросу понимания модульности.)

Ответ на »сообщение 3740« (info21)
___________________________

Ответ на »сообщение 3735« (iZEN)
___________________________

Я никак не могу понять, чем неудобна Java. Объясните, пожалуйста.

Давно объяснено:
http://www.uclic.ucl.ac.uk/harold/srf/javaspae.html
Искусственные примеры.
Половина из которых мне ни разу не встретились за 7 лет использования Java, а про вторую половину мне (и большинству разработчиков) известно.

Ответ на »сообщение 3780« (Сергей Перовский)
___________________________

Нужна теория :)
Иначе как эталон выбирать.
Давайте попробуем для начала выработать хотя бы определение:  модульное программирование - это ... отличающееся тем, что ... с целью ....

Будем разбираться потихонечку. Сначала отделим мух от котлет, т.е. компоненты от модулей. Затем двинемся дальше.

Ответ на »сообщение 3782« (Сергей Губанов)
___________________________

Модули - это компоненты модульных систем. С точки зрения модульных систем модуль рассматривается одновременно как: 1) единица компиляции; 2) динамически загружаемая (и выгружаемая) единица исполнения (компонент системы); 3) объект, описываемый паттерном проектирования "Синглетон"; 4) единица (настоящей!) инкапсуляции; 5) единица расширения системы.

Возникает сразу несколько вопросов:

1. Модуль и компонент -- это одно и тоже? Или же есть (a)компоненты модульных систем и (b)компоненты немодульных систем?

2. Требование того, что модуль является единицей компиляции, автоматически наличие сущность "модуль" в языке программирования. Так?

3. Требование того, что модуль является динамически загружаемой/выгружаемой единицей исполнения, автоматически подразумевает наличие сущности "модуль" в среде исполнения. Так?

Модуль пункта 2 и модуль пункта 3 -- это один и тот же модуль в одном и том же виде? Или здесь надо еще вводить понятие вида модуля?

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

Теперь насчет компонента. Возьмем понятный образец -- систему Oberon (имею в виду Oberon System 3, или ETH Oberon). Там есть гаджет, т.е. хранимый в долговременной памяти объект (persistent object).

Вопросы:

4. Это компонент или нет?
5. А подгружаемый/выгружаемый модуль -- компонент?
6. Какой модуль нельзя назвать компонентом и какой компонент нельзя назвать модулем? Почему? Где проходит граница между модулем и компонентом?

Не все так просто. Ваши пункты 3-5 в определении модуля я еще даже и не обсуждаю, не говоря об остальном.

Модульное программирование - это ...

Модульное программирование - это программирование (расширяемых) модульных систем. Нельзя дать модулю определение исходя из каких-то его внутренних свойств. Определение модуля надо давать внешнее - через модульные системы. Нет модульной системы - нет модулей. Есть модульная система - вот и модули.


Секреты компонентного программирования

Губанов Сергей Юрьевич
21 ноября 2005

Модули - это компоненты модульных систем. С точки зрения модульных систем модуль рассматривается одновременно как: 1) единица компиляции; 2) динамически загружаемая (и выгружаемая) единица исполнения (компонент системы); 3) объект, описываемый паттерном проектирования "Синглетон"; 4) единица (настоящей!) инкапсуляции; 5) единица расширения системы. Взаимодействие между модулями осуществляется благодаря механизму импорта одним модулем нескольких других, тех которые он использует, т.е. является их клиентом. Граф импорта модулей ацикличен. Загрузкой (и выгрузкой) модулей в систему занимается ядро системы - среда времени исполнения. Модуль агрегирует в себе все программные сущности: константы, типы, переменные, процедуры. Некоторые программные сущности модуль экспортирует (делает доступными для клиентов), остальные скрывает - инкапсулирует. Поскольку модуль является единицей компиляции, то такую инкапсуляцию можно признать настоящей, ибо единственный способ ее взлома - изучение бинарного кода модуля. Совокупность экспортируемых модулем сущностей определяет его интерфейс. Через него осуществляется взаимодействие с модулями-клиентами. Если два модуля имеют одинаковый интерфейс (модули от разных производителей), то они взаимозаменяемы. Если из двух модулей второй имеет расширенный по сравнению с первым интерфейс (т.е. строго включает в себя интерфейс первого модуля, плюс к этому экспортирует дополнительные сущности), то второй модуль взаимозаменяем с первым (обратная совместимость). Это позволяет расширять спектр задач решаемых системой не только с помощью добавления новых модулей, но и заменой старых модулей на их расширенные версии. Однако, добавление нового или замена старого модуля ни в коем случае не должно приводить к разрушению целостности системы. Роль полицейского возложена на среду времени исполнения – ведь именно она загружает модули.
На каком основании среда времени исполнения может принимать решение о совместимости модулей? Самый простой способ – помечать каждый модуль какой-либо меткой о его версии (будь-то, явно указанная версия, или время последней компиляции timestamp). Старые (первые) модульные системы использовали механизм меток - timestamp. Но явное указание версии более предпочтительно, поскольку более поздний timestamp говорит лишь о том, что данный модуль скомпилировали в более позднее время, но не говорит о том, что его интерфейс реально был изменён. Техника выставления какой-либо метки версии модулю обладает следующим недостатком. Допустим, новый модуль отличается от старого модуля тем, что в нём изменена только небольшая часть интерфейса (например, поменяли значение одной экспортируемой константы, а всё остальное оставили без изменений). Формально, этот модуль теперь должен быть помечен другой версией. Но, существуют такие модули-клиенты, которые используют только неизменившуюся часть интерфейса. Из-за смены версии всего модуля все модули-клиенты будут инвалидированы – среда времени исполнения откажется загружать их (запускать на выполнение) совместно с формально изменённым модулем (все их надо перекомпилировать). Можно сказать, что такой простой механизм проверки совместимости модулей – хулиганство со стороны среды времени исполнения, которая будет инвалидировать все модули-клиенты без разбора. К счастью, существуют умные способы проверки совместимости модулей. Секрет умной проверки состоит в том, что каждая экспортируемая модулем сущность (константа, переменная, тип, процедура) снабжается своей собственной меткой - «отпечатком пальцев» (fingerprint) получаемой как некая «контрольная сумма» вычисленная над определёнными структурными инвариантными свойствами данной сущности. Найти правильный способ вычисления fingerprint-меток – нетривиальная задача особенно для сложных расширяемых типов данных. Более десяти лет назад в ETH на тему грамотного вычисления fingerprint-меток защищались докторские диссертации (см., например, диссертацию доктора Regis Crelier “Separate Compilation and Module Extension”, чьим научным руководителем были Никлаус Вирт и Хенспер Мёссенбёк – соавторы языка Oberon-2). Оказалось, что овчинка выделки стоит! Судите сами, если модули системы созданы разными производителями, то у потребителя (обладателя модульной системы) нет их исходных текстов, он имеет одни лишь исполнимые файлы модулей, следовательно, не может выполнить перекомпиляцию. Если какой-то модуль от одного производителя формально (т.е. с точки зрения среды времени исполнения) не полностью совместим с другими модулями, то та часть системы, которая с ним всё-таки совместима – гарантированно будет работать.
Программирование модульных систем, вообще говоря, не требует обязательного использования объектно-ориентированного подхода и наоборот. Однако, одновременное использование этих двух (независимых друг от друга) подходов для построения расширяемых систем привело к появлению новой парадигмы программирования. Десять лет назад, профессор Клеменс Шиперски (Clemens Szyperski) сформулировал основные положения Компонентно-ориентированного подхода (КОП) через ограничения, накладываемые на модульный подход и на ООП для их непротиворечивого одновременного сосуществования (“Component-Oriented Programming A Refined Variation on Object-Oriented Programming”, The Oberon Tribune, Vol 1, No 2, December 1995). Цель КОП – построение расширяемых (в полном смысле этого слова) систем с помощью модулей и ООП. Таким образом, КОП находится (по мнению Шиперского) «За пределами ООП» (так называется его уже дважды изданная за рубежом книга-бестселлер,  к огромному сожалению, до сих пор не переведённая в России). Фундамент КОП образуют: взятый из ООП полиморфизм, взятые из модульных систем позднее связывание (динамическая загрузка/выгрузка модулей) и настоящая инкапсуляция (возможная только на уровне модуля), а также тотальный контроль безопасности со стороны системы времени исполнения. Система времени исполнения теперь помимо управления динамической загрузкой/выгрузкой модулей контролирует корректность (динамического) приведения типов, корректность индексов массивов, осуществляет автоматическую сборку мусора. Автоматический сбор мусора – это не роскошь, а необходимость – одна из гарантий глобальной целостности компонентной системы (вспомним, что компоненты системы – модули создаются, вообще говоря, разными производителями). Теперь,  обратите внимание на то, что понятие «наследование» (т.е. расширение типа), так рекламируемое рядом современных ООП языков, не включено в фундамент КОП вовсе. Объяснение этому тривиальное. Если расширение типов используется внутри модулей, то это обычное ООП – там свои правила. Если же используется межмодульное расширение типов, то модули, типы между которыми связаны отношением наследования, становятся более жестко сцепленными друг с другом. Трудно заменить модуль с базовым типом на аналогичный модуль от другого производителя не инвалидировав при этом модули-клиенты, где этот тип расширен. КОП рекомендует использовать межмодульное наследование только от абстрактных типов (интерфейсов) – это разумный компромисс между ООП и модульными системами. Но программист, конечно, вправе сам решать стоит ли ему в его конкретной системе использовать межмодульное наследование типов «по полной программе» (тем самым жестко сцепляя модули) или же предпочесть вариант взаимозаменяемых модулей созданных различными производителями.
Прошло десять лет после появления КОП. Что мы имеем на сегодняшний день? Компания Microsoft продвигает свою версию компонентной системы – «платформу .Net» с каноническим для этой платформы языком программирования C#. Приятно, что лидер рынка средств разработки ПО, наконец, занялся компонентными системами. Однако предлагаемая им система не лишена недостатков. Во-первых, с огорчением констатирую, что среда времени исполнения .Net для проверки совместимости модулей не пользуется описанным выше fingerprint-механизмом. Вместо этого используется примитивная техника явного указания номера версии модуля. То есть, например, если .Net модуль кроме всего прочего экспортирует константу (которую, быть может, мало кто использует), то, внеся изменение в интерфейс этого модуля – поменяв значение константы, надо поменять и номер версии модуля тем самым инвалидировав все модули-клиенты (даже те, которые этой константой не пользовались). Во-вторых, с не меньшим огорчением констатирую, что в языке C#, предназначенном для программирования (больших) модульных расширяемых систем отсутствует само понятие модуля на синтаксическом уровне (стало быть, и импорта модулей). Глядя на исходный текст модуля, написанный на языке C# нельзя понять: а) какие модули он импортирует; б) в каком модуле определён тот или иной идентификатор (используемый механизм namespace – не связан с именами модулей). Но если количество модулей велико, то сложно удерживать в голове информацию о том, в каких модулях определены те или иные сущности. То есть собираемся создавать модульные системы, а язык используем прежний – заточенный для создания монолитных систем. Тем не менее, в настоящее время, существуют компонентные системы и компонентные языки программирования, практически свободные от недостатков. Может вызвать удивление, но первые модульные системы и языки появились еще в конце 70-тых годов прошлого века. Например, это операционная система для компьютера Lilith написанная на языке Modula-2 профессором Никлаусом Виртом. Затем, им же была создана операционная система Oberon (на одноимённом языке Oberon), которую уже можно считать компонентной, причём работа над ней началась еще в 1985 году (т.е. за 10 лет до формального провозглашения принципов КОП). В наши дни, например под OS Windows существует бесплатно распространяемая (с открытыми исходными текстами) компонентная среда BlackBox Component Builder производства компании Oberon Microsystems, Inc основанной в 1992 году. (Никлаус Вирт входит в состав совета директоров; а одним из сооснователей этой компании является «идеологический отец» КОП - профессор Клеменс Шиперски, правда в настоящее время он уже трудится в Microsoft). Есть версии BlackBox под MacOS, UNIX для 64-битных процессоров, сейчас готовится версия под Linux. Язык системы BlackBox является расширением языка Oberon-2 и называется Component Pascal. В BlackBox созданы: программа мониторящая крупнейшую на планете ГЭС на Амазонке; операционная система жесткого реального времени Portos (после чего от Oberon Microsystems отпочковалась дочерняя компания Esmertec переделавшая Portos в JBed – ОС реального времени используемую, например, в мобильных телефонах; BlackBox был превращен в среду кросс-разработки встраиваемых систем). По заказу компании Borland компания Oberon Microsystems написала для неё JIT компилятор Java для системы JBuilder. Недавно, у нас в России появилась первая компания ООО «Метасистемы» (г. Орёл) объявившая об использовании BlackBox Component Builder в качестве основного средства разработки своих программ. Существует международный проект «Информатика 21», одной из целей которого является продвижение системы BlackBox в школы на смену морально устаревшего Turbo Pascal. Если попытаться ответить на вопрос что лучше BlackBox или .Net, то надо учесть, что «сложность = уязвимость», а .Net сложнее BlackBox. Время всё расставит на свои места. Такие интересные секреты есть у компонентного программирования.