Java дизайн: слишком много получателей

Question

После написания нескольких менее значимых программ при изучении Java я разработал программы с Model-View-Control.С использованием MVC у меня есть множество методов получения в модели для представления.Мне кажется, что, хотя я выигрываю от использования MVC, для каждого нового добавленного значения я должен добавить два новых метода в модель, которые быстро загромождают все с помощью getter & setters.

Так что я подумал, может быть, мне следует использовать метод notifyObserver, который принимает аргумент.Но я не чувствовал бы себя очень разумно, чтобы отправлять каждое значение отдельно, поэтому я подумал, может быть, если я отправлю своего рода контейнер со всеми значениями, предпочтительно только те, которые действительно изменились.Это могло бы привести к тому, что вместо множества методов-получателей у меня мог бы быть только один метод в модели, который поместил бы все соответствующие значения в контейнер.Тогда в представлении у меня будет метод, вызываемый из обновления, который извлекает значения из контейнера и присваивает их правильным полям.

У меня есть два вопроса по этому поводу.

Первое: isэто действительно жизнеспособный способ сделать это.Вы бы порекомендовали мне сделать что-то в этом духе? ​​

Во-вторых: если я использую этот план и не хочу продолжать отправлять поля, которые на самом деле не менялись.Как бы я справился с этим, не имея операторов if, чтобы проверить, является ли значение не нулевым для каждого отдельного значения?

Answer 1

Я более знаком с парадигмой MVP, но, надеюсь, они достаточно похожи, чтобы комментировать. Хотя геттеры (и сеттеры) сами по себе не обязательно являются злом, они иногда являются признаком того, что ваши подсистемы слишком сильно связаны. Один действительно отличный способ отделить это - использовать шину событий: см. Рекомендации по архитектуре приложений GWT . Это позволяет представлению просто снимать события, которые контроллер может прослушивать, когда происходит что-то важное, и представление может прослушивать события, когда что-то меняется в модели, что соответствует обновлению представления. В идеале вам даже не нужно было бы передавать модель представлению, если вы можете разбить любые изменения на инкрементные фрагменты и просто указать представлению изменить эту часть, а затем эту другую часть.

Answer 2

Если вы чувствуете, что в вашем классе модели слишком много геттеров (и сеттеров), возможно, у вас слишком много полей. Возможно ли, что в вашей модели есть несколько разных классов? Если вы извлечете их в отдельные классы, это может сделать вашу модель более управляемой.

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

В целом, Java - это многословный язык, который требует от вас установки всех этих методов получения и установки (и многих других). Тем не менее, любая достойная IDE может сгенерировать их для вас несколькими нажатиями клавиш. Также обратите внимание, что вам нужно написать их только один раз, и вы будете читать и вызывать их еще много раз. Подробный также означает легко читаемый.

Answer 3

Если у вас слишком много добытчиков, это нормально. Но вам не нужен сеттер. Предполагается, что представление только чтение / запрос модель.

Шаблон MVC должен продвигать нечто асимметричное: элемент управления обновляет модель, вызывая методы в модели, в которые встроена логика, и соответственно обновляет состояние; это учитывает инкапсуляцию . Представление читает / запрашивает модель через геттеры. Это немного противоречит скрытию информации , но именно так работает MVC.

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