grexhideА нафига включать мозги... кхм, на унитазе или при ваянии UI - я тут, увы, вообще не могу понять всю глубины мысли.
Ну, на унитазе для собственного удовольствия :) А то как то не гламурно получается - тупо срешь, и все. А в UI - для того, чтобы потом 3 месяца не тратить на переделку того, что голыми рефлексами набросал за неделю.

grexhide Прохожий....А в UI - для того, чтобы потом 3 месяца не тратить на переделку того, что голыми рефлексами набросал за неделю.

Ок... Согласен. На самом деле так и происходит.

Я за 10-минут делаю прототип. Ты его делаешь за два дня.

Потом я его за три часа (x30) довожу до кондиционного состояния (пару раз переделев, т.е. цикл 10 минут, час один день, час другой, час третий - с разрывом в три недели - классика написания/вычитки/правки хоть книг, хоть чего то еще).

Ты же, вместо трех часов на передлку - будешь тратить два месяца (потому что я просто в дизайнере поработаю, ты же будешь сопя во все сопелки и натужно попу..(зачернуто) сидеть и переписывать код на каждое замечание Тестера/Шефа/Заказчика)

Все сходится, никакой Америки.

--

Кстати, на вполне логичный вопрос - почему же все тогда на Delphi не делается отвечу просто: нас меньше, чем индусов, это раз, в остальное время - мы гоняем балду, постаём в форумы, трем с коллегами, читаем новости, беседуем с Заказчиком, аналитиками или дизайнерами о самих задачах и занимаемся прочим приятным времяпровождением - а не от 10 до 18-45-ти - натужное фтыкание в эклипс, деплой, поиск методов перепрыгивания через експепшины и прочее, что там у вас, яверов, принято).

Вот и все. Каждый выбирает себе сам, чего ему больше нравится.
Я все таки ООП предпочитаю использовать. Расчленяю бизнес-логику на ограниченные "черные ящики", определяю интерфейс взаимодействия этих "ящиков". 2-3 дня трачу на разработку настраиваемых "компонентов" (в смысле на каждый компонент) - модель данных + примитив отображения + торчащие наружу акшоны, получаю "сторительные кирпичи" для UI, потом плюхаю эти компоненты там, где мне надо, открываю те функции, которые необходимо, обеспечиваю взаимодействие между "кирпичиками" (друг о друге они ничего не знают) - это быстро.
При изменении бизнес-логики или требований мне достаточно изменить несколько строк кода для того, чтобы функционал изменился всезде, где эта бизнесс-логика задействована.
Да, кстати - по-настоящемму качественный UI предполагает поддержку многопоточности (ты же, надеюсь, реакцию на мышь с клавиатурой + отрисовку не делаешь в том же потоке, что и обращение к СУБД/серверу приложений), кэширование данных из СУБД, прддержка актуальности для кэша, транзакционный контекст (изменения в кэше должны откатиться при откате изменений на сервере)... Для всего этого тоже мозги не надо включать???

Да, в некотрых случаях принципиально разные "компоненты" используют одну и ту же обобщенную модель данных. Просто отображают/редактируют ее. И друг о друге ничего не знают. Это в сложных случаях.

grexhideУбедил?
Меня нет :) Напомню, мне приходилось программировать на Дельфи, и не один год. Так что с описанными подходами я хорошо знаком. они позволяют быстро создавать некачественный интерфейс. Интеллектуальные UI (повторюсь - многопоточность, кэш, транзакционность, гибкость) программировать с таким подходом безумно сложно.

grexhide Прохожий....Я все таки ООП предпочитаю использовать. Расчленяю бизнес-логику на ограниченные "черные ящики", определяю интерфейс взаимодействия этих "ящиков". 2-3 дня трачу на разработку настраиваемых "компонентов" (в смысле на каждый компонент) - модель данных + примитив отображения + торчащие наружу акшоны, получаю "сторительные кирпичи" для UI, потом плюхаю эти компоненты там, где мне надо, открываю те функции, которые необходимо, обеспечиваю взаимодействие между "кирпичиками" (друг о друге они ничего не знают) - это быстро.
При изменении бизнес-логики или требований мне достаточно изменить несколько строк кода для того, чтобы функционал изменился всезде, где эта бизнесс-логика задействована.
Да, кстати - по-настоящемму качественный UI предполагает поддержку многопоточности (ты же, надеюсь, реакцию на мышь с клавиатурой + отрисовку не делаешь в том же потоке, что и обращение к СУБД/серверу приложений), кэширование данных из СУБД, прддержка актуальности для кэша, транзакционный контекст (изменения в кэше должны откатиться при откате изменений на сервере)... Для всего этого тоже мозги не надо включать???

Неа... Все, о чем ты только что рассказал - у меня уже десять лет назад как реализовано в базовых формах (VFI). Один раз и навсегда (а для чего еще нужен ООП?)

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

Аналогично, на уровне сервера (типа модель по вашему) - все идет на генерациях. Все, что мне нужно написать (иногда) - это куда чего потом от чего считать (книгу покупок от счетов фактур, проводки от документов ну и так далее).

Минимизация кода - это принцип. Повторяющиеся задачи - это зло и вырезается как класс.

--

Ты все еще кодируешь "поддержание транзакционности" в каждой форме? ну ну, кодируй кодируй.
И это работает с данными любой сложности, степени взаимодействия, с любыми источниками (реляционные СУБД, удаленные Web сервисы, асинхронные сообщения, файловая система, просто XML и т.д. и т.п.)??? Все в базовой форме закодировано? И многопоточность нормальная поддерживается? и любая бизнеа-логика поверх данных за 10 минут мышкой стпроится? Круто!!! Вообще то, если бы ты так не тормозил, то ты бы уже был миллиардером - на таком компоненте можно больше бабок срубить, чем на продаже Windows. Так что подумай в этом направлении!!!!
Хотя нет - лучше не думай - а то мы все без работы останемся...

Все, пошел стреляться. Господа программисты - срочно осваиваем метлу и совковую лопату - grexhide на всех сделал работы в IT скоро не останется!!! Будет только grexhide и его форма!!!
Всем срочно перевалифицироваться в дворники!!! Пока не поздно - конкуренция там пока еще не слишком велика.