«Геттеры и сеттеры злые» терпят неудачу для слоя представления?

Question

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

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

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

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

Есть много людей, которые думают, что добытчики / сеттеры вовсе не злые. Это также не то, что я хотел бы услышать в защиту, так как я думаю, что они ДЕЛАЮТ зло в других местах, чем те, о которых я упоминал.

Answer 1

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

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

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

Answer 2

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

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

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

Идея состоит в том, что вы можете разложить то, что вы написали, и это почти то, чего может хотеть представление.

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