#java #algorithm #user-interface #gwt #design-patterns
#java #алгоритм #пользовательский интерфейс #гвт #шаблоны проектирования #gwt
Вопрос:
Я помогаю создавать приложение GWT для клиента и переписал большую часть материала, чтобы работать лучше, короче код, быстрее и т.д. Однако во всех приложениях с графическим интерфейсом, над которыми я работал (на самом деле их не так много), наступает момент гибкости, когда вам просто нужно ввести множество правил и перенести логику от слушателей к какому-то общему посреднику. Затем иногда это может привести к уродливому беспорядку, так что вы можете делать все, что считаете нужным, в слушателе.
Давайте рассмотрим пример:
- форма с 10-20 полями
- два эксклюзивных радиоуправления контролируют примерно половину состояния других полей (включение, проверка, ограничения ввода)
- три эксклюзивных радиоуправления снова управляют почти теми же полями, но по-другому (влияют на вычисления, позволяют); они также управляются вышеупомянутыми
- 4 или около того числовых поля проверяются «на лету» в зависимости от предыдущих выборов и некоторого объекта данных реального времени; они могут иметь верхние / нижние пределы, быть включены / отключены
- один выпадающий список управляет следующими 6 или около того элементами управления — отображение / скрытие их, изменение средств проверки
- некоторые флажки (показанные приведенной выше комбинацией) активируют некоторые поля ввода, а также определяют алгоритм их проверки
Хотя все запущено, без известных ошибок, есть несколько ошибок в кодировании, которые меня действительно беспокоят:
- код распространяется среди слушателей и некоторых методов-посредников.
- загрузка формы с некоторыми предустановленными значениями сопряжена со своими проблемами: например, объекты данных, которые могут быть доступны или нет, объекты данных, которые могут изменять свое состояние и последующее поведение полей
- для некоторых полей установлено значение по умолчанию, и его не следует перезаписывать при автоматическом заполнении, но если объектов данных там нет (пока), то их нужно будет заполнить в конечном итоге, когда станут доступны более поздние
- форма не может быть отправлена, если какое-либо из полей не проверено
Мой подход:
- определите, какие поля имеют общий afair, и переместите код в одно место
- каждая группа радиостанций использует единственную реализацию слушателя для своих радиостанций
- заполнение формы по умолчанию откладывается до тех пор, пока не будут доступны текущие данные (насколько это возможно), и в результате оно вызывается несколько раз
- каждое действие содержит вызов общего метода проверки
- средство проверки проходит через все поля в форме, вызывает их средства проверки (которые выделяют все ошибки) и возвращает единственное логическое значение
- каждое соответствующее нажатие клавиши или мыши, изменение данных откладывается для вызова через 250 мс после последнего вызова; это означает, что первый вызов просто помещает средство проверки в качестве отложенного действия, последующие вызовы сбрасывают таймер
Хорошо, нет смысла вдаваться в подробности, но меня больше расстраивает тот факт, что нет четкого разделения между визуальными действиями (включение), действиями с данными (установка значений полей формы), прослушивателями полей, получением значений формы и прослушивателями данных в реальном времени.
Какой был бы хороший подход / шаблон (возможно, в следующий раз), чтобы убедиться, что MVC отделяется и лучше поддается обслуживанию? Я знаю, что это не типичный вопрос, но я прочитал все документы, которые смог достать, и все еще не нашел какого-либо полезного ответа.
Комментарии:
1. Избегайте использования слишком большого количества слушателей (разве это не устарело в любом случае?), Не делайте программу слишком болтливой. Используйте MVP, добавляйте аналогичные функциональные наборы в свои собственные виджеты. В противном случае начнется ад, когда вы захотите отладить свою программу через 6 месяцев.
2. Несмотря на то, что я пока принял лучший ответ, я все еще открыт для любых предложений. Просто для последующего ознакомления я добавляю еще один ресурс: code.google.com/p/acris/wiki/MVP_Acris
Ответ №1:
Я бы подошел ближе к MVP, чем к MVC. Очевидно, что Google намерен идти по этому пути, поэтому его принятие, вероятно, будет означать, что вы сможете плыть по течению, а не бороться с течением.
Как это влияет на вас? Что ж, я полагаю, вам следует согласиться с тем, что более аккуратная реализация может потребовать больше кода, а не «более короткого кода», на который вы надеялись. Но, если это логически структурированный, эффективный код, компилятор Google должен иметь возможность обрезать множество на этапе оптимизации компилятора.
Итак, перенесите как можно больше логики на уровень модели. Тщательно протестируйте это и убедитесь, что происходит правильный уровень сброса / очистки страницы (все это можно сделать с помощью простого JUnit, без какого-либо пользовательского интерфейса). Затем используйте свой Presenter (Действие), чтобы привязать Представление к Модели: обработка взаимодействий, заполнение полей и т.д.
Комментарии:
1. Я не о code.google.com/webtoolkit/doc/latest /… . Моя проблема в том, что большая часть кода, над которым я работаю, унаследована И что это мой первый опыт работы с GWT, поэтому приветствуются любые предложения. Я взглянул на то, как реализованы GXT и другие приложения / фреймворки, но пока это меня только заводит.
2. Кроме того, я не «боюсь» большего количества кода, но в GWT это почти всегда переводит более интерпретируемый Javascript, и эта форма должна быть быстрой. Я даже не знаю, как его профилировать — Speedtracer дает мне некоторую информацию, но в скомпилированном режиме трудно понять, какое влияние оказывает Java-код. Кроме того, меня беспокоит, что я уже начал использовать отложенные вызовы для замедления некоторых действий — в моей книге это переводится как unknown flow. Было бы здорово также иметь шаблон типа: вы можете выполнять эти действия параллельно, это следующее действие зависит от этого. Например, операционные системы, где они загружают драйверы или службы при запуске.
3. Привет, промывка мозгов. Да, GWT может выдавать много кода. Однако, как правило, это минимальный код, необходимый для поддержки вашего Java-кода во всем диапазоне выбранных браузеров (это цена, которую приходится платить за кроссбраузерный код). Этап компиляции GWT записывает только js для GWT API, которые на самом деле вызываются вашим кодом: таким образом, он создает минимальный код, соответствующий вашим требованиям. Помимо этого, вы можете использовать разделение кода, чтобы гарантировать, что с сервера передаются только возможности приложения, используемые текущим пользователем. Я не могу помочь с отложенными вызовами, но то, что вы описываете, похожена то, что вы сами кодируете
Ответ №2:
вы можете разделить Огромный класс на разные классы, не разделяя графический интерфейс на разные JPanels. Все панели реализованы в разных классах, расширяющих JPanel. Думаю, это помогло бы тебе.