Если я не хочу раскрывать состояние своего объекта, но мне все равно нужно его отображать (скажем, в HTML, XML или JSON), как мне это сделать в среде MVC. Имеет ли смысл иметь метод экспорта, который экспортирует тупой неизменяемый объект («класс данных», если хотите). Как насчет добавления метода рендеринга, который взаимодействует с интерфейсом? Есть ли другие подходы к этой проблеме?
Могу ли я использовать mvc без геттеров и сеттеров?
Ответы (2)
Метод рендеринга наиболее близок к скрытому состоянию. Другой метод (хорошо известный пользователям Smarty) состоит в том, чтобы передать представлению необъектные структуры данных для работы.
Однако стоит спросить, какую проблему решают эти абстракции и/или интерфейс, который они обслуживают? Если вы собираетесь делать всю эту работу, IMO, вы должны убедиться, что есть какая-то работа, которая вас спасает.
person
chaos
schedule
26.07.2009
Вопрос не в сохранении работы. Во всем есть компромиссы. Я считаю, что всегда будет компромисс между инфраструктурой RAD и хорошо спроектированной системой. Фреймворк RAD никогда не создаст хороший поддерживаемый код, но он быстро выполняет свою работу. Я просто пытаюсь решить проблему в чистом виде, стараясь максимально придерживаться принципов объектно-ориентированного программирования, потому что я считаю, что это лучший способ сделать систему, которую можно обслуживать.
- person blockhead; 26.07.2009
Причина сделать что-то ремонтопригодной системой состоит в том, чтобы сэкономить на обслуживании. Если вы позволите чистоте уйти от ее мотива экономии труда, вы получите удивительно чистую систему, с которой ужасно работать. Так происходит все время.
- person chaos; 26.07.2009
Суть инкапсуляции в сокрытии реализации. Существует "состояние", о котором должны знать другие объекты - иногда вся назначение объекта сообщает такое состояние.
Например, было бы довольно бесполезно иметь объект Defined Finite Automata, который не имеет геттера для того, находится ли он в конечном состоянии или нет. Но, безусловно, полезно инкапсулировать, как эта информация хранится внутри.
Теперь цель геттеров и сеттеров — предоставить интерфейс к свойствам состояния объекта, который может не иметь ничего общего с тем, как он реализован на самом деле. Конечно, в большинстве случаев эти свойства являются полями в объекте, а геттеры и сеттеры — просто поверхностными оболочками. С другой стороны, у вас есть свобода изменять внутреннюю реализацию, потому что геттеры и сеттеры обеспечат совместимость интерфейса.
Однако, если эти свойства слишком связаны с фактической реализацией и не так сильно связаны с тем, о чем объект, то вам следует рассмотреть возможность удаления таких геттеров и сеттеров.
Сказав все это, если вам нужно что-то отобразить пользователю, то об этом свойстве должны знать другие объекты. Объект не должен заботиться о том, как отображать себя, по многим причинам. Один из них заключается в том, что он не может знать, как он должен отображаться, не зная, как он используется приложением, что заставит ИТ-отдел слишком много знать о других объектах.
person
Daniel C. Sobral
schedule
26.07.2009
Что касается последнего пункта, интерфейс позаботится о том, как он отображается. Объект не будет знать ничего, кроме того, что он передает часть своего состояния средству визуализации, но не знает, что средство визуализации делает с ним. Реальный вопрос в том, считается ли это слишком сильной связью (возможно, объект даже не должен знать, что его нужно визуализировать), или я просто сошел с ума.
- person blockhead; 26.07.2009
