juste pour clarifier, je veux dire quelque chose comme: Ceci est particulièrement agréable lorsque vous n'avez pas toujours besoin getbarn code> et
getbarn code> est particulièrement coûteux (par exemple, a un appel de dB). Y a-t-il un moyen d'éviter le conditionnel? Cela prend beaucoup d'espace, a l'air moche et voyant que des conditionnels disparaissent est toujours agréable. Y a-t-il un autre paradigme pour gérer ce chargement paresseux que je ne peux tout simplement pas voir? P> p>
6 Réponses :
Je me suis demandé cela de temps en temps, mais je ne peux certainement pas penser à un. Sauf si vous souhaitez créer une seule fonction pour gérer cela avec des tableaux et des recherches de propriétés réfléchissantes. P>
ou le PHP 5.3 (?) Un: P>
retour ($ this-> grange = $ ceci-> grange? $ this-> Barn: getbarn ()); Code> P>
retour ($ this-> grange = $ ceci-> grange ?: getbarn ()); code> p> p>
Je parlais du conditionnel en général, pas seulement du si code>, mais merci pour la suggestion.
+1 pour l'utilisation de 5,3 opérateur de coalesce. toujours assez déroutant de lire pour novice php ou <5,3 utilisateurs cependant heh.
@TANDU Si vous utilisez 5.3, il est à peine conditionnel: p si vous êtes avant 5,3, il a l'air laid et répétitif :(
@Esailija logiquement i>, c'est un conditionnel.
@Tandu bien je n'ai pas dit que ce n'était pas et ça compte même? Vos plaintes étaient qu'il faut beaucoup d'espace, a l'air laid et est un conditionnel ... c'est deux sur trois. Qu'est-ce qui va exactement mal avec être logiquement un conditionnel en soi?
Vous pouvez faire:
return $this->barn != null ? $this->barn : ($this->barn = self::getBarnImpl());
Je ne pense pas avoir déjà vu une méthode d'élimination de ce type de vérification d'initialisation paresseuse, mais il est intéressant de penser. Avec un échantillon de jouet, il ne semble pas y avoir d'avantage, mais dans de grands objets, vous pouvez refroidir le comportement d'initialisation paresseux dans l'objet à être initialisé ou (plus précisez) une sorte de motif d'initialisateur de paresseux générique (je décris quelque chose à peu près quelque chose semblable à un singleton). Fondamentalement, sauf si elles décident de la construire en tant que construction de langue (auquel cas il serait toujours là, seulement caché) Je pense que le mieux que vous puissiez faire est d'encapsuler le code vous-même.
class LazyObject { ... public function __construct($type, $args) { $this->type = $type; ... } public getInstance() { if (empty($this->instance)) $this->instance = new $this->type($args); return $instance; } } class AggregateObject { private $foo; private $bar; public function __construct() { $this->foo = new LazyObject('Foo'); $this->bar = new LazyObject('Bar'); } public function getFoo() { return $this->foo->getInstance(); } ... }
En utilisant la méthode Magic Une fois j'ai fait quelque chose comme ça: < / p> puis p> __ d'appel de PHP () CODE>, nous pouvons facilement écrire un objet de décorateur qui intercepte tous les appels de méthode et cache les valeurs de retour.
Je peux penser à la classe d'écouteurs. P>
Constructor () { object = null listener = new Object() { // this is called once object = init() listener = new Object() { // next time do-nothing() // this is called } } Object get() { listener.invoke() return object