вопрос по архитектуре (конфликт доступа конструкторов)

[Духовность™]

вопрос по архитектуре (конфликт доступа конструкторов)

Поскольку реальный код сложноват, опишу все абстрактно.

Есть класс Data содержащий конструктор типа public.

Есть класс Registry и Session, которые должны быть унаследованы от класса Data. Но конструктор у них должен быть private, ибо эти классы реализуют одиночку. Соответственно объявление private конструктора у этих двух классов вызывают Fatal error: Access level to Registry::__construct() must be public (as in class Data)

Как быть?

 

[Dovg]

Рождай в конструкторе исключение, например.

ps. А зачем они наследуют Data?

 

[Adelf]

[тут было тоже самое что и в посте выше]

 

[Духовность™]

Рождай в конструкторе исключение, например.

т.е. прерывать с ошибкой? (

ps. А зачем они наследуют Data?

Data реализует ArrayAccess, магические методы и кучу всего остального - объектный массив, короче, методы которого очень не хочется дублировать в Registry и Session

 

[Dovg]

А приватный конструктор разве не "прервет с ошибкой"?
У тебя тут на выбор только fatall error vs exception

 

[Adelf]

Dovg
Некрасиво получается. Эксепшен, который гарантированно сгенерится - бред.
Можно хотя бы сделать приватное статическое поле, и юзая как флаг внутреннего создания, не генерировать эксепшен в случае создания из своего getInstance.

А вообще, все сложности из-за наследования от Data Он хоть абстрактный?

 

[Духовность™]

Я вот думал, а правильно ли будет ввести какой-то промежуточный класс - тот же Data, но без публичного метода? Или это уже костыли?

-~{}~ 06.09.10 18:50:

А вообще, все сложности из-за наследования от Data Он хоть абстрактный?

нет, он реальный. и он наследуется от другого абстрактного

 

[Adelf]

triumvirat
ну твоя мысль правильная вроде. Делать AbstractData с функционалом, из-за которого ты решил наследовать тех двух товарищей от Data, а Data и остальные от него.

 

[Духовность™]

Adelf
минус данного подхода в том, что мы жертвуем реализацией родителя ради одной конкретной проблемы у потомка! Не кажется ли тебе это очень плохой практикой?

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

 

[Adelf]

triumvirat
Родителя можно было создавать напрямую. Потомка нет. Это уже неправильная ситуация, которая в итоге потребовала исправления родителя.
Нельзя делать что-то приватным, что до этого в родителе было публичным. Я не сильно разбираюсь в канонах, но уверен, что это что-то там нарушает Твой случай как-раз из-за этого и возник. В родителе можно, а у потомка почему-то нельзя. Как итог, более правильная иерархия, где такого конфликта уже нет.

 

[weregod]

как вариант:
в родителе вынести инициализацию в метод init(), оставив конструктор пустым, в наследнике при вызове init-а фаталить

 

[tz-lom]

вызывай в конструкторе trigger_error , со стороны вообще никакой разницы не будет PHP ругнулся ли на приватный конструктор,или ругнулся принудительно

 

[Adelf]

tz-lom
Создавать объект один раз все равно придется. Не надо никаких error.

 

[AmdY]

выбрось одиночку нафик и не будет гемороя

 

[Духовность™]

выбрось одиночку нафик

нельзя, это Session и Registry решения

В общем, я ввел промежуточный абстрактный класс Data_Abstract. Конкретный класс уже реализует конструктор так, как ему нужно.

 

[fixxxer]

Кстати, отличный пример случая, в котором очень в тему traits.

 

[Adelf]

fixxxer
На множественное наследование похоже. Только с дополнительными вкусностями типа различных кастомизаций использования treat.

Что-то мне не нравится в этой идее. Вроде бы давно такое хотелось, причем в любом ООП-языке, который использовал. Но... на душе, что называется, кошки скребут Какая-то чорная магия это.

 

[whirlwind]

А protected конструктор разве не канает?

 

[Духовность™]

А protected конструктор разве не канает?

в базовом классе Data он все равно нужен как public

 

[fixxxer]

>> Какая-то чорная магия это

Черная магия - это monkey patching в том же Ruby. А тут то все довольно строго получается, если с умом делать.