L'appel de la variable directement la propriété vs lecture/définition - OOP de Conception

Ce serait un changement bienvenu dans mon
processus de conception comme je vois la nécessité d'
des getters/setters de s'en aller, mais ce
d'autres obstacles/avantages pourraient se produire dans les
faire cela?

Vous perdre la capacité de mettre en place des get/set logique sur une propriété particulière. Pour les propriétés qui sont des scalaires (chaînes de caractères, des entiers, des booléens) peut-être que ce n'est pas un problème. Mais que faire si vous avez une propriété qui est un chargement paresseux instance de classe?

class Document
{
    protected $_createdBy;

    public function getCreatedBy()
    {
        if (is_integer($this->_createdBy)) {
            $this->_createdBy = UserFactory::loadUserById($this->_createdBy);
        }
        return $this->_createdBy;
    }
}

Cette astuce ne fonctionne que dans une méthode. Vous pouvez utiliser __get et __set pour cette logique, mais à mesure que vous ajoutez des propriétés de vous retrouver avec un gros méchant switch() bloc:

public function __get($name)
{
    switch ($name) {
        case 'createdBy':
            //blah blah blah
        case 'createdDate':
            //more stuff
        //more case statements until you scream
    }
}

Si vous voulez juste pour éviter ou à remettre à l'écriture des getters et setters, utilisez le __call méthode magique pour intercepter les appels de méthode qui suivent la getProperty() et setProperty() convention de nommage. Vous pouvez mettre tous les défaut get/set logique dans __call et de ne jamais toucher à nouveau:

abstract class Object
{
    public function __call($method, $args)
    {
        $key = '_' . strtolower(substr($method, 3, 1)) . substr($method, 4);
        $value = isset($args[0]) ? $args[0] : null;
        switch (substr($method, 0, 3)) {
            case 'get':
                if (property_exists($this, $key)) {
                    return $this->$key;
                }
                break;

            case 'set':
                if (property_exists($this, $key)) {
                    $this->$key = $value;
                    return $this;
                }
                break;

            case 'has':
                return property_exists($this, $key);
                break;
        }

        throw new Exception('Method "' . $method . '" does not exist and was not trapped in __call()');
    }
}

Cette approche est très rapide à partir d'un développement point de vue parce que vous pouvez simplement étendre la classe de l'Objet, de définir certaines propriétés, et vous êtes hors de la course:

class Foo extends Object
{
    protected $_bar = 12345;
}

$foo = new Foo();
echo $foo->getBar();  //outputs '12345'
$foo->setBar(67890);  //next call to getBar() returns 67890
$foo->getBaz();       //oops! 'baz' doesn't exist, exception for you

C'est lent à partir d'un exécution point de vue parce que les méthodes magiques sont damnés lent, mais vous pouvez atténuer que, plus tard, par la définition explicite getBar() et setBar() méthodes (parce que __call est invoqué lorsque vous appelez une méthode qui n'est pas défini). Mais si une propriété n'est pas d'obtenir un accès très souvent, peut-être que vous ne se soucient pas comment lent, il est. Le point est, il est facile d'ajouter des méthodes get/set plus tard, et le reste de votre code ne sait jamais la différence.

J'ai chipé cette approche de Magento et je trouve que c'est très abordable pour les développeurs. Lancement d'une exception lors de l'appel de la get/set pour une propriété qui n'existe pas, vous aide à éviter fantôme de bugs causés par les fautes de frappe. Conserver les biens logique spécifique dans ses propres méthodes get/set rend le code plus facile à maintenir. Mais vous n'avez pas à écrire toutes les méthodes d'accès au début, vous pouvez facilement revenir en arrière et ajouter sans refactoring tous vos autres code.

La question est-ce que vous essayez d'optimiser? Le temps du développeur ou du code de la vitesse? Si vous souhaitez optimiser le code de vitesse, assurez-vous que vous savez où votre goulets d'étranglement avant de construire votre code autour d'eux. L'optimisation prématurée est la racine de tous les maux.

Vous pouvez également utiliser l' __get et __set méthodes magiques:

class Example
{
    private $allowedProps = array('prop1', 'prop2', 'prop3');
    private $data = array();

    public function __set($propName, $propValue)
    {
        if (in_array($propName, $this->allowedProps))
        {
            $this->data[$propName] = $propValue;
        }
        else
        {
            //error
        }
    }

    public function __get($propName)
    {
        if (array_key_exists($propName, $this->data))
        {
            return $this->data[$propName];
        }
        else
        {
            //error
        }
    }
}

Cela dépend si $name est public ou pas. Si elle ne l'est pas, vous ne pouvez pas accéder/modifier directement. Le compromis est d'exposer votre classe interne des éléments de données directement aux intégrateurs. Cela peut être OK pour certaines classes, mais pas pour d'autres.

Par exemple, vous ne pouvez pas forcément envie à d'autres d'être en mesure de modifier le prix d'un produit directement dans un Product classe.