Merci pour le tuto et judicieuses remarques sur la fin et le fait de ne déjà plus savoir d'où vient la méthode rouler utiliser, même dans un exemple aussi basique que celui-là... Alors en vrai avec plusieurs dizaines de traits, j'imagine bien qu'on s'y perd vite ^^'
@toupieornottoupie5165 жыл бұрын
19:00 "qui à trait à" ... joli le jeu de mots ^^
@yaokouassi51766 жыл бұрын
Merci infiniment! S'il te plait peut nous faire une video sur le pattern Command par exemple cas de la Console pour generer une instruction comme inserer des donnees dans la Base de donnees etc etc.. Merci!
@ArtcodEAscetik3 жыл бұрын
Ah ben ça, je ne connaissais pas! Merci pour l'info, ça va m'être utile.
@adilmourahi10 жыл бұрын
Super tuto "comme d'habitude". Juste une petite information : Les traits sont des "copie - coller", donc côté performance et vitesse ça coûte, alors que l'interface est "un policier qui vous rappel les codes de la route" et donc vous impose des règles. Merci
@StefTweet10 жыл бұрын
Super je me posais la question sur les traits merci
@ArtcodEAscetik3 жыл бұрын
L'avantage des méthodes abstraites d'un trait, c'est de permettre de déclarer des méthodes privées/protégées. Ce qui n'est pas permis par les interfaces
@rickert7810 жыл бұрын
Cool, merci pour ce tuto
@LordMakiavel10 жыл бұрын
Pour moi les traits c'est un peu les interfaces V2, non seulement on peut imposer la signature de méthodes pour uniformiser un comportement entre les classes (comme les interfaces) tout en pouvant coller des méthodes complètes qui seraient communes par la suite (énorme défaut des interfaces pour moi). Seul point à vérifier, savoir si on a le droit de les "typehinter" comme les interfaces en argument de méthode genre function bidon(monTrait $objetQuelconqueRequis) ce serait génial si c'était le cas...
@grafikart10 жыл бұрын
Selon moi les traits et les interfaces n'ont pas le même but. Je pense que ça serait un défaut de n'utiliser les traits que comme des simple "définition de méthodes". Comme tu le dis on ne peut pas les typehinter du coup ça réduit leur intérêt. Les traits ont vraiment une vocation différentes, celle d'apporter de l'horizontalité au niveau de l'héritage. Au final on a : Class : Héritage vertical Trait : Héritage horizontal Interface : Définition et typehinting
@LordMakiavel10 жыл бұрын
***** Ce qui serait peut-être judicieux (à toi de me dire ce que t'en pense), pour combiner les avantages des deux serait éventuellement de faire : - une interface iSlug qui définit les signatures du comportement attendu - un trait Sluggable qui implémente iSlug et qui écrit les méthodes ? Sauf peut-être une ou deux qu'on laissera à la classe car trop spécifiques - puis on implémente l'interface ET le trait dans une classe quelconque ce qui permettra de la typhinter en faisant (iSlug $monObjet) tout en évitant de SYSTEMATIQUEMENT recopier les même méthodes dans tous les objets car les comportements ont souvent beaucoup de code en commun... Donc on peut "importer" les méthodes toutes faites grâce au trait :D Comme ça, comme tu disais on garde séparés les signatures et l'héritage "horizontal", de plus, on pourrait tout à fait avoir deux traits différents qui implémenteraient la même interface différemment par exemple... Une solution élégante ou pas à ton avis ?
@SliiiiiiK10 жыл бұрын
***** Tout dépend ce que tu veux faire, en l’occurrence, ta méthode Slug devrait se trouver dans une classe (String, Formatter, ...) et non dans un Trait.