Библиотеки для Delphi

← →
euru (2003-01-29 14:25) [0]

Есть ли еще кроме KOL и VCL какие-либо библиотеки визуальных компонентов для Delphi?

← →
Ru (2003-01-29 14:41) [1]

Jedi
TMS
... and many many other ...

← →
Ihor Osov'yak (2003-01-29 14:44) [2]

а что такое "библиотека"? Сходи на www.torry.net, может чего и отыщешь под свой критерий библиотечности....

← →
Ru (2003-01-29 14:57) [3]

на мой взгляд пакет компонентов или просто компоненты

← →
euru (2003-01-29 15:04) [4]

Мне интересно, есть ли какие другие варианты организации иерархии классов, отличающиеся от VCL. В качестве примера можно назвать KOL. А еще?

← →
euru (2003-01-29 16:08) [5]

Неужели ничего нет?

← →
euru (2003-01-29 17:06) [6]

Все так плохо?

← →
danilka (2003-01-29 17:08) [7]

зайди на кол, там были ссылки на подобные библиотеки.

← →
euru (2003-02-06 10:54) [8]

Предлагаю продолжить эту тему.

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

← →
Ketmar (2003-02-06 11:03) [9]

>euru © (06.02.03 10:54)
йафл -- в кладовку, ссылку - сюда. а мы уж потом заплюём.

Satanas Nobiscum! 06-Feb-XXXVIII A.S.

← →
Ketmar (2003-02-06 11:04) [10]

ммать! "йафл" = "файл". пардон.

Satanas Nobiscum! 06-Feb-XXXVIII A.S.

← →
euru (2003-02-06 11:32) [11]

Выложил.

Ссылка: http://delphi.mastak.ru/cgi-bin/download.pl?get=1044520123&n=2

Жду критику, вопросы, предложения.

← →
Ketmar (2003-02-06 12:02) [12]

не совсем понял ЗАЧЕМ такое извращение...

Satanas Nobiscum! 06-Feb-XXXVIII A.S.

← →
euru (2003-02-06 12:42) [13]

> Ketmar ©

Если вкратце, то при таком подходе реализация (имплементация) класса не зависит от его декларации.
Преимущества:
1. можно поменять реализацию класса, не имея ее исходников (лишь бы интерфейс был правильно описан).
2. можно подменить реализацию родительского класса, при этом все его потомки автоматически поменяют свое поведение - это позволит уменьшить ветвистость иерархии.
Например, есть у нас компонент TComboBox с итерфейсами IDisplay (для вывода на экран) и IDataSource (для получения выводимых данных). Достаточно будет перегрузить только эти интерфейсы или один из низ, чтобы поменять поведение стандартного TComboBox"а на необходимое (типа, брать данные из потока или из базы данных).
3. Может еще что-то можно придумать, но мне пока не придумывается :)

Недостатки:
Собственно ддя этого я и выложил пример.
Желательно бы, конечно, услышать что-то конструктивное.

> не совсем понял ЗАЧЕМ такое извращение...

Если про извращение, то я пока не вижу, как это проще выразить в Delphi (да и в других языках)ю
Если про ЗАЧЕМ, то вдруг эта идея кому-нибудь придет по вкусу (есть же поклонники KOL) и он ее разовьет до чего-то потребного

← →
Ketmar (2003-02-06 12:58) [14]

>euru © (06.02.03 12:42)
вот теперь понял немного. а может ты бы сделал чуть больше классов подобных? вот хотя бы твои пример с комбобоксом. еще чего. а то уж больно лаконично там всё... сразу и не придумаешь, куда приткнуть %-)

зыж
не обращай внимания на слово "извращение". никакого негативного смысла в данном случае я в него не вкладывал.

Satanas Nobiscum! 06-Feb-XXXVIII A.S.

← →
euru (2003-02-06 13:40) [15]

>Ketmar © (06.02.03 12:58)
Реальных примеров у меня нет, пока есть только идея (реализацию которой я предоставил) и несколько экспериментов. Экперименты представляют собой нагромождения кода, из которых еще предстоит извлечь новые идеи :)
Я лучше напишу возможные пути развития, которые я увидел (под компонентами я подразумеваю не VCL-ские компоненты):

1. В принципе, ничего не мешает применить уже показанный способ не для класса, а для какого-то конкретного объекта. Полезность: используются стандартные компоненты, но один или несколько отличаются - не нужно порождать еще 1 класс, достаточно перегрузить реализацию класса для этого объекта.

2. (отсюда и далее из экспериментов) В дополнение к наследованию классов и интерфейсов можно сделать наследование реализаций. Полезность: при реализации своих интерфейсов необязательно полностью переписывать весь код - можно вызвать код реализации предыдущего интерфейса и сделать необходимые дополнения.

3. При описании класса можно вообще не указывать какие интерфейсы он будет использовать, а добавить их во время исполнения программы (при этом класс будет себя вести как будто эти интерфейсы были описаны еще при объявлении класса). Полезность: не нужно добавлять дополнительные свойства и поведения классу без лишней необходимости (напр., часто VCL компоненты используют drag&drop или docking? - значит, нужно добавлять эту возможность только когда она действительно нужна)

4. А если все это объединить... :)

← →
euru (2003-02-06 15:10) [16]

Неужели никого это не заинтересовало?

← →
Игорь Шевченко (2003-02-06 15:39) [17]

euru © (06.02.03 15:10)

Не совсем понятна цель такого построения классов...Идея как раз понятна - сделать нечто похожее на COM. Но COM, вроде, уже сделан...Разве что лавры Ивана Кулибина покоя не дают...
Кстати, рекомендую книгу: Delphi 6 и технологии COM. Елманова, Трепалин, Тенцер.

← →
euru (2003-02-06 16:07) [18]

> Игорь Шевченко © (06.02.03 15:39)

Честно признаюсь, что не силен в COM. Но:
- разве COM уже есть в Linux?
- COM поддерживает реализацию вышеуказанных мною пунктов (euru © (06.02.03 13:40))?

← →
Игорь Шевченко (2003-02-06 17:03) [19]

> COM поддерживает реализацию вышеуказанных мною пунктов

Да вроде...

Про Linux ничего сказать не могу.

← →
euru (2003-02-06 17:19) [20]

>Игорь Шевченко © (06.02.03 17:03)

>Да вроде...
Хотелось бы посмотреть, как это делается в COM. Желательно бы пример, типа, вот смотри этот код, он делает тоже, что и у тебя, или очень похожее на это.

Может другие знатоки COM помогут? (это не вызов, мне действительно интересно, можно ли так извратиться с COM)

← →
Игорь Шевченко (2003-02-06 17:41) [21]

Книгу я посоветовал. Читайте и воздастся вам сполна. На худой конец - Тейксейра, Пачеко: Delphi 5(6). Руководство разработчика.
Там тоже достаточно подробно написано. Велосипед, опять же, не надобудет изобретать.

← →
euru (2003-02-06 18:00) [22]

>Игорь Шевченко © (06.02.03 17:41)

Вот ведь какая оказия. Ищу я, значит, какую-то из этих книг, читаю, углубленно изучаю СОМ. На это уходит время. А потом оказывается, нельзя так использовать СОМ - не предназначен он для этого. Велосипед построить - пожалуйста, самокат - да ради бога, а вот махолет - извиняйте, не по адресу товарищ.

Вот я и спрашиваю - есть такие примеры с СОМ или нет? Покажите пример, а потом можете и послать меня :) ... к вышеукзанным авторам или даже MSDN.

← →
Набережных С. (2003-02-06 18:01) [23]

Что-то я не понял - чего здесь оригинального-то? ИМХО, обычная работа с интерфейсами, если только не считать банального смешивания интерфейсной и объектной моделей, из-за чего пришлось отключить механизм подсчета ссылок. Или я все-таки чего-то не понял?

← →
euru (2003-02-06 22:57) [24]

>Набережных С. (06.02.03 18:01)
На оригинальность я не претендовал. Просто предложил организовать иерархию классов по другому принципу. Вроде даже написал, какие при этом преимущества достигаются по сравнению со стандартным методом. Про недостатки не писал, потому что пока не нашел - наверно, мешает эйфория того, что у меня эта идея заработат :) Собственно, это одна из причин, почему я выложил этот код.

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

← →
iZEN (2003-02-07 11:05) [25]

Похоже на паттерны проектирования "Abstract Factory" и "Prototype".
Ничего нового.
Читайте книжку: "Приемы объектно-ориентированного проектирования. Паттерны проектирования", Эрик Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес, изд.Питер, 2000 г.
http://www.books.ru/shop/books/8451/

← →
JibSkeart (2003-02-07 11:16) [26]

слышал что DCOM в lunix-e поддеоживается теперь ...
но вот правда это или нет, незнаю :))
А кто может посоветовать про СОМ
хорошую книжку для Buildera C++
или для Visual C++ ???

← →
euru (2003-02-07 12:08) [27]

>iZEN © (07.02.03 11:05)
>Похоже на паттерны проектирования "Abstract Factory" и "Prototype".
>Ничего нового.

Вы правы, похоже. И одной из причин, по которой я занялся этими экпериментами, была статья (или сайт - уже не помню), посвященная шаблонам (паттернам) проектирования. Но там и, я думаю, в книге Эрика Гаммы была описана концепция шаблонов, их виды, преимущества и недостатки. Конечно, были и примеры, но они сводились к тому, как на основе данного шаблона создать набор классов и интерфейсов, удовлетворяющих вашему условию.

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

← →
iZEN (2003-02-07 12:29) [28]

Для euru © (07.02.03 12:08).
Вы - практик. Но всё-таки не надо изобретать велосипеды, а посмотреть на существующие.
То, что выпредлагаете, - это реализация известной идеи.
Хотя конечно, практика даёт опыт и знания. Можно и нужно смотреть на обычные вещи по-другому, а вдруг найдётся что-то новое.
Паттерны тоже рождались в проектах...
Удачи в поисках!

← →
iZEN (2003-02-07 12:32) [29]

Кстати, паттерны проектирования в реализации C#:
http://dotsite.spb.ru/

← →
iZEN (2003-02-07 12:38) [30]

Вот ещё интересный сайт:
http://ooad.asf.ru/

← →
Набережных С. (2003-02-07 15:07) [31]

>euru © (06.02.03 22:57)

Похвально, что Вы сами до этого додумались, но это все давно применяется на практике.

>euru © (06.02.03 12:42)
> Ketmar ©

>Если вкратце, то при таком подходе реализация (имплементация) >класса не зависит от его декларации.

Это и есть суть концепции интерфейса. Одна из основных идей COM заключается в том, что пользователь объекта не должен вообще что-то предполагать о внутреннем устройстве объекта, вся работа идет через интерфейс. При этом один и тот же интерфейс может быть реализован любым количеством никак не связанных между собой объектов. Более того, никто не запрещает Вам взять любой, разработанный не Вами интерфейс и реализовать его в собственном объекте, при этом нет никаких ограничений на то, как он будет реализован. Единственное - должен быть соблюден "контракт", определяемый объявлением интерфейса, но это, я полагаю, и так понятно. Примеров у Вас полно на Вашей же машине, те же интерфейсы, реализованные в Shell или, например, моникеры, а также функции для получения объектов, их реализующих. Еще пример - ActiveX. Каждый компонент ActiveX должен реализовать определенный набор интерфейсов, но как он их реализует - личное дело его разработчика. Точно также Вы можете в своем проекте использовать свои или чужие интерфейсы, не задействуя при этом механизмы COM - примерно так, как Вы это делаете в своем примере. Все, устал:)

Библиотеки для Delphi Найти похожие ветки