Меню
Что нового?

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

Да, с трейтами такие штуки оч хорошо будут получаться. А если по теме, то наследовать Registry и Session от какого-то Data - плохое решение: они очевидно друг с другом не связаны и не должны быть в одной иерархии наследования - это раз. А два - класса Data вообще не должно быть - это как класс Object, который постоянно появляется в коленочно-самописных ЦМСках. И это явный пример антипаттерна God-object, который с какого-то хрена почему-то знает, что нужно всем его многочисленным потомкам (явно, так сказать, от разных матерей).
 
не должны быть в одной иерархии наследования - это раз
Нажмите для раскрытия...
не должны, но копипастить код не хочется/

это как класс Object, который постоянно появляется в коленочно-самописных ЦМСках
Нажмите для раскрытия...
от того видно и появляется, что нужен часто. А идея класса Data на самом деле простая - объектный НОРМАЛЬНЫЙ массив. Как во всех нормальных языках программирования.
 
Есть класс Registry и Session, которые должны быть унаследованы от класса Data
Нажмите для раскрытия...
Заменить наследование делегированием или реализацией общего интерфейса.
Всё остальное, имхо, будет костылями.
 
triumvirat
есть одно простое правило "если получается сложно - значит это не правильно". выбрось реестр, выбрось статические методы - они нелогичны, всё что не передаётся явно в конструктор или нельзя получить методом $this->get<Объект>() - всё вон, это неявно и плохо. пожалей коллег, которые будут писать код, пожалей свою память.
 
всё что не передаётся явно в конструктор или нельзя получить методом $this->get<Объект>() - всё вон, это неявно и плохо
Нажмите для раскрытия...
где прикажете хранить мелкие настройки программы- пути, соль, email-адреса роботов и т.д.? В глобальной области видимости?

И почему такое утверждение? Вон, livestreet так хранит настройки: Config::Get('path.root.server')

Чем это хуже чем через Registry::getInstance()->path['root']['server'] ?

Заменить наследование делегированием
Нажмите для раскрытия...
как это, поясни на примере.
 
Через делегирование не всегда получается сделать красиво, увы.

Один из частых примеров - реализация какого-либо достаточно частоиспользуемого общего интерфейса, типа IDatasource. Приходится плодить кучу методов, которые хоть и коротенькие, но все делают одно и тоже, или делегировать все это некоему ValueObject-у.

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

Тут traits очень в тему. Надеюсь, что trait может реализовывать интерфейс без побочных эффектов :) (да, я ленивая сволочь и еще не собирал из транка и не тестил, просто рассуждаю вслух, но - как то уже привык, что в php часто выходит "как всегда"...).
 
В общем fixxxer меня убедил :) Я вот только не понял каковы перспективы у traits? Сейчас оно существует как отдельный пропатченный php... Есть какие-либо надежды?
 
Это значит, что оно появится в следующем крупном релизе (5.4), если не передумают (то есть, не вылезет что-то страшное, что все ломает).

Шансы на появление в 5.3.х примерно нулевые - так как добавлено зарезервированное слово (и сломаются скрипты, которые, например, содержат функцию trait).
 
Войдите или зарегистрируйтесь для ответа.
Сверху