Наследование vs Агрегация

[Long]

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

 

[HraKK]

Еще и Agile за это

 

[zerkms]

кстати да, хороший аргумент выше от Scud. Вариант с аггрегацией добавляет дополнительный контроль над типами данных.

 

[Scud]

Long Я не буду это делать через addMarker(), наследуясь от TheRegistry вы предоставили мне методы register/unregister, которые тип не проверяют.

 

[Long]

zerkms, сеттеры и геттеры переопределяются в cMarkersBox (расширяют базовые) - это разве нарушает принципы наследования?

а в чем проблема с тем, чтобы на полочке лежали не только маркеры?

 

[HraKK]

Если вы не уверены, что налицо отношение общего и частного (is а), вместо наследования лучше применить агрегацию или что-нибудь еще.

Гради Буч.

Думаю, на этом и закончим

-~{}~ 10.02.09 03:16:

сеттеры и геттеры переопределяются в cMarkersBox (расширяют базовые)

ничего у тебя там не переопределяеться.

 

[Long]

Scud, addMarker, если внимательно посмотреть на определение принимает только cMarker со всеми вытекающими

register/unregister - конечно же должны явно переопределяться в cMarkersBox.

 

[Scud]

Я говорил только о register/unregister, и они не были переопределены в первом сообщении, к тому же переопределить их на register($label, cMarker $value) уже нельзя - это нарушение интерфейса, так что придётся проверять instanceof'ом

 

[HraKK]

register/unregister - конечно же должны явно переопределяться в cMarkersBox.

Подожди? Как это "должны" у тебя они мало того что не переопределены, так еще и явно используется parent:: статический( что кстати вызовет вроде Strict error ) доступ к родителю так что твое переопределение тут ничего не даст, пока ты не поменяешь parent на $this->.

 

[Long]

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

 

[HraKK]

Long
Признай, уже

Бонусы тебе уже описали. Имхо, ложись спать завтра лучше со свежей головой прочитай заново спокойно)

 

[zerkms]

register/unregister - конечно же должны явно переопределяться в cMarkersBox.

зачем их переопределять? реализация cMarkersBox уже самодостаточна. другое дело - что она предоставляет средства для бесконтрольного доступа к данным. это решается:

1. изменением области видимости методов базового класса на protected. этот вариант перечеркнёт использование TheRegistry standalone.
2. аггрегацией

что выбирать - уже проблема программиста. я бы выбрал аггрегацию (точнее тут оно - делегирование)

 

[Scud]

Как раз таки агрегация + делегирование, TheRegistry ведь не синглтон.

 

[HraKK]

zerkms
Как по мне, он уже все сам понял но как и я порой не может признать своей ошибки, предлагаю лечь спать, а завтра продолжить, если будет такое желание)) Тем более уже есть новая тема)

 

[zerkms]

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

правильно. незачем. всю логику переносите в один класс. делаете методы доступа к данным приватными.

 

[HraKK]

всю логику переносите в один класс. делаете методы доступа к данным приватными.

Это было бы не плохим решением, но оно перечеркивается задачей)
ПЫСЫ задача хелло ворд ин паттрнс

 

[zerkms]

Это было бы не плохим решением, но оно перечеркивается задачей)
ПЫСЫ задача хелло ворд ин паттрнс

нууууу....... отнюдь не перечёркивается. академически хорошее решение содержит столько паттернов, сколько должно. это ведь не соревнование, кто сколько их знает и сможет уместить в 10 строк?

 

[HraKK]

Эм, ты не в теме. http://www.phppatterns.com/docs/design/hello_world_in_patterns
Это так называемый антипаттерн) Вот и тут он нужен.

 

[Long]

zerkms, изменение области видимости методов базового класса на protected - в таком случае мы теряем возможность напрямую работать с TheRegistry (создать объект этого класса).
уж лучше явно определить register/unregister в cMarkersBox - закрыть возможность их использования.
т.е. наследуем мы в данном случае не потому что это идеологически правильно (с точки зрения ооп), а потому что:
1. cMarkersBox специфичное, но все же хранилище. логично, что оно должно наследоваться от базового хранилища.
2. не нужно явно создавать объект.
3. как следствие 2 - полностью абстрагируемся от того, какое это хранилище.

предлагаю сойтись на том, что имеют право на жизнь оба подхода - в каждом есть свои плюсы и минусы.

 

[zerkms]

в таком случае мы теряем возможность напрямую работать с TheRegistry (создать объект этого класса).

я это указал ведь:

1. изменением области видимости методов базового класса на protected. этот вариант перечеркнёт использование TheRegistry standalone.

1. cMarkersBox специфичное, но все же хранилище. логично, что оно должно наследоваться от базового хранилища.

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

2. не нужно явно создавать объект.

вообще "академическое" ООП не очень хорошо относится к статике. статика только портит код своей "статичностью".

3. как следствие 2 - полностью абстрагируемся от того, какое это хранилище.

эм... для замены хранилища в случае наследования тебе нужно будет поменять предка, extended NewStorage. это - поломает уже работающий код, если ты в тайпхинтах использовал TheRegistry.
к тому же - вариант с делегированием позволит хранилище вообще параметризировать и менять его по запросу/аргументу конструктора.