Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Как учитывать и использовать компоненты?  (Прочитано 7312 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« : 21-10-2006 18:01 » 

Всем привет!
Пока особо не размышлял, но возник такой вопрос.
Есть у меня разработанный компонент, который реализует несколько интерфейсов.
Теперь возникла необходимость создание еще одного компонента системы, который тоже должен поддерживать эти интерфейсы.
Создать не проблема. Будет у меня Компонент1.Интерфейс1 или Компонент2.Интерфейс1.
Но получается, что клиент, который должен работать с компонентами должен их знать! А мне хотелось-бы что-бы ему было сугубо фиолетово, лишь бы компоненты предлагали нужный/ые интерфейсы. Т.е. он должен "видеть" все компоненты с такими интерфейсами.
Как это сделать?
Записан

Ёжики, это не только ценные шкурки...
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #1 : 23-10-2006 14:12 » 

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

Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 23-10-2006 14:27 » 

Igel, а почему не сделать один единственный КОМ-объект, и компоненты, его юзащие? вопрос учитывания интерфейсов ляжет на CoClass, а сами объекты будут по необходимости создаваться и освобождаться.
Это по принципу Фабрики объектов?

В моем случае не подойдет. Это как расширяемая система или плагины.
Например в системе 2 модуля. Один из которых знает про другой. Например модуль работы с данными и модуль отчета.
Модуль отчета знает некий интерфейсм модуля данных, по которому может построить отчет.
Модуль работы с данными вообще не подозревает о модуле отчета.
В систему добавлено еще несколько модулей работы с данными - со своими спецификами - расширение системы. Модуль отчета должен работать с ними.
Записан

Ёжики, это не только ценные шкурки...
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #3 : 23-10-2006 14:30 » 

не совсем понял, кто кого юзает, модуль данных командует модулем отчёта, или наоборот?

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

x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #4 : 23-10-2006 14:41 » 

т.е. я имею в виду, что когда модуль отчёта будет юзать чей-то интерфейс, он, собственно, не будет знать, чей именно интерфейс он юзает - потомка или предка. если предка - всё понятно (работает так, как сейчас у тебя), если потомка - то у потомка методы, задействуемые интерфейсами предка будут переопределены. модуль отчёта будет их также вызывать, не имея понятия, как именно они отрабатывают.
Записан

Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 23-10-2006 15:19 » new

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

можно, например, завести один модуль данных, и научить с ним работать модуль отчёта. в модуле данных основные функции сделать виртуальными. а далее остальные модули данных будут наследоваться от исходного и, при необходимости, переопределять эти самые основные функции.
Тэкс... это-то как раз таким образом почти и реализуется.
Когда я говорил о модуле данных, я имел ввиду самостоятельное приложение, например dll-файл.
Модуль отчета умеет работать с интерфейсом модуля данных. Остальное ему знать и не нужно.
Записан

Ёжики, это не только ценные шкурки...
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines