Форум: "Основная";
Текущий архив: 2002.09.30;
Скачать: [xml.tar.bz2];
ВнизДокумент/представление Найти похожие ветки
← →
qube (2002-09-17 10:10) [0]Братья-программисты!
Я думаю, не секрет, что программисты на C++ недолюбливают Delphi (не будем превращать этот топик в очередной флейм типа "кто умнее, Вирт или Страуструп?") за отсутствие разделения данных и интерфейса, т.е. очень часто можно увидеть, как в программе на Delphi данные разбросаны по глобальным переменным или полям классов форм, а весь код сконцентрирован в ButtonXXClick. Есть ли библиотеки для Delphi, или, может быть, кто-то пробовал писать сам, или просто задумывались над вопросом, как организовать архитектуру приложения с разделением ядра и интерфейса, как, например, в архитектуре Doc/View из MFC?
← →
Дмитрий Баранов (2002-09-17 10:36) [1]Стандарты как бы давно известны - приложение сперва грамотно проектируется (на бумажке или CASE-средствами), затем пишутся классы-обертки (на Delphi) или COM-объекты(на чем угодно), моделирующие реальные объекты и инкапсулирующие логику.
← →
Johnny Smith (2002-09-17 10:46) [2]2Дмитрий Баранов © (17.09.02 10:36)
Согласен. Именно так нормальные системы и делаются. А вешать логику на ButtonXXClick"и можно только на первом году учебы программированию :))).
← →
qube (2002-09-17 10:54) [3]2 Johnny Smith:
Да и я согласен, и я далеко не первый год учусь программированию :). Да только загвоздка в этом слове грамотно. Как пишут классики, OOA & OOD & OOP -- процесс сложный, итерационный, неформализованный, хорошая архитектура должна быть выстрадана, многократно испытана в различных приложениях. В случае MFC уже есть готовая архитектура, поэтому проектирование для рядового программиста упрощается, есть скелкт, на который можно натягивать все остальное.
← →
alena.svt (2002-09-17 11:00) [4]VCL
← →
Кулюкин Олег (2002-09-17 11:01) [5]2 qube © (17.09.02 10:10)
> с разделением ядра и интерфейса, как, например, в архитектуре Doc/View из MFC?
А как это?
Не силен я в MFC :(
Полностью с Вами согласен, данные отдельно, интерфейсы отдельно.
Одно плохо - на такой подход уходит больше времени, а сроки поджимают, а люди не привыкли так писать...
А сроки срывать нельзя.
← →
qube (2002-09-17 11:07) [6]
> alena.svt © (17.09.02 11:00)
> VCL
Нет, в VCL как раз этого и близко нет (не бросайте в меня камнями! я люблю VCL, но ничего похожего на Doc/View в ней не имеется)
Кулюкин Олег © (17.09.02 11:01)
А как это?
Не силен я в MFC :(
В MFC есть класс CDocument, с которым может быть связано много разных CView. Наследуя свои классы от CDocument и CView, мы создаем свое приложение для конкретных нужд.
← →
alena.svt (2002-09-17 11:12) [7]Да MFC42.dll библиотека отличная но увы мелкософт на нее дает исходничков а лишь оберточку при установленном VC++
Но я полностью согласна с Кулюкин Олег © (17.09.02 11:01)Одно плохо - на такой подход уходит больше времени, а сроки поджимают, а люди не привыкли так писать...
← →
qube (2002-09-17 11:15) [8]Если бы на такой подход уходило больше времени, буржуи бы его не практиковали. Больше времени уходит на выпуск первой кое-как работающей версии. Сопровождение же и модификация значительно упрощаются.
← →
alena.svt (2002-09-17 11:16) [9]2qube © (17.09.02 11:07)Наследуя свои классы от CDocument и CView, мы создаем свое приложение для конкретных нужд.
А вот здесь как раз все под рукой(VCL)
И наследуйте чего от чего хотите только б навсегда выучить кто от кого беремен.
← →
alena.svt (2002-09-17 11:19) [10]qube © (17.09.02 11:15)
А буржуи на всем практикуют.
И примерчик плиз...
← →
nikkie (2002-09-17 11:20) [11]имхо, Document/View не панацея. для каких-то приложений это классно (особенно если делается несколько view на один документ), а для других (e.g. разного рода db приложений) даром не надо.
вобщем, поддерживаю Дмитрия Баранова.
PS кстати, сам в высоких материях не разбираюсь :), но читал высказывания, что Document/View - неправильная архитектура. правильная - Document/Controller/View.
← →
qube (2002-09-17 11:21) [12]Многоуважаемая alena.svt!
Наследуя от классов VCL, я могу получить новые контролы или др. компоненты/классы списков и проч. структур данных/ тд и тп.
Класса типа TDocument там нет, да и TApplication глобальный модификации не подлежит.
← →
qube (2002-09-17 11:24) [13]nikkie
> PS кстати, сам в высоких материях не разбираюсь :), но читал
> высказывания, что Document/View - неправильная архитектура.
> правильная - Document/Controller/View.
Я тоже не оч. разбираюсь, Буч упоминает Model/View/Controller. Увидеть бы пример грамотной реализации на Object Pascal...
← →
REA (2002-09-17 11:30) [14]MCF - must die, Doc/View - must die. Идея была неплохая, но реализация в MFC меня бесит. В Delphi такого нету ну и не очень то и напрягает, хотя возможно я не прав. Если есть идеи как реализовать (формализовать технологию) - можно над этим задуматься. В Delphi много чего другого из C не перенесено было вовремя - потихоньку исправляются.
← →
alena.svt (2002-09-17 11:31) [15]qube © (17.09.02 11:21)
Так системка поставлена по другому
Что есть СDocument/СView/CString/CDaoDataBase/COleClienItem /CException/CEditView/CArchive/CArray()/CBitmap/CBrush/CCheckListBox/CColorDialog/CComboBox/CCommonDialog/CControlBar и т.к.
И как насчет разницы? А разница в букве С и T!
Все они теже классы объекты etc
← →
nikkie (2002-09-17 11:45) [16]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:54) [17]nikkie © (17.09.02 11:45)
Разница есть и между TEDIT и TSCREEN
CListView и CListCtrl оба они классы но выполняют свою роль.
← →
qube (2002-09-17 12:00) [18]
> в чем проблема? пронаследуйте TDocument от TObject
..., т.е. создайте с нуля, своими словами.
В том-то и дело, что в моем исполнении это получится кривой велосипед, а не многократно испытанная в различных приложениях архитектура. Надоело изобретать кривые велосипеды, в ООП я далеко не гений, хотя хотелось бы. Недаром же придумали design pattern"ы.
← →
alena.svt (2002-09-17 12:07) [19]qube © (17.09.02 12:00)
Так об этом я и пыталась все время сказать
А вот то что в Delphi нет его то нет с этим согласна.
А имхо он и не нужен ничем он особо таким не обладает
Представление ввиде общего документа чтож удобно, но может в D8 будет.
← →
qube (2002-09-17 12:25) [20]Как обычно, флейма не хотелось, но он получился :((.
Почему молчат мастера, проблема-то фундаментальная?
← →
Кулюкин Олег (2002-09-17 12:25) [21]2 qube © (17.09.02 11:15)
> Если бы на такой подход уходило больше времени, буржуи бы его не практиковали.
Времени уходит больше, зато облегчается поддержка, сопровождение и доработка.
Так что - проигрываем в краткосрочной перспективе, выигрываем в долгосрочной.
Буржуи пытаются смотреть на пару лет вперед.
← →
alena.svt (2002-09-17 12:35) [22]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)
Или вы ждете что кто то это начнет делать?
← →
qube (2002-09-17 12:46) [23]
> alena.svt ©
не обижайтесь, весь топик вышел бессмысленным. Т.е. высказывались некоторые общие неплохие, но неоформившиеся идеи. Я хотел получить ответ от мастеров, некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.
← →
Старый паскалист (2002-09-17 13:30) [24]2qube ©
>Надоело изобретать кривые велосипеды
>Недаром же придумали design pattern"ы.
Во первых, ты как-то неправильно понимаешь паттерны проектирования.
Паттерн - это идея, концепция. Её реализация - за тобой.
Во вторых, лично я считаю, что нужно изобретать кривые велосипеды.
(Тогда начинаешь лучше понимать, как устроены прямые)
Чтобы освоить ООП, нужно написать много классов, классов и ещё
раз класов (иерархий классов, систем классов).
В третьих, хорошее средство от кривизны велосипедов - не
писать жирный интерфейс на все случаи жизни.
← →
Кулюкин Олег (2002-09-17 13:32) [25]2 qube
> некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.
Я разделял ручками.
Отдельные юниты с моими классами и API.
Из ButtonXXClick вызывались функции...
Никакой (почти никакой) логики в формах.
Время разработки значительно возрастает, но вносить изменения намного проще.
Может это не так удобно, как в MFC, но успешно работает.
← →
qube (2002-09-17 13:54) [26]
> Старый паскалист
Согласен абсолютно со всем сказанным.
Уточню проблему.
В случае MFC есть инкапсуляция Win32 API и нек. других полезных API + архитектура Doc/View, все от одного разработчика, поэтому никаких проблем стыковки не возникает, все окна являются наследниками CView и т.д.
В VCL же -- инкапсуляция Win32 API + много полезных классов, Doc/View отсутствует, все формы являются наследниками TForm.
Т.е. если я попытаюсь реализовать (как было замечено) паттерн Model/View/Controller, мне надо будет создать свою иерархию классов, а потом пристыковать ее к существующей в VCL. Это и вызывает затруднения.
← →
qube (2002-09-17 15:28) [27]??????
← →
alena.svt (2002-09-17 18:28) [28]Вообще вот взять библиотеку KOL (хотя к MFC она ес-но не относиться), но вот человек методоми проб ошибок неудач но все же перестроил
Но врятли найдется тот кто решится на такое ради всего этого так как большой выгоды это не имеет а если все же и имеет то поймут это с годами тут уже дело привычки и еще много зависящих фактов.
Но все сказанное прошу считать IMXO.
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2002.09.30;
Скачать: [xml.tar.bz2];
Память: 0.51 MB
Время: 0.009 c