Здравствуйте, Max.Subpixel, Вы писали:
MS>Я согласен про ПропертиГрид — он годится для программистов и администраторов. MS>Но я предлагал нечто другое — там вам пожалуйста — полная свобода.
То, что вы предлагаете, конечно же, намного лучше, чем проперти грид. Но все равно, непонятно, почему нужно заставлять пользователей перекладывать контролы. Если предметная область хорошо определена, то существует относительно немного оптимальных структур UI; и выбрать их — обязанность проектировщика. Кто-то из usability спецов говорил, что все настройки UI в программах отражают непонимание разработчиками стоящей перед ними задачи.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Подумайте о кодогенерации... Атрибуты это не отменяет, зато позволяет какие-то вещи делать быстрее (производительность и время на разработку). По сути R# полезная и удобная вещь — парсер есть, кодогенератор есть. Если не обращать внимание на мелочи в орфографии — все работает. Спасибо Владу (он меня уже не любит, правда, за флейм о шрифтах )
Да. это интересная мысль. вот только мне кажется я ещё не дорос до неё. Я ещё не наигрался с объектной моделью в стиле C#.
Кстати, как мне кажется, каждому программеру надо наиграться с некоторой технологией прежде чем перейти на следующий уровень. Как например, сторонники кустарного GUI ещё не устали от игры в формочки-кнопочки.
Наверное поэтому мы так медленно двигаемся в направлении продвинутых парадигм программирования типа Lisp-a.
А>C#. Это более удобно в .NET, а недостатков по сравнению с MC++ в бизнес приложениях нет (мы не нашли по крайней мере).
А можно вопрос?. (блин!, опять тавтология) Так вот вопрос — у вас изменения в объектах модели синхронизируются между клиентскими приложениями? если да, то не могли бы вы рассказать как это у вас работает.
Здравствуйте, alku, Вы писали:
A>могу предложить TreeListView собственной закваски... A>правда в не доработаном варианте, но достаточно рабочий чтобы показывать и дописываться...
спасибо. всё лучше чем с чистого листа начинать
пиши на vladimir_lipatov@mail.ru
Здравствуйте, WoldemaR, Вы писали:
WR>Да. это интересная мысль. вот только мне кажется я ещё не дорос до неё. Я ещё не наигрался с объектной моделью в стиле C#.
Воспринимайте её как некий простой код, который делает за вас тупую работу по программированию — позволяет избежать ошибки и делать то, что вам уже надоело, позволяя не придумывать гигантских и ненужных конструкций.
WR>Кстати, как мне кажется, каждому программеру надо наиграться с некоторой технологией прежде чем перейти на следующий уровень. Как например, сторонники кустарного GUI ещё не устали от игры в формочки-кнопочки. WR>Наверное поэтому мы так медленно двигаемся в направлении продвинутых парадигм программирования типа Lisp-a.
Наверное это правильно. Но некоторые вещи реально экономят время.
А играть с технологией мне кажется нужно не до предела — я этим сам часто страдал...
WR>А можно вопрос?. (блин!, опять тавтология) Так вот вопрос — у вас изменения в объектах модели синхронизируются между клиентскими приложениями? если да, то не могли бы вы рассказать как это у вас работает.
Во-первых у нас .NET — не знаю, что у вас.
У нас сделано так — мы взвесили все за и против и классифицировали изменения:
1. Частые в райнтайме
Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними). 2. Редкие в рантайме
Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов. 3. Редкие в компайл-тайме
Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Max.Subpixel, Вы писали:
MS>>Я согласен про ПропертиГрид — он годится для программистов и администраторов. MS>>Но я предлагал нечто другое — там вам пожалуйста — полная свобода. S>То, что вы предлагаете, конечно же, намного лучше, чем проперти грид. Но все равно, непонятно, почему нужно заставлять пользователей перекладывать контролы. Если предметная область хорошо определена, то существует относительно немного оптимальных структур UI; и выбрать их — обязанность проектировщика. Кто-то из usability спецов говорил, что все настройки UI в программах отражают непонимание разработчиками стоящей перед ними задачи.
Тут вопрос о применениях. Конечный пользователь не будет настраивать диалоги — он даже тулбары то не настраивает...
Поэтому речь не об этом. Я и, по всей видимости, Вольдемар, связаны с крупными системами. А здесь работают другие принципы — классы все время меняются — от клиента к клиенту, от задачи к задаче. И настройкой диалога должны заниматься те, кто, например, готовит продукт под конкретного клиента, или делает специальную версию, или администратор клиента. А в целом я согласен с тем, что вы говорите — вопрос лишь в том, что это не всегда возможно. И те кто настраивают диалоги, наверное, должны и анализировать и исследования проводить и т.д. Но это не программисты. 100%. А так — сделал продукт, отдал юзабелисту, а он сидит и формы компонует. Тут сразу ему и тесты готовы и прототипов не надо. Понимаете? Мне кажется это только всем на пользу...
Здравствуйте, Max.Subpixel, Вы писали:
MS>Здравствуйте, alku, Вы писали:
MS>Процитируйте проблему. Но конечно, на что-то возможно это не рассчитано. MS>Мне трудно представить, правда, что тогда рассчитано... MS>Что такое легковесные — это видимо и не контролы тогда совсем... MS>Может быть дело было в неправильном использовании? Пример, приведите, мне интересно.
сорри тяжело вспомнить, и фирму поменял и проект... постараюсь на досуге найти...
Здравствуйте, Max.Subpixel, Вы писали:
MS>Во-первых у нас .NET — не знаю, что у вас. MS>У нас сделано так — мы взвесили все за и против и классифицировали изменения:
Надеюсь, что у нас тоже будет NET, поэтому собираю аргументы за и против.
MS>1. Частые в райнтайме MS>Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними).
У нас такие изменения относятся к работе скрипта.
Идея такая. при модификации объекта никакой синхронизации с сервером и опосредованно с другими приложениями не происходит, но формируется список изменённых объектов. Затем над этим списком делаем Commit. Обекты серилизуются бинарно и передаются на сервер. Сервер раздаёт уведомления остальным клиентам и пишет в базу.
пока ещё не придумал как соединить клиент с сервером приложений. пока рассматриваю 2 варианта .NET Remouting и http://www.genuinechannels.com
MS>2. Редкие в рантайме MS>Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов.
Это как правило ручные модификации через пользовательский интерфейс.
Тут нам нужена синхронизация в отдельности для каждого свойства/метода и + валидация и возможность откатов. т.е. придётся формировать стеки команд.
MS>3. Редкие в компайл-тайме MS>Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
Только не в компайл тайме. Но очень похожие изменения происходят при:
1) Обновлении объектов клиента после получения уведомления со списком изменённых объектов от сервера.
2) Восстановлении конфигурации прерванной сессии.
В общем получается, что объектная модель представляет из себя иерархию классов с довольно хитрой, но примерно одинаковой реализацией методов set для каждого свойства и add/remove для контейнеров.
Кстати насчёт remove. Этот метод потенциально может нарушить целостность базы. Решили, что выполнять его может только админ в монопольном режиме. в парадигме COM надо было-бы реализовывать и запрашивать специальный интерфейс администратора. У нас появилась другая идея. — Помечать такие админские методы атрибутом forAdminOnlyAttribute и при генерации GUI выдавать их на тулбар или не выдавать в зависимости от прав пользователя.
Здравствуйте, alku, Вы писали:
A>сорри тяжело вспомнить, и фирму поменял и проект... постараюсь на досуге найти...
Может это был глюк?
Или что-то там такое плохо работало, но исправили.
Или было что-то совсем редкое?
Или надо было как-то архитектурно вопрос решать.
Я рассматривал разные компоненты — не могу сказать, что DX компоненты тормозят.
Они вполне адекватно работают. Глупостей я тоже пока не видел, по крайней мере, существенных.
Но, поймите меня правильно, я не работаю на DX и опыт эксплуатации еще не огромен, так что а) я могу что-то не знать (потому и спрашиваю) б) мне пока нравится больше чем то, что пока видел другое. Но и, конечно, не бывает решений, которые устроят всех. Просто я не согласен, что там качество плохое. Уж точно лучше самоделок и других известных наборов.
Best Regards. Max.
Re[12]: Генерация GUI на основе атрибутов
От:
Аноним
Дата:
11.04.06 16:48
Оценка:
Здравствуйте, alku, Вы писали:
A>есть такая книжка "Безопасный код" Microsoft press — очень советую почитать... highly recommended.
Здравствуйте, WoldemaR, Вы писали:
WR>Надеюсь, что у нас тоже будет NET, поэтому собираю аргументы за и против.
А, да, я забыл.
MS>>1. Частые в райнтайме MS>>Это мы делаем без изменения самих объектов — т.е. коллекции на объектах (коллекция данных + коллекция правил работы с ними).
WR>У нас такие изменения относятся к работе скрипта. WR>Идея такая. при модификации объекта никакой синхронизации с сервером и опосредованно с другими приложениями не происходит, но формируется список изменённых объектов. Затем над этим списком делаем Commit. Обекты серилизуются бинарно и передаются на сервер. Сервер раздаёт уведомления остальным клиентам и пишет в базу. WR>пока ещё не придумал как соединить клиент с сервером приложений. пока рассматриваю 2 варианта .NET Remouting и http://www.genuinechannels.com
От ремотинга мы отказались после прошлой версии. Медленно и плохоконтроллируемо. Для кого-то наверное пойдет.
Но надо сказать мы вообще отказались от отправки изменений на сервер в виде объектов.
Вместо этого мы отправляем верхние вызовы методов (кодогенерация тут тоже).
Преимуществ просто масса. Если интересно — расскажу.
Но я говорил про изменения схемы, а не объектов...
MS>>2. Редкие в рантайме MS>>Это мы делаем как DynamicMethod — т.е. подцепка свойств объектам путем доставки динамических методов в данных объекта, описывающего класс. Позволяет работать без всяких там псевдо-имен классов (как в ASP.NET) и без работы с выгрузкой доменов.
WR>Это как правило ручные модификации через пользовательский интерфейс. WR>Тут нам нужена синхронизация в отдельности для каждого свойства/метода и + валидация и возможность откатов. т.е. придётся формировать стеки команд.
Да, стеки команд мы и посылаем. Сервер посылает объекты. Мы ему команды. База локальная дублирована. Онлайн/Оффлайн, откат итп.
MS>>3. Редкие в компайл-тайме MS>>Это требует рестарта при получении объекта с измененной схемой. После рестарта грузятся новые классы и схема кэшированных данных обновляется.
WR>Только не в компайл тайме. Но очень похожие изменения происходят при: WR>1) Обновлении объектов клиента после получения уведомления со списком изменённых объектов от сервера. WR>2) Восстановлении конфигурации прерванной сессии.
Опять же я говорил про смену классов. А не объектов.
WR>В общем получается, что объектная модель представляет из себя иерархию классов с довольно хитрой, но примерно одинаковой реализацией методов set для каждого свойства и add/remove для контейнеров.
Кодогенерация вас спасет. Иначе труба или читать IL в рантайме и проверять.
WR>Кстати насчёт remove. Этот метод потенциально может нарушить целостность базы. Решили, что выполнять его может только админ в монопольном режиме. в парадигме COM надо было-бы реализовывать и запрашивать специальный интерфейс администратора. У нас появилась другая идея. — Помечать такие админские методы атрибутом forAdminOnlyAttribute и при генерации GUI выдавать их на тулбар или не выдавать в зависимости от прав пользователя.
У нас круче. У нас вообще на все атрибуты ролей. А потом админ может переконфигурировать это под то, что ему надо. И + еще ресурсная безопасность сбоку. А за счет того, что мы не шлем объекты на сервер — кроме всех плюсов у нас еще и гарантия безопасности — метод присылается полностью подписанный сертификатом клиента. Может хоть по почте присылать обновления... А мержить как удобно...
MS>Позвольте не согласиться. Если формы жесткие, то это может быть иногда правда. Правда почему-то мы все, тем не менее, легко пользуемся ПропертиГридом в студии, который к тому же до безобразия простой, но ничего. В SQL2005 тоже почему-то тот-же простенький контрол решает задачи форм.
Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно. Дело даже не в том, что есть экраны которые надо проектировать, а есть вспомогательные экраны, которые можно сгенерировать на основе некоей внутренней структуры данных. При грамотном проектировании может оказаться, что вообще эти вспомогательные экраны и не нужны -- модальные окна (да и не модальные) это лучший способ заставить пользователя выйти их контекста основной работы и заставлять его принимать решения, когда этого делать совершенно не нужно.
Сгенерированные интерфейсы совершенно не предусматривают массу реальных сценариев, по которым работают пользователи и уж тем более не учитывают контекста их работы. Даже если есть тщательно описанный Use Case работы оператора, то там, как правило, не учитывается как пользователь вводит информацию -- со слов клиента или например с листа бумаги.
Предсавьте себе, что реальные предметы герегировались бы исходя из внутренне структуры. Я думаю, что такой телевизор вы бы ни жизнь не купили У него была бы куча регуляторов, матрица совершенно одинаковых кнопок (на пульте в том числе), на диспелее была бы куча ненужно информации, и выглядел бы он так, что подходить к нему было бы страшно.
Кстати, искренне рекоммендую к прочтению пару книгу на эту тему:
"Психбольница в руках пациентов" Алана Купера, (http://www.bolero.ru/product-36418704.html?terms=%CD%EE%F0%EC%E0%ED
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, copylove, Вы писали:
C>>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.
WR>Очень смешно.
Зачем спрашивал-то? Чтобы нахамить всем, кто с тобой не согласен?
FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Здравствуйте, copylove, Вы писали:
C>Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно.
Вы меня неправильно поняли. Иногда бывают ситуации когда приходится идти с обеих сторон и искать компроммисы. Если у вас 2-3-10 форм и они жесткие, то полный порядок — делайте как всегда, это правильно и удобно.
C>Дело даже не в том, что есть экраны которые надо проектировать, а есть вспомогательные экраны, которые можно сгенерировать на основе некоей внутренней структуры данных.
Я с этим не спорю. Но иногда все — вы знаете — вот этим объектам нужны диалоги.
КОНЕЧНО там и вообще диалоги есть, просто так. Но речь не об этом.
C>При грамотном проектировании может оказаться, что вообще эти вспомогательные экраны и не нужны -- модальные окна (да и не модальные) это лучший способ заставить пользователя выйти их контекста основной работы и заставлять его принимать решения, когда этого делать совершенно не нужно.
Не очень понял суть в контексте темы.
C>Сгенерированные интерфейсы совершенно не предусматривают массу реальных сценариев, по которым работают пользователи и уж тем более не учитывают контекста их работы. Даже если есть тщательно описанный Use Case работы оператора, то там, как правило, не учитывается как пользователь вводит информацию -- со слов клиента или например с листа бумаги.
Вы просто не очень поняли что означает сгенерированные диалоги. Они могут быть абсолютно любыми... Но иногда уже очевидно — нужен диалог управления задачей. Там может еще 1001 способ управления задачей. Но еще и нужен диалог. И вот о таких диалогах идет речь. Немодальных.
C>Предсавьте себе, что реальные предметы герегировались бы исходя из внутренне структуры. Я думаю, что такой телевизор вы бы ни жизнь не купили У него была бы куча регуляторов, матрица совершенно одинаковых кнопок (на пульте в том числе), на диспелее была бы куча ненужно информации, и выглядел бы он так, что подходить к нему было бы страшно.
Это не совсем так (совсем не так):
1. Класс это не его внутренняя структура — это наоборот его фасад, на котором к тому же вы можете определить как он должен выглядеть
2. Вас никто не заставляет все ручки выносить наружу — вы выносите только те, которые нужны и в таком виде, как нужно (я больше скажу — вам в двух разных местах могут быть нужны 2 разных диалога на 1 и тот-же класс — пожалуйста
3. Выглядеть он будет так как вы хотите — практически никаких ограничений (вы видимо не читали, что я там бальше писал)
C>Кстати, искренне рекоммендую к прочтению пару книгу на эту тему: C>"Психбольница в руках пациентов" Алана Купера, (http://www.bolero.ru/product-36418704.html?terms=%CD%EE%F0%EC%E0%ED
Спасибо, как-нибудь, на досуге, но думаю, что я уже читал прилично переворачивающей литературы на эту тему и все стороны мозгов уже видел.
Поймите меня правильно. Я не спорю с вами — Вы все вроде как правильно говорите. Просто есть некоторые исключения (решения, которые, не такие как вы думаете/знаете). Потом есть особые ситуации. О них и была речь. Если внимательно прочитаете, то что я писал тут в теме, то скорее всего ваша претензия снимется. И добавлю, что я по професии юзабелист в первую очередь, а уже потом архитектор и менеджер продукта.
И кстати, знаете, довольно часто лучше бы программисты использовали уж ПропертиГрид, чем городили бы тот идиотизм, что они делают в интерфейсах...
И вообще, я к вам может еще прийду за консультациями (а то, что-то Ярослав Перевалов занят совсем), но буду пользоваться этими самыми диалогами. Так что не надо считать меня сторонником автоматических диалогов. Если задумаетесь, то поймете, то, что я предложил — это очень хороший вариант для юзабилити — он ничего общего не имеет с полным автоматом — это просто способ оторвать представление от логики и объектов. И способ создавать много диалогов без кода вообще и вообще после того, как приложение готово. Это же вообще мечта.
А книжки — почитаю на досуге, хотя Купера не люблю...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Ну как-же, надо смотреть профиль всех кому собираешься "нахамить"? Это же так долго...
P.S. Я еще думаю, где-то я уже этот ник видел, но вроде не тут.
А тут вспомнил — ага, community.livejournal.com/ru_ucdesign
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, WoldemaR, Вы писали:
WR>>Здравствуйте, copylove, Вы писали:
C>>>То, что вы описали является любимым мифом разработчиков. Результат, который вы получите иначе как браузером базы данных назвать нельзя -- на выходе бедному пользователю придется работать с моделью реализации системы. С такой моделью работать может только робот с бесконечной памятью и безграничным вниманием. Интерфейсы нужно проектировать исходя из слабостей Homo Sapiens и опираясь на его сильные стороны. Так как работающей модели Homo Sapiens до сих пор нет, то и о генерации интерфейса речь идти не может.
WR>>Очень смешно.
ЗХ>Зачем спрашивал-то? Чтобы нахамить всем, кто с тобой не согласен? ЗХ>FYI, некто copylove, также известный как Алексей Копылов, сотрудник UIDesign Group (все это можно узнать из его профайла), и в русскоязычном юзабалити сообществе достаточно известный человек. К тому, что он утверждает, стоит хотя бы прислушаться.
Чувствую что стоит объясниться.
Так вот. Я вам как юзабелист юзабелисту объясню, что юзабилити юзабилити рознь. Есть разница между интерфейсом для бегинера и для эксперта. Эпловский стандарт по размещения элементов на формах десктопа пожно спустить в унитаз при проектировании вокзального терминала.
У нас этого юзабилити ну просто завались. ТОлько это, как правило, не примитивные формочки с кнопочками. А специализированные и очень дорогие контролы в которых отображаются карты, таблицы, диаграммы, графики, кореляционные разрезы. Всё это работает в обрамлении контрол-панелей. Которых нужно минимум, так как основная площадь занята спецконтролами, короче говоря это похоже на архитектуру CAD-систем. И универсальный браузер и универсальная таблица и проперти грид, очень нужны. Они тут рулят и спасают пользователя от хаотичного нагромождения модальных диалогов.
А рулят деревья, гриды т таблицы потому, что с системой работают не бегинеры и им важно быстро производить все изменения единым способом, не хлопая глазами вспоминая или узнавая расположение элементов на очень удобной уникальной форме. Ещё проблема в том, что таких форм — сотни. и если сядет бегинер их изучать, то с ним случиться перегрузка.
Появление каждой новой формы на экране — это задержка на её изучение, оно происходит медленнее изучения проперти грида, так как в гриде всё однотипно выровненно, а форма — это очередной полёт фантазии человека возомнившего себя юзабелистом.
Нет, я вовсе не против форм и юзабелистов.
Например, если надо продемонстрировать сложность системы и мотивировать клиентов на обучение, как это делается в ERP — системах, то конечно да. Там держать отдел специалистов по формочкам можно себе позволить.
Но у нас сейчас мескольно иная специфика работы.
Теперь по поводу моего хамства. Да, характер не сахар. Такая у меня реакция на неарументированные и безапеляционные утверждения отвергающего, неконструктивного характера.
Здравствуйте, copylove, Вы писали:
C>Ваша ошибка в том, что на взаимодействие пользователя с программой вы рассматриваете с точки зрения модели реализации, что в корне уже неправильно.
Не поймут вас. Поскольку мало кто умеет удерживать в голове два "мифа" одновременно.
(А "модель реализации" и "модель интерфейса" — это варианты мифов.)
А потому народ все равно будет либо показывать пользователю модель реализации,
либо прошивать в архитектуру системы жесткие завязки на пользовательский интерфейс.
Выше вы писали про "слабости Homo Sapiens" — пользовтаеля, но забываете про "слабости Homo Sapiens" — разработчика.
P.S.
Посмотрел ваш сайт.
Порадовался отсутвию "переливающихся рюшечек" в портфолио.
Огорчился отсутствию хотя бы некоего намека на прайс... Не могли бы вы исправить эту ситуацию,
скинув мне _порядок_ цен на alexsoff[собака]gmail.com ?
Здравствуйте, EXO, Вы писали:
EXO>Не поймут вас. Поскольку мало кто умеет удерживать в голове два "мифа" одновременно. EXO>(А "модель реализации" и "модель интерфейса" — это варианты мифов.) EXO>А потому народ все равно будет либо показывать пользователю модель реализации, EXO>либо прошивать в архитектуру системы жесткие завязки на пользовательский интерфейс.
Мне кажется, что вы слишком категоричны.
Так или иначе, но даже самые системные программисты, если им приходится делать интерфейс как-то, но думают. Другое дело, что 1) программисты не юзабелисты чаще всего (и не разбираются особо) 2) бывает конфликт задач и нельзя идеально сделать интерфейс, а уже потом плясать от него.
Здравствуйте, Max.Subpixel, Вы писали: MS>Мне кажется, что вы слишком категоричны.
Возможно.
Но жизнь, к сожалению, демонстирует примеры...
MS>Так или иначе, но даже самые системные программисты, если им приходится делать интерфейс как-то, но думают.
Конечно думают. Но думают как бы "со стороны"... "А вот для пользователя мы сделаем..."
То есть "для них", "внешнее". Мало кто дает себе труд залезть в чужую шкуру.
MS> 2) бывает конфликт задач и нельзя идеально сделать интерфейс, а уже потом плясать от него.
А это вообще никогда нельзя. Можно другое: изящно выразить одну модель на языке другой.
И это именно то решение. Поскольку порой у одной системы (у одной внутренней модели) бывает несколько совершенно разных (даже идеологически) внешних интефейса.
1.1.4 stable rev. 510
— все работает. Спасибо Владу (он меня уже не любит, правда, за флейм о шрифтах 
) 
Издательство: Символ-Плюс
Издательство: Вильямс
