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

← →
Карелин Артем © (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]
> А может лучше прозрачный код писать ? :)

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

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

saxon (04.10.06 13:11) [41]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← →
TohaNik © (2006-10-04 13:39) [49]

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

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

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

← →
Игорь Шевченко © (2006-10-04 14:06) [50]

saxon (04.10.06 13:37) [48]

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

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

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

> Игорь Шевченко © (04.10.06 14:06) [50]

Это уже сила привычки, навыков, хотения и ... да и вообще - каждому свое.

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

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

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

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

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

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

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

← →
Petr V. Abramov © (2006-10-04 14:54) [53]

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

← →
Petr V. Abramov © (2006-10-04 15:06) [54]

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

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

> 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 объединить, то вообще нечто термоядерное получается.

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