C# & КОП - Философия программирования

Считаю что C# + .NET пока далек от компонентного программирования, хотя приблизился к нему немного ближе чем многие другие языки и среды.

Что такое КОП и компонента, насколько я понял, нет однозначного определения. У меня ИМХО такое:

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

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

— В КОП Должна быть возможность манипуляции такими сущностями как компонента (как это делается с классами в ООП).
Например:
Из нескольких компонент создать один новый компонент,
или из компонента создать новый, слегка его модифицировав его объектную модель. Так чтобы в результате опять получился компонет — единица инкапсуляции и деплоймента. Вот с этим у C# проблемы.

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

-----------------------------------------------------

Например имеем компоненту A с такой объектной моделью с корнем IA1.

interface IA1
{
IA2 IA2{get;}
void Func1();
}

interface IA2
{
void Func2();
ICallback Callback{get;set;}
}

Необходимо создать компоненту B на базе A.
Чтобы из B торчала почти такая же ОМ как IA1 (отнаследоваться от ОМ).
Но реализовать следующее внутри B:
1) реализовать и подключить CallBack.
2) Закрыть доступ к проперти CallBack.
3) Добавить новую функцию (или поддерево в ОМ).
4) И естейственно чтобы эта компонента B осталась компонентой, т.е. инкапсулированой единицей деплоймента, такой же простой в подключении как исходная A.

На C# сейчас такое сделать принципиально невозможно, ... а зря.
Враперами теоретически можно обернуть. Но на практике это не реально в дереве могут быть не два узла а десятки, сотни.
--------------------------------------
Если нужен совсем конкретный пример, то ткнем пальцем в компоненты из Office, например PivotTable или Charting. Проимпортируем OWC, полученые обертки будут компонетой, единицей инкапсуляции и деплоймента ( по крайней мере если там где будем деплоить стоит офис). Но в ОМ у PivotTable есть несколько глючных пропертей для DataSource, они завязаны на древние RecordSet'ы, чтобы загнать в них данные нужно DataSet перегнать в XML файл на диске,потом отконвертировать XML в другой формат и потом его вставлять в компоненту. Лучше было бы отнаследоваться от этой компоненты и прикрыть в ОМ эти проперти, и на их место повесить свою проперти типа DataSet.

А на C# в лучшем случае можно сделать компоненту с отдельной функцией
SetDataSource(axPivotTable pt,DataSet ds), инкапсуляцией здесь не пахнет.
Для одной функции может так и сойдет, но для чего то большего это криво.

Здравствуйте, Silver_s, Вы писали:

S_> <...>

"компонента" ---> "компонент системы"

Если я правильно Вас понял, то компонент системы, в общем случае, экспортирует структуру взаимосвязанных интерфейсов объектов — то что Вы назвали объектной моделью (ОМ), а также экспортирует фабрики по производству объектов реализующих эти (и другие) интерфейсы. (Хотя могут быть и вырожденные компоненты системы: 1) экспортирующие только взаимосвязанные интерфейсы, 2) экспортирующие только фабрики по производству объектов реализующих интерфейсы описанные в другом компоненте системы.) С этим я совершенно согласен.

У меня поправочка по поводу:

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

компонент системы должен быть очень маленьким. Десятки и сотни экспортируемых интерфейсов объектов это слишком много. Лично у меня (после тщательного проектирования) количество взаимосвязанных интерфейсов внутри одного компонента системы не превосходило десятка. Я этого добивался за счет агрегации.

Здравствуйте, Silver_s, Вы писали:

S_>- Компонента это следующий, более крупный уровень инкапсуляции после классов.

КОП ортогонально классам.

S_> Инкапсулированный код это минимум деталей торчащих наружу. Для компонентов желательно чтобы они были в двоичном формате,

Обязательно.

S_>- Судя по всему с понятием компонента тесно связано понятие объектная модель.

Компонентная модель.

S_> Класс это (с натяжкой) фабрика объектов с плоским набором функций, компонента может выступать как фабрика объектных моделей.

Нет. Фабрика это сущность, класс это декларация.

S_> или из компонента создать новый, слегка его модифицировав его объектную модель.

Такого требования ни в одном опреджелении КОП я не видел.

S_> Так чтобы в результате опять получился компонет — единица инкапсуляции и деплоймента. Вот с этим у C# проблемы.

Никаких.

S_>В C# компоненты в бинарном формате создавать, инкапсулировать и использовать можно, но этого недостаточно,

Достаточно.

S_>Например имеем компоненту A с такой объектной моделью с корнем IA1.

Опять ты путаешь КОП и ООП.

S_>interface IA1
S_>{
S_> IA2 IA2{get;}
S_> void Func1();
S_>}

S_>interface IA2
S_>{
S_> void Func2();
S_> ICallback Callback{get;set;}
S_>}

S_>Необходимо создать компоненту B на базе A.
S_>Чтобы из B торчала почти такая же ОМ как IA1 (отнаследоваться от ОМ).
S_> Но реализовать следующее внутри B:
S_> 1) реализовать и подключить CallBack.
S_> 2) Закрыть доступ к проперти CallBack.
S_> 3) Добавить новую функцию (или поддерево в ОМ).
S_> 4) И естейственно чтобы эта компонента B осталась компонентой, т.е. инкапсулированой единицей деплоймента, такой же простой в подключении как исходная A.
S_> На C# сейчас такое сделать принципиально невозможно, ... а зря.

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

S_> Враперами теоретически можно обернуть. Но на практике это не реально в дереве могут быть не два узла а десятки, сотни.

CBO спасет отца русской демократии.

S_> Если нужен совсем конкретный пример, то ткнем пальцем в компоненты из Office,

Хреновый пример. Большую кашу, чем API офиса, еще поискать надо.

S_> например PivotTable или Charting. Проимпортируем OWC, полученые обертки будут компонетой, единицей инкапсуляции и деплоймента ( по крайней мере если там где будем деплоить стоит офис). Но в ОМ у PivotTable есть несколько глючных пропертей для DataSource, они завязаны на древние RecordSet'ы,
S_>чтобы загнать в них данные нужно DataSet перегнать в XML файл на диске,потом отконвертировать XML в другой формат и потом его вставлять в компоненту.

Для преобразования XML сохранять его на диск не обязательно.

S_> Лучше было бы отнаследоваться от этой компоненты и прикрыть в ОМ эти проперти, и на их место повесить свою проперти типа DataSet.

PivotTable это СОМ. При чем тут C#?

S_> А на C# в лучшем случае можно сделать компоненту с отдельной функцией
S_> SetDataSource(axPivotTable pt,DataSet ds), инкапсуляцией здесь не пахнет.
S_> Для одной функции может так и сойдет, но для чего то большего это криво.

А правильным решением было бы создание отдельного компонента, занимающегося преобразованием требуемых потоков данных.

... << RSDN@Home 1.1.4 beta 3 rev. 232>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>У меня поправочка по поводу:

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

СГ>компонент системы должен быть очень маленьким. Десятки и сотни экспортируемых интерфейсов объектов это слишком много. Лично у меня (после тщательного проектирования) количество взаимосвязанных интерфейсов внутри одного компонента системы не превосходило десятка. Я этого добивался за счет агрегации.

Ну в MSHTML объектной модели например, там довольно много обьектов и интерфейсов и сложно сказать что там что-то лишнее.
Зависит от сложности сущности на которую натягивают объектную модель.

Здравствуйте, AndrewVK, Вы писали:

AVK>КОП ортогонально классам.

Возможно я другое понятие КОП имею в виду, так сказать ObjectModel Oriented Programming

S_>> Класс это (с натяжкой) фабрика объектов с плоским набором функций, компонента может выступать как фабрика объектных моделей.

AVK>Нет. Фабрика это сущность, класс это декларация.

S_>> или из компонента создать новый, слегка его модифицировав его объектную модель.
AVK>Такого требования ни в одном опреджелении КОП я не видел.

Я тоже в теории такого требования к КОП не видел, такие требования предявляют реальные задачи.

S_>> Так чтобы в результате опять получился компонет — единица инкапсуляции и деплоймента. Вот с этим у C# проблемы.
AVK>Никаких.

Проблем нет только при полной агрегации и полном сокрытии всех агрегированных компонентов.
А определение какой то структуры данных или класс из агрегированой компоненты протолкнуть
наружу уже нельзя. Единственный выход долбаные враперы для них писать.

S_>>interface IA1
S_>>{
S_>> IA2 IA2{get;}
S_>> void Func1();
S_>>}

S_>>interface IA2
S_>>{
S_>> void Func2();
S_>> ICallback Callback{get;set;}
S_>>}

S_>>Необходимо создать компоненту B на базе A.
S_>>Чтобы из B торчала почти такая же ОМ как IA1 (отнаследоваться от ОМ).
S_>> Но реализовать следующее внутри B:
S_>> 1) реализовать и подключить CallBack.
S_>> 2) Закрыть доступ к проперти CallBack.
S_>> 3) Добавить новую функцию (или поддерево в ОМ).
S_>> 4) И естейственно чтобы эта компонента B осталась компонентой, т.е. инкапсулированой единицей деплоймента, такой же простой в подключении как исходная A.
S_>> На C# сейчас такое сделать принципиально невозможно, ... а зря.

AVK>Возможно. Вот только здесь явные проблемы с дизайном. Такую кашу в интерфейсах в реальности нужно рефакторить по получения ясной модели.

Каша это если за каждым интерфейсом по 10 строчек функционала. А если десятки тысяч, то это очень мощная инкапсуляция.
Все зависит от метрик, какой обьем функционала удалось упаковать по отношению
к размеру логичности и понятности интерфейсной части.
К сожалению не всякий функционал можно упрятать за плоским набором функций.
Такой патерн в нескольких проектах очень круто разруливал ситуацию.
Конкретнее: Имеем компоненту объемом пару десятков тыс. строк и довольно сложными связями
внутри. Удалось состряпать интерфейс из небольшой и логичной объектной модельки. Штук 8-10 интерфейсов в дереве,
по 5-10 функций и пропертей в каждом.
Далее на одном из узлов дерева гнездо для плагина — ICallback Callback{get;set;}, в колбэк интерфейсе 5-7 родственных функций
Сам плагин — не совсем плагин а наращивание функционала, по сложности и объему он примерно такой же как и первая компонента (много человеко месяцев), но там совсем другой функционал.
Плагин втыкает в дерево свой колбэк и плюс еще пользуется разными частями дерева ОМ.
В данном случае такая декомпозиция единственно возможный вариант, т.к. резко упростила разработку этих 2 компонент.
Если компоненту-плагин засунуть внутрь то кранты, там связанность и зависимости между частями значительно сложнее,
чем это выглядит по объектной модели.
Все бы хорошо но эта компонента+плагин опять образуют единицу инкапсуляции. Т.е. клиент этих компонент поступает так:
Инстанциирует сущность которая в компоненте 1, инстанциирует плагин передав ему ссылку на ОМ компоненты.
И дальше пользуется функционалом плагина, и частью функционала ОМ компоненты 1 , помня что нежелательно в этой ОМ кое что трогать-то куда прикрепился плагин.
Дык вот нужны средства из этой связки сделать более инкапсулированный компонент, более цивилизоваными средствами чем враперы.
Т.е. кое что прикрыть нужно в этом дереве и кое что прикрепить, чтобы единая сущность получилась.

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

S_>> На C# сейчас такое сделать принципиально невозможно, ... а зря.

AVK>Возможно. Вот только здесь явные проблемы с дизайном. Такую кашу в интерфейсах в реальности нужно рефакторить по получения ясной модели.

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

Но изменение этих мелочей выливается во что-то большое и монстрообразное, если исходный компонент имел структуру далекую от плоской.

Здравствуйте, Silver_s, Вы писали:

AVK>>КОП ортогонально классам.

S_>Возможно я другое понятие КОП имею в виду, так сказать ObjectModel Oriented Programming

http://en.wikipedia.org/wiki/Special:Search?search=objectmodel+oriented+programming

Нет совпадений.

http://www.google.ru/search?hl=ru&q=%22objectmodel+oriented+programming%22&lr=

Нет совпадений.

S_>>> или из компонента создать новый, слегка его модифицировав его объектную модель.
AVK>>Такого требования ни в одном опреджелении КОП я не видел.

S_> Я тоже в теории такого требования к КОП не видел, такие требования предявляют реальные задачи.

А при чем тут тогда КОП? Рассказывай в чем у тебя проблемы, а не обвиняй современные языки в недостаточной компонентноориентированности.

S_>>> Так чтобы в результате опять получился компонет — единица инкапсуляции и деплоймента. Вот с этим у C# проблемы.
AVK>>Никаких.

S_> Проблем нет только при полной агрегации и полном сокрытии всех агрегированных компонентов.
S_> А определение какой то структуры данных или класс из агрегированой компоненты протолкнуть
S_> наружу уже нельзя.

Это называется подключение реализаций.

S_> Единственный выход долбаные враперы для них писать.

Не единственный. Как минимум есть еще уже упомянутый CBO и возможность делать это при помощи кодогенерации в рантайме.
А можно просто перепроектировать структуру программы так, чтобы подключение реализаций не понадобилось. Для этого существуют несколько паттернов, например коннектор.

AVK>>Возможно. Вот только здесь явные проблемы с дизайном. Такую кашу в интерфейсах в реальности нужно рефакторить по получения ясной модели.

S_> Каша это если за каждым интерфейсом по 10 строчек функционала.

Это пофигу. Каша не в реализации, а в интерфейсе.

S_> А если десятки тысяч, то это очень мощная инкапсуляция.
S_> Все зависит от метрик, какой обьем функционала удалось упаковать по отношению
S_> к размеру логичности и понятности интерфейсной части.
S_>К сожалению не всякий функционал можно упрятать за плоским набором функций.

Мдя. А по русски никак?

S_> Конкретнее: Имеем компоненту объемом пару десятков тыс. строк и довольно сложными связями
S_> внутри. Удалось состряпать интерфейс из небольшой и логичной объектной модельки. Штук 8-10 интерфейсов в дереве,
S_> по 5-10 функций и пропертей в каждом.
S_> Далее на одном из узлов дерева гнездо для плагина — ICallback Callback{get;set;}, в колбэк интерфейсе 5-7 родственных функций

Я не могу ничего сказать про то, что ты описываешь, могу лишь догадываться. А догадки такие:
1) Колбеки очень неприятная штука на самом деле, особенно при сложных объектных графах, особенно в условиях GC.
2) Практически в любой ситуации существуют несколько проектных решений, одинаково хороших по большинству параметров.
3) Выставление наружу сложных объектных графов как правило сильно утежеляет API и делает его запутанным и слабомасштабируемым. По возможности с подобным следует бороться. Для этого опять же существуют паттерны — мост, визитор.

S_>В данном случае такая декомпозиция единственно возможный вариант,

Не верю.

S_> т.к. резко упростила разработку этих 2 компонент.

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

... << RSDN@Home 1.1.4 beta 3 rev. 231>>

Здравствуйте, AndrewVK, Вы писали:

S_>> Так чтобы в результате опять получился компонет — единица инкапсуляции и деплоймента. Вот с этим у C# проблемы.
AVK>Никаких.

Вот все таки хочется такую фичу как выборочный экспорт типов из агрегированой сборки наружу.

Например приобрели у некоторого разработчика компоненту. Т.е. сборку .dll
Подключили к проекту, и вылетает ошибка, какая то функция возвращает System.Drawing.Point, надо добавлять ссылку на System.Drawing. А нельзя ли было сделать так чтобы этот компонент ссылался на System.Drawing, и экспортировал Point(ну и все от которых зависит), так чтобы клиент не добавлял ссылки на System.Drawing и не видел бы из нее другие типы кроме Point , желательно даже чтобы через Reflection видно не было. Если же подключит Drawing, естейственно нужно чтобы эти Point оказались одним и тем же типом.

Ну для стандартных то сборок это не так актуально.
А вот если разработчику приспичило при разработке компоненты сделать декомпозицию на 4 сборки.

Вопрос на засыпку, это будет хорошая инкапсуляция или нет?: Если мы приобретем компоненту в таком виде — Разработчик впарил нам компоненту состоящую из 4-х .dll. И инструкцию по применению,
1) Все dll должны лежать в исполняемой директории,
2) При подключении к проекту добавлять ссылку на 3 dll. Одна основная, в двух других по одному классу которые используются основной сборкой как возвращаемый параметр, поэтому на них ссылки тоже надо подключать. На четвертую сборку можно не обращать внимания, она просто должна быть, и никуда ее подключать не надо.
3) Главная сборка полностью для клиента, а из 2 другх используются 2 класса, а остальные 50 классов из них трогать не стоит они только для внутреннего взаимодействия между этими 4 частями.

Ну скажем этому разработчику — "криво получилось, иди дальше инкапсулируй".
"А он скажет — да не могу я их инкапсулировать, я одну сборку вобще купил у третьего разработчика, а во второй сборке этот класс нельзя переносить в основную иначе архитектура попортится сложнее разработка будет. А враперы для этих 2 классов писать запарюсь. Так что либо на 30% стоимость компоненты увеличу, либо не обращай внимания на эти лишние 50 классов, если их не тревожить они вреда не причинят..."
...И накапливаться это будет как снежный ком, разрушая инкапсуляцию.
Так что при сборке одной компоненты из нескольких, проблемки с инкапсуляцией есть.

Здравствуйте, Silver_s, Вы писали:

S_> Например приобрели у некоторого разработчика компоненту. Т.е. сборку .dll
S_> Подключили к проекту, и вылетает ошибка, какая то функция возвращает System.Drawing.Point, надо добавлять ссылку на System.Drawing. А нельзя ли было сделать так чтобы этот компонент ссылался на System.Drawing, и экспортировал Point(ну и все от которых зависит), так чтобы клиент не добавлял ссылки на System.Drawing и не видел бы из нее другие типы кроме Point , желательно даже чтобы через Reflection видно не было. Если же подключит Drawing, естейственно нужно чтобы эти Point оказались одним и тем же типом.

Ничего не понял. Разрешение ссылок все равно происходит в рантайме. Ссылки в студии по большей части нужны для компилятора. Даже если ты ссылаешься на сборку, она все равно реально загрузится только в момент использования, а если не ссылаешься то вполне можешь загрузить сам. Если же тебе нужна хитрая механика управления доступностью кода, то для этого есть CAS.

S_> Вопрос на засыпку, это будет хорошая инкапсуляция или нет?: Если мы приобретем компоненту в таком виде — Разработчик впарил нам компоненту состоящую из 4-х .dll. И инструкцию по применению,
S_>1) Все dll должны лежать в исполняемой директории,
S_>2) При подключении к проекту добавлять ссылку на 3 dll. Одна основная, в двух других по одному классу которые используются основной сборкой как возвращаемый параметр, поэтому на них ссылки тоже надо подключать. На четвертую сборку можно не обращать внимания, она просто должна быть, и никуда ее подключать не надо.
S_>3) Главная сборка полностью для клиента, а из 2 другх используются 2 класса, а остальные 50 классов из них трогать не стоит они только для внутреннего взаимодействия между этими 4 частями.

Если есть объективные причины такого разнесения по сборкам (раздельная поставка, компоненты третьих фирм и т.п.) то вполне нормально.

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

Пока что я проблем не увидел.

... << RSDN@Home 1.1.4 beta 3 rev. 231>>

Здравствуйте, AndrewVK, Вы писали:

AVK>А при чем тут тогда КОП? Рассказывай в чем у тебя проблемы, а не обвиняй современные языки в недостаточной компонентноориентированности.

Я на C# особо не наезжаю, просто некоторые фичи хотелось бы иметь дополнительно.

S_>> Все зависит от метрик, какой обьем функционала удалось упаковать по отношению
S_>> к размеру логичности и понятности интерфейсной части.
S_>>К сожалению не всякий функционал можно упрятать за плоским набором функций.
AVK>Мдя. А по русски никак?

Если две крупные компоненты связаны всего одним callback интерфейсом с 6 функциями, значит они получились очень независимыми. Между 2 сущностями по 500 строчек каждая, callback такого объема это слабенькая инкапсуляция, если они по 10тыс. строк тогда сильная инкапсуляция. Нравится это или нет но эти связи останутся по любому. И лучше эти связи явно запротоколировать интерфейсом и разделить эти части.

AVK>1) Колбеки очень неприятная штука на самом деле, особенно при сложных объектных графах, особенно в условиях GC.
AVK>2) Практически в любой ситуации существуют несколько проектных решений, одинаково хороших по большинству параметров.
AVK>3) Выставление наружу сложных объектных графов как правило сильно утежеляет API и делает его запутанным и слабомасштабируемым. По возможности с подобным следует бороться. Для этого опять же существуют паттерны — мост, визитор.

Да,конечно, несколько решений существует. То что я описал имеет аналоги в ООП. Если бы делалось в стиле ООП, то очень приближенно первая компонента была бы плоским классом где все свалено в кучу. Но все же в этом классе еще были бы парочка коллекций других классов, в которых абстрактные функции — это альтернатива callback интерфейсам для прикрепления функционала. Классы в этих коллекциях не просто лежат, а взаимодействуют и между собой и с контейнером
Ну скажем примерно 10тыс строк на основные классы, и 10тыс строк на реализацию абстрактных функций.
Но такой вариант был бы очень неудачный, слабая инкапсуляция со всеми вытекающими последствиями.
А так оно реально выглядит как наследование от сложной иерархической компоненты и расширение функционала. Те. наследование от более высокоуровневой штуки чем класс. Только сам механизм которым достигается такое наследование не очень удобный.

S_>> т.к. резко упростила разработку этих 2 компонент.
AVK>Да я уж вижу как упростила. Так что возможностей языка перестало хватать, а от взгляда даже на грубую модель наружного интерфейса становится страшно

Лучше небольшие сложности поиметь на самом верхнем уровне при стыковке этих компонент, чем сложности при их реализации.

Здравствуйте, AndrewVK, Вы писали:

AVK>Не единственный. Как минимум есть еще уже упомянутый CBO и возможность делать это при помощи кодогенерации в рантайме.

ContextBoundObject? Да его вроде немного для другого делали. Слишком уж темные делишки
внутри него творятся. И перфоманс он вроде неслабо просаживает.
А рантайм кодогенерация вызывает аналогии с ассемблерными вставками на C++, вcе же штатные средства получше и с проверками в компайл тайм.

AVK>А можно просто перепроектировать структуру программы так, чтобы подключение реализаций не понадобилось. Для этого существуют несколько паттернов, например коннектор.

Ну для начала исходим из того что могут быть случаи когда есть компонента с интерфейсом который трогать нельзя — либо от стороннего производителя и без исходников, либо этих исходников гигабайты..терабайты и в них ковыряться нельзя.

Вот что мешает для начала в язык добавить хотя бы такую фичу? :
Здесь IExternalInterface неизменяемый интерфейс из компоненты от сторннего производителя.
Здесь полудинамическое подключение во время конструирования. В компайл тайм здесь все полностью проверяемо. Т.е компилер всегда найдет ошибки если реализация подключилась не вся. А возни с враперами хоть немного но меньше будет.

interface IExternalInterface
{
    void ExternalFunc1();
    void ExternalFunc2();
    void ExternalFunc3();
}

interface IMyInterface
{
    void ExternalFunc1();
    void ExternalFunc3();
    void MyFunc1();
}

public class MyClass: IMyInterface
{
    public MyClass(IExternalInterface ei):IMyInterface(ei) {}
    void MyFunc1(){}
}

......

IExternalInterface exInt=component.Get();
IMyInterface my=new MyClass(exInt);

my.ExternalFunc1();

Здравствуйте, AndrewVK, Вы писали:

AVK>1) Колбеки очень неприятная штука на самом деле, особенно при сложных объектных графах, особенно в условиях GC.
.....
AVK>3) Выставление наружу сложных объектных графов как правило сильно утежеляет API и делает его запутанным и слабомасштабируемым. По возможности с подобным следует бороться. Для этого опять же существуют паттерны — мост, визитор.

В патерне мост тоже своеобразный колбек, только вид сбоку. Если смотреть реализацию здесь:
http://www.dofactory.com/patterns/PatternBridge.aspx

Мост это по идее разновидность абстракции — "Не до конца реализованый объект + изолированная реализация". Вариантов реализации этой абстракции может быть много для разных целей, одна из них — "патерн мост". Даже простое наследование и переопределение виртуальных функций это похожая вешь но более статическая и с меньшей изоляцией.

Вот вариант с более мощной изоляцией:

IBase — это интерфейс не до конца реализованного объекта, находящегося в изолированой компоненте.

interface IBase
{
    void BaseFunc();
    ICallback Callback{get;set;}
}
interface ICallback
{
    void CallbackFunc();
}

//Реализация

abstract class Inherited: ICallback
{
    IBase _Base;
    public Inherited(IBase i)
    {
        _Base=i;
        _Base.Callback=(ICallback)this;
    }

    public abstract void CallbackFunc();
    public void BaseFunc(){_Base.BaseFunc();}
}

class Inherited2 : Inherited
{
    Inherited2(IBase i):base(i){}
    public override void CallbackFunc(){}
}

Здравствуйте, Silver_s, Вы писали:

S_> ...не обращай внимания на эти лишние 50 классов...

О! А я что говорил! Модули (то бишь компоненты системы, они же сборки в дотНете) должны быть маленькими. 10 классов в одном модуле — это уже серьезно, а 50 — явный перебор.

Здравствуйте, AndrewVK, Вы писали:

AVK> КОП ортогонально классам.

Дело не в ортогональности. Разница между КОП и ООП в масштабе грануляции. ООП с классами — это микроуровень. КОП с компонентами — это макроуровень. Один КОП-компонент включает в себя несколько ООП — классов/интерфейсов объектов.

Здравствуйте, Silver_s, Вы писали:

S_> Считаю что C# + .NET пока далек от компонентного программирования, хотя приблизился к нему немного ближе чем многие другие языки и среды.

Ошибашся.

S_> Что такое КОП и компонента,

Он — компонет. Кого — компонента. Он не мужского рода.

S_> насколько я понял, нет однозначного определения.

компонет

S_>В C# компоненты в бинарном формате создавать, инкапсулировать и использовать можно, но этого недостаточно, должна быть возможность и средства производить с компонентами различные манипуляции .
S_> Манипуляций довольно много, в которых реально возникает необходимость.
...
S_>Необходимо создать компоненту B на базе A.

Это детали реализации которые к КОП отношения не имеют.

S_> На C# сейчас такое сделать принципиально невозможно, ... а зря.

Все на нем возможно. Было бы желание и умение.

... << RSDN@Home 1.1.4 beta 3 rev. 207>>

	От:	Silver_s
	Дата:	19.11.04 13:09
	Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	19.11.04 13:32
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	19.11.04 13:42
Оценка:	+2

	От:	Silver_s
	Дата:	19.11.04 14:02
	Оценка:

	От:	Silver_s
	Дата:	19.11.04 16:23
	Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	19.11.04 17:16
Оценка:

От:	VladD2	www.nemerle.org
Дата:	26.11.04 01:51
Оценка: