не работают ли «геттеры и сеттеры - зло» для уровня представления?

Многие знают эту статью: подробнее о геттерах и сеттерах < / а>. Я думаю, что это убедительно изображает злую сторону геттеров / сеттеров. Я также тестировал его, пытаясь преобразовать существующий проект (незавершенный) в код без геттеров / сеттеров. Это сработало. Читаемость кода значительно улучшилась, меньше кода, и мне даже удалось избавиться от геттеров / сеттеров там, где я изначально думал, что они действительно необходимы. За исключением одного места.

Я думаю, что этот подход упускает из виду суть доведения моделей до области просмотра. В статье автор использует построитель для экспорта модели. Проблема в том, что над тем, что помещается в построитель, столько же контроля, сколько над тем, что вы получили бы с геттерами. Да, он скрывает реализацию, как она представлена ​​в модели. Но геттеры не извлекают из модели чего-то очень отличного от того, что было заложено в нее. Если вы создаете объект Money, передавая через конструктор цифру 5, то money.getAmount () не вернет это значение, преобразованное в какую-либо другую валюту, или как массив с одним элементом 5 в нем.

То, что вы установили, вы получите. И через представление мы устанавливаем значения, и те значения, которые мы ожидаем, когда мы запрашиваем их (получаем) от объекта, который должен содержать то, что мы установили в первую очередь. Строитель, экспортирующий их, ожидает того же.

Это немного долго для вопроса. Но мне хотелось бы, чтобы моя точка зрения была оспорена. Являются ли геттеры и сеттеры злом для передачи данных модели на уровень представления?

Многие считают, что геттеры / сеттеры вовсе не зло. Это также не то, что я хотел бы услышать в защиту, поскольку я думаю, что они ДЕЙСТВИТЕЛЬНО являются злом в других местах, чем те, которые я упомянул.


person koen    schedule 20.08.2009    source источник
comment
Вы должны увидеть книгу Алана Холуба amazon.com/Holub- Patterns-Learning-Design-Looking / dp / 159059388X Он много говорит о том, что геттеры и сеттеры - зло и когда они приемлемы. Он показывает много примеров, так что писать их здесь было бы слишком много.   -  person Yaroslav Yakovlev    schedule 22.08.2009


Ответы (2)


В очень простых случаях объект данных не имеет поведения для инкапсуляции, поэтому аргументы, основанные на улучшении инкапсуляции поведения, на самом деле не применимы.

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

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

person Pete Kirkham    schedule 20.08.2009
comment
Модель отправляет некоторые данные в представление, но это более или менее то же самое, что получение данных. Ожидаете ли вы другого результата между StackOverflowPost.getTitle () и StackOverflowPost.RegisterObserver (представление), когда представление затем получает заголовок (получить)? - person koen; 20.08.2009
comment
Замечание: используются ли наблюдатели таким образом, чтобы их не уведомляли об изменении getSomething? - person koen; 20.08.2009
comment
«объект данных» - это название «структуры» во всех языках, являющихся объектами. - person Pete Kirkham; 20.08.2009
comment
›Замечание: используются ли наблюдатели таким образом, чтобы их уведомляли об изменении getSomething? Да, особенно в сетевых приложениях, где уведомление с полезной нагрузкой «foo стало 7» при 29843214324 мс. UTC «стоит одну задержку сообщения, но« foo изменилось »,« что такое foo, то «foo = 7» стоит три, и его легче спутать. если данные меняются со скоростью, близкой к задержке. - person Pete Kirkham; 20.08.2009
comment
@PeteKirkham: включение в сообщение нового значения иногда может быть выгодным, но иногда может быть и обратное. Например, с чем-то вроде индикатора выполнения может быть полезно, чтобы первое изменение его процента завершения запускало сообщение индикатора выполнения обновления в очереди пользовательского интерфейса, но для последующих изменений не следует делать этого до тех пор, пока пользовательский интерфейс не будет обновлен. Код, состояние завершения которого отображается, не должен заботиться о том, как часто пользовательский интерфейс реагирует на такие обновления; элемент управления должен быстро обрабатывать повторяющиеся обновления, отбрасывая все значения, кроме самого последнего. - person supercat; 24.08.2012

В языке Scala используется альтернативная модель, но ее действительно можно использовать где угодно. Это модель Конструктор / Экстрактор. Конструктор и есть конструктор класса. Экстрактор - это метод, который при вызове вернет параметры, которые, переданные в конструктор, создадут клон этого объекта.

Для динамических языков вы просто возвращаете список и все готово. Для статически типизированных языков вы можете использовать список объектов, которые затем должны быть обработаны, чтобы каждый тип мог быть правильно назначен, или у вас должен быть класс кортежа с параметризацией типа, чтобы вы могли возвращать каждый параметр с правильный тип.

В конкретном случае Scala его экстракторы похожи на статические методы Java, и они получают объект в качестве входных данных. Он либо возвращает параметры, либо возвращает None, который выполняет функцию, аналогичную функции null в Java.

Идея в том, что вы можете разложить то, что вы составили, что в значительной степени может понадобиться представлению.

У вас, возможно, возникнет еще одно понятие: «скажи, не спрашивай» намеревается сохранить бизнес-правила с данными, к которым они применяются. Теперь бизнес-правила представления обязательно связаны с представлением, поэтому у вас остаётся проблема запрашивать данные у модели ... если вы не инвертируете игру. Модель может сообщать представлению о необходимости отображения данных, передавая ему соответствующие поля вместо того, чтобы запрашивать их. Таким образом, модель сообщает представлению о необходимости отображения данных, а представление сообщает модели об обновлении данных.

person Daniel C. Sobral    schedule 20.08.2009