Лучшая практика: магические методы PHP __set и __get [дубликаты]

Возможный дубликат:
Являются ли магические методы лучшей практикой в PHP?

Это простые примеры, но представьте, что в вашем классе больше двух свойств.

Что было бы лучшей практикой?

а) Использование __get и __set

class MyClass {
    private $firstField;
    private $secondField;

    public function __get($property) {
            if (property_exists($this, $property)) {
                return $this->$property;
            }
    }

    public function __set($property, $value) {
        if (property_exists($this, $property)) {
            $this->$property = $value;
        }
    }
}

$myClass = new MyClass();

$myClass->firstField = "This is a foo line";
$myClass->secondField = "This is a bar line";

echo $myClass->firstField;
echo $myClass->secondField;

/* Output:
    This is a foo line
    This is a bar line
 */

б) Использование традиционных сеттеров и геттеров

class MyClass {

    private $firstField;
    private $secondField;

    public function getFirstField() {
        return $this->firstField;
    }

    public function setFirstField($firstField) {
        $this->firstField = $firstField;
    }

    public function getSecondField() {
        return $this->secondField;
    }

    public function setSecondField($secondField) {
        $this->secondField = $secondField;
    }

}

$myClass = new MyClass();

$myClass->setFirstField("This is a foo line");
$myClass->setSecondField("This is a bar line");

echo $myClass->getFirstField();
echo $myClass->getSecondField();

/* Output:
    This is a foo line
    This is a bar line
 */

В этой статье: http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html

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

Во-первых, тогда было очень популярно использовать магические функции PHP (__get, __call и т. д.). На первый взгляд в них нет ничего плохого, но на самом деле они действительно опасны. Они делают API непонятными, автодополнение невозможным и, самое главное, они медленные. Вариант использования для них состоял в том, чтобы взломать PHP, чтобы делать то, чего он не хотел. И это сработало. Но сделал плохие вещи.

Но хотелось бы услышать еще мнения по этому поводу.


person rfc1484    schedule 31.05.2011    source источник
comment
(совет) GetterEradicator   -  person Gordon    schedule 31.05.2011
comment
(совет) Как удалить геттеры и сеттеры   -  person Gordon    schedule 01.06.2011
comment
Я согласен с тем, что __get медленнее пользовательской функции get (делает то же самое), это 0,0124455 времени для __get(), а это 0,0024445 для пользовательского get() после 10000 циклов.   -  person Melsi    schedule 24.11.2012
comment
этот вопрос (и ответы на него) гораздо более ценен, чем возможный дубликат. Особенно, если дубликат даже закрыт   -  person shock_gone_wild    schedule 29.11.2015
comment
@Gordon Этот вопрос действительно ценен, и он не является дубликатом «Являются ли магические методы лучшей практикой в ​​​​PHP?». Вы, как Zend Certified Engineer, должны понимать это очень хорошо. Плохая практика — закрывать действительно ценные вопросы по жалким причинам.   -  person Roman Podlinov    schedule 06.01.2016
comment
@Roman проголосуйте за открытие, если вы не согласны.   -  person Gordon    schedule 06.01.2016
comment
Я прошу сообщество поддержать этот вопрос и проголосовать за повторное открытие. Пожалуйста, проголосуйте за этот комментарий, если вы считаете, что этот вопрос ценен и должен быть открыт повторно. Если я увижу, что за него проголосуют более 10 человек, я снова открою этот вопрос.   -  person Roman Podlinov    schedule 06.01.2016
comment
@Roman, чего бы это ни стоило: вопросы о передовой практике слишком часто приводят к мнениям (как мы можем видеть в ответах ниже). Мы не любим такие вопросы в Stack Overflow. Поэтому связанный вопрос закрыт как неконструктивный. Сообщество могло тогда закрыть это как неконструктивное по той же причине. Вместо этого они решили подобрать обман, что дает ОП больше информации. Я думаю, что это достаточно хорошо. На заметку: я не знаю, почему вы выделяете и нападаете именно на меня. Я не закрывал его один.   -  person Gordon    schedule 06.01.2016
comment
@ Гордон извини за это :) не намеренно. Я несколько раз видел, что модераторам не нравятся вопросы Best Practice.   -  person Roman Podlinov    schedule 07.01.2016
comment
Это очень полезный вопрос, содержащий несколько очень твердых ответов. Дубликат не является ни тем, ни другим.   -  person Chuck Le Butt    schedule 01.06.2017
comment
Я только что провел несколько тестов. Интересно читать: pastebin.com/DdWKU5wp   -  person Chuck Le Butt    schedule 01.06.2017


Ответы (9)


Я был точно в вашем случае в прошлом. И я пошел на магические методы.

Это была ошибка, последняя часть вашего вопроса говорит сама за себя:

  • это медленнее (чем геттеры/сеттеры)
  • отсутствует автоматическое завершение (и это на самом деле серьезная проблема) и управление типами в среде IDE для рефакторинга и просмотра кода (в Zend Studio/PhpStorm это может обрабатываться с помощью аннотации @property phpdoc, но для этого требуется их поддерживать: довольно больно)
  • документация (phpdoc) не соответствует тому, как предполагается использовать ваш код, и просмотр вашего класса также не дает много ответов. Это смущает.
  • добавлено после редактирования: наличие геттеров для свойств больше соответствует «настоящим» методам, где getXXX() не только возвращает частное свойство, но и выполняет настоящую логику. У тебя такое же имя. Например, у вас есть $user->getName() (возвращает частную собственность) и $user->getToken($key) (вычисляется). В тот день, когда ваш геттер получает больше, чем геттер, и ему нужно выполнить некоторую логику, все по-прежнему непротиворечиво.

Наконец, и это самая большая проблема IMO: это волшебство. А магия — это очень и очень плохо, потому что нужно знать, как работает магия, чтобы правильно ею пользоваться. Это проблема, с которой я столкнулся в команде: все должны понимать магию, а не только ты.

Геттеры и сеттеры сложно писать (я их ненавижу), но они того стоят.

person Matthieu Napoli    schedule 31.05.2011
comment
Я думаю, что магические методы существуют не просто так... - person Adam Arold; 31.05.2011
comment
Хотя я согласен с вашим общим аргументом о том, что __get и __set не следует использовать для ленивых методов доступа, это неправда, что вы не можете получить для них автозаполнение. См. stackoverflow.com/questions/3814733/ о том, как это сделать. - person Gordon; 31.05.2011
comment
@Gordon: очень интересно, спасибо! Но работает ли это с Eclipse? - person Matthieu Napoli; 01.06.2011
comment
@stereofrog: Да, это именно так: с. Но я забыл упомянуть еще одну вещь: наличие геттеров для свойств лучше согласуется с реальными методами, где getXXX не только возвращает частное свойство, но и выполняет настоящую логику. У тебя такое же имя. Например, у вас есть $user->getName() (возвращает свойство) и $user->getToken() (вычисляется). - person Matthieu Napoli; 01.06.2011
comment
Я обновил свой ответ относительно комментариев. - person Matthieu Napoli; 01.06.2011
comment
ну, наличие $user-›name (обычный) и $user-›token (вычисляемый через __get) еще более последовательны, не так ли? - person user187291; 01.06.2011
comment
@Matthieu, я не уверен на 100%, но, учитывая, что он работает в Zend Studio, а Zend Studio основан на Eclipse, я бы сказал да. Оно работает. - person Gordon; 01.06.2011
comment
Токен @stereofrog, возможно, был не лучшим примером. Если я возьму $user->getNewPosition($direction, $speed), это будет более очевидно из-за параметров, которые не позволяют ему быть свойством. Но я согласен, что это также может быть $user->speed = 5; $user->move(); $newPosition = $user->position;... Это просто согласуется с методами, которые не могут быть свойствами, но это, вероятно, вопрос вкуса. - person Matthieu Napoli; 01.06.2011
comment
Единственное, с чем я действительно могу согласиться, это то, что они, вероятно, медленнее, чем геттеры/сеттеры, но во многих случаях это не имеет большого значения; что такое миллисекунда, если не используется часто? Вы можете получить автозаполнение (по крайней мере, в PhpStorm), установив @property PHPDoc, который также предоставляет документацию, и последний пункт о согласованности - это просто мнение, а мнения различаются (см. комментарий пользователя 187291.) Есть преимущество использования __get(), о котором не упоминалось AFAICT, и его свойства могут быть встроены в HEREDOC, но вызовы методов не могут. - person MikeSchinkel; 24.02.2013
comment
Я не согласен со вторым пулемётом. Почему поддержка документации @property может быть более сложной, чем написание отдельных геттеров и сеттеров? - person andrewtweber; 13.03.2015
comment
@andrewtweber Честно говоря, 4 года спустя я думаю, что последний пункт списка + волшебный аргумент в конце концов являются самыми важными. - person Matthieu Napoli; 14.03.2015
comment
@MatthieuNapoli, последний пункт списка - хороший момент, о котором я не подумал. Для меня основная проблема заключается в том, что при использовании интерфейсов вы можете принудительно использовать функции getName и setName, но вы не можете принудительно использовать свойство имени в любом классе, реализующем интерфейс. - person andrewtweber; 14.03.2015
comment
По вашему мнению, современные фреймворки, такие как Laravel, имеют совершенно плохой дизайн. Там много волшебства. Как простому пользователю этих фреймворков мне очень нравится интуитивно понятный способ доступа к данным, особенно в моделях. Как разработчик с большим интересом, я мог бы копнуть глубже и взглянуть на предоставленную магию. Во всех смыслах не плохо... - person shock_gone_wild; 29.11.2015
comment
Вы можете быть правы, но ваши причины невелики: вам нужно будет выполнить 10 000 действий, чтобы увидеть какое-либо замедление. Это не причина не использовать их большую часть времени. Автозаполнение тоже может работать нормально. Ответ @vbence - самый правильный ИМО. - person Chuck Le Butt; 19.04.2017
comment
Откуда вы знаете, что __get медленнее, чем использование функции получения? - person Marco Demaio; 24.12.2018
comment
@AdamArold, да, у магических методов есть веская причина. Вам нужно это в очень динамичном программном обеспечении, таком как magento, так что вам просто нужно запустить сценарий обновления базы данных, чтобы ваши новые атрибуты EAV добавлялись/удалялись в/из базы данных без необходимости какого-либо дополнительного программирования от вас, например. вам не нужно добавлять/удалять все геттеры и сеттеры после запуска скриптов базы данных. - person Black; 13.09.2019

Вам нужно использовать магию только в том случае, если объект действительно «магический». Если у вас есть классический объект с фиксированными свойствами, используйте сеттеры и геттеры, они отлично работают.

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

person vbence    schedule 31.05.2011
comment
Я согласен. Лучший ответ на данный момент. Не знаю, почему у него нет больше голосов. Делайте это так: $user->getFirstName() и используйте магию только тогда, когда это действительно необходимо. - person Jo Smo; 03.07.2014
comment
Великолепно. Объедините это с ответом пользователя 187291 выше, и все готово. - person Andrew; 13.02.2016
comment
Исходя из прекрасного мира скомпилированных, статически типизированных языков, я бы сказал, что если ваш объект находится на уровне базы данных и имеет динамические свойства, то мой голос будет за метод ->get($columnName): он дает понять, что то, что вы получаете, является чем-то динамичным. Волшебные методы — это всего лишь еще один уровень ужасности PHP, созданный, по-видимому, с единственной целью — заманить разработчиков в ловушки. Черты - это другое (боже, как они ужасны? - и все же насколько они подходят для остального ужаса в PHP) - person Daniel Scott; 04.10.2018

Я максимально использую __get (и публичные свойства), потому что они делают код более читабельным. Сравнивать:

этот код однозначно говорит, что я делаю:

echo $user->name;

этот код заставляет меня чувствовать себя глупо, что мне не нравится:

function getName() { return $this->_name; }
....

echo $user->getName();

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

echo "
    Dear $user->firstName $user->lastName!
    Your purchase:
        $product->name  $product->count x $product->price
"

и

echo "
    Dear " . $user->getFirstName() . " " . $user->getLastName() . "
    Your purchase: 
        " . $product->getName() . " " . $product->getCount() . "  x " . $product->getPrice() . " ";

Ответственность за то, должен ли $a->b действительно что-то делать или просто возвращать значение, лежит на вызываемом объекте. Для вызывающей стороны $user->name и $user->accountBalance должны выглядеть одинаково, хотя последнее может потребовать сложных вычислений. В моих классах данных я использую следующий небольшой метод:

 function __get($p) { 
      $m = "get_$p";
      if(method_exists($this, $m)) return $this->$m();
      user_error("undefined property $p");
 }

когда кто-то вызывает $obj->xxx, а в классе определено get_xxx, этот метод будет вызываться неявно. Таким образом, вы можете определить геттер, если вам это нужно, сохраняя при этом унифицированный и прозрачный интерфейс. В качестве дополнительного бонуса это обеспечивает элегантный способ запоминания вычислений:

  function get_accountBalance() {
      $result = <...complex stuff...>
      // since we cache the result in a public property, the getter will be called only once
      $this->accountBalance = $result;
  }

  ....


   echo $user->accountBalance; // calculate the value
   ....
   echo $user->accountBalance; // use the cached value

Итог: php — это динамический язык сценариев, используйте его таким образом, не притворяйтесь, что занимаетесь Java или C#.

person user187291    schedule 31.05.2011
comment
Хороший ответ. Синтаксис — лучшая причина для использования магических методов. $foo-›bar() подразумевает выполнение чего-либо, в то время как $foo-›bar подразумевает доступ к чему-либо. - person None; 11.09.2012
comment
@J.Money Да, но что, если вашему простому $foo->bar теперь нужно сделать простую вещь, прежде чем возвращать значение (или вычислять значение). Вам нужно изменить везде, где он используется для $foo->getBar(). В то время как с геттерами вы всегда сохраняете один и тот же интерфейс, вы просто меняете реализацию. И этот случай происходил со мной много раз. Сохраненные значения и вычисляемые значения на самом деле не сильно отличаются, и ИМО они должны быть названы последовательно (с get...). - person Matthieu Napoli; 12.10.2012
comment
@Matthieu: Как отмечено в ответе, $foo->bar просто вызовет $this->get_bar(), который является геттером и может быть изменен, чтобы делать все, что вам нужно. - person FtDRbwLXw6; 13.02.2013
comment
ты знаешь -› Уважаемый {$user-›getFirstName()} ?? - person Mauro; 11.06.2013
comment
Ваша последняя строка — это моя философия: пусть PHP будет PHP, пусть SQL будет SQL, пусть Javascript будет Javascript, пусть HTML будет HTML, пусть Java, C# или выбранный вами язык будут такими, какие они есть, и пусть работают так, как они предназначены для работы. Неотъемлемой частью этого является то, что это в основном эффективно, когда ваша команда знает, как это сделать, как использовать язык с максимальным потенциалом, а не втискивать его в стиль другого языка, но именно так вы В любом случае, вы получите лучшую работу, это не будет попытка сделать PHP Java и т. д. - person Jason; 22.08.2013
comment
... Кроме того, я чувствую, что многие лучшие практики в PHP основаны на Java-программистах, которые начали использовать PHP, потому что им нужен был или они хотели лучший язык веб-страницы, и обнаружили (в то время) действительно ужасное состояние хорошего гигиена программирования в мире PHP и навязали свое мировоззрение только для того, чтобы получить некоторую структуру, а какая-то структура лучше, чем ничего, было принято, что это на самом деле лучший способ делать что-то в PHP. Возможно, именно к этому и движется язык, но я не думаю, что он представляет истину в последней инстанции, по крайней мере, на данный момент. - person Jason; 22.08.2013
comment
@ Джейсон, я согласен. Вот почему у меня нет проблем, например, с магическими функциями получения и установки Magento. - person Matthew G; 08.11.2013
comment
Вы эмулируете свойства (известные из VB или C#), используя второстепенную функцию PHP. Код, использующий эту логику, не будет легко переноситься на другие языки и не будет соответствовать требованиям будущего. - person vbence; 20.01.2014
comment
@vbence Почему это не будет рассчитано на будущее? Какое изменение вы представляете, что может сломать такой код? - person Mark Amery; 21.01.2014
comment
@MatthieuNapoli Вся суть того хака, который предлагает этот ответ, заключается в том, что вам никогда не нужно менять свой интерфейс, когда ваши свойства меняются с отсутствия необходимости в пользовательской логике на необходимость в ней. Недостатком вашего подхода является то, что вам нужно либо никогда использовать общедоступные поля (и предоставлять метод получения и установки для всего, что в противном случае было бы общедоступным полем - ужасно многословно) или иметь смесь общедоступных полей и геттеров (ужасно непоследовательных, и вы рискуете изменить свой интерфейс, когда поле, которое вы не ожидали, нуждается в сложном геттере). - person Mark Amery; 21.01.2014
comment
@MarkAmery Нет полей public, да. Вот что я рекомендую: инкапсуляция. - person Matthieu Napoli; 21.01.2014
comment
@MatthieuNapoli Поправьте меня, если я туплю, но я не вижу никакой разницы в количестве инкапсуляции между вашим подходом и подходом user187291; оба обеспечивают возможность чтения и установки свойства как части общедоступного интерфейса вашего объекта. Я не говорю, что у вашего способа нет никаких плюсов — он явно есть, — но при любом разумном определении «инкапсуляции», которое я могу себе представить, утверждение, что ваш подход имеет больше инкапсуляции, прямо ложно. - person Mark Amery; 21.01.2014
comment
@MarkAmery Вы правы, технически оба инкапсулированы, поскольку с помощью __get и __set вы контролируете доступ к свойству. Но с практической точки зрения инкапсуляция также означает, что вы понятия не имеете, каковы свойства объекта. Вам просто дан набор общедоступных методов, которые вы можете вызывать для объекта. Для меня это имеет значение, может для других нет. - person Matthieu Napoli; 21.01.2014
comment
Мне это нравится, особенно элегантное кеширование, но почему-то я все еще чувствую себя грязным, используя публичные свойства ;) Два небольших замечания, однако, в вашей функции get_accountBalance отсутствует возврат, но, возможно, это очевидно для всех. И пример с эхом немного вводит в заблуждение, поскольку вы также можете сразу же использовать геттеры в строке, выполнив: echo Dear {$user-›get_firstName()} {$user-›get_lastName()}; - person Bas; 17.03.2014
comment
-1, я не согласен, магические методы не более читабельны, ваш пример ошибочен, так как вы можете легко использовать sprintf для такой строки и сохранить код читаемым с помощью геттеров --- __get и __set не являются универсальным решением для взаимодействия с объектами - person ioleo; 07.02.2016
comment
отличный ответ, но ваша суть либо глупа, либо я этого не понимаю. Возможно, лучший результат заключается в том, почему бы не использовать мощную функцию языка, которая может упростить как написание, так и просмотр вашего кода. - person Andrew; 13.02.2016
comment
Нет причин не писать на PHP так же, как вы пишете на Java или C#. Написание хорошо структурированного, поддерживаемого кода — хорошая идея, даже если PHP позволяет вам поступить иначе. PHP дает вам достаточно веревки, чтобы повеситься, но вам решать, сунуть ли вам голову в петлю. - person Henry; 05.12.2016

Я комбинирую ответ Эдема и ваш второй код. Таким образом, у меня есть преимущества общих геттеров/сеттеров (завершение кода в вашей IDE), простота кодирования, если я хочу, исключения из-за несуществующих свойств (отлично подходит для обнаружения опечаток: $foo->naem вместо $foo->name), свойства только для чтения и составные свойства .

class Foo
{
    private $_bar;
    private $_baz;

    public function getBar()
    {
        return $this->_bar;
    }

    public function setBar($value)
    {
        $this->_bar = $value;
    }

    public function getBaz()
    {
        return $this->_baz;
    }

    public function getBarBaz()
    {
        return $this->_bar . ' ' . $this->_baz;
    }

    public function __get($var)
    {
        $func = 'get'.$var;
        if (method_exists($this, $func))
        {
            return $this->$func();
        } else {
            throw new InexistentPropertyException("Inexistent property: $var");
        }
    }

    public function __set($var, $value)
    {
        $func = 'set'.$var;
        if (method_exists($this, $func))
        {
            $this->$func($value);
        } else {
            if (method_exists($this, 'get'.$var))
            {
                throw new ReadOnlyException("property $var is read-only");
            } else {
                throw new InexistentPropertyException("Inexistent property: $var");
            }
        }
    }
}
person Carlos Campderrós    schedule 31.05.2011
comment
Это сбивает с толку: всегда избегайте предоставления двух способов сделать одно и то же. - person Matthieu Napoli; 31.05.2011
comment
Ну, я всегда кодирую одинаково, используя эти виртуальные свойства. Обычно я помещаю геттеры и сеттеры в приватные, но ради примера я оставил их здесь общедоступными, потому что кто-то жаловался на автозаполнение IDE. - person Carlos Campderrós; 31.05.2011
comment
Я думаю, что это имеет большой смысл. Вы можете позволить волшебству делать работу большую часть времени и реализовывать пользовательские функции get/set только для того, чтобы волшебство вызывалось по мере необходимости. - person colonelclick; 18.06.2013
comment
Я голосую против. ИМО, этот пример усугубляет ситуацию. Это не Чистый Код. Вы делаете дублирование. Ваш пример только для 2 свойств, для реального класса их будет намного больше. Для автоматического завершения вы можете использовать комментарии PhpDoc. - person Roman Podlinov; 06.01.2016
comment
Этот способ идеален. Я поместил магические функции get/set в трейт, чтобы я мог легко использовать его в нескольких классах. - person nfplee; 09.05.2016

Я голосую за третье решение. Я использую это в своих проектах, и Symfony тоже использует что-то подобное:

public function __call($val, $x) {
    if(substr($val, 0, 3) == 'get') {
        $varname = strtolower(substr($val, 3));
    }
    else {
        throw new Exception('Bad method.', 500);
    }
    if(property_exists('Yourclass', $varname)) {
        return $this->$varname;
    } else {
        throw new Exception('Property does not exist: '.$varname, 500);
    }
}

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

person Adam Arold    schedule 31.05.2011
comment
Я тоже рекомендую против этого, я подробно объяснил, почему в своем ответе. - person Matthieu Napoli; 31.05.2011
comment
Это противоположно тому, что вы хотели бы сделать. Это делает все ваши личные и защищенные свойства общедоступными, и их нельзя переопределить. Вы не должны добавлять геттеры/сеттеры только ради того, чтобы иметь их. - person mpen; 24.04.2015
comment
@mpen Это решение предоставляет только магические геттеры для всех свойств, но не сеттеры. Это может иметь смысл, если вы хотите предоставить доступ только для чтения ко всем свойствам объекта. Но я согласен с вами: есть лучшие варианты сделать это. Это решение требует в общей сложности 4 вызовов функций для получения значения свойства. - person Philipp; 23.04.2017

Лучшей практикой будет использование традиционных геттеров и сеттеров из-за самоанализа или размышлений. В PHP есть способ (точно такой же, как в Java) получить имя метода или всех методов. Такая вещь вернет «__get» в первом случае и «getFirstField», «getSecondField» во втором (плюс сеттеры).

Подробнее об этом: http://php.net/manual/en/book.reflection.php

person SteeveDroz    schedule 31.05.2011
comment
Кроме того, магические методы не будут работать с интерфейсами и абстрактными классами/методами. А что с видимостью? Наличие закрытого или защищенного свойства, которое можно изменить с помощью магического метода __set, является утечкой. Добавьте их к своим примерам, и я соглашусь, что есть много хороших аргументов против использования магических методов для геттеров/сеттеров, и нет реальных аргументов в их пользу. Для быстрых одноразовых действий, возможно, используйте их для чего-то, но они не являются лучшей практикой для многократно используемого кода/библиотек/API. - person joelhardi; 31.05.2011

Второй пример кода - гораздо более правильный способ сделать это, потому что вы получаете полный контроль над данными, которые передаются class. Есть случаи, когда __set и __get полезны, но не в этом случае.

person skowron-line    schedule 31.05.2011

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

person Wesley van Opdorp    schedule 31.05.2011
comment
Использование объектов stdClass не решает проблему OP; весь смысл этого вопроса в том, что ему нужны геттеры и сеттеры, которые выполняют пользовательскую логику, а не не объект данных без поведения. - person Mark Amery; 21.01.2014
comment
В нижней части вопроса ОП он ясно отмечает, что хотел бы услышать больше мнений по этому вопросу. Так что, высказывая свое мнение, я действительно отвечаю на его вопрос. Он не запрашивает фактический образец кодирования или что-то в этом роде. - person Wesley van Opdorp; 22.01.2014
comment
Я не критикую отсутствие примеров кода или тот факт, что предложенный вами подход не является одним из двух, первоначально предложенных в вопросе, - я критикую тот факт, что он просто не работает, точка, с той целью, чтобы OP спрашивал (у которого были свойства с настраиваемой логикой получения и настройки). - person Mark Amery; 22.01.2014

Теперь я возвращаюсь к сеттерам и геттерам, но я также помещаю геттеры и сеттеры в магические методы __get и __set. Таким образом, у меня есть поведение по умолчанию, когда я это делаю

$класс->вар;

Это просто вызовет геттер, который я установил в файле __get. Обычно я просто использую геттер напрямую, но есть еще несколько случаев, когда это проще.

person AntonioCS    schedule 31.05.2011