дизайн классов

AlbertTheII

Новичок
дизайн классов

пусть есть простенькая веб-система обработки запросов клиента. соотвественно, есть класс клиента, запроса, итераторы для них и т.д.
вопрос:
поскольку подобная систeма может отображать клиента десятком способов, какой из классов должен управлять отображением ? должены ли это быть методы клиента или его наследника или ещё как-нибудь ? где, например, будет метод построения формы деталей клиентов ?

спасибо
 

whirlwind

TDD infected, paranoid
> где, например, будет метод построения формы деталей клиентов

Зависит от того, насколько форма коррелирует с системой. Видимо, для каждого представления должен быть свой класс. Наследовать нужно только если у вас в базовом заложена структура наследника. В остальных случаях лучше обходиться агрегированием.
 

AlbertTheII

Новичок
Автор оригинала: whirlwind
> где, например, будет метод построения формы деталей клиентов

Зависит от того, насколько форма коррелирует с системой. Видимо, для каждого представления должен быть свой класс. Наследовать нужно только если у вас в базовом заложена структура наследника. В остальных случаях лучше обходиться агрегированием.
ОК, 10x

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

whirlwind

TDD infected, paranoid
Зависит от реализации MVC. Например в PHP в роли VIEW может быть шаблон, т.е. если отбросить шаблонизатор, практически пассивный элемент. Обработку ввода нельзя выполнить интерактивно, по этому вопрос отношений между моделью и видом можно отбросить. На мой взгляд, для веб-приложений наиболее подходит схема где контроллер расположен между моделью и видом, а не так как на классической схеме.
 

AlbertTheII

Новичок
возникает ещё такой вопрос:
поскольку Controller должен реагировать на события UI, часть из которых должна обрабатываться на клиенте т.е. в javascripte, куда выносить эту логику ?
 
Сверху