наследование стандартных объектов PHP

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

Мне понадобилось создать класс, расширяющий Datetime - My_Datetime. Изменения коснулись лишь одного конструктора.

Но вызывая код

$date = My_Datetime::createFromFormat(...);

print_r($date);

я получаю не объект моего класса My_Datetime, а стандартный объект типа Datetime:

DateTime Object ( [date] => 1985-03-01 00:00:00 [timezone_type] => 3 [timezone] => Europe/Lisbon )

разве это правильное ОО-поведение? И как мне добиться того, что бы стандартные методы расширенного объекта My_Datetime возвращали экземпляры My_Datetime, а не Datetime?

 

[A1x]

никак. для пользовательского родительского класса можно было бы применить LSB а тут не получится.
Используй агрегирование

 

[Ragazzo]

http://php.net/manual/en/language.oop5.static.php
на всякий случай там в примерах

 

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

http://php.net/manual/en/language.oop5.static.php
на всякий случай там в примерах

я не догоняю. ткни носом, куда смотреть?

 

[Ragazzo]

я не догоняю. ткни носом, куда смотреть?

Я походу не понял что тебе нужно было, я имел ввиду модификатор parent...сорри...переработал)

 

[Вурдалак]

Уже ответили:

никак. для пользовательского родительского класса можно было бы применить LSB а тут не получится.
Используй агрегирование

 

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

как использовать агрегирование? я не догоняю.

 

[Вурдалак]

http://ru.wikipedia.org/wiki/Шаблон_делегирования

 

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

Я в курсе, что такое делегирование. Я не понимаю, в контексте этой задачи какую оно роль играет?

 

[Вурдалак]

Тебе предлагают объект класса DateTime пихнуть в объект твоего класса.

 

[A1x]

я имел в виду вместо наследования использовать агрегирование

 

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

решил так:

class Module_Common_Type_Datetime extends DateTime
{
    public function __construct($time = 'now', DateTimeZone $timezone = null)
    {
        if (null === $time || false === strtotime($time))
        {
            throw new Module_Common_Exception_BadValueGiven();
        }

        parent::__construct($time, self::getBugTimezone($timezone));
    }

    public static function createFromFormat($format, $time, DateTimeZone $timezone = null)
    {
        $datetime = parent::createFromFormat($format, $time, self::getBugTimezone($timezone));
        $this_instance = new self();
        $this_instance->setTimestamp($datetime->getTimestamp());
        return $this_instance;
    }

    /**
     * Bug #52063   DateTime constructor's second argument doesn't have a null default value
     * http://bugs.php.net/bug.php?id=52063&thanks=6
     */
    private static function getBugTimezone($timezone)
    {
        return null === $timezone
               ? new DateTimeZone("Europe/Moscow")
               : $timezone;
    }
}

 

[A1x]

под коньяк получается термоядерный говнокод, помню по себе но стараюсь такое не практиковать

 

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

никакого говнокода. я пишу убийцу Доктрины

 

[A1x]

Доктрина уже точит нож чтобы самой перерезать себе горло

 

[Вурдалак]

triumvirat, скажи, пожалуйста, какой смысл в твоём коде несёт переопределение метода DateTime::createFromFormat()?..

 

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

Вот поэтому и пишу. Технология, которой я занимаюсь будет называться Object Relation Syntactic Sugar (ORSS) , главной идеологией которой будет сохранение гибкости SQL, но любой результат на основании карты модели будет являться объектом, инкапсулирующим логику домена. ORM с ей сложностью должно будет уйти в прошлое.

 

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

triumvirat, скажи, пожалуйста, какой смысл в твоём коде несёт переопределение метода DateTime::createFromFormat()?..

он возвращает объект моего собственного типа. Мне это необходимо для стандартизации и корректной работы моей сложной системы - Object Relation Syntactic Sugar (ORSS).

 

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

Я сейчас на работе работаю с доктриной. А точнее - пляшу около ПК с бубном и выстукиваю результат. Меня удручает та сложность, с которой приходится сталкиваться.
Я много думал над ORM и пришел к выводу, что это фактически утопия. SQL очень гибок, но сухие данные, возвращенные SQL запросами, меня лишали гибкости ООП. А поскольку работа с CRUD в вебе - основная часть, я решил упростить себе жизнь - я понял, что любую строку таблицы данных, имеющую PK, нужно представлять в программе как объект, который будет обернут тем самым Syntactic Sugar - логикой домена этих строк. И не больше. А что бы совсем упростить себе жизнь, я придумал подход, позволяющий создавать свои собственные типы данных в рамках одной модели. Например, тип Datetime, тип Email и т.д. Даже могу Int тип ввести, если захочу и это тоже будет Syntactic Sugar над полем таблицы (свойством модели). Syntactic Sugar из логики над сущьностями дает по меньшей мере удобный интерфейс для программирования. Ну и легкость валидации данных, CRUD операции...

Всё. Пошел допивать коньяк.

 

[korchasa]

А разве в доктрине этого нет?
В onPHP - http://habrahabr.ru/blogs/php/94972/ (см. meta)
В Limb - http://wiki.limb-project.com/doku.php?id=limb3/ru/packages/active_record/value_objects