Смешение бизнес-логики и интерфейса в классах

← →
Александр Иванов © (2006-10-04 07:23) [0]

Допускаете ли вы подобное? Сейчас разбираю чужой код. Читается крайне тяжело.

← →
Карелин Артем © (2006-10-04 08:26) [1]

Да, очень легко и удобно работать с этим. В студии правда такое сделали.
Очень высокоуровневые классы у нас с стандартным интерфейсом и стандартной бизнес-логикой.

← →
Александр Иванов © (2006-10-04 08:33) [2]

> Карелин Артем © (04.10.06 08:26) [1]

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

← →
Юрий Зотов © (2006-10-04 09:36) [3]

> Смешение бизнес-логики и интерфейса в классах

Ужасно. Хорошо хотя бы то, что существует DFM - потому, что когда в ту же кучу кода валится еще и СОЗДАНИЕ интерфейса (чем, кстати почему-то так гордятся апологеты Джавы), то читать код становится еще ужаснее.

← →
Игорь Шевченко © (2006-10-04 09:54) [4]

> Смешение бизнес-логики и интерфейса в классах

Это неправильно.

Юрий Зотов © (04.10.06 09:36) [3]

> потому, что когда в ту же кучу кода валится еще и СОЗДАНИЕ
> интерфейса (чем, кстати почему-то так гордятся апологеты
> Джавы),

Апологеты Java, например, Мартин Фаулер, настоятельно рекомендует отделять бизнес-логику от интерфейса. Не надо всех в одну кучу.

← →
Суслик © (2006-10-04 09:57) [5]

имхо, зависит от размеров задачи.
в некоторых вспомогательных проектах я этим не заморачиваюсь.
в больших проектах, в которых есть время на *выработку* подхода к разделению логики и ГУИ, я, безусловно, это делал и буду делать.
Другой вопрос, что не всегда это просто. Поэтому прежде чем делать стоит серьезно подумать о целесообразности.

← →
Александр Иванов © (2006-10-04 09:58) [6]

> Юрий Зотов © (04.10.06 09:36) [3]

Валится, валится :(
Именно там формы и создаются.
Язык - C#.

← →
Иксик © (2006-10-04 10:00) [7]

> Карелин Артем © (04.10.06 08:26) [1]
> Да, очень легко и удобно работать с этим. В студии правда
> такое сделали.
> Очень высокоуровневые классы у нас с стандартным интерфейсом
> и стандартной бизнес-логикой.
> <Цитата>

Ты не понял, имеется ввиду пользовательский интерфейс, не интерфейсы классов :)

← →
Иксик © (2006-10-04 10:00) [8]

> Суслик © (04.10.06 09:57) [5]

Согласен!

← →
Карелин Артем © (2006-10-04 10:12) [9]

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

← →
Суслик © (2006-10-04 10:14) [10]

> Ужасно. Хорошо хотя бы то, что существует DFM - потому,
> что когда в ту же кучу кода валится еще и СОЗДАНИЕ интерфейса
> (чем, кстати почему-то так гордятся апологеты Джавы), то
> читать код становится еще ужаснее.

дано уже есть среды, в которых создание этого самого кода может быть полностью скрыто от пользователя в нередактируемых и по умолчанию скрытих регионах кода. От dfm мало чем это отличается.

← →
Суслик © (2006-10-04 10:15) [11]

> [9] Карелин Артем © (04.10.06 10:12)

главное, чтобы тебе и твоему коллективу был понятен подход к созданию программы и к ее *поддержке*. А уж как там сделано второй вопрос.

← →
Карелин Артем © (2006-10-04 10:26) [12]

> Суслик © (04.10.06 10:15) [11]

Новички сразу и без проблем вливаются в процесс разработки.
Сделано вообще суперски.

← →
Суслик © (2006-10-04 10:27) [13]

> Сделано вообще суперски.

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

← →
vuk © (2006-10-04 10:50) [14]

Ну, не знаю... У нас вся бизнес-логика на сервере живет. Поэтому смешать её с интерфейсом несколько затруднительно. Подстановку параметров и вызов ХП бизнес-логикой не считаю.

← →
Иксик © (2006-10-04 10:55) [15]

Кистате, вопрос не совсем в тему, но все же... Понравилась Class Diagram в VS2005, до этого подобным не пользовался. Не подскажите, что еще есть во всяких uml средствах помимо того, что есть в VS2005 Class Diagram?

← →
Суслик © (2006-10-04 10:59) [16]

2[15]
смотря для чего.
если чиста для рисования - без кодогенерации, скорее для осознания и документирования, то мне очень нравится UMLet (кстати, фришный, может быть и opensourceный) - *чисто рисование* без всяких ограничений.
Проще некуда. Я иногда рисую, экспортирую в jpg и вставляю рисунки в доки.

UMLet - требует java. Можешь jre скачать с sun (несколько мегов)

более сложными средствами не пользуюсь, т.к. они сложные :)

← →
Курдль © (2006-10-04 10:59) [17]

> Карелин Артем © (04.10.06 10:12) [9]

Похоже на продуманную технологию.
Только если усложнять проект, придется увеличивать кол-во базовых классов даже для пользовательского интерфейса. Навскидку от себя добавлю к Вашему "набору" модальное окно выбора записи (напр. чтобы выбрать контрагента из многих тысяч). Если наборы данных надо ограничивать (удаленка и т.п.) то перед вызовом каждой "списочной" формы придется выводить модальное окно критериев отбора.
А "базовый невизуальный класс" для работы на уровне технических служб - это сам Бог велел, особенно при исполнении трехзвенки. Там он не один, а сотня набежит.
Кстати, я все больше и больше захвачен идеей паттернов проектирования (хотя бы не задумываешься, как называть классы) :)

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

← →
Суслик © (2006-10-04 11:03) [18]

> Кстати, я все больше и больше захвачен идеей паттернов проектирования

это пройдет :)
имхо главное, чем паттерны могут помочь *дельфи* программисту - это осознать, что для повторного использования кода есть не только наследование. когда это поймешь + будешь знать паттерны будут естественным образом рождаться свои подходы, пригодные для *твоей* разработки.

а гнаться чисто за паттернами смысла не вижу, т.к., если заметишь, они (как миниум в Гамме и (с)) в основном относятся *не* к бизнес логике.

паттерны по БЛ в основном описаны у Фаулера в архитектуре корпоративных приложений (дословным рускоязычный перевод).

← →
Курдль © (2006-10-04 11:08) [19]

> Суслик © (04.10.06 11:03) [18]
> > Кстати, я все больше и больше захвачен идеей паттернов
> проектирования
> это пройдет :)

Едва ли! :)
Кстати, я больше склоняюсь к архитектурным паттернам GRASP, чем к упомянутому Вами творению "Банды Четырех" во главе с Гаммой.
Первых - всего 10. И они не являются шаблонами классов, а только технологиями архитектурного подхода. Кстати, многие из них просто упорядочивают в голове и так известные приемы. Напр. паттерн "Levels" - всего-навсего список критериев, по которым следует делить приложение по уровням. А "Низкое связывание" - как раз аптимизирует классы (модули) для повторного использования.

← →
Суслик © (2006-10-04 11:15) [20]

> Едва ли! :)

жизнь покажет.

← →
Игорь Шевченко © (2006-10-04 11:22) [21]

Иксик © (04.10.06 10:55) [15]

> Понравилась Class Diagram в VS2005, до этого подобным не
> пользовался. Не подскажите, что еще есть во всяких uml средствах
> помимо того, что есть в VS2005 Class Diagram?

Диаграммы классов - сакс и мастдай. Вся логика должна быть понятна из кода. Если логика из кода непонятна, удали файлы с этим кодом, и иди в хозяйственный магазин.

← →
Курдль © (2006-10-04 11:24) [22]

Как я в предыдущем посте умудрился написать "аптимизирует"?.. :)))

> Суслик © (04.10.06 11:15) [20]
> жизнь покажет.

А я не вижу смысла отказываться от такой вкусняшки. Например, это помогает общению в команде. Если на брифинге коллега утверждает, что "в этом модуле будет фабрика классов, работающая на контроллер под обсервером", то при определенном опыте совместной работы это сильно помогает сократить кол-во букав.

← →
Карелин Артем © (2006-10-04 11:37) [23]

> Курдль © (04.10.06 10:59) [17]
>
> > Карелин Артем © (04.10.06 10:12) [9]
>
>
> Похоже на продуманную технологию.
> Только если усложнять проект, придется увеличивать кол-во
> базовых классов даже для пользовательского интерфейса. Навскидку
> от себя добавлю к Вашему "набору" модальное окно выбора
> записи (напр. чтобы выбрать контрагента из многих тысяч).
Окно для просмотра списка в модальном просмотре имеет кнопки "Ок", "Отмена" для выбора записи и возвращает идентификатор контрагента.
> Если наборы данных надо ограничивать (удаленка и т.п.)
> то перед вызовом каждой "списочной" формы придется выводить
> модальное окно критериев отбора.
Модальное окно творится руками и передает параметры отбора списку четко стандартизированным способом.
А так обычно параметры отбора задаются в базовой панельке для фильтра.

← →
Иксик © (2006-10-04 11:42) [24]

> Суслик © (04.10.06 10:59) [16]

Спасибо!

> Игорь Шевченко © (04.10.06 11:22) [21]
> Иксик © (04.10.06 10:55) [15]
>
>
> > Понравилась Class Diagram в VS2005, до этого подобным
> не
> > пользовался. Не подскажите, что еще есть во всяких uml
> средствах
> > помимо того, что есть в VS2005 Class Diagram?
>
>
> Диаграммы классов - сакс и мастдай. Вся логика должна быть
> понятна из кода. Если логика из кода непонятна, удали файлы
> с этим кодом, и иди в хозяйственный магазин.

Я подавился кофе... За что вы меня так жестоко?
Честно говоря, ну не то, чтобы не согласен, но если огромный проект, чужой и ты пытаешься его понять? Или разве плохо написать структуру классов при помощи этой диаграммы?

И вообще, чего вы все на меня наезжаете? :))

← →
Карелин Артем © (2006-10-04 11:44) [25]

> Иксик © (04.10.06 11:42) [24]

Ты какой студией пользуешься? Я что-то в своей 2005pro не нашел к своему стыду.

← →
Курдль © (2006-10-04 11:46) [26]

> Карелин Артем © (04.10.06 11:37) [23]
> Окно для просмотра списка в модальном просмотре имеет кнопки
> "Ок", "Отмена" для выбора записи и возвращает идентификатор
> контрагента.

Т.е. одно и то же окно может выступать в роли дочернего MDI и модального?
Когда-то применял такой подход, но на Delphi.
Не готов спорить о его недостатках, но мне кажется, что они есть.
Например, для форм выбора, в соответственных в базовых классах прописано немало специфических методов именно для логики выбора. А для обычного "списка" (кстати который может быть и "деревом", в отличие от первого) предусмотрены совсем иные методы в базовых формах.

← →
Карелин Артем © (2006-10-04 11:47) [27]

Извиняюсь, плохо искал. Навскидку - очень удобная штука, особенно при документированном коде.

← →
Иксик © (2006-10-04 11:50) [28]

> Карелин Артем © (04.10.06 11:44) [25]

VS 2005 Team Edition
Ее можно, например, из Solution Explorera или Class View вызвать.

← →
Суслик © (2006-10-04 11:50) [29]

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

← →
saxon (2006-10-04 12:04) [30]

> Иксик © (04.10.06 11:50) [28]
> VS 2005 Team Edition

Такого нет в принципе. :)

← →
Игорь Шевченко © (2006-10-04 12:05) [31]

Иксик © (04.10.06 11:42) [24]

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

А зачем делать двойную работу и сопровождать ее ? Одна работа - диаграмма классов, другая работа - код. Я вот честно не понимаю. В two-way tools я не слишком верю, потому как написание кода и автоматическое красивое отображение его же на диаграмме - это утопия, следовательно, при решении одной и той же задачи придется выполнять двойную работу, а любая двойная работа - место для внесения потенциальных ошибок.

> И вообще, чего вы все на меня наезжаете? :))

Я обычно наезжаю исключительно в целях профилактики нарушений правил форума :)

Суслик © (04.10.06 11:50) [29]

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

Вот скажи мне, часто ли ты пользуешься диаграммами классов для большого проекта VCL ? (проект действительно большой, классов там, как звезд на небе).

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

← →
Карелин Артем © (2006-10-04 12:08) [32]

> saxon (04.10.06 12:04) [30]

Visual Studio Team System или VS 2005 Team Edition for ***(Database или еще чего) Professionals

← →
Карелин Артем © (2006-10-04 12:11) [33]

> Игорь Шевченко © (04.10.06 12:05) [31]

> А зачем делать двойную работу и сопровождать ее ? Одна работа
> - диаграмма классов, другая работа - код. Я вот честно не
> понимаю. В two-way tools я не слишком верю, потому как написание
> кода и автоматическое красивое отображение его же на диаграмме
> - это утопия, следовательно, при решении одной и той же
> задачи придется выполнять двойную работу, а любая двойная
> работа - место для внесения потенциальных ошибок.

Вы не верите в 2-way tool? диаграммы классов не хранятся. Они считываются из кода. Хранится только отображение их. Дезигнер визуальный тоже 2-way в студии. Аналогов DFM нет в 2003/2005 студии.

← →
Иксик © (2006-10-04 12:12) [34]

> saxon (04.10.06 12:04) [30]

Стоит у меня на компьютере... В About пишет так...

> Игорь Шевченко © (04.10.06 12:05) [31]

> А зачем делать двойную работу и сопровождать ее ? Одна работа
> - диаграмма классов, другая работа - код. Я вот честно не
> понимаю. В two-way tools я не слишком верю, потому как написание
> кода и автоматическое красивое отображение его же на диаграмме
> - это утопия, следовательно, при решении одной и той же
> задачи придется выполнять двойную работу, а любая двойная
> работа - место для внесения потенциальных ошибок.

Ага, ясно! Честно говоря, я был уверен что он two-way.. :))) В принципе создает он только заголовки и даже если не two-way, то можно заново его прогнать по коду и он сам построит диаграмму, но это конечно не совсем то.

← →
Игорь Шевченко © (2006-10-04 12:16) [35]

Карелин Артем © (04.10.06 12:11) [33]

> Вы не верите в 2-way tool? диаграммы классов не хранятся.
> Они считываются из кода. Хранится только отображение их.
> Дезигнер визуальный тоже 2-way в студии. Аналогов DFM нет
> в 2003/2005 студии.

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

← →
saxon (2006-10-04 12:37) [36]

> Карелин Артем © (04.10.06 12:08) [32]
> Иксик © (04.10.06 12:12) [34]

хм...
http://msdn.microsoft.com/vstudio/teamsystem/products/compare/
На самом деле все переназвали. А ведь еще вроде месяца 3 назад все было подругому:)
Но все равно, суть в том что в этих студиях движок от pro.

> Игорь Шевченко © (04.10.06 12:16) [35]

Прогресс не стоит на месте. Ничего 2 раза делать ненадо.
Могу отметить что такие фичи очень хороши при коммандной работе, а если есть удаленные группы - так и совсем хорошо. Согласитесь зачем некой группе залазить в код если она его тока юзает и никогда не учавствует в разработке. Ей хватит иметь перед глазами реальную(!), визуальную картину. Ну а как хорошо это для менеджеров-руководителей так и ваще говорить не стоит.
Не даром же вот уже у всех (наверное) компонентов есть приставка - Team.

← →
Игорь Шевченко © (2006-10-04 12:46) [37]

saxon (04.10.06 12:37) [36]

> Прогресс не стоит на месте. Ничего 2 раза делать ненадо.
>

Точно не надо ? При изменениях в коде диаграммы сами обновляются ?

> Могу отметить что такие фичи очень хороши при коммандной
> работе, а если есть удаленные группы - так и совсем хорошо.
> Согласитесь зачем некой группе залазить в код если она
> его тока юзает и никогда не учавствует в разработке

А чем может помочь диаграмма классов при "юзании" кода ?
Я не понимаю.

> Ну а как хорошо это для менеджеров-руководителей так и ваще
> говорить не стоит.

А им-то нафига ?

← →
Курдль © (2006-10-04 12:53) [38]

> Игорь Шевченко © (04.10.06 12:16) [35]
> Не верю. Если хоть что-то хранится, то уже двойная работа
> получается, а главное, я не понимаю, зачем она нужна. В
> чем ее великий смысл, диаграммы классов ? Если помогает
> понять иерархию классов, то для нормальной иерархии в большинстве
> случаев уровней не так много, чтобы их нельзя было увидеть
> из кода.

Дерево классов, на мой взгляд, и вправду не слишком нужно. Но как было бы удобно иметь под рукой инструмент, способный составлять collaboration diagramm, а в мечтах - составлять код из такой диаграммы.
Есть такие приблуды, но говорят, что они медленно работают.

← →
Игорь Шевченко © (2006-10-04 13:07) [39]

Курдль © (04.10.06 12:53) [38]

А может лучше прозрачный код писать ? :)

← →
Карелин Артем © (2006-10-04 13:08) [40]

> Игорь Шевченко © (04.10.06 12:46) [37]
> Точно не надо ? При изменениях в коде диаграммы сами обновляются
> ?

Подвинуть квадратик, цвет подправить. Остальное автоматом.

← →
saxon (2006-10-04 13:11) [41]

> Игорь Шевченко © (04.10.06 12:46) [37]
> Точно не надо ? При изменениях в коде диаграммы сами обновляются ?

Мы сейчас говорим конкретно студии. (для уточнения)

По части полей, свойств, методов, связей, делегатов, евентов, описания (ремарки, значений по умолчанию и т.д) - да. Код самих методов - нет (может - пока:) ).

> А чем может помочь диаграмма классов при "юзании" кода ?

"Юзает" имееться ввиду не код а сущности и их медоды, свойства, а также в принятии решения, чтож и когда необходимо использовать (Опять же всякие патерны).
Безусловно и то что такие вещи должны знать заранее, но - все мы люди и всем свойственно ошибаться, забывать ...

> А им-то нафига ?

Например - контроль, принятия/изменения стратегических решений, в конце концов документация и т.д.

Естественно это все - с моей точки зрения, опыта моего и команд с которыми работал(ю), и мировой тенденции. Не судите строго. :)

← →
Игорь Шевченко © (2006-10-04 13:11) [42]

Карелин Артем © (04.10.06 13:08) [40]

Ну и нафига еще какие-то действия делать, спрашивается.

А главное - в чем великий смысл диаграммы, объясни.

← →
Курдль © (2006-10-04 13:14) [43]

> Игорь Шевченко © (04.10.06 13:07) [39]
> А может лучше прозрачный код писать ? :)

Ничто в мире не может быть прозрачным, кроме вакуума.
Если пишешь много - ОНО рано или поздно перестает быть прозрачным даже для писателя, а не то, что для коллектива писателей.
Я, например, не могу себе представить, как объяснить модель БД на словах или на скриптах. Так же трудно поставить задачу, или коллективно разработать структуру программы, не используя графических образов. Разве это плохо, если код будет представлен графически в виде классов и их взаимосвязей?

saxon (04.10.06 13:11) [41]

> "Юзает" имееться ввиду не код а сущности и их медоды, свойства,
> а также в принятии решения, чтож и когда необходимо использовать
> (Опять же всякие патерны).

А что дает знание метода на диаграмме без его кода ? Насчет принятия решения по диаграмме, я, честно говоря, не могу увидеть примера. Если бы был пример, мне было бы проще ориентироваться.

> Например - контроль, принятия/изменения стратегических решений,
> в конце концов документация и т.д.

Для документации - согласен. За вечерним чаем, на сон грядущий полистать диаграмму классов, милое дело. Насчет контроля и принятия/изменения решений, так они обычно меняются по мере изменения или уточнения предметной области, и я, опять же, не вижу, чем может помочь диаграмма.

> Естественно это все - с моей точки зрения, опыта моего и
> команд с которыми работал(ю), и мировой тенденции. Не судите
> строго. :)

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

> Игорь Шевченко © (04.10.06 13:11) [42]

Один проектирует интерфейсы на экране в диаграммах. Другой, имея заготовки интерфейса и его методов в коде(диаграмме), пишет код. На диаграмму ему смотреть не надо, все шапки с комментами сами в коде появились при рисовании диаграммы. Разделение труда проектировщика и кодера. Не понравился кодеру метод(название, параметры), он его правит и при этом диаграмма сама меняется под исправления кодера.
Еще много чего интересного в области командного применения диаграмм показали год назад на Днях разработчика M$.

Курдль © (04.10.06 13:14) [43]

> Если пишешь много - ОНО рано или поздно перестает быть прозрачным
> даже для писателя

А не надо много писать. Оно серьезно сказано :)

> Я, например, не могу себе представить, как объяснить модель
> БД на словах или на скриптах

А как ты объясняешь в картинках логику триггеров и хранимых процедур ?

> Так же трудно поставить задачу, или коллективно разработать
> структуру программы, не используя графических образов

Вот тут я уже перестаю понимать.

> Разве это плохо, если код будет представлен графически
> в виде классов и их взаимосвязей?

Может и неплохо, но полезность работы для создания графического кода вызывает большие сомнения.

Карелин Артем © (04.10.06 13:19) [45]

> Один проектирует интерфейсы на экране в диаграммах. Другой,
> имея заготовки интерфейса и его методов в коде(диаграмме),
> пишет код.

Ну тут как бы неплохо знать, а какой код надо писать...А то получится как на картинке про качели...

> Еще много чего интересного в области командного применения
> диаграмм показали год назад на Днях разработчика M$.

Так я год назад на семинаре в Russee тоже много чего интересного видул - разумеется, MS активно рекламирует свой продукт, ему продать его хочется как можно большему количеству пользователей.

← →
saxon (2006-10-04 13:37) [48]

Игорь Шевченко © (04.10.06 13:17) [44]

> А что дает знание метода на диаграмме без его кода ?

Да в принципе тоже самое что и описание, например, какойнить старонней длл. Да + "схема". Красота. :)

> меняются по мере изменения или уточнения предметной области

Не спорю. А у Вас не бывало такого? - Спроектировали - все вроде хорошо, стали писать, смотреть так сказать "с высока" - косяки (может и не существенные) всеже есть. Понимание предметной области не изменилось.

> Мировая тенденция - это дело такое. ...

Согласен поэтому то и - Не судите строго. :)

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

ЗЫ:
Почему не рубят за офтоп ? :)

> Курдль © (04.10.06 13:14) [43]

> Разве это плохо, если код будет представлен графически
> в виде классов и их взаимосвязей?

Графически- это хорошо на презентации, когда кода еще нет, что б заказ пробить:)

saxon (04.10.06 13:37) [48]

> А у Вас не бывало такого? - Спроектировали - все вроде хорошо,
> стали писать, смотреть так сказать "с высока" - косяки
> (может и не существенные) всеже есть. Понимание предметной
> области не изменилось.

Бывало. Но диаграмма тут не помощник, а наоборот, скорее.

← →
saxon (2006-10-04 14:23) [51]

> Игорь Шевченко © (04.10.06 13:25) [46]
> А как ты объясняешь в картинках логику триггеров и хранимых процедур ?

В виде блок-схемы алгоритма, если уж на то пошло.

> > Так же трудно поставить задачу, или коллективно разработать
> > структуру программы, не используя графических образов
> Вот тут я уже перестаю понимать.

Что именно не понятно?
Что программа разбивается на модули, уровни, основные классы и возникает необходимость функционального разделения, разделения областей видимости, определения взаимосвязей и т.п.? А как Вы все это описываете? Эпистолярно?

> Может и неплохо, но полезность работы для создания графического
> кода вызывает большие сомнения.

Так это и есть основная работа программиста - спроектировать. А кодить - это уже рутина.

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

[53] +
особенно если это все раскрасить поярче :)

> Petr V. Abramov © (04.10.06 14:54) [53]
> что код, что блок-схема - разные формы записи одного и
> того же алгоритма. В том, что блок-схема - более наглядная
> форма, баальшие сомнения (хотя бы с точки зрения компактности).
> Ну кроме как на презентациях или в детском саду.

Я в "детском саду" писал проги на АSМе. Каюсь - без квадратиков и стрелочек не обошлось :(
Некоторые процедурины (будт то ХП или код на Паскале) тоже приходилось частями в блок-схеме проектировать. Может у меня мосх не правильно заточен? Я все люблю в виде графиков и схем представлять. Даже времена года у меня, как дуги эллипса...

> Может у меня мосх не правильно заточен? Я все люблю в виде графиков и
> схем представлять. Даже времена года у меня, как дуги эллипса...
называется "в основном зрительное восприятие". насчет правильности и неправильности - не знаю :) но от того, что рисовать блок-схему, а потом писать код - это ДВЕ работы вместо одной никуда не денешься...

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

> Но я не понимаю, как можно спроектировать (придумать, обсудить,
> довести), а главное - задокументировать взаимосвязи модулей, уровней,
> классов?
словесами :) и если словами не дублиовать написанное в коде, часто это будет компактнее, чем в виде разноцветных геометрических фигур. Однако ж людей со зрительным восприятием очень много, поэтому иногда "красота" будет не лишнией. Но надо учитывать, что
1. Она не является НЕОБХОДИМОЙ
2. Все-таки это ДОПОЛНИТЕЛЬНАЯ работа (время-деньги-геморрой)

← →
Ученик чародея. (2006-10-04 16:29) [59]

> Александр Иванов © (04.10.06 07:23)
> Допускаете ли вы подобное? Сейчас разбираю чужой код. Читается
> крайне тяжело.

Да, вот только интегрировал бизнеслогику в TTreeview компонент. Удобно, сразу с управлением данными идет их отображение.

> Ученик чародея. (04.10.06 16:29) [59]

Один компонент это не страшно. Представь десяток форм, с несколькими деятками таблиц. Формы создаются и управлятся из классов с прочей логикой, таблицы передаются как параметры для заполнения и прочее :)

← →
Ученик чародея. (2006-10-04 17:00) [61]

> Александр Иванов © (04.10.06 16:51) [60]
>
> > Ученик чародея. (04.10.06 16:29) [59]
>
> Один компонент это не страшно. Представь десяток форм, с
> несколькими деятками таблиц. Формы создаются и управлятся
> из классов с прочей логикой, таблицы передаются как параметры
> для заполнения и прочее :)

А такое у меня управляется данными из базы данных. Каждая форма на основании текущих данных в базе данных сама собой управляет.

Максимум, что я позволяю из классов выставить флаг на запуск какой-то активности.

Лучше модели DataFlow пока не придумали, а если ее с объектным подходом и функциональными языками типа SQL объединить, то вообще нечто термоядерное получается.

Смешение бизнес-логики и интерфейса в классах Найти похожие ветки