Кодирование пользовательского интерфейса Java / GWT - чистый код
Я начал с некоторого базового Java-кодирования с gwt, и я немного обеспокоен состоянием моего основного класса.
Например - как можно разделить обработчики ключей, так как они запускают ряд изменений в пользовательском интерфейсе, как я могу переместить это в отдельный файл.class и при этом иметь возможность доступа ко всем различным виджетам в основном классе без необходимости передать все обработчику (т. е. все виджеты, которыми я манипулирую после события click).
Я гуглил, но не нашел особо хороших примеров - знаете какие-нибудь легко читаемые кодовые базы, которые я мог бы прочитать, чтобы увидеть, как это должно быть сделано? (Собственные вещи GWT довольно просты, и просто помещают все вещи в один файл)
Спасибо!
2 ответа
Я не хочу говорить что-то такое невообразимое, но MVC работает - это не самое главное, но оно может начать вас организовывать.
РЕДАКТИРОВАТЬ: При поиске по полу-связанной теме, я столкнулся с этим, у которого есть подобные идеи с моим, но идет в более подробно.
С точки зрения GWT это означает, что вы должны подумать о том, чтобы просто расположить компоненты GUI в одном классе, поместить всю обработку событий в секунду и отделить объекты объектной модели от двух других.
Один из способов сделать это - сделать большинство или все элементы управления открытыми членами вашего графического интерфейса. Это звучит неубедительно, но их использование заключено в контроллере, поэтому вы не имеете неконтролируемого доступа - на самом деле ваш доступ яснее / лучше определен, чем если бы все ваши члены были частными, но ваш код представления был объединен с контроллером.
Особые хитрости:
Пусть слушатели будут в своем классе. Вы можете часто использовать их - другими словами, избегать анонимных внутренних классов. Я иногда создаю класс слушателя и создаю новый экземпляр для каждой кнопки / элемента управления, который должен иметь аналогичный эффект при нажатии. Если мне нужно, чтобы он работал немного по-другому для данной кнопки, я передам что-то в конструктор "специальных" обработчиков, чтобы они знали, что они действуют немного по-другому. При необходимости вы также можете создавать различные подклассы обработчиков - я просто говорю, что не забывайте, что обработчики событий - это классы, вы можете использовать наследование и все, что нужно.
Один очень старый трюк с графическим интерфейсом, который я изучил давным-давно, старайтесь не использовать различные мини-обработчики, модифицирующие графический интерфейс различными способами, вместо этого пусть все "активные" кнопки и элементы управления устанавливают состояние в вашем графическом интерфейсе, а затем вызывают единственный метод, который применяет это состояние ко всем элементам управления в вашем графическом интерфейсе. Когда вы выходите за рамки обычного графического интерфейса, это может спасти жизнь. Если мне неясно, оставьте комментарий, и я оставлю вам пример.
Листы недвижимости:
Существует особый случай для графических интерфейсов - GUI стиля листа свойств. Я сделал много из них, и они раздражают, как АД. У них, как правило, есть десятки или сотни элементов управления, каждый элемент управления GUI имеет тенденцию быть привязанным к определенному полю в вашей модели, и есть только сотни строк кода для копирования и вставки, соединяющих их, каждая группа копируется и вставляется с помощью нескольких элементы изменены - как минимум 3 строки кода на элемент управления (создание элемента управления, копирование значения внутрь и копирование значения).
Я всегда пишу их с помощью "умного" контроллера, который может интеллектуально связать управление с некоторыми данными без какого-либо уникального кода. Это может быть сложно, и если это ваша проблема, дайте мне знать в комментариях, и я могу дать вам несколько общих советов относительно некоторых хитростей, которые вы можете попробовать. Я прошел путь от минимального рефлексивного решения до полноценного решения на основе XML. Если бы я сделал это снова, я мог бы рассмотреть аннотации на основе.
Пример MVC:
Обратите внимание, это всего лишь пример, есть миллионы способов сделать MVC.
В вашем ГЛАВНОМ:
- Создавать MyView
- Создание экземпляра MyModel
- Создание экземпляра MyController (myView, myModel)
- myView.setVisible (правда)
по-моему
- вероятно расширяет рамку
- Большинство компонентов являются общедоступными окончательными (public final Button b=new Button())
- Если публичные участники заставляют вас нервничать, используйте getters- тот же самый эффект EXACT, что и для публичных финальных участников с небольшим дополнительным синтаксисом.
- Помните, что вы можете установить конечные элементы в своем конструкторе.
- Может иметь общие методы, такие как reset(), но MyController может быть лучшим местом для этого.
в MyController
- сохраняет ссылки на myView и myModel
- при необходимости добавляет слушателей в myView (см. советы по слушателям выше)
- настраивает myView на основе состояния myModel
- когда нажата кнопка "сделано", копирует состояние из myView в myModel
- уведомляет myModel, что его данные были обновлены, и уничтожает себя.
в моей модели:
Это будет типичный класс модели, он будет содержать вашу бизнес-логику (в основном не используется как часть GUI, это больше похоже на логику GUI в MyController. Контроллер будет стремиться устанавливать значения в вашей бизнес-логике, а затем вызывать какой-либо метод, например updated() заставить некоторую бизнес-логику взять управление. Она не должна ничего знать о GUI- это ваш "чистый" бизнес-класс.
Иногда GUI может вызывать update() или какой-либо другой метод, чтобы вызвать изменение данных, а затем перезагружать элементы управления GUI из модели - это довольно хороший способ интеграции вашей бизнес-логики с вашим GUI, когда ваша модель не знает о GUI....
Кроме того, как я уже говорил выше, я бы вложил больше усилий в MyController, если бы работал с листами свойств только из-за большого количества шаблонных строк, которые вы получите, если не разберетесь в этом.
Обратите внимание, что View и Controller почти всегда сопряжены. Вы не можете просто заменить Swing-представление веб-представлением и ожидать, что контроллер останется безмолвным, но модель не должна изменяться для представления или контроллера.
Сначала вы должны взглянуть на лучшие практики для приложений GWT:
http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
Одна из концепций, о которых они говорят, - это MVP (не MVC) для структурирования вашего приложения. В Google Code есть пример проекта, который вы можете посмотреть, чтобы понять, как структурировать приложение GWT следующим образом: