Какой смысл оформлять классы, не имеющие...

← →
Kolan © (2006-12-11 10:38) [160]

> [159] Юрий Зотов © (11.12.06 10:33)
> Тогда вспоминается анекдот, как медведь пытался летать с
> вороной...

Гост вроде есть. Нас по нему заставляли делать курсовые. Где то даже лежит дома. Ессно его я не читал...

← →
Vga © (2006-12-11 14:34) [161]

> [137] ors_archangel © (11.12.06 03:33)

В основном либо уже есть (инлайны, перегрузки операторов), либо делается (шаблоны), либо довольно сомнительно (множественное наследование, из Java его например выкинули, а в одной книге по С++ видел - "MFC показывает, что множественное наследование использовать можно, но лучше этого не делать"), насчет делегатов и анонимных методов точно не знаю, хеши - что это? И языковое ли это средство? То, что я понимаю по умолчанию под хэшами - реализуется библиотекой, а не языком.

← →
Vga © (2006-12-11 14:35) [162]

> зато есть запрет на циклы в юзасах модулей

Почитай книги/статьи по теме и подумай, тогда ты поймешь, чем обоснован этот запрет и почему в С/С++ его нет.

← →
MikePetrichenko © (2006-12-11 14:39) [163]

> Какой смысл оформлять классы

Никакого. Да и вообще программирование - бессмысленное занятие. Ведь материальной вещи не создается. Так. Картинки на мониторе, да и то руками не пощупать...

Хотя, если с точки зрения "пофлудить бы о чем", то тогда конечно. Культурная ценность классов весьма велика.

P.S. Вот и я присоединился к "пофлудить".

← →
Vga © (2006-12-11 20:44) [164]

> [163] MikePetrichenko © (11.12.06 14:39)

То, что "руками не пощупать" однако не мешает тебе продавать свою библиотеку, и за приличные (для меня) деньги. :)

← →
Cyrax © (2006-12-12 00:11) [165]

1. Сабж
2. dfm-ки без кодового аналога
3. "Delphi и Object Pascal - лучшая IDE и язык для написания прикладных программ под платформу Win32." - смеяться или плакать ?
4. Шаблоны и множественное наследование
5. h/cpp vs interface/implementation

>Anatoly Podgoretsky © (11.12.06 09:47) [148]
>Ух ты, а готов аргументировано и грамотно критиковать?
>Пока не видно.

Будет, Анатолий, будет. Всё будет...
(с VCL"ем проблем не возникло, с этим их тоже не будет)

← →
Anatoly Podgoretsky © (2006-12-12 00:14) [166]

> Cyrax (12.12.2006 0:11:45) [165]

Ну тогда я спокоен.

← →
Vga © (2006-12-12 00:30) [167]

> [165] Cyrax © (12.12.06 00:11)

1) Визуальная разработка. Delphi же RAD-среда. Она в первую очередь ориентирована именно на визуальное проектирование.
2) Ну и зачем он им?
3) Все вместе. Утверждение действительно спорное. По крайней мере, без указания критериев оценки.
4) Первое - есть, второе - даже из некоторых наследников С++ выкинули.
5) Мож мне кто-нить укажет достоинства первого по сравнению со вторым? Не вижу.

← →
vuk © (2006-12-12 00:38) [168]

to Vga © (12.12.06 00:30) [167]:
>5) Мож мне кто-нить укажет достоинства первого по сравнению со вторым?
>Не вижу.
Вот-вот. Наличие модульности всяко лучше её отсутствия. :)

← →
Cyrax © (2006-12-12 00:45) [169]

Vga, список тех вопросов требует отдельного детального рассмотрения... под моим контролем...
Насчёт 5-го пункта: вижу, тебе интересно, какие аргументы я приведу...

← →
Vga © (2006-12-12 00:51) [170]

> [169] Cyrax © (12.12.06 00:45)

Не ты. Кто-нибудь более знающий.

← →
isasa © (2006-12-12 00:56) [171]

Cyrax © (12.12.06 00:11) [165]

5. h/cpp vs interface/implementation

А попробуй подключи COM объкты через idl по схеме h/cpp(с автогенерацией этих *.h и *.c), а потом избавиться от duplicate declaration _IID_Class ... :)

← →
Юрий Зотов © (2006-12-12 02:06) [172]

Интересный спор, однако.

Некий чел декларирует, что "нечто есть плохо" (например, "dfm-ки без кодового аналога"). Даже не пытаясь ни доказать, ни хотя бы объяснить, чем и почему это плохо. Плохо - и все. По определению.

Куча других челов говорит ему: "слушай, а чем и почему это плохо?".

Игнорирует. Просто пропускает мимо ушей, совершенно никак не реагируя. А потом, немного выждав, снова свое - это плохо.

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

Тоже игнорирует. Тоже просто пропускает мимо ушей, совершенно никак не реагируя. А потом - снова свое: это плохо.

В результате действо сильно напоминает дискуссию с бульдозером. Но тогда возникает простой вопрос: а это не глупо - бульдозеру что-то объяснять и доказывать? Не приберечь ли бисер-то?

Пожалуй, приберечь. Попробовали - ну и хватит.

← →
Eraser © (2006-12-12 03:20) [173]

> [172] Юрий Зотов © (12.12.06 02:06)

> В результате действо сильно напоминает дискуссию с бульдозером.
> Но тогда возникает простой вопрос: а это не глупо - бульдозеру
> что-то объяснять и доказывать? Не приберечь ли бисер-то?

см. [30]

← →
Юрий Зотов © (2006-12-12 03:39) [174]

> Eraser © (12.12.06 03:20) [173]

И правда.

← →
Чапаев © (2006-12-12 08:44) [175]

> смеяться или плакать ?
Поплачь, писять меньше будешь.

> [172] Юрий Зотов © (12.12.06 02:06)
http://redeyes.ru/panopticum/zhelezyakin/zhelezyakin.shtml

← →
MikePetrichenko © (2006-12-12 11:15) [176]

Где-то тут была ссылка на БиоРеактор.
Да и:
"Никогда не спорь с дураком, люди могут не заметить между вами разницы" (С) К. Прутков

← →
Суслик © (2006-12-12 11:18) [177]

я этого не далю
классы - они и есть классы.

← →
vuk © (2006-12-12 11:47) [178]

to Юрий Зотов © (12.12.06 02:06) [172]:
>Тогда куча других челов начинает доказывать ему, что это не плохо, а,
>наоборот, хорошо.
Тут такое дело. Если сравнивать Two Way и ресурсы в dfm, то, на мой взгляд, получится, что Two Way таки лучше. Проблем меньше в результате. По себе сужу. Мы активно используем в проектах фреймы. Их главный минус в том, что если меняем фрейм, то часто приходится "протаскивать" изменения через все фреймы, в который вложен измененный и так далее по дереву. Был бы Two Way, таких проблем не было бы, т.к. все свойства расписаны один раз, а не будут повторяться в dfm-е чуть ли не при каждом вложении фрейма.

Проблема именно в механизме dfm и невозможности им управлять. Если бы управление было возможно, с удовольствием запретил бы запись в dfm свойств вложенных фреймов.

← →
vuk © (2006-12-12 12:23) [179]

>запретил бы запись в dfm свойств вложенных фреймов
Поправлю себя. Правильнее было бы сказать так: "запретил запись компонентов, расположенных на вложенных фреймах". То есть, если фрейм A вложен во фрейм B, то в dfm фрейма B попадали бы свойства самого фрейма A, но не компонентов на нем.

← →
ZeroDivide © (2006-12-12 12:54) [180]

> vuk © (12.12.06 12:23) [179]
>
> >запретил бы запись в dfm свойств вложенных фреймов
> Поправлю себя. Правильнее было бы сказать так: "запретил
> запись компонентов, расположенных на вложенных фреймах".
> То есть, если фрейм A вложен во фрейм B, то в dfm фрейма
> B попадали бы свойства самого фрейма A, но не компонентов
> на нем.

Мы тоже активно юзаем фреймы. Я бы ни в коем случае не запрещал.

Их главный минус в том, что если меняем фрейм, то часто приходится "протаскивать" изменения через все фреймы, в который вложен измененный и так далее по дереву.

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

← →
vuk © (2006-12-12 12:59) [181]

to ZeroDivide © (12.12.06 12:54) [180]:
>Т.е. не вкладывать фреймы в фреймы, а наследовать фреймы расширяя их
>функциональность?
Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.

← →
ZeroDivide © (2006-12-12 12:59) [182]

ЗЫ: Фреймы вообще уникальная вещь, ни в каких других языках и IDE нет ничего подобного по функциональным возможностям. Подобное есть, но до Borland"овского TFrame - не дотягивает.

← →
ZeroDivide © (2006-12-12 13:04) [183]

Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.

Почему?

← →
vuk © (2006-12-12 14:18) [184]

to ZeroDivide © :
>Фреймы вообще уникальная вещь
Составной компонент. Ничего уникального.
По идее, и использование такое же - накромсали кирпичиков прикладного уровня и используем. Только вот ведет он себя не совсем так, как компонент в части сохранения свойств. Конечно, из этой ситуации есть выход. Нужно просто покидать фреймы в пакет и зарегистрировать в IDE.Тогда в dfm попадут только свойства самого фрейма. Но это уже существенно замедляет разработку, да и палитра компонентов лопнет от перекорма.

>ни в каких других языках и IDE нет
>ничего подобного по
>функциональным возможностям.
Копался в .net, есть там пользовательские контролы. Использовать их можно прямо в том проекте, где они определены. Всем бы хорошо, только мы-то не под .net.

>Нелогично.
>Почему?
Ровно по той же причине, по которой TDBGrid не является наследником TDataSet.

← →
ZeroDivide © (2006-12-12 16:24) [185]

Конечно, из этой ситуации есть выход. Нужно просто покидать фреймы в пакет и зарегистрировать в IDE.Тогда в dfm попадут только свойства самого фрейма.
Угу... и придеться отказаться от визуального наследования фреймов... нет уж... + еще несколько существенных проблем. Мы отказались от этой идеи.

Копался в .net, есть там пользовательские контролы. Использовать их можно прямо в том проекте, где они определены. Всем бы хорошо, только мы-то не под .net.

В UserControl нельзя перемещать контролы базового класса и вешать на них обработчики в дизайнере... тьфу на этот UserControl.

>Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.
>Почему?
Ровно по той же причине, по которой TDBGrid не является наследником TDataSet.

Как раз все наоборот "Ровно по той же причине, по которой TDBGrid не является наследником TDataSet." можно от него унаследоваться и расширить его еще одним гридом. Мы же не от грида наследуемся, а от фрейма содержащего грид.

У нас есть один такой базовый фрейм: Справа DBTree слева DBGrid... При открытии ветки дерева DBGrid отбирает соответствующие записи. Наследован от фрейма в котором есть только DBGrid... Вполне красиво и юзабельно.

Немного концепции... можно сделать фрейм-предок типа TfrmGridsContainer и научить его управлять положенными на себя умеющимися управляться фреймами типа TfrmUserGridView с гридами. Затем что-то типа TfrmGridsMasterDetailContainer, наследник от TfrmGridsContainer, который бы и реализовывал m-d связь. А TfrmUserGridView был бы наследником от TfrmBasicUserGridView, содержащий общую для просмотра всех таблиц функциональность. (Это упрощенная модель)

← →
Джо © (2006-12-12 16:28) [186]

> [175] Чапаев © (12.12.06 08:44)
> > [172] Юрий Зотов © (12.12.06 02:06)
> http://redeyes.ru/panopticum/zhelezyakin/zhelezyakin.shtml

Хм, точно Железякин! :)

Начало -> если А -> то А -> результат А -> конец.
Начало -> если Б -> то Б -> результат Б -> конец.

Любые твои попытки перейти на фортран или бейсик (не говоря уж о С++) ведут к сбою цепочки Железякина и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Любая новая информация, привносимая извне, приравнивается Железякиным к сбою цепочки и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Ты можешь блестяще (как тебе кажется) опровергнуть любой из его доводов. Это приравнивается Железякиным к сбою цепочки и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Ты можешь потрясающе глубоко и остроумно проанализировать психологические причины зацикливания Железякина на своем любимом алгоритме. Это приравнивается Железякиным к сбою цепочки и... ну, ты понял.

← →
vuk © (2006-12-12 20:08) [187]

to ZeroDivide (12.12.06 16:24) [185]:

>Угу... и придеться отказаться от визуального наследования фреймов...
Внутри пакета - наследуйтесь сколько хотите.

>В UserControl нельзя перемещать контролы базового класса
>и вешать на них обработчики в дизайнере...
И правильно. Навешивание обработчика на вложенный контрол является
нарушением инкапсуляции. Хотите обработчик - выводите наружу event. К тому же в Delphi всё назначение обработчиков вложенных контролов после операции "Revert to inherited" отправляется в dev/null. А к операции этой иной раз приходится прибегать, т.к. иногда изменения в фреймах ну никак не хотят отображаться в тех местах, где фреймы используются, иногда бывает хуже, и некоторые проблемы лечатся только удалением фрейма целиком и складыванием его назад. И тут либо нужно помнить, что, кому и зачем прописывалось (угу, через пару-тройку лет) либо прописывать их руками в коде инициализации.

>Вполне красиво и юзабельно.
Прокатывает все это дело только в элементарных случаях, поскольку не дает
возможности строить приложения из готовых функциональных "кирпичиков", т.к. если где-то есть что-то похожее/аналогичное, но унаследовать уже нельзя то остается только copy/paste. Либо все-таки складывать готовые фремы и иметь в виду что будут некоторые проблемы. Я не знаю, как у вас, но мы предпочитаем иметь некоторые проблемы, но обойтись без copy/paste.

>Это упрощенная модель
Мда... если это упрощенно... Вообще говоря, у нас чаще всего весь Master/Detail обходится в одно событие у Master и одно свойство у Detail (ну, еще иногда обртная связь бывает нужна). Безо всяких заморочек. Большинство фреймов (в основном проекте их больше 700, форм меньше раза в три) содержат всю нужную им функциональность и расширения не требуют.

← →
Ученик чародея © (2006-12-12 21:50) [188]

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

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

http://skipy.dev.juga.ru/philosophy.html

> [188] Ученик чародея © (12.12.06 21:50)
> Отвлекаясь от этого случая, задумайтесь вот над чем. Как
> вообще происходит разработка приложения на Delphi? Кликнули
> - создали форму. Кликнули - положили на нее меню. Кликнули
> - создали набор action-ов. Кликнули несколько раз - создали
> сами action-ы (и все кликами - и картинку им выбрать, и
> обработчик создать, пока что пустой). Кликнули несколько
> раз - накидали элементов в меню. Каждому элементу сопоставили
> action - тоже кликами. Кликнули - ... Кликнули - ... Кликнули
> - ... ... ...

Это всего лишь одна часть работы, для меня — ничтожная по сравнению со временем, потраченным на остальными задачи.

> Кликнули - создали форму. Кликнули - положили на нее меню.
> Кликнули - создали набор action-ов.
Ну можно всё это произвести вручную. Только кому это нафиг надо? В большинстве случаев неоправданная трата времени.

>>Джо © (12.12.06 21:54) [189]

Человек, Java - программист считает, что если делфист - значит ламер. Я пытался оспаривать - логические доводы не действуют:

http://forum.juga.ru/showthread.php?s=&threadid=13376

> Я пытался оспаривать
Себе дороже выйдет. Охота ж нервы себе портить...

Стандартное мнение тех, кто разглагольствут о том, чего не знает. Ничего нового.

И правильно. Навешивание обработчика на вложенный контрол является
нарушением инкапсуляции.
:) И давно?

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

Мрак... Тоже не знаю, как вы там используете фреймы, но видимо не лучшим образом. У нас таких проблем не возникает. Хотя в нашей парадигме код инициализации так же приходится ручками прописывать, т.к. если фреймы не в пакете (как я уже говорил, мы отказались), то published-свойства писать бесполезно, они не видятся в инспекторе объеков, для фреймов-наследников :( Это в нашей парадигме - единственная неприятность, связанная с фреймами. Впрочем, тоже решаемая - компоненты лежащие на фремах показывают свои published property и достаточно много можно переложить на компоненты, а иерархии фреймов оставить только роль визуальной иерархии.
Да и писать обычно приходится не очень много, не больше чем:

constructor TfrmXXXX.Create(AOwner: TComponent); begin inherited; Title := "Имя фрейма"; ClassEditForm := TfmXXXXEdit ClassQueryForm := TfmXXXXQuery //Если фрейм вызван как справочник if IsDictionary then begin ..... end; //Если зашли сюда с TfrmYYYYYY, то производим определенные действия if (fmMain.ActiveFrame is TfrmYYYYYY) then begin // допонительная фильтрация (как пример) InsertFilterConditionToDataset(WDM.odsWorkers, "(DISMISS_DATE is null)"); ... end; end;

Все остальное настраивается в инспекторе.

Прокатывает все это дело только в элементарных случаях, поскольку не дает
возможности строить приложения из готовых функциональных "кирпичиков",
Дает. Этих самых "элементарных случаев" не так уж и много для всех возможных UI для всех видов реляционных отношений.

Я не знаю, как у вас, но мы предпочитаем иметь некоторые проблемы, но обойтись без copy/paste.

Аналогично.

Мда... если это упрощенно... Вообще говоря, у нас чаще всего весь Master/Detail обходится в одно событие у Master и одно свойство у Detail

У нас в вызовом одной функции (правда с кучей параметров).

Большинство фреймов (в основном проекте их больше 700, форм меньше раза в три)
У нас тоже фреймов не меньше в некоторых проектах, но все они наследники от базовых фреймов из нашей иерархии и фактически, все что нужно: выбрать подходящего предка и настроить его на работу с определенными данными. Повторюсь: вариантов UI для всех видов реляционных отношений - не так уж и много. У нас порядка 30 базовых фреймов всего. БД клиенты собирать полностью из "кирпичиков" - реально.

ZeroDivide © (13.12.06 01:29) [195]:
>И давно?
Изначально. Работа с объектом должна вестись через его свойства и методы. Навешивая снаружи что-либо на вложенные объекты мы можем нарушить работу внутренних механизмов. К тому же это ведет к ситуации, когда клиенты объекта завязаны на его внутреннюю реализацию.

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

>Тоже не знаю, как вы там используете фреймы, но видимо не лучшим
>образом.
Нормально используем. Штатно. А как - я уже сказал. Фреймы - это составные компоненты, и по большей части каждый из них функционально завершен. Сложные фреймы собираются в дизайнере из простых и тогда функциональность сложных заключается в том, что они являются "клеем" для более простых и координируют их работу. Все навешиваемые на фреймы обработчики прописываются руками, благо их обычно мало, штук 5 - это уже много. Ситуации проблемные возникают крайне редко. Связаны, в основном, с тем, как вложенность фреймов сохраняется в dfm.

← →
test2 (2006-12-13 03:47) [197]

test

> Изначально. Работа с объектом должна вестись через его свойства
> и методы. Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов. К тому же
> это ведет к ситуации, когда клиенты объекта завязаны на
> его внутреннюю реализацию.

Бред.

Работа с объектом должна вестись через его свойства и методы.

Она так и ведется. А то, что объект может обладать свойствами объектного типа - никоим образом инкапсуляцию не нарушает. И доступ к свойствам объекта вида Object.Property1.Property2.Event1 - вполне нормально для ООП.
Пример:
frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").AsInteger;
Или у вас это выглядит, как
frmGridView.FieldByName("ID").AsInteger;
:)
?

Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов.
Опять же, скорее наоборот: навешивая изнутри что-то мы можем нарушить работу предполагаемого поведения наших объектных пропертей. Хотя и в том и другом случае мы можем нарушить, а можем и не нарушить.
Пример: повесить обработчик события на вложенный компонент при инициализации фрейма, если при этом не написать код сохрания и вызова обработчика установленного разработчиком фрейма-потомка в инспекторе, то этот обработчик пойдет лесом... А если программер захочет повесить обработчик в рантайм? ... Тогда лесом пойдет обработчик, который повесил фрейм. В общем, как раз такое - делать нельзя!

>Сложные фреймы собираются в дизайнере из простых

Да... не лучшим образом.

1. На вложенных фреймах не будут работать наследники TComponentEditor
2.
>Связаны, в основном, с тем, как вложенность фреймов сохраняется в dfm.

3. Еще что-то... уже не помню (но есть)

Мы пришли к тому, что сделали из фреймов простое дерево, без вложенности веток друг в друга... в некоторых случаях пришлось пожертвовать уникальностью кода, копируя многие участки кода из одних веток этого дерева в другие, создавая в ветках повторяемые UI элементы...
Да, такую парадигму сделать и поддерживать, наверное сложнее... но только "трогать" базовые фреймы уже давно не приходится. Зато безглючность, гибкость, юзабельность вот этой получившейся основы - великолепная, куда выше чем была вкладывая фреймы друг в друга. Натуральный "Кирпичизм" получился: кода писать не надо, все возможные варианты интерфейса - уже написаны в базовых фреймах.
Остается писать бизнес-логику на стороне сервера... но это другая тема....

Какой смысл оформлять классы, не имеющие... Найти похожие ветки