Удобный способ декларации свойств

[tenshi]

Удобный способ декларации свойств

Следите за руками:

class Divider extends ProtoObject {

    protected $_divident; 
    protected $_divisor;

    protected $_result;
    function set_result( $val ){
        throw new Exception( 'result is autogenerated property' );
    }
    function get_result( $val ){
        return $this->divident / $this->divisor;
    }

}

$div= new Divider;
echo $div->divident( 6 )->divisor( 3 )->result;

Подробнее тут: http://habrahabr.ru/blogs/php/95233/

Как вам такое задание свойств? Используете ли вы свойства в своих классах и как их определяете?

 

[grigori]

отношение зависит от целесообразности
с какой целью ты это делаешь?

если красоты ради - глупость

 

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

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

 

[Raziel[SD]]

Какой практический смысл, кроме сомнительной красоты ?

 

[tenshi]

отношение зависит от целесообразности
с какой целью ты это делаешь?

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

-~{}~ 02.06.10 19:11:

Автор оригинала: triumvirat
я правильно понял, что автор хочет к каждому свойству создавать свой метод с уникальной для этого свойства логикой?

не для каждого, а для тех, которым это необходимо

 

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

у меня модель устроена наверно таким образом: если происходит обращение к несуществующему сеттеру или геттору, то вызывается __call, где определяется имя свойства, к которому надо присвоить (или взять) значение:

$object->setUserName('vasya');
// такого метода нет, на самом деле мы делаем
// $this->user_name = 'vasya';

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

class Model..
    public function setUrl($url)
    {
        // строка 'http://' приходит из POST т.к. 
        // часто стоит по умолчанию в html
        $this->url = $url === 'http://' ? NULL : $url;
    }

 

[tenshi]

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

-~{}~ 02.06.10 20:26:

        // строка 'http://' приходит из POST т.к. 
        // часто стоит по умолчанию в html

лучше не писать мусор в поле, а положить под него див с подсказкой.

 

[grigori]

Автор оригинала: tenshi
что делаю?

кто здесь?

реализую поддержку свойств? ну как бы инкапсуляция и всё такое.

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

почему реализую именно так?

меня интересует соблюдение принципа "Бритвы Оккама"
чем обосновано усложнение

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

зависит от "стандарта" - ты про какой?
для меня стандарт - это явное описание сеттеров и геттеров

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

не для каждого, а для тех, которым это необходимо

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

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

 

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

в случае опечатки никто не ругнётся на несуществующее свойство

у меня ругается

иде-шка не подсказывает имена несуществующих полей

ну извините....

для меня стандарт - это явное описание сеттеров и геттеров

замучаешься их описывать, ИМХО.

 

[grigori]

>замучаешься их описывать, ИМХО.
IDE это делает автоматически ... afaik

 

[tenshi]

нестандартно реализуешь маскировку полей объекта, причем неясно - за магическими методами, или как ...

а стандартно - это как? классовая иерархия построенная от ProtoObject будет везде иметь такую маскировку и как раз использование других схем будет "не стандартным".

к инкапсуляции отношения не имеет - это просто API класса, стиль кодинга и дело вкуса

если объект не может контролировать доступ к полям извне, то это нарушение инкапсуляции, ибо стандартный объектный апи (об этом позже) позволит поломать внутреннюю структуру данных. поэтому надо иметь возможность перехватывать обращения к ним и как следствие скрывать.

меня интересует соблюдение принципа "Бритвы Оккама"
чем обосновано усложнение

лучше част потерять, зато потом за 5 минут долететь ;-) сложность тут только в непривычности. однако выиграем мы в удобстве использования, наглядности и гибкости.

зависит от "стандарта" - ты про какой?
для меня стандарт - это явное описание сеттеров и геттеров

про этот:
$obj->count= 123;
echo $obj->count;
$obj->count+= 5;

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

это замечание касалось стандартного механизма с использованием только лишь __get и __set

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

почему?

-~{}~ 02.06.10 21:43:

у меня ругается

значит ты где-то указываешь какие проперти определены. где?

-~{}~ 02.06.10 21:53:

Автор оригинала: grigori
>замучаешься их описывать, ИМХО.
IDE это делает автоматически ... afaik

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

 

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

значит ты где-то указываешь какие проперти определены. где?

в классе модели

 

[tenshi]

это как бы очевидно. может ты пример нарисуешь?

 

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

а есть смысл? это велосипед, который не заслуживает ни критики, ни оценки. он попросту сырой.

http://adverts.ru/codes/kernel/Module/User/Model/User.php

 

[AmdY]

новый тип - говнокод от любителей jQuery.
автокомплит даже с помощью property не прикрутишь.
забыл передать параметр - получи evil баг.

какой плюс такого подхода, когда сеттер с гетером объеденные в один метод?

-~{}~ 02.06.10 21:32:

triumvirat
для связанных сущностей заведи подклассы OnoToOne OneToMany

'user_phone' => array('type'=> 'OneToMany', 
// тип свойства                             
'content_type'=>'Module_User_Model_UserPhone', 
// допустимый тип объектов
),

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

 

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

для связанных сущностей

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

 

[AmdY]

всё это ОРМ - утопия, но хорошо годится для быстрой разработки, особенно админки, а всё остальное - только ручками. вот простой абстрактный метод для грубого извлечения связей 1-* и т.д. - очень удобно иногда. сейчас дальше простенького table data getway стараюсь не лезть, спасибо Ирокез надоумил отказаться от доктрины.

 

[tenshi]

Автор оригинала: triumvirat
а есть смысл? это велосипед, который не заслуживает ни критики, ни оценки. он попросту сырой.

http://adverts.ru/codes/kernel/Module/User/Model/User.php

ты в каждом чтоли классе заново задаёшь этот массив с декларациями свойств? о_0"

 

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

ты в каждом чтоли классе заново задаёшь этот массив с декларациями свойств? о_0"

в каждом классе модели. что значит "заново"? есть класс user, у него есть массив описания свойств.

 

[grigori]

>лучше част потерять, зато потом за 5 минут долететь ;-)

пилите, Шура, пилите
все с Вами ясно, нам не по пути

-~{}~ 02.06.10 23:16:

AmdY
неплохая идея на тему lazy load для сложных типов данных в поле
только писать обработку влом

-~{}~ 02.06.10 23:21:

triumvirat
не лучше ли типы объектов описывать через константы?
'visitdate' => array(bModel::type=>bModel:bject, bModel::fieldName=>'user_visitdate')

да, кстати, а не влом писать эту китайскую копипасту?