| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Документ/представление
qube © (2002-09-17 10:10:00)Братья-программисты!
Я думаю, не секрет, что программисты на C++ недолюбливают Delphi (не будем превращать этот топик в очередной флейм типа "кто умнее, Вирт или Страуструп?") за отсутствие разделения данных и интерфейса, т.е. очень часто можно увидеть, как в программе на Delphi данные разбросаны по глобальным переменным или полям классов форм, а весь код сконцентрирован в ButtonXXClick. Есть ли библиотеки для Delphi, или, может быть, кто-то пробовал писать сам, или просто задумывались над вопросом, как организовать архитектуру приложения с разделением ядра и интерфейса, как, например, в архитектуре Doc/View из MFC?
alena.svt (2002-09-17 18:28:00) [1]Вообще вот взять библиотеку KOL (хотя к MFC она ес-но не относиться), но вот человек методоми проб ошибок неудач но все же перестроил
Но врятли найдется тот кто решится на такое ради всего этого так как большой выгоды это не имеет а если все же и имеет то поймут это с годами тут уже дело привычки и еще много зависящих фактов.
Но все сказанное прошу считать IMXO.
qube (2002-09-17 15:28:00) [2]??????
qube (2002-09-17 13:54:00) [3]
> Старый паскалист
Согласен абсолютно со всем сказанным.
Уточню проблему.
В случае MFC есть инкапсуляция Win32 API и нек. других полезных API + архитектура Doc/View, все от одного разработчика, поэтому никаких проблем стыковки не возникает, все окна являются наследниками CView и т.д.
В VCL же -- инкапсуляция Win32 API + много полезных классов, Doc/View отсутствует, все формы являются наследниками TForm.
Т.е. если я попытаюсь реализовать(как было замечено) паттерн Model/View/Controller, мне надо будет создать свою иерархию классов, а потом пристыковать ее к существующей в VCL. Это и вызывает затруднения.
Кулюкин Олег (2002-09-17 13:32:00) [4]2 qube
> некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.
Я разделял ручками.
Отдельные юниты с моими классами и API.
Из ButtonXXClick вызывались функции...
Никакой (почти никакой) логики в формах.
Время разработки значительно возрастает, но вносить изменения намного проще.
Может это не так удобно, как в MFC, но успешно работает.
Старый паскалист (2002-09-17 13:30:00) [5]2qube ©
>Надоело изобретать кривые велосипеды
>Недаром же придумали design pattern"ы.
Во первых, ты как-то неправильно понимаешь паттерны проектирования.
Паттерн - это идея, концепция. Её реализация - за тобой.
Во вторых, лично я считаю, что нужно изобретать кривые велосипеды.
(Тогда начинаешь лучше понимать, как устроены прямые)
Чтобы освоить ООП, нужно написать много классов, классов и ещё
раз класов (иерархий классов, систем классов).
В третьих, хорошее средство от кривизны велосипедов - не
писать жирный интерфейс на все случаи жизни.
qube (2002-09-17 12:46:00) [6]
> alena.svt ©
не обижайтесь, весь топик вышел бессмысленным. Т.е. высказывались некоторые общие неплохие, но неоформившиеся идеи. Я хотел получить ответ от мастеров, некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.
alena.svt (2002-09-17 12:35:00) [7]2 Кулюкин Олег © (17.09.02 12:25)Я пример просила на чем буржуи практикуют.....?
2qube © (17.09.02 12:25)
Как обычно, флейма не хотелось, но он получился :((.
Про них вроде мне говорилось
2qube © (17.09.02 12:25)Почему молчат мастера, проблема-то фундаментальная?
Так в чем проблема то с учетом темы alena.svt © (17.09.02 12:07)
Или вы ждете что кто то это начнет делать?
Кулюкин Олег (2002-09-17 12:25:00) [8]2 qube © (17.09.02 11:15)
> Если бы на такой подход уходило больше времени, буржуи бы его не практиковали.
Времени уходит больше, зато облегчается поддержка, сопровождение и доработка.
Так что - проигрываем в краткосрочной перспективе, выигрываем в долгосрочной.
Буржуи пытаются смотреть на пару лет вперед.
qube (2002-09-17 12:25:00) [9]Как обычно, флейма не хотелось, но он получился :((.
Почему молчат мастера, проблема-то фундаментальная?
alena.svt (2002-09-17 12:07:00) [10]qube © (17.09.02 12:00)
Так об этом я и пыталась все время сказать
А вот то что в Delphi нет его то нет с этим согласна.
А имхо он и не нужен ничем он особо таким не обладает
Представление ввиде общего документа чтож удобно, но может в D8 будет.
qube (2002-09-17 12:00:00) [11]
> в чем проблема? пронаследуйте TDocument от TObject
..., т.е. создайте с нуля, своими словами.
В том-то и дело, что в моем исполнении это получится кривой велосипед, а не многократно испытанная в различных приложениях архитектура. Надоело изобретать кривые велосипеды, в ООП я далеко не гений, хотя хотелось бы. Недаром же придумали design pattern"ы.
alena.svt (2002-09-17 11:54:00) [12]nikkie © (17.09.02 11:45)
Разница есть и между TEDIT и TSCREEN
CListView и CListCtrl оба они классы но выполняют свою роль.
nikkie (2002-09-17 11:45:00) [13]2 alena.svt
Вы создаете флейм, видимо не очень разбираясь в MFC и том, что такое doc/view. есть разница между CListView и CListCtrl.
2 qube
кстати, если Вы берете за образец MFC... а вы можете положить CListView на диалог?
если хочется иметь doc/view на дельфи - в чем проблема? пронаследуйте TDocument от TObject. вроде надо всего несколько методов - регистрация view, UpdateAllViews, ... не знаю уж что еще. я бы только view на дельфи реализовывал как interface, с наследованием от одного предка как в MFC мне не нравится (см. выше по поводу CListView/CListCtrl)
alena.svt (2002-09-17 11:31:00) [14]qube © (17.09.02 11:21)
Так системка поставлена по другому
Что есть СDocument/СView/CString/CDaoDataBase/COleClienItem /CException/CEditView/CArchive/CArray()/CBitmap/CBrush/CCheckListBox/CColorDialog/CComboBox/CCommonDialog/CControlBar и т.к.
И как насчет разницы? А разница в букве С и T!
Все они теже классы объекты etc
REA (2002-09-17 11:30:00) [15]MCF - must die, Doc/View - must die. Идея была неплохая, но реализация в MFC меня бесит. В Delphi такого нету ну и не очень то и напрягает, хотя возможно я не прав. Если есть идеи как реализовать (формализовать технологию) - можно над этим задуматься. В Delphi много чего другого из C не перенесено было вовремя - потихоньку исправляются.
qube (2002-09-17 11:24:00) [16]nikkie
> PS кстати, сам в высоких материях не разбираюсь :), но читал
> высказывания, что Document/View - неправильная архитектура.
> правильная - Document/Controller/View.
Я тоже не оч. разбираюсь, Буч упоминает Model/View/Controller. Увидеть бы пример грамотной реализации на Object Pascal...
qube (2002-09-17 11:21:00) [17]Многоуважаемая alena.svt!
Наследуя от классов VCL, я могу получить новые контролы или др. компоненты/классы списков и проч. структур данных/ тд и тп.
Класса типа TDocument там нет, да и TApplication глобальный модификации не подлежит.
nikkie (2002-09-17 11:20:00) [18]имхо, Document/View не панацея. для каких-то приложений это классно (особенно если делается несколько view на один документ), а для других (e.g. разного рода db приложений) даром не надо.
вобщем, поддерживаю Дмитрия Баранова.
PS кстати, сам в высоких материях не разбираюсь :), но читал высказывания, что Document/View - неправильная архитектура. правильная - Document/Controller/View.
alena.svt (2002-09-17 11:19:00) [19]qube © (17.09.02 11:15)
А буржуи на всем практикуют.
И примерчик плиз...
alena.svt (2002-09-17 11:16:00) [20]2qube © (17.09.02 11:07)Наследуя свои классы от CDocument и CView, мы создаем свое приложение для конкретных нужд.
А вот здесь как раз все под рукой(VCL)
И наследуйте чего от чего хотите только б навсегда выучить кто от кого беремен.
| |
Страницы: 