Les Traits en PHP – tout des exemples du monde réel et de pratiques exemplaires?

Traits ont été l'un des plus grands ajouts pour PHP 5.4. Je sais que la syntaxe et de comprendre l'idée derrière les traits, comme horizontale code re-utiliser pour le commun des trucs comme l'exploitation forestière, la sécurité, la mise en cache etc.

Cependant, je ne sais toujours pas comment je pourrais utiliser des traits dans mes projets.

Existe-il des projets open source qui utilisent déjà les traits? Tout de bons articles/matériel de lecture sur la façon de structurer les architectures à l'aide de traits?

  • Voici mon avis: un blog sur le sujet que j'ai écrit sur le sujet. TL;DR: en gros, j'ai peur que pendant qu'ils sont puissant et peut être utilisé pour de bon, la majorité des utilisations, nous allons voir vont être complet anti-modèles et provoquer beaucoup plus de douleur qu'ils n'en résolvent...
  • Jetez un oeil à scala de la bibliothèque standard et vous trouverez de nombreux exemples de traits de caractère.
InformationsquelleAutor Max | 2011-10-25
  1. 83

    Mon opinion personnelle est qu'il y a en fait très peu de demande pour des caractères lors de l'écriture de code propre.

    Au lieu d'utiliser des traits de hack code dans une classe, il est mieux de passer dans les dépendances via le constructeur ou par l'intermédiaire de setters:

    class ClassName {
    protected $logger;

    public function __construct(LoggerInterface $logger) {
        $this->logger = $logger;
    }
    //or
    public function setLogger(LoggerInterface $logger) {
        $this->logger = $logger;
    }
}

    La principale raison pour laquelle je trouve que c'est mieux que l'aide de traits, c'est que votre code est beaucoup plus souple en retrait de la dur de couplage à un trait. Par exemple, vous pouvez tout simplement passer à un autre enregistreur de classe. Cela rend votre code réutilisable et testable.

    • À l'aide de traits, vous pouvez également utiliser un autre enregistreur de classe à droite? Il suffit d'éditer le trait, et toutes les classes qui utilisent le trait est mis à jour. Corrigez-moi si je me trompe
    • Bien sûr, vous pourriez le faire. Mais vous auriez besoin de modifier le code source d'un trait. Donc, vous le changer pour chaque classe à l'aide d'elle, et pas seulement le particulier que vous voulez un autre enregistreur de pour. Et si vous souhaitez utiliser la même classe, mais avec deux enregistreurs? Ou si vous souhaitez passer une maquette enregistreur pendant le test? Vous ne pouvez pas, si vous utilisez des traits, vous pouvez, si vous utiliser l'injection de dépendance.
    • Je peux voir votre point de vue, je suis également se demandant si les traits sont à peine ou pas. Je veux dire, dans moderne des frameworks comme Symfony 2, vous avez de l'injection de dépendances tous sur la place qui semble superioir plus de traits dans la plupart des cas. Au moment où je vois des traits que pas beaucoup plus de "compilateur assistée copie & coller". 😉
    • pour le moment je vois des traits que pas beaucoup plus de "compilateur assistée copie & coller". 😉: @Max: c'est exactement ce Que les traits ont été conçus pour être, de sorte que c'est tout à fait correct. Il le rend plus "gérables", car il n'y a qu'une seule définition, mais il est fondamentalement juste à c&p...
    • et NikiC – ce qui me vient à l'esprit: ma manière préférée de l'injection de dépendances dans une classe est un conteneur d'injection de dépendances comme mentionné Smyfony 2 cadre. Mais dans certaines situations, un DI contaier n'est pas disponible ou ne peut être mis en œuvre, comme l'héritage des bases de code. Peut-être les traits pourraient aider il y a comme une langue prise en charge de faire horizontale code reusage plus facile?
    • Je dirais que l'héritage de la base de code vous parler de bénéficieraient davantage de refactoring pour être en mesure d'utiliser le DI (et, par conséquent, être testable, et obtenir tous les avantages qu'apporte), plutôt que de l'optimisation dans les traits de là...
    • c'est probablement vrai, dépend toujours de la taille de la refactorisation est. Je veux dire, l'e. g. ce n'est pas toujours possible en raison peut-être de temps constraits, donc si l'Id d'être pressé, Id plutôt ajouter un trait au lieu de copier du code plus et puis, comme vous l'avez justement dit, le corriger dans la prochaine itération. Tout comme une idée de l'endroit où les traits pourraient peut-être de les utiliser.
    • NikiC est à côté de l'essentiel: à l'aide d'un trait de caractère qui n'empêche pas l'aide de l'Injection de Dépendance. Dans ce cas, un trait ne laissez chaque classe qui implémente la journalisation de ne pas dupliquer le setLogger() la méthode et la création de l' $logger propriété. Le trait serait de leur fournir. setLogger() serait-type de l'indice sur LoggerInterface que l'exemple ne, de sorte que tout type d'enregistreur de données peut être transmise. Cette idée est similaire à Gordon de réponse ci-dessous (seulement on dirait qu'il est de type hinting sur un Enregistreur super classe plutôt qu'à un Enregistreur interface).
    • Trop souvent, l'architecture que les gens proposons est le "droit" l'architecture est si complexe que beaucoup ne peut pas envelopper leur tête autour d'elle et de ce qu'il résultats si plus de mal que de bien. L'Injection de dépendance et les Traits peuvent être utilisés à des fins similaires, mais ils sont optimisés pour les différents cas d'utilisation. À l'aide de DI lorsque Traits est plus appropriée est beaucoup plus complexe et donc difficile à utiliser hiérarchie de classe.
    • Cette juste montrer que vous ne compreniez pas les traits à tous. Les Traits sont le seul moyen, au moins en PHP, pour injecter du code réutilisable dans des classes à plusieurs ancêtres. Par exemple, en réutilisant les mêmes méthodes de vote sur les deux Post et Commentaire des classes. C'est une approche alternative pour obtenir l'héritage multiple dans une langue qui ne le supporte pas. J'utilise fortement les traits.
    • Je suppose que vous ne savez pas qui nikiC est... astuce: vérifiez les collaborateurs du php-src repo github: vous n'avez pas besoin de faire défiler beaucoup, il est l'un des principaux contributeurs. Pour tous vous le savez, il est même écrit une partie de la caractéristique de mise en œuvre. Et de voir que vous utilisez des traits tellement: voici un blog post sur pourquoi vous ne devriez pas. C++ supporte l'héritage multiple, mais de nombreux développeurs vont vous dire que vous ne devriez pas aller dans cette voie, oui traits existent, est-ce la bonne? Pas de
    • Vraiment? Ipse Dixit! Depuis NikiC est en PHP, le code de la base contributeur son opinion est pertinente, et la mienne ne l'est pas? C'est drôle en effet. Il est tout simplement faux. Pour résoudre tous les problèmes que vous avez décrit dans votre article, il suffit d'utiliser une interface et de faire le trait d'implémenter l'interface elle-même. Type d'indicateur est conservé et est donc le contrat. Si vous modifiez le trait, et la nouvelle mise en œuvre n'est pas satisfaire à l'interface, la charpie mettra en évidence les erreurs, parce que le contrat est passé entre l'interface et la classe qui l'a mise en œuvre. Un trait est juste un morceau de code injecté par l'interprète.
    • Je ne dis pas que votre avis n'est pas pertinent. Je signale simplement que votre réclamation que NikiC ne pas comprendre traits est plutôt absurde, car il sait probablement plus que vous et moi réunis. Ce que je vais dire, cependant, c'est que vous ne semblez pas obtenir le point que j'essayais de faire de mon blog. Assurez-vous de Trait de + Interface résout la plupart des problèmes dont je parle. Cependant: les Interfaces sont des méthodes publiques seulement. Trait de conflits de noms s'appliquent toujours, et plus que tout: je n'ai pas encore rencontré un problème qui m'a obligé à utiliser des traits.
    • Mon principal problème avec des traits est simplement ceci: la façon dont les traits sont implementated laisse une trop grande marge d'erreur de l'opérateur. Il ya des tonnes de PHP devs qui ne comprennent pas les choses comme le principe de liskov, ou RDA, ou DI. La façon dont vous pouvez abuser des traits de maintenant ne sera pas aider à l'image de PHP étant un drôle de langage qui est mal construite, et n'est pas adapté pour programmer sérieusement
    • Pour le record, je ne pense pas que les traits sont tout à fait inutile, ils ont relativement peu d'applications que je considère comme compatible avec le bien-conçu de code. Les Traits sont essentiellement compilateur assistée copie&coller de code et il n'y a pas beaucoup de cas où la copie&coller du code est vraiment la meilleure solution à un problème. Mais bien sûr, il ya certains, généralement en raison des limitations de langue (notamment ici est l'héritage multiple).
    • n'traits étant essentiellement un compilateur assistée, c&p mécanisme implique que le fait de désactiver le cache d'OPCode peut provoquer une augmentation de l'e / s de disque? et ne vous arrive de savoir si mes soupçons au sujet de traits mis en œuvre de même pour les classes abstraites sont fondées? merci
    • L'injection de dépendance est un exemple de la composition d'une instance d'un objet (par exemple, chaque instance a ses propres dépendances). Les Traits sont un exemple de class composition. Vous êtes à la composition de la classe elle-même, de sorte que toutes les instances de partager ces traits. Si vous avez utilisé l'injection de dépendance pour ce faire, vous seriez la répétition du code sur chaque instanciation.
    • Les Traits de résoudre le problème de l'héritage multiple n'existe pas en PHP.

    InformationsquelleAutor NikiC
  2. 192

    Je pense qu'on serait à rechercher dans les langues qui ont des Traits pour un certain temps maintenant d'apprendre les Bonnes/Meilleures pratiques. Mon opinion sur le Trait est que vous ne devriez les utiliser pour le code que vous devez dupliquer dans d'autres classes que de partager la même fonctionnalité.

    Exemple pour un Enregistreur de trait:

    interface Logger
{
    public function log($message, $level);    
}

class DemoLogger implements Logger
{
    public function log($message, $level)
    {
        echo "Logged message: $message with level $level", PHP_EOL; 
    }
}

trait Loggable //implements Logger
{
    protected $logger;
    public function setLogger(Logger $logger)
    {
        $this->logger = $logger;
    }
    public function log($message, $level)
    {
        $this->logger->log($message, $level);
    }
}

class Foo implements Logger
{
    use Loggable;
}

    Et puis vous n' (démo)

    $foo = new Foo;
$foo->setLogger(new DemoLogger);
$foo->log('It works', 1);

    Je suppose que la chose importante à considérer lors de l'utilisation de traits, c'est qu'ils sont vraiment juste des morceaux de code qui sont copiés dans la classe. Cela peut facilement conduire à des conflits, par exemple, lorsque vous essayez de modifier la visibilité des méthodes, par exemple,

    trait T {
    protected function foo() {}
}
class A { 
    public function foo() {}
}
class B extends A
{
    use T;
}

    Ci-dessus entraînera une erreur (démo). De même, toutes les méthodes déclarées dans le trait qui le sont déjà déclarés dans l'utilisation de la classe ne sera pas copiée dans la classe, par exemple

    trait T {
    public function foo() {
    return 1;
}
}
class A { 
    use T;
    public function foo() {
    return 2;
}
}

$a = new A;
echo $a->foo();

    imprime 2 (démo). Ce sont des choses que vous voulez éviter, car ils font des erreurs difficiles à trouver. Vous voulez aussi éviter de mettre des choses en traits qui opèrent sur des propriétés et des méthodes de la classe qui l'utilise, par exemple, 

    class A
{
    use T;
    protected $prop = 1;
    protected function getProp() {
        return $this->prop;
    }
}

trait T
{
    public function foo()
    {
        return $this->getProp();
    }
}

$a = new A;
echo $a->foo();

    œuvres (démo) mais maintenant, le trait est intimement liée à l'Un et à l'ensemble de l'idée à l'horizontale réutilisation est perdu.

    Lorsque vous suivez les L'Interface De La Ségrégation Principe, vous aurez de nombreuses petites classes et d'interfaces. Qui rend les Traits d'un candidat idéal pour les choses que vous avez mentionnées, par exemple problèmes intersectoriels, mais pas de composer des objets (dans un structurelle sens). Dans notre Enregistreur exemple ci-dessus, le trait est complètement isolé. Il n'a pas de dépendances sur les classes de béton.

    Nous pourrions utiliser agrégation/composition (comme on l'a montré ailleurs sur cette page) pour atteindre la même classe, mais l'inconvénient de l'utilisation de l'agrégation/composition, c'est que nous devrons ajouter le proxy/délégataire méthodes manuellement à chaque classe alors que ce devrait être en mesure de se connecter. Les Traits de résoudre ce bien en me permettant de garder le standard en un seul endroit et de manière sélective l'appliquer en cas de besoin.

    Remarque: étant donné que les traits sont un nouveau concept en PHP, toute opinion exprimée ci-dessus est sujette à changement. J'ai pas eu beaucoup de temps pour évaluer le concept de moi-même encore. Mais j'espère qu'il est assez bon pour vous donner quelque chose à penser.

    • C'est un intéressant cas d'utilisation: utiliser une interface qui définit le contrat, utiliser le trait afin de satisfaire le contrat. Bon.
    • J'aime ce type de vrais programmeurs, qui proposent un vrai travail d'exemples à court desc pour chaque. Thx
    • Que faire si quelqu'un d'utiliser une classe abstraite à la place? Le remplacement de l'interface et de trait, on peut créer une classe abstraite. Aussi, si l'interface est donc nécessaire pour l'application, la classe abstraite peut aussi mettre en œuvre l'interface et la définition des méthodes comme le trait n'. Donc, pouvez-vous expliquer pourquoi nous avons encore besoin de traits?
    • Classe abstraite suivre les règles de l'Héritage. Que faire si vous avez besoin d'une classe qui implémente exploitables d'ici et pouvant être mis en Cache? Vous auriez besoin de la classe d'étendre AbstractLogger qui doit s'étendre AbstractCache ensuite. Mais cela signifie que tous les Loggables sont des Caches. C'est un assemblage que vous ne souhaitez pas. Il limite la réutilisation et bousille votre héritage graphique.
    • je me demande comment le demoLogger de se connecté avec Logger 🙁
    • Dans l'exemple ci-dessus demoLogger n'est pas en s'appuyant sur tout l'extérieur de la classe pour gérer les logs. Il a juste fait l'écho d'un message lorsqu'il se connecte. Comme @Gordon a expliqué, de son aire d'origine log() fonction ne sera pas sur-écrite par le trait qu'elle utilise. Donc, je pense que c'est juste destiné à servir comme un exemple d'une classe implémentant l' Logger interface sans l'utilisation de traits.
    • Je pense que la démo liens sont morts
    • ok, je vais upvote une autre réponse aléatoire de votre, seulement parce que cela mériterait au moins un +20: c'est le meilleur moyen que j'ai trouvé pour enfin éviter tous les obtenir-code réutilisable pour accéder aux composants de méthodes de la composite, comme $foo->getLogger()->log(), Maintenant je peux le faire $foo->log() et dans le même temps, gardez à l'aide de la composition. Super !

    InformationsquelleAutor Gordon
  3. 19

    🙂 Je n'aime pas à théoriser et de débat sur ce qui doit être fait avec quelque chose. Dans ce cas, les traits. Je vais vous montrer ce que je trouve traits utiles et vous pouvez apprendre de lui, ou de l'ignorer.

    Traits - ils sont parfaits pour appliquer stratégies. Stratégie de modèles de conception, en bref, sont utiles lorsque vous souhaitez les mêmes données à manipuler (de filtrer, trier, etc) de façon différente.

    Par exemple, vous avez une liste de produits que vous souhaitez filtrer en fonction de certains critères (les marques, les spécifications, peu importe), ou triés par différents moyens (prix, étiquette, peu importe). Vous pouvez créer un tri trait de caractère qui contient des fonctions différentes pour les différents types de tri (numérique, chaîne, date, etc). Vous pouvez ensuite utiliser ce trait non seulement dans votre classe de produit (comme dans l'exemple), mais également dans d'autres classes qui ont besoin de stratégies similaires (pour appliquer un tri numérique à certaines données, etc).

    Essayer:

    <?php
trait SortStrategy {
private $sort_field = null;
private function string_asc($item1, $item2) {
return strnatcmp($item1[$this->sort_field], $item2[$this->sort_field]);
}
private function string_desc($item1, $item2) {
return strnatcmp($item2[$this->sort_field], $item1[$this->sort_field]);
}
private function num_asc($item1, $item2) {
if ($item1[$this->sort_field] == $item2[$this->sort_field]) return 0;
return ($item1[$this->sort_field] < $item2[$this->sort_field] ? -1 : 1 );
}
private function num_desc($item1, $item2) {
if ($item1[$this->sort_field] == $item2[$this->sort_field]) return 0;
return ($item1[$this->sort_field] > $item2[$this->sort_field] ? -1 : 1 );
}
private function date_asc($item1, $item2) {
$date1 = intval(str_replace('-', '', $item1[$this->sort_field]));
$date2 = intval(str_replace('-', '', $item2[$this->sort_field]));
if ($date1 == $date2) return 0;
return ($date1 < $date2 ? -1 : 1 );
}
private function date_desc($item1, $item2) {
$date1 = intval(str_replace('-', '', $item1[$this->sort_field]));
$date2 = intval(str_replace('-', '', $item2[$this->sort_field]));
if ($date1 == $date2) return 0;
return ($date1 > $date2 ? -1 : 1 );
}
}
class Product {
public $data = array();
use SortStrategy;
public function get() {
//do something to get the data, for this ex. I just included an array
$this->data = array(
101222 => array('label' => 'Awesome product', 'price' => 10.50, 'date_added' => '2012-02-01'),
101232 => array('label' => 'Not so awesome product', 'price' => 5.20, 'date_added' => '2012-03-20'),
101241 => array('label' => 'Pretty neat product', 'price' => 9.65, 'date_added' => '2012-04-15'),
101256 => array('label' => 'Freakishly cool product', 'price' => 12.55, 'date_added' => '2012-01-11'),
101219 => array('label' => 'Meh product', 'price' => 3.69, 'date_added' => '2012-06-11'),
);
}
public function sort_by($by = 'price', $type = 'asc') {
if (!preg_match('/^(asc|desc)$/', $type)) $type = 'asc';
switch ($by) {
case 'name':
$this->sort_field = 'label';
uasort($this->data, array('Product', 'string_'.$type));
break;
case 'date':
$this->sort_field = 'date_added';
uasort($this->data, array('Product', 'date_'.$type));
break;
default:
$this->sort_field = 'price';
uasort($this->data, array('Product', 'num_'.$type));
}
}
}
$product = new Product();
$product->get();
$product->sort_by('name');
echo '<pre>'.print_r($product->data, true).'</pre>';
?>

    Comme une clôture note, je pense que sur des traits comme accessoires (ce que je peux utiliser pour modifier mes données). Les mêmes méthodes et des propriétés qui peut se couper de mes cours et les mettre en un seul endroit, pour un entretien facile, plus courte et plus propre code.

    • Tout cela permet de maintenir le public interface propre à l'interne, l'on peut devenir très complexe avec cela, surtout si vous l'élargir à d'autres choses, comme les couleurs par exemple. Je pense que de simples fonctions ou méthodes statiques pour mieux ici.
    • J'aime le terme strategies.
    InformationsquelleAutor D. Marti
  4. 4

    Je suis très heureux pour les Traits, car ils résoudre un question commune lors de l'élaboration des extensions de la plateforme de commerce électronique Magento. Le problème se produit lorsque les extensions d'ajouter des fonctionnalités à une classe de base (comme par exemple le modèle de l'Utilisateur) en l'élargissant. Ceci est fait en pointant le Zend autochargeur (via un fichier de configuration XML) pour utiliser le modèle de l'Utilisateur de l'extension, et ont de ce nouveau modèle d'étendre le modèle de base. (exemple) Mais si deux extensions de remplacer le même modèle? Vous obtenez une "race condition" et que l'on est chargé.

    La solution actuelle est de modifier les extensions si on étend l'autre modèle de remplacer classe dans une chaîne, puis définissez la configuration d'extension pour les charger dans le bon ordre, donc l'héritage de la chaîne d'œuvres.

    Ce système provoque souvent des erreurs, et lors de l'installation de nouvelles extensions, il est nécessaire de vérifier les conflits et modifier les extensions. C'est une douleur, et rompt le processus de mise à niveau.

    Je pense à l'aide de Traits serait un bon moyen de faire la même chose sans cette fâcheuse modèle de remplacer la "race condition". Accordée, il pourrait encore y avoir des conflits si plusieurs Traits de mettre en œuvre des méthodes avec le même nom, mais j'imagine quelque chose comme un simple espace de noms de la convention pourrait régler ce, pour la plupart.

    TL;DR je pense que les Traits pourraient être utiles pour la création d'extensions/modules/plugins pour les grandes PHP progiciels comme Magento.

    InformationsquelleAutor thaddeusmt
  5. 0

    Vous pourriez avoir un trait de lecture seule de l'objet comme ceci:

      trait ReadOnly{  
protected $readonly = false;
public function setReadonly($value){ $this->readonly = (bool)$value; }
public function getReadonly($value){ return $this->readonly; }
}

    Vous pourriez détecter si ce trait de caractère est utilisé et de déterminer si ou non vous devriez écrire cet objet dans une base de données, fichier, etc.

    • Donc la classe qui serait use ce trait serait alors appel if($this -> getReadonly($value)); mais ce serait de générer une erreur si vous n'avez pas use ce trait de caractère. A cet effet cette exemple est défectueux.
    • Eh bien, vous avez besoin de vérifier si le trait est à utiliser en premier. Si la lecture seule caractéristique est définie sur un objet, vous pouvez ensuite vérifier si il est en lecture seule ou non.
    • J'ai fait un générique preuve de concept pour une telle caractéristique dans le gist.github.com/gooh/4960073
    • Vous devez déclarer une interface pour ReadOnly à cet effet
    InformationsquelleAutor Nico