В чем основная задача ООП? На мой взгляд - облегчить сопровождение программы. И такие вещи как наследование, полиморфизм и инкапсуляция действительно помогают в этом. Потому что в верно спроектированную ОО-систему всегда не трудно добавить функциональность или внести какие-нибудь другие изменения. Кто-то говорил, что ООП возможно не только на ОО языках. Возможно... но я слабо представляю себе полиморфизм на языке C (Ручное создание таблицы виртуальных функций?!). ОО языки облегчают сам процесс ООП. Основное понятие ООП - объект. (Вернее даже "субъект"). Мы знаем ЧТО он делает , но нам совсем не обязательно знать КАК он делает, если конечно он делает то, что мы от него ожидаем, не больше и не меньше
Например, легковой автомобиль. Мы знаем для чего он предназначен, как им управлять, какое топливо покупать, у нас есть даже права, но при этом мы можем и не знать, какие процессы происходят внутри автомобиля. Также не секрет, что автомобиль содержит в себе множество различных деталей, каждая из которых также может состоять из других деталей. Кроме того, детали нашего легкового автомобиля врядли подойдут другим объектам, например нашей стиральной машине или холодильнику. А теперь представим, что мы конструкторы автомобиля...
Прежде чем создать автомобиль нам нужно создать детали, из которых он состоит. И вот тут возникают вопросы... Понятно, что некоторые детали мы можем взять уже готовыми. Если говорить терминами КП - из других модулей. Но некоторые придется делать самим (должен же наш автомобиль чем-то отличаться от других!) Куда разместить эти наши детали? Опять же, если говорить о КП, то тут такие варианты:
1) для каждой детали создаем свой модуль.
2) все детали помещаем в тот же модуль, где находится автомобиль.
В КП второй подход, на мой взгляд, совершенно противоречит ООП, так как детали в автомобиле взаимодействуют между собой. А объекты внутри модуля могут получать доступ к полям друг друга, скорее всего невидимым вне модуля. А детали могут быть совершенно разными. И что произойдет, когда нам придет в голову поменять какую-нибудь деталь?! Конечно, детали внутри модуля могут быть связаны друг с другом только через свои интерфейсы. Они и должны быть связаны друг с другом только через свои интерфейсы!
ООП - фактически ограничение самого себя с помощью компилятораА если ограничений нет, то нет и ООП (программирования, проектирование есть). Получается, нам нужно каждую деталь хранить в отдельном модуле. А отдельный модуль с одним экспортируемым типом в КП, чем не класс в С++?
Можно также поместить все схожие по назначению детали в один модуль. Эти детали уж точно никак не будут взаимодействовать между собой (Карбюратор и инжектор внутри одного автомобиля не уживаются) Но где гарантия? То есть в этом плане КП ограничивает свободу - правильных решений не много.
Мне кажется, отсутствие инкапсуляции внутри модуля в КП, то есть отсутствие понятия КЛАСС - недостаток КП. Такой же, как отсутствие понятия МОДУЛЬ в С++. Чем плохо, если бы RECORD в КП аналогично CLASS или SCRUCT в С++ имел бы директивы PRIVATE и PUBLIC,  действующие внутри модуля тоже?
[/b]