Re: Наследование vs композиции
От: arsena  
Дата: 21.07.04 16:51
Оценка:
Здравствуйте, 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;}
является ИМХО неудачным с точки сокрытия реализации.....
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.