Как называется подход в ООП?

[Screjet]

http://snaps.php.net/

 

[_RVK_]

Screjet
сеньк

 

[algo]

По поводу геттеров-сеттеров.

Их наличие позволяет указать разные уровни доступа для чтения и записи переменной.
Например, protected set / public get. Т.е, писать может только сам объект, читать - кто угодно.

Предложенная реализация через __set/__get обеспечивает возможность перехвата операций чтения/записи - это замечательно.
Но как специфицировать, какие уровни доступа имеют эти операции ?

 

[whirlwind]

> И, в этом случае, применения getter/setter будет излишним.

getters/setters рулят, особливо в PHP и иже с ним

class foo{
    var $bar;
    function bar($v){
      $this->bar = $v;
   }
}

$ref = new foo;

$ref->bur = 1;
$ref->ber = 2;
$ref->bbar = 4;

$ref->bar(2);
$ref->bbur(1);

результат на лице


> Этот вопрос сродни использовать @ или нет.
Уволил бы программера, который забудет собаку на коннекте к БД...

 

[_RVK_]

>Уволил бы программера, который забудет собаку на коннекте к БД..

Я бы сам уволился если бы меня заставляли собаку на конекте ставить....

-~{}~ 21.11.05 16:44:

И перечитай топик, особенно примеры фиксера.

 

[whirlwind]

Перечитывал, перечитывал, но что то цимуса не уловил... В чем же преимущество "без проблем модифицируется" перед "изначально упорядочено"?

А по поводу коннектов и собак... Дык ИМХО лучше труднонаходимый баг, чем хакер в базе. Видать не было случая заценить, завидую...

PS. Трэк еррорс рулит.

 

[_RVK_]

>PS. Трэк еррорс рулит.

Рулит dispaly_errors. А еще рулит возможность посмотреть ошибки в логах. А собака не даст записать в лог. Так что безопаснее?

ЗЫ. Сколько же невинных программистов пострадали от недостаточных знаний матчасти начальством

 

[whirlwind]

Безопаснее переопределить обработчик ошибок и слать в лог необходимый максимум, а на экран давать отлуп для вида. И display_errors тут совсем не рулит, особенно когда какой нить pg_connect выкидывает куда и под каким юзером бедный пхп не может коннектнуться. Обычному кастомеру эта инфа не нужна, а вот всякие нехорошие непреминут этим воспользоваться.

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

 

[_RVK_]

whirlwind
Эта тема не о собаке. Поищи на форуме, тут все хорошо описано, и разжевано. В крайнем случае создай новую тему. А то наверное многие соскучились

 

[whirlwind]

И правда, че эт я Возвращаясь в топик...

Я к тому, что установка несуществующего атрибута пройдет безболезненно, а вот вызов несуществующего метода - это ошибка, которую сразу исправят. Когда проект большой это очень даже имеет значение. Да и потом, в ОРМ вообще без геттеров/сеттеров ну никак

PS. Какие нафик мэджики могут быть, если к примеру с 5.0.4 на + такой геммор со ссылками. А правильно говорят - нефик жаловаться, надо было писать нормально.

 

[_RVK_]

whirlwind
Ну не хочется мне сейчас пречитывать топик полугодичной давности за тебя. Там же фиксер привел прикрасный пример с использованием _set/_get методов, кторые срабатывают на факт отсутствия переменной класса. В них ты можешь выводить любые ошибки и другую информацию при попытке достува к несуществующей (а в php 5.1.x и недоступной) переменной класса.

 

[whirlwind]

Да видел я этот код... Я одного не пойму - зачем что то еще писать, если все прекрасно работает и так? Или чем больше хинтов, тем круче программер? Назови пожалуйста хотя бы одну причину, по которой в наше время необходимо жертвовать прозрачностью кода в угоду скорости?

ИМХО, ООП - это прежде всего методы и все, что к ним привинчено. Если нужны исключительно атрибуты, надо юзать структуры, хэши, etc... Для атрибутов наследование - это обычный структурный юнион.

 

[_RVK_]

Для того что бы не писать для каждой переменной еще и по 2 метода. Скорость тут непричем.

Тут что-то было сказано про ORM. Так представь себе, у меня присвоение $orm_object->some_field = some_value; работает прекрасно. А учитывая что набор полей все время меняется, мне не приходится для каждого писать свои гетеры/сетеры

-~{}~ 21.11.05 19:26:

Меня абсолютно не вдохновляет этот спор. Так как полгода назад я был на твоем месте(правда я не придлагал писать по 2 метода а предлагал использовать __call) и признал свою ошибку. Ты тоже признаешь если внимательно перечитаешь топик.

 

[whirlwind]

> А учитывая что набор полей все время меняется, мне не приходится для каждого писать свои гетеры/сетеры

Ща опять в офф унесет

Сдается мне прелесть ОРМ не в some_field = some_value, а в some_field = some_object. Как у тебя будет выглядеть выражение с объектом в левой части, я представляю смутно. Мне упорно мерещится что getAttribute/setAttribute в базовом классе и трансляторы ака геттеры/сеттеры все же эффективнее.

 

[_RVK_]

Можешь оставаться при своем мнении. Ты мне напоминаешь одного моего начальника, слава богу бывшего. Ему и RFC не догма была. Он оправдывался тем что этот RFC был написан в 1998 году и теперь устарел. А он знает как надо делать.

 

[whirlwind]

Не, ну интересный Вот наглядный пример

class orm_object{
    private $hash;

    function getAttr($name){
        return $this->hash[$name];
    }

    function setAttr($name,$v){
        $this->hash[$name] = $v;
    }

    function getById($id){
        return $this->hash = $this->fetchhash("SELECT * FROM orm_object WHERE id=$id");
    }
}

Тут много чего нет, но эти элементарные действия избавляют тебя от работы с атрибутами вообще как таковыми. И меняй таблицы сколько влезет.

PS. Ну ладно, при своем, так при своем...

 

[_RVK_]

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

 

[algo]

Создание геттеров-сеттеров это большое количество лишнего кода.

Для PHP нет нормального IDE, так что поддерживать и модифицировать их - несколько раздражает.

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