public void edit(Model model){
// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п.
}
}
Вариант 2
class Object {
private Model model;
public void edit(Model model){
// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п.
}
public Model getModel(){return model;}
}
Теперь, рассудите меня с коллегой. Если какие-нибудь серьезные основания против Версии 1 (Наследования).
Мое мнение в данном случае, что в данном случае наследование является наиболее органичным решением. Выделея данные в отдельный класс я просто разгружаю класс объекта от лишних методов (get и set) для класса объекта и все основания, что наследование это зло и от него надо старатся уходить к данному случаю не имеют отношения.
Здравствуйте, Tourist, Вы писали:
T>Пусть есть
T>class Model { T> private long n;
T> public long getN(){ T> return n; T> }
T>}
T>Вариант 1
T>class Object extends Model {
T> public void edit(Model model){ T> // здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. T> } T>}
T>Вариант 2
T>class Object { T> private Model model;
T> public void edit(Model model){ T> // здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. T> }
T> public Model getModel(){return model;} T>}
T>Теперь, рассудите меня с коллегой. Если какие-нибудь серьезные основания против Версии 1 (Наследования). T>Мое мнение в данном случае, что в данном случае наследование является наиболее органичным решением. Выделея данные в отдельный класс я просто разгружаю класс объекта от лишних методов (get и set) для класса объекта и все основания, что наследование это зло и от него надо старатся уходить к данному случаю не имеют отношения.
Это пишет коллега-оппонент:
Тут надо на самом деле понимать, что Model представляет собой просто тупой набор данных, который сохраняется/берется в/из БД, То есть, фактически он является полной копией набора полей соответствующих таблиц реляционной базы.
ИМХО, полноценный объект (Object) НЕ является структурой данных(наследование), а содержит ее(композиция). Посему наследовать Object от Model мягко говоря некорректно. Да и к тому же с помощью композиции можно использовать кучу паттернов, которые делают его мощным инструментом для повторного использования классов.
А вот метод в классе Object
public Model getModel(){return model;}
является ИМХО неудачным с точки сокрытия реализации.....
Здравствуйте, Tourist, Вы писали:
T>Пусть есть
T>class Model { T> private long n;
T> public long getN(){ T> return n; T> }
T>}
T>Вариант 1
T>class Object extends Model {
T> public void edit(Model model){ T> // здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. T> } T>}
Тогда уж нужно изменить сигнатуру метода
с
public void edit(Model model)
на
public void edit()
или
public static void edit(Model model)
Но в Вашем случае агрегация более предпочтительна.
ZEN>Тогда уж нужно изменить сигнатуру метода ZEN>с ZEN>public void edit(Model model) ZEN>на ZEN>public void edit() ZEN>или ZEN>public static void edit(Model model)
ZEN>Но в Вашем случае агрегация более предпочтительна.
так нельзя, как бы edit и есть операция над данным текущего объекта, а параметром мы передаем ему структуру с его новыми параметрами
можно написать по другому
public void edit(long newN){.....}
и все таки пока я считаю что наследование это более правильно просто с точки зрения восприятия данного объекта, опять же вопрос, а как при агрегации из объекта получать данные его модели данных
писать везде типа
object.getModel().genN()
или в классе объъекта реализовывать методы обертки над методами модели данных
class Object {
....
public long getN(){ return this.model.getN()}
}
Здравствуйте, Tourist, Вы писали:
T>Пусть есть
T>class Model { T> private long n;
T> public long getN(){ T> return n; T> }
T>}
T>Вариант 1
T>class Object extends Model {
T> public void edit(Model model){ T> // здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. T> } T>}
T>Вариант 2
T>class Object { T> private Model model;
T> public void edit(Model model){ T> // здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. T> }
T> public Model getModel(){return model;} T>}
T>Теперь, рассудите меня с коллегой. Если какие-нибудь серьезные основания против Версии 1 (Наследования). T>Мое мнение в данном случае, что в данном случае наследование является наиболее органичным решением. Выделея данные в отдельный класс я просто разгружаю класс объекта от лишних методов (get и set) для класса объекта и все основания, что наследование это зло и от него надо старатся уходить к данному случаю не имеют отношения.
Хочу сразу оговориться, что всё что я здесь скажу не является готовым решением, но всего лишь некоторыми общими мыслями на тему. ) И так, начнём.
Взгляд со стороны пуриста OO
Варинат 1 ) Когда мы наследуемся от класса, то мы наследуем не реализацию, но и интерфейс. В этом смысле весьма красноречив коментарий:
public void edit(Model model){
// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п.
}
О чём он говорит лично мне? Что скорее всего, при провале операции по проверке прав будет выкинут Exception. Хуже того, скорее всего некоторый разумный Exception ( что-нибудь вроде SecurityException ). А это, в свою очередь, обозначает, что изменился интерфейс. А это уже не наследование ))) Это уже что0то совсем другое. Скорее всего ошибка проектирования.
В варианте 2, по сути, объявляется НОВЫЙ интерфейс. На мой взгляд, это более корректно. По крайней мере, можно задокументировать поведение.
Взгляд со стороны тестирования.
Я являюсь горячим поклонником Test Driven Development. И очень люблю писать тесты) (что, кстати, всем и рекомендую) С какой трудностью мы столкнёмся в процессе тестирования данного класса?
Первое, наиболее очевидное, что добавляется новое предусловие: пользователь должен иметь права для совершения операци. Ессно, что тесты на старый класс ничего об этом предусловии не знают, а значит и не беспокоятся о его выполнении. А что в свою очередь обозначает, что при передаче тестам базового экземпляра наследника, будут возникать ошибки, что попахивает нарушением принципа подстановки Лискоу.
Опять же, второй вариант этого недостатка лишён. Более того, для него просто пишется свой собственный набор тестов по проверке прав доступа.
Взгляд со стороны шаблонов проектирования.
С первого взгляда, вопрос идёт о выборе между паттерном Декоратор и Прокси. Смотрим в описание паттернов. Деократор — динамически добавляет классу новые обязанности. Прокси — Является суррогатом к объхекту и контролирует доступ к нему. По моему, даже исхродя из определения более подходящим является второй вариант) Хотя использование в этом случае Прокси тоже ставит некоторые проблемы, которые частично затрагивались ранее ( как новые эксепшены и т.д ) Но с другой стороны, это даёт возможность в этот наш псевдопрокси подсовывать различные наследники класса Model. Что опять же хорошо.
Взгляд со стороны патерна MVC
Название Model навевает на мысли, что здесь пытаются применить паттерн MVC. У меня такое впечатление, что проверять права доступа должны, всё-таки, классы контролера, а не модели. В товремя как применение наследования логически выглядит как дополнения модели, а не созданние специфического контроллера.
Взгляд со стороны реальной жизни.
Всё это хорошо, но может быть совершенно не применимо к реальному проекту. ) Задача может стоять таким образом, что всей программе абсалютно всё равно, какие Exception летят из данного интерфейса ) Есмли ситуация именна такова, и надо быстро добавить проверку прав пользователя, которая не будет приводить к тотальному переписыванию программы, то такая заплатка вполне оправдана. В программировании цель оправдывает средства ))) К сожалению, я не могу судить о целесообразности рефакторинга в данном конкретном случае.
Вот и всё, что я могу сказать на эту тему. Надеюсь, это поможет )
Здравствуйте, Бодхисатва, Вы писали:
Б>С первого взгляда, вопрос идёт о выборе между паттерном Декоратор и Прокси. Смотрим в описание паттернов. Деократор — динамически добавляет классу новые обязанности. Прокси — Является суррогатом к объхекту и контролирует доступ к нему. По моему, даже исхродя из определения более подходящим является второй вариант) Хотя использование в этом случае Прокси тоже ставит некоторые проблемы, которые частично затрагивались ранее ( как новые эксепшены и т.д ) Но с другой стороны, это даёт возможность в этот наш псевдопрокси подсовывать различные наследники класса Model. Что опять же хорошо.
Прокси здесь не подходим, мы не переопределяем свойства наследуемого класса и не котролируем к ним доступ, класс Модел это просто набор данных (private) к которым объявлен открытый интерфейс getXxx()
А патерн прокси как раз используется как замиститель какого-то другого класса, который реализует интерфейс какого-то другого объекта, вроде примерно так.
Б>Взгляд со стороны патерна MVC
Б>Название Model навевает на мысли, что здесь пытаются применить паттерн MVC. У меня такое впечатление, что проверять права доступа должны, всё-таки, классы контролера, а не модели. В товремя как применение наследования логически выглядит как дополнения модели, а не созданние специфического контроллера.
Б>Взгляд со стороны реальной жизни.
Б>Всё это хорошо, но может быть совершенно не применимо к реальному проекту. ) Задача может стоять таким образом, что всей программе абсалютно всё равно, какие Exception летят из данного интерфейса ) Есмли ситуация именна такова, и надо быстро добавить проверку прав пользователя, которая не будет приводить к тотальному переписыванию программы, то такая заплатка вполне оправдана. В программировании цель оправдывает средства ))) К сожалению, я не могу судить о целесообразности рефакторинга в данном конкретном случае.
Б>Вот и всё, что я могу сказать на эту тему. Надеюсь, это поможет )
да, более всего нам подходит взгляд со стороны реальной жизни.
Не которые уточнения вобще по всему вопросу, в своем первом посте я упростил ситуацию, наверно может надо больше жизни
У нас web приложении.
Каркас системы реализован примено по патерну DAO.
Есть классы Action туда приходит запрос, из запроса формируем класс Model и передаем методу DAO ( к примеру DAO.edit(model) )
Есть Action для операции удалить, который так же берет запрос и обращается к методу DAO ( DAO.delete( long n) )
понадобилась создать проверку прав пользователя, соответственно я создал объект, который себя иницилизирует получая номер объекта из запроса
// метод обращается через DAO к б.д. и иницилизирует себя
Object object = Object.getInstance(long n);
а потом вызываю метод объекта, который проверяет доступ и если все нормально вызывает соответсвующий метод DAO
object.edit(model);
главная суть классов Object — они расширают классы Model конкретными операциями над данными сущностями которые описывают классы Model.
и возник спор, что нельзя абсолютно в данной ситуации использовать наследование или можно (мое imho даже предпочтительней )
плюсы наследования:
1. можно привести тип класса Object к классу Model, и соответсвенно скрыть операции над объектом, когда нужен только один интерфейс к данным объекта (при обертывании данных в XML мне нужны только get) + не надо не чего переписывать так как старым методам мы возвращаем прежний Model
2. в классе Object ни как не надо реализовавывать операции для доступа к данными (методы getXxx()) т.к. они уже унаследованы от базового класса, в варианте 2 их придется заново определять, либо возвращать модельку с данными, что есть раскрытие внутренего состояния объекта
особых плюсов от композиции в данной ситуации я пока не вижу.
Здравствуйте, Tourist, Вы писали:
T>Здравствуйте, Бодхисатва, Вы писали:
Б>>С первого взгляда, вопрос идёт о выборе между паттерном Декоратор и Прокси. Смотрим в описание паттернов. Деократор — динамически добавляет классу новые обязанности. Прокси — Является суррогатом к объхекту и контролирует доступ к нему. По моему, даже исхродя из определения более подходящим является второй вариант) Хотя использование в этом случае Прокси тоже ставит некоторые проблемы, которые частично затрагивались ранее ( как новые эксепшены и т.д ) Но с другой стороны, это даёт возможность в этот наш псевдопрокси подсовывать различные наследники класса Model. Что опять же хорошо.
T>Прокси здесь не подходим, мы не переопределяем свойства наследуемого класса и не котролируем к ним доступ, класс Модел это просто набор данных (private) к которым объявлен открытый интерфейс getXxx() T>А патерн прокси как раз используется как замиститель какого-то другого класса, который реализует интерфейс какого-то другого объекта, вроде примерно так.
Б>>Взгляд со стороны патерна MVC
Б>>Название Model навевает на мысли, что здесь пытаются применить паттерн MVC. У меня такое впечатление, что проверять права доступа должны, всё-таки, классы контролера, а не модели. В товремя как применение наследования логически выглядит как дополнения модели, а не созданние специфического контроллера.
Б>>Взгляд со стороны реальной жизни.
Б>>Всё это хорошо, но может быть совершенно не применимо к реальному проекту. ) Задача может стоять таким образом, что всей программе абсалютно всё равно, какие Exception летят из данного интерфейса ) Есмли ситуация именна такова, и надо быстро добавить проверку прав пользователя, которая не будет приводить к тотальному переписыванию программы, то такая заплатка вполне оправдана. В программировании цель оправдывает средства ))) К сожалению, я не могу судить о целесообразности рефакторинга в данном конкретном случае.
Б>>Вот и всё, что я могу сказать на эту тему. Надеюсь, это поможет )
T> да, более всего нам подходит взгляд со стороны реальной жизни.
T>Не которые уточнения вобще по всему вопросу, в своем первом посте я упростил ситуацию, наверно может надо больше жизни
T>У нас web приложении. T>Каркас системы реализован примено по патерну DAO.
T>Есть классы Action туда приходит запрос, из запроса формируем класс Model и передаем методу DAO ( к примеру DAO.edit(model) )
T>Есть Action для операции удалить, который так же берет запрос и обращается к методу DAO ( DAO.delete( long n) )
T>понадобилась создать проверку прав пользователя, соответственно я создал объект, который себя иницилизирует получая номер объекта из запроса
T>// метод обращается через DAO к б.д. и иницилизирует себя T>Object object = Object.getInstance(long n);
T>а потом вызываю метод объекта, который проверяет доступ и если все нормально вызывает соответсвующий метод DAO
T>object.edit(model);
T>главная суть классов Object — они расширают классы Model конкретными операциями над данными сущностями которые описывают классы Model.
T>и возник спор, что нельзя абсолютно в данной ситуации использовать наследование или можно (мое imho даже предпочтительней )
T>плюсы наследования: T> 1. можно привести тип класса Object к классу Model, и соответсвенно скрыть операции над объектом, когда нужен только один интерфейс к данным объекта (при обертывании данных в XML мне нужны только get) + не надо не чего переписывать так как старым методам мы возвращаем прежний Model T> 2. в классе Object ни как не надо реализовавывать операции для доступа к данными (методы getXxx()) т.к. они уже унаследованы от базового класса, в варианте 2 их придется заново определять, либо возвращать модельку с данными, что есть раскрытие внутренего состояния объекта
T>особых плюсов от композиции в данной ситуации я пока не вижу.
Первым делом, конечно, надо извиниться, потому что все мои ответы были не совсем в тему по невнимательности )
Чтро же касается всего остального, то:
1) Получается неестественная привязка процесса к данным. Класс Object получает неиспользуемые методы get и set. Совсем непонятно, зачем в метод edit передаётся парамтром объект класса Model?
class Object extends Model {
public void edit(Model model){
// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п.
}
}
Было бы гораздо естественнее создать объект класса Object, установить необходимые поля и вызвать edit без параметров. На то она и привязка операций к данным объекта. ( И это начинает напоминать Data Transfer Object, когда есть некоторая сущность с бизнес-операциями, и есть объект, который переносит данные сквозь слои ( объект класса model, в которм только и есть методы get и set )
Тогда код выглядел бы так.
В случае защитного подхода
object = new Object(model)
object.edit() -> DAO.getInstance( n) -> object.CheckRights() -> DAO.Delete( n )
В случае контрактного подхода
object = new Object(model)
if
(
object.CheckRights() -> DAO.getInstance( n) -> object.InternalCheckRights()
) {
Здравствуйте, Бодхисатва, Вы писали:
Б>1) Получается неестественная привязка процесса к данным. Класс Object получает неиспользуемые методы get и set. Совсем непонятно, зачем в метод edit передаётся парамтром объект класса Model?
почему не используемые, внутри реализации своих метод он их использует, причем методы set объявляются protected
public void edit(Model model){
check();
DAO.edit(this.getN(), model);
}
Б>class Object extends Model {
Б>public void edit(Model model){ Б>// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. Б>} Б>}
Б>Было бы гораздо естественнее создать объект класса Object, установить необходимые поля и вызвать edit без параметров. На то она и привязка операций к данным объекта. ( И это начинает напоминать Data Transfer Object, когда есть некоторая сущность с бизнес-операциями, и есть объект, который переносит данные сквозь слои ( объект класса model, в которм только и есть методы get и set ) Б>Тогда код выглядел бы так.
Б>В случае защитного подхода
Б>object = new Object(model) Б>object.edit() ->> DAO.getInstance( n) ->> object.CheckRights() ->> DAO.Delete( n )
Б>В случае контрактного подхода
Б>object = new Object(model) Б>if Б>( Б> object.CheckRights() ->> DAO.getInstance( n) ->> object.InternalCheckRights() Б>) {
Б>object.edit() ->> DAO.Delete( n ) Б>}
насчет реализации операции edit, можно порасуждать, но вопрос не в этом, можно ли говорить что на 100% здесь наследование не подходит и при реализации композицией дизайн будет намного проще.
меня впринципе смущает одна вещь в предложенном подходе к edit, это мне придется вызывать метод DAO.geInstance(n) в каждом методе (а их может быть много), не проще все таки такой подход что получаем в одной точке объект при иницилизации а потом ему говорим объект.изменитьСвойства(новыеЗначенияСвойств).
или
объект.изменитьНазвание(новоеНазвание)
Здравствуйте, Tourist, Вы писали:
T>Здравствуйте, Бодхисатва, Вы писали:
Б>>1) Получается неестественная привязка процесса к данным. Класс Object получает неиспользуемые методы get и set. Совсем непонятно, зачем в метод edit передаётся парамтром объект класса Model?
T>почему не используемые, внутри реализации своих метод он их использует, причем методы set объявляются protected
Б>>class Object extends Model {
Б>>public void edit(Model model){ Б>>// здесь проверяем доступ пользователя, редактируем модуль, сохраняем в базу и т.п. Б>>} Б>>}
Б>>Было бы гораздо естественнее создать объект класса Object, установить необходимые поля и вызвать edit без параметров. На то она и привязка операций к данным объекта. ( И это начинает напоминать Data Transfer Object, когда есть некоторая сущность с бизнес-операциями, и есть объект, который переносит данные сквозь слои ( объект класса model, в которм только и есть методы get и set ) Б>>Тогда код выглядел бы так.
Б>>В случае защитного подхода
Б>>object = new Object(model) Б>>object.edit() ->>> DAO.getInstance( n) ->>> object.CheckRights() ->>> DAO.Delete( n )
Б>>В случае контрактного подхода
Б>>object = new Object(model) Б>>if Б>>( Б>> object.CheckRights() ->>> DAO.getInstance( n) ->>> object.InternalCheckRights() Б>>) {
Б>>object.edit() ->>> DAO.Delete( n ) Б>>}
T>насчет реализации операции edit, можно порасуждать, но вопрос не в этом, можно ли говорить что на 100% здесь наследование не подходит и при реализации композицией дизайн будет намного проще.
T>меня впринципе смущает одна вещь в предложенном подходе к edit, это мне придется вызывать метод DAO.geInstance(n) в каждом методе (а их может быть много), не проще все таки такой подход что получаем в одной точке объект при иницилизации а потом ему говорим объект.изменитьСвойства(новыеЗначенияСвойств). T>или T>объект.изменитьНазвание(новоеНазвание)
T>хотя об этом можно подумать
Ответь мне на следующий вопрос: зачем нужны эти геттеры и сеттеры этому объекту? И зачем его надо приводить к типу Model, когда объект этого типа и так передаётся параметром? Почему DAO сразу нельзя его передать? И что эти гетеры и сеттеры делают, когда их вызывают? И как они связаны с параметром метода edit?
Б>Ответь мне на следующий вопрос: зачем нужны эти геттеры и сеттеры этому объекту? И зачем его надо приводить к типу Model, когда объект этого типа и так передаётся параметром? Почему DAO сразу нельзя его передать? И что эти гетеры и сеттеры делают, когда их вызывают? И как они связаны с параметром метода edit?
Гетеры используются в сервелете для обертывания данных из объекта в XML. Сетеры нет, если я где и сказал об этом я имел в виду что гипотетически их можно использловать объявив protecte и только внутри объекта, т.к. согласно принятому нами каркасу классы Модели не должны иметь открытых методов setXxx().
Третий вопрос я не доконца понял, но все отвечу, что сервлет ожидает класс Model и соотвественно ни чего неломая можно Object передать и все будет корректно.
Т.к. хотелось собрать в рамках одного класса все обращения к DAO, это реально упростило код т.к. в одном месте можно было сразу увидить все обращения к DAO и упростило проверку доступов у пользователей для выполнения данного действия, т.к. в класс Object определен единный механизм для всех операций.
И что эти гетеры и сеттеры делают, когда их вызывают? возвращают и устанавливают значение конкретного свойства объекта
В принципе вместо
public void edit(Model model) { ....}
можно написать
public void edit(long newN, long newName, long newId, ....)
я передал в метод edit модельку чтоб не усложнять сигнатуру метода большим количеством параметров, оберткой данной структуры и является класс Model
Здравствуйте, Tourist, Вы писали:
T>Здравствуйте, Бодхисатва, Вы писали:
Б>>Ответь мне на следующий вопрос: зачем нужны эти геттеры и сеттеры этому объекту? И зачем его надо приводить к типу Model, когда объект этого типа и так передаётся параметром? Почему DAO сразу нельзя его передать? И что эти гетеры и сеттеры делают, когда их вызывают? И как они связаны с параметром метода edit?
T>Гетеры используются в сервелете для обертывания данных из объекта в XML. Сетеры нет, если я где и сказал об этом я имел в виду что гипотетически их можно использловать объявив protecte и только внутри объекта, т.к. согласно принятому нами каркасу классы Модели не должны иметь открытых методов setXxx(). T>Третий вопрос я не доконца понял, но все отвечу, что сервлет ожидает класс Model и соотвественно ни чего неломая можно Object передать и все будет корректно. T>Т.к. хотелось собрать в рамках одного класса все обращения к DAO, это реально упростило код т.к. в одном месте можно было сразу увидить все обращения к DAO и упростило проверку доступов у пользователей для выполнения данного действия, т.к. в класс Object определен единный механизм для всех операций. T>И что эти гетеры и сеттеры делают, когда их вызывают? T> возвращают и устанавливают значение конкретного свойства объекта
T>В принципе вместо T>public void edit(Model model) { ....} T>можно написать T>public void edit(long newN, long newName, long newId, ....) T>я передал в метод edit модельку чтоб не усложнять сигнатуру метода большим количеством параметров, оберткой данной структуры и является класс Model
На солкько я понял, сервлет принмает Model, DAO работает с Model, всё работает с Model, он даже параметром в edit передаётся. Единственное, что я не понимаю, почему это model? котрый и так везде гуляет не передавать всем в качестве параметра без всяких гемороев? ) Иначе, чтобы передавать везде Object надо в методе edit сначала установить все проперти объекта класса Object в соответсвии со значениями соответственных пропертей параметра метода edit. На фиг это надо — я не понимаю ) Единственный вариант, когда сервлет создаёт объект класса Object, сразу же его заполняет данными из формы и потм говорит ему edit, но опять же, без параметров )
В общем теперь полностью понятно, что это типичный паттерн Data Transfer Object. А по паттерну надо чтобы класс Object принимал в конструкторе model и умел отдавать модифицированный model, а не наследовался от него )
Здравствуйте, Tourist, Вы писали:
T>главная суть классов Object — они расширают классы Model конкретными операциями над данными сущностями которые описывают классы Model.
T>и возник спор, что нельзя абсолютно в данной ситуации использовать наследование или можно (мое imho даже предпочтительней )
T>плюсы наследования: T> 1. можно привести тип класса Object к классу Model, и соответсвенно скрыть операции над объектом, когда нужен только один интерфейс к данным объекта (при обертывании данных в XML мне нужны только get) + не надо не чего переписывать так как старым методам мы возвращаем прежний Model
Очень похоже на архитектуру наследования в GUI: MenuItem -> Menu. Где класс Menu — наследник MenuItem.
Б>На солкько я понял, сервлет принмает Model, DAO работает с Model, всё работает с Model, он даже параметром в edit передаётся. Единственное, что я не понимаю, почему это model? котрый и так везде гуляет не передавать всем в качестве параметра без всяких гемороев? ) Иначе, чтобы передавать везде Object надо в методе edit сначала установить все проперти объекта класса Object в соответсвии со значениями соответственных пропертей параметра метода edit. На фиг это надо — я не понимаю ) Единственный вариант, когда сервлет создаёт объект класса Object, сразу же его заполняет данными из формы и потм говорит ему edit, но опять же, без параметров )
Б>В общем теперь полностью понятно, что это типичный паттерн Data Transfer Object. А по паттерну надо чтобы класс Object принимал в конструкторе model и умел отдавать модифицированный model, а не наследовался от него )
будем считать что убедили
последний вопрос, не хочу показаться не грамотным, где можно почитать про Data Transfer Object, боюсь я с ним не знаком ( а может и знаком это оно (может тогда появятся другие аргументы),
а так class Object еще можно расматривать как прокси, взглянув еще раз, пришел к выводу что он выполнят единственную функцию контролирует доступ к методам DAO для изменения какой-то сущности в б.д.
да, более всего нам подходит взгляд со стороны реальной жизни.