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

← →
Александр Иванов © (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 вызвать.

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

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

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

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

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

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

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

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

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

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

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

> saxon (04.10.06 12:04) [30]

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

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

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

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

> saxon (04.10.06 12:04) [30]

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

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

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

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

Карелин Артем © (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.

saxon (04.10.06 12:37) [36]

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

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

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

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

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

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

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

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

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

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

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