Документ/представление

← →
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 будет.

Как обычно, флейма не хотелось, но он получился :((.

Почему молчат мастера, проблема-то фундаментальная?

2 qube © (17.09.02 11:15)
> Если бы на такой подход уходило больше времени, буржуи бы его не практиковали.
Времени уходит больше, зато облегчается поддержка, сопровождение и доработка.
Так что - проигрываем в краткосрочной перспективе, выигрываем в долгосрочной.
Буржуи пытаются смотреть на пару лет вперед.

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)
Или вы ждете что кто то это начнет делать?

> alena.svt ©

не обижайтесь, весь топик вышел бессмысленным. Т.е. высказывались некоторые общие неплохие, но неоформившиеся идеи. Я хотел получить ответ от мастеров, некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.

← →
Старый паскалист (2002-09-17 13:30) [24]

2qube ©
>Надоело изобретать кривые велосипеды
>Недаром же придумали design pattern"ы.

Во первых, ты как-то неправильно понимаешь паттерны проектирования.
Паттерн - это идея, концепция. Её реализация - за тобой.

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

В третьих, хорошее средство от кривизны велосипедов - не
писать жирный интерфейс на все случаи жизни.

2 qube
> некоторые принципы, которыми пользуются они при написании приложений для достижения эффекта разделения интерфейса и данных.
Я разделял ручками.
Отдельные юниты с моими классами и API.

Из ButtonXXClick вызывались функции...
Никакой (почти никакой) логики в формах.

Время разработки значительно возрастает, но вносить изменения намного проще.

Может это не так удобно, как в MFC, но успешно работает.

> Старый паскалист

Согласен абсолютно со всем сказанным.

Уточню проблему.
В случае MFC есть инкапсуляция Win32 API и нек. других полезных API + архитектура Doc/View, все от одного разработчика, поэтому никаких проблем стыковки не возникает, все окна являются наследниками CView и т.д.

В VCL же -- инкапсуляция Win32 API + много полезных классов, Doc/View отсутствует, все формы являются наследниками TForm.

Т.е. если я попытаюсь реализовать (как было замечено) паттерн Model/View/Controller, мне надо будет создать свою иерархию классов, а потом пристыковать ее к существующей в VCL. Это и вызывает затруднения.

??????

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

Документ/представление Найти похожие ветки