Нужно ли создавать отдельный класс?

[FB3]

Нужно ли создавать отдельный класс?

К примеру, имеется автомобиль, пока мы его не приобрели, то у него есть свойство Цена, мы можем его посмотреть с помощью методов типа Открыть дверь, Открыть багажник и т.п.
После того, как мы его приобрели, то у него могут появляться новые свойства и методы. Например, свойство Кол-во бензина в баке и методы Заправить бензин, Помыть и т.д. Исчезает не нужное свойство Цена, так как появляется свойство Рыночная цена.

Т.е. фактически функциональность классов разная, но предмет то один. Вот и мучает меня иногда вопрос, должны ли это быть разные классы или второй класс должен наследовать первый? Или еще как-то? Пока писал, подумал, что может быть пример не очень удачный выбрал, но навскидку в голову не приходит, как бы можно было получше объяснить.

 

[Ragazzo]

Предчувствую большой срач...погодите щас HraKK придет, и понесутся дискуссии про ООП =)

 

[Вурдалак]

Я так понимаю, что это пример, высосанный из пальца.

 

[AmdY]

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

 

[cDLEON]

FB3
Когда ты купишь машину и друзья у тебя спросят: "сколько она стоит ?", ты пойдёшь звать оценщика, что бы назвать цену?
Мне, кажется, можно ли "заправить" и т.д. должно решаться за счёт разграничения прав доступа. Ведь заправить можно и машину в магазине ) Наглость - второе счастье =)))
Естественно иногда лучше использовать наследование, иногда - делегирование.

 

[vasa_c]

Это интерфейсы, один и тот же объект предоставляет объекту-хозяину и объекту-прохожему разные интерфейсы

А вообще объяснять ООП на примерах автомобилей, людей-студентов-преподавателей никогда ни к чему хорошему не вела.

 

[itprog]

даа, лучше на кошках
хотя подождите, кошку тоже надо кормить и мыть!
> Это интерфейсы, один и тот же объект предоставляет объекту-хозяину и объекту-прохожему разные интерфейсы
э, чо?

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

 

[vasa_c]

> Это интерфейсы, один и тот же объект предоставляет объекту-хозяину и объекту-прохожему разные интерфейсы
э, чо?

Автомобиль, как был автомобиль, так тем же автомобилем и остался.
А "помыть", "заправить" это из интерфейса, который он предоставляет хозяину )

 

[korchasa]

vasa_c
Неа. Во-первых "помыть" и "заправить" вообще не часть его интерфейса. Во-вторых, если рассматривать ситуацию с открыванием двери, то смена состояния происходит по приему сообщения "разблокировать дверь", ну или "снять с сигналки" в случае центрального замка. Интерфейс же при это не меняется.

 

[FB3]

Вот другой пример, ближе к реальному.
В игре есть предметы, которые можно приобрести в магазине. Пока игрок не приобретает предмет, то предмет имеет только свойства для отображения в магазине и не должен иметь никаких методов, кроме как для доступа к этим свойствам.
После покупки у предмета появляется уникальный id (например первичный ключ из таблицы в БД). То есть фактически создаем экземпляр класса. Получается, что нужные статические свойства и методы, которые нужны для отображения предмета в магазине без создания экземпляра класса и не статические свойства и методы, которые могут быть вызваны после приобретения в игре этого предмета?

 

[grigori]

lazy load

 

[FB3]

grigori, не понял, к чему оно здесь...
Я не про загрузку данных, а про классы и интерфейсы...

 

[grigori]

Автор оригинала: FB3
Я не про загрузку данных, а про классы и интерфейсы...

у предмета появляется уникальный id (например первичный ключ из таблицы в БД).

стою на асфальте я в лыжи обутый?

-~{}~ 28.09.10 15:40:

ладно, еще раз медленно
товар - объект, список товаров - коллекция
вывод списка - отрисовка небольшого кол-ва данных
чтобы не грузить полные объекты, реализуешь через Lazy Load (Value Holder/Ghost)

 

[FB3]

Ну я бы хранил список товаров со свойствами, которые продаются в магазине, в отдельной таблице или вообще не в таблице, поскольку это небольшой объем информации.
А список купленных товаров в другой таблице, где уникальный id первичный ключ, владелец - id владельца и т.д.

Может я про первичный ключ объяснил не так?

 

[grigori]

а как у тебя список представлен в php - 2-мерным массивом?

 

[Crys]

Пока игрок не приобретает предмет, то предмет имеет только свойства для отображения в магазине и не должен иметь никаких методов, кроме как для доступа к этим свойствам.

То есть игрушечный вертолет после покупки может научиться стирать носки?

 

[grigori]

я думаю, ТС просто пытается придумать, как работать с объектами, не отказываясь от привычного 2-мерного массива с данными их базы

 

[FB3]

Автор оригинала: grigori
а как у тебя список представлен в php - 2-мерным массивом?

Сейчас да, поэтому и спрашиваю Правда к этому массиву имеется интерфейс в виде класса.

Crys, нет, не может. Не понял, к чему это опять же.

Взять любой интернет магазин, там есть каталог товаров. В каталоге есть описание товаров, их цена, кол-во на складе. После того, как осуществляется заказ и оплата, в базу данных пишем в одну таблицу заказ, в другую таблицу список вещей в заказе с их уникальными серийными номерами и id принадлежности к определенному заказу. То есть, к примеру, конкретный монитор с конкретным серийным номером относится к определенному заказу. Но в этой таблице нам совершенно пофиг на его свойства из каталога, в том числе и на кол-во еще таких мониторов на складе. Тем более что в каталоге со временем и цена может поменяться, а в заказе она уже не изменится.
В итоге один и тот же товар (в данном случае монитор) - это разные сущности в ООП получаются?

-~{}~ 28.09.10 17:45:

Автор оригинала: grigori
я думаю, ТС просто пытается придумать, как работать с объектами, не отказываясь от привычного 2-мерного массива с данными их базы

Скорей всего да, я еще сам не понимаю до конца

 

[grigori]

в ООП каждая запись при выборке представляется объектом
Value Object
Row Data Gateway

 

[Crys]

В итоге один и тот же товар (в данном случае монитор) - это разные сущности в ООП получаются?

Да, потому что это в корне разные вещи..

Куча мониторов на "Складе" - это коллекция объектов "Монитор", куча мониторов в прайс-листе - это объект "Прайс-лист" с описанием каких-то товаров. В первом случае мы можем из коллекции выбрать объект "Монитор", во втором случае мы должны пойти на "Склад", чтобы выбрать нужный объект. Но по связи (тот же серийный номер) мы можем для конкретного "Монитора" узнать информацию из прайс-листа (цена, гарантия, производитель). Также по информации из "Прайса" мы можем на "Складе" найти нужный монитор.