 Un mot un peu compliqué, un titre un peu compliqué, promis à bord, on va commencer un peu doucement, j'espère que vous avez bu bien de café, histoire de ne pas vous endormir. A ne pas le ver rapidement, qui a déjà fait la programmation orientée objets ? Ça va, c'est pas mal. Qui connaît les design paterne ? Toujours, ça va, c'est plutôt pas mal. Ok, donc j'espère pas trop vous perdre, on va essayer de métaphoriser un peu tout ça pour mieux comprendre comment on va industrialiser notre code. Donc rapidement qui suis-je, donc je m'appelle Thomas Donelin, j'ai 24 ans, et donc ingénieur en développement web chez Urplan, c'est une start-up lyonnaise où on fait essentiellement de la billeterie en ligne, la vente sur place, les imprimantes thermiques, tout ça, pour des organisateurs comme le WorldCamp, ça pourrait être super, c'est dans ces idées-là. Et je suis également auteur du plugin VP God, un plugin qui permet de traquer vos erreurs sur vos sites WordPress, vous l'installez essentiellement en production, c'est vraiment l'intérêt. Et ça vous remonte tout, tout votre notice, vos indefine index et compagnie. Et bon, aujourd'hui, il est en redeveloppement en version SaaS, bref, c'est pas le sujet du jour. On va partir d'un petit constat sur WordPress que j'ai fait, que je ne suis pas le seul à le faire. Ces WordPress évoluent vite, mine de rien, c'est évolué extrêmement vite en termes de fonctionnalité. Aujourd'hui, on avait perroquettes, on a du cash, on a du polylangue, on a un peu tout ce qu'on veut. C'est évolué vite grâce à la communauté, je ne sais pas combien, peut-être plus de 100 aujourd'hui. Si on est tous là, on fait tous évoluer WordPress un petit peu chaque jour. Et aujourd'hui, c'est 25% du web, ce n'est pas négligeable et c'est grâce essentiellement à cette communauté, mais aussi à une certaine liberté en fait. C'est-à-dire que pour démarrer du WordPress, un plugin ou un thème bêtement, c'est quelques lignes de code. C'est vraiment un plugin, au bout de dix lignes, vous avez un plugin, le plugin élo ne fait pas 36 lignes. Et pourtant, c'est un plugin. Un thème, c'est pareil. Vous avez votre fichier de style, un fichier de fonction, un fichier d'index et c'est parti, vous avez un thème. Il ne fait pas grand chose, c'est sûr, mais vous en avez un. Le problème, c'est que j'estime qu'il en laisse énormément, ce qui fait qu'on est peut-être tous là aujourd'hui, beaucoup de liberté, mais pour moi, il en laisse beaucoup trop. Beaucoup trop parce qu'on arrive à des fois, à faire des développements, sur un chantier comme celui-ci, n'importe qui arrive, à moi, j'avais pas telle convention, à moi, c'était pas comme ça. Souvent, on ne comprend rien. Et voici souvent ce qu'on retrouve en termes de fichier de fonction. Alors, pour être gentil, c'est un fichier de fonction que j'ai écrit il y a deux ans, je crois. Donc, c'est vraiment pour vous montrer que ça évolue. C'est, excusez-moi l'expression, c'est vraiment un bordel. J'y comprends rien. Aujourd'hui, je reviens dessus, je n'y comprends rien. Typiquement, là, il y a une petite fonction, là, contervue. Elle fait, elle fait des choses, elle fait, enfin, il y a trois lignes, mais on ne comprend pas ce qu'elle fait. Elle compte des vues, des vues de quoi, sur une single, sur une page, pour ensuite appeler une autre fonction qui update, c'est un contervu, avec un guide viril dit, OK, très bien. Je suis à ligne, il y a 100, le fichier de fonction, il fait 1000 lignes. Alors là, je ne vous dis pas, je vous épargne la suite, mais honnêtement, je ne veux jamais le revoir, ce fichier. Ce que, ça, à mon avis, c'est la tête que vous faites quand vous retournez sur vos projets 3, 4 mois après vos développements, avec des fichiers de fonction extraordinaires. Alors, il y en a certains, ils font, ouais, mais moi, maintenant, j'externalise, je fais d'autres fichiers. C'est bien, c'est bien. Il faut, c'est déjà une première industrialisation, une forme d'industrialisation de votre code. Vous déjà, vous externalisez, par exemple, tous vos customs post-tips, comme ça, vous revenez, ah bah oui, je sais, j'avais fait un fichier de customs post-tips. Mais tout le monde ne fait pas ça, et c'est énorme, c'est vous qui les avez définis, c'est pas WordPress, c'est personne, et c'est vraiment l'engagement de la communauté qui va dire, au sud des conférences et compagnies, que bon, bah, ça serait plutôt cool de faire ça. Pourtant, on écrit certes du code pour les ordinateurs, donc, pour qu'il interprète notre site web, mais l'ordinateur, que vous faites du PHP, du Ruby, du Python, il s'en fiche complètement, lui, c'est des 0 et des 1 derrière. Mais, enfin, c'est cool, mais bon, lui, ça ne le change pas sa vie, le fichier de fonction de milline, mais vraiment pas. Par contre, un humain, ça va lui changer sa vie. Un humain, quand il revient sur votre fichier de fonction, on a vu la tête creuser. Quand on code propre, cool, enfin, voilà, c'est plus agréable de revenir sur des projets qu'on comprend. Et vraiment, enfin, pour moi, l'unité de mesure d'un très bon code, c'est what the fuck à la minute que vous allez dire quand vous voyez votre fichier, en fait. C'est, ouais, il y a les tests, il y a les sites, il y a les sites, il y a la PO, mais la meilleure unité de mesure, c'est combien vous allez dire what the fuck, quoi. Plus vous le dites, plus c'est pourri. C'est vraiment, moi, vous le dites, mieux c'est, mais je vous rassure, même à très, très bon code, même le code parfait, vous allez en dire quand même. C'est un petit moment philosophique. Le code d'aujourd'hui est meilleur que celui d'hier, mais moins bien que celui de demain, c'est évident, ça évolue sans arrêt. Pour l'objet, donc du procédural vers l'objet. Parce que ce qu'on a vu, le fichier de fonction, c'est un code procédural. Il n'y avait pas de classe, il n'y avait pas de si, il n'y avait pas de ça. C'est vraiment du procédural. Procédural, c'est une flèche, je pars du haut et je vais vers le bas. Aller vers l'objet, c'est aller vers une programmation, on va dire industrielle, c'est quand même le but de la conf. C'est des petits engrenages, c'est plusieurs classes. Ce n'est pas des God Objects où vous avez une classe de 1000 lignes. Si vous mettez le fichier de fonction tout à l'heure dans une classe de 1000 lignes, rester sans la classe, c'est vraiment même. Et j'ai envie de dire qu'il était temps, parce que l'objet, c'est 1970. 1970, avec le langage Smalltalk, qui a démarré ça, normalisé, démocratisé avec le C++. PHP, il est arrivé plus tard. Forcément, c'est déjà un langage moins vieux. Donc en 2004, ça fait 12 ans. On est en 2016, ça serait peut-être tant de 6 mètres. Et pourquoi ? Parce que l'objet répond à beaucoup, beaucoup, beaucoup de problématiques, de conception sur vos développements. Ça, c'est un objet, c'est facile. Donc une classe boisson qui prépare un bière, qui prépare un café, pourquoi pas, un bière avec un peu d'alcool, éventuellement. Ça, c'est une fonction intéressante. Bon, voilà, je vous dis l'objet, vous rentrez, vous pouvez démarrer. C'est bon, on va faire des objets. C'est industrielle, ça. En réalité, moi, c'est ce que je viens de voir. C'était un bordel sans nom. Pourtant, il n'y avait rien d'écrit, mais je vous assure que c'était une catastrophe. L'idée, c'est de comprendre pourquoi. L'objet, c'est des principes. C'est des principes, notamment le principe solide, qui, rapidement, a entendu parler du principe solide dans la salle, à la main levée. D'accord, donc il n'y en a vraiment pas beaucoup. C'est quand on fait l'objet, on fait ça avant. Parce que faire l'objet sans ça, c'est faire un peu n'importe quoi. Et je considère quelqu'un qui fait un très bon procédural, a mieux compte de faire du procédural, que de tenter à faire un objet qui n'a vraiment pas de sens. Il y a une grotte, vraiment. Je ne suis pas là pour vous dire, ne faites plus de procédural. Pareil, ça dépend aussi du checker que va vous donner votre client. Si il met 100 euros, ne vous embêtez pas à faire des trucs bien. C'est normal. C'est beaucoup de termes un peu compliqués. Je vais essayer de vous les expliquer plus facilement. Pas tout de suite, juste après. Je vous les laisse comme ça. Vous pourrez regarder les slides. Je vous donnerai l'URL plus tard. L'idée, c'est que ça paraît compliqué, mais il faut surtout rester simple. Donc qui se paraît ? Vous avez peut-être entendu ce mot-clé. Qui pique stupide simple. Vraiment, plus vous serez simple dans vos développements, plus ça sera simple de revenir ensuite. Un code, un très bon code objet, ça s'ilit. Même quelqu'un qui n'y comprend rien, je peux lui faire lire un code objet. Il va me dire, oui, ça fait un peu près ça. Alors il sait pas ce qui se passe dans les entrailles, mais il va me dire, il lit, il fait, oui, ça fait des choses. Ça fait des choses et je comprends plus ou moins ce que ça fait. On va rester simple et donc pour rester simple dans notre code, on va industrialiser maintenant. Pour industrialiser, c'est atomiser les comportements. Donc de manière très simple en procédural, par exemple, faire des fichiers un peu partout. Et surtout penser service. On parle de programmation objet, mais comme on l'a vu, l'objet tout à l'heure qui était un foutoir, j'ai plus envie de parler de service en fait. En atomisant les comportements, ça va vraiment être la réflexion qui va être amenée, c'est de penser service. Pour penser service, on va reprendre nos cinq petits critères tout à l'heure, on les simplifie un petit peu. On va démarrer, on va dire que mon service est indépendant. Indépendant, c'est... Imaginez, vous êtes enfin... c'est des entreprises, vous avez votre service comptabilité, votre service informatique, votre service X, c'est un service. Il est indépendant. Si vous sortez votre service comptabilité de l'entreprise, il marche toujours. Vous vous externalisez peut-être votre comptabilité. C'est un service. Si on parle de boisson, de bière et de café, ma machine Nespresso, c'est un service. Elle me prépare mon café. Le SodaStream, il me prépare le gazeuse. C'est un service. Ils sont tous indépendants. Vous avez tous ces petits objets chez vous éventuellement. Donc première chose, quand on fait une classe, quand je dis service, pensez classe. Quand on va faire une classe, pensez qu'elle doit être indépendante. Toute seule, elle peut marcher, elle peut faire des choses. Par contre, on va lui dire des petites choses à cette classe. Donc elle ne sait faire déjà qu'une chose. Ma Nespresso, elle ne prépare pas du café. Elle ne prépare pas de la bière. Elle ne prépare pas d'autres trucs. Elle prépare du café. C'est pareil, le service comptabilité ne va pas réparer votre imprimante. Il ne sait pas faire. C'est le même principe. Votre service ne sait faire qu'une seule chose. Je le laisse tranquille quand il marche. Une fois qu'il est en prod, il faut s'amuser à le trifouiller. Une classe qui tourne, un service qui tourne, imaginez 5 minutes que vous avez 60 000 sites, des péroquettes, avec un installation de plug-in. Imaginez que vous touchez une classe qui peut impacter beaucoup de choses. Pourtant, la classe, elle marchait. Pourquoi vous allez la trifouiller ? Vous allez devoir tout retester. Bien pour ceux qui ont fait des tests unitaires, mais moi, je n'en fais pas tant que ça. Tout retester, c'est du temps. Vous avez cette classe tranquille, vous l'étendiez, vous l'héritiez, vous la décorez, vous ne cassez pas votre code sur les 60 000 sites. En revanche, vous l'améliorez pour ceux qui font la mise à jour. Et ceux qui ne la font pas, ou même ceux qui la font, ça sera tellement cloisonné, ça ne va pas impacter votre code. Mais vraiment, c'est pas possible. LISCOF Substitution. Si on l'améliore, on ne change pas toute la logique. Si vous améliorez votre service comptabilité, votre directeur est tout foutre en l'air, mais vous évitez de tout casser quand un service y tourne, quand votre machine n'asperce soit elle tourne, si vous voulez qu'elle prépare de la bière, vous n'avez plus qu'à expérer qu'il y ait un plugin, une extension sur la machine qui vous prépare votre bière à côté, mais vous n'ouvrez pas la machine à trifouiller le circuit intégré pour qu'elle prépare une bière. Elle tourne, on la laisse tranquille, et si on l'améliore, on laisse quand même ce qui marche. Je lui fasse des conventions. Ma machine pour qu'elle me fasse mon café, c'est une convention. Elle a besoin de cette capsule pour vous faire votre café. Le SodaStream, c'est pareil, il a des conventions souvent de bouteilles quand vous les mettez pour faire votre gaseuse. Il a des conventions. Il y en a qui prennent plusieurs conventions, vous pouvez créer d'autres capsules qui ont les mêmes conventions, et vous pouvez la mettre dans la machine d'Aspresso, ça marche aussi. Pareil pour votre service, pour votre classe, on lui donne des conventions. C'est les interfaces, qui parallèlent un peu techniques, ce qu'on appelle les interfaces en objets, c'est ce qui va vous permettre de faire des conventions. C'est ce dont il a besoin pour travailler. Ma machine d'Aspresso, sans capsule, elle ne fait pas de café. Donc il faut lui donner. Pareil pour le service, ce n'est pas à lui de savoir d'avoir dans son paquet ces capsules, c'est vous qui allez lui donner. Maintenant qu'on a vu tout ça, reprenons notre petite classe de tout à l'heure, donc ça retourne en arrière. Pourquoi moi, c'est une catastrophe, parce que ma classe boisson, on est déjà hyper mal nommée, elle pressait préparer une bière et aussi un café. Donc elle n'est pas dépendante et elle sait faire deux choses. Une boisson qui sait préparer une bière à un café, c'est assez fort. Elle est dépendante de la sortie. Donc de la sortie, je parle du eco. Là, ça affiche à l'écran. Mais moi, la bière, je l'avais en main. Et pourtant, si je veux vraiment ma bière en main, je vais devoir aller modifier ce code-là, on casse le principe d'open close. Je suis en train de trifouiller mon circuit intégré. Du texte que j'écris. Là, il y a un peu d'alcool, mais moi, j'en veux beaucoup. J'avais modifié la classe. 60 000 sites vont être impactés par ce changement. Est-ce qu'il n'y en a pas qui voulaient toujours un peu d'alcool ? Alors oui, on peut faire des switch, oui, on peut faire des ifs. Mais l'objet, avec tous ces principes, vous aurez toujours les switch et les ifs, c'est pas l'idée de les supprimer, mais ils seront beaucoup plus logiques. C'est des petits engrenages qui vont faire que ça marche tout seul. Avec un peu de code quand même, mais ça marche. Maintenant, dans WordPress, pour moi, il y a deux petits problèmes pour démarrer l'objet, qu'on va essayer de dégrossir un petit peu. Prolème numéro un, c'est que qui dit programmation orientée aux objets, donc service, fait qu'on a beaucoup de fichiers. Rappinement, sans même écrire une ligne de code, si vous avez votre service qui prépare des boissons, une classe, j'ai des conventions, donc je vais avoir quelques interfaces, on va dire peut-être deux. Une troisième pour l'appeler, un handler, j'ai encore rien écrit, je suis à cinq classes, ça fait cinq fichiers. Un projet très bien formé, ça peut monter à 150 fichiers, mais ça ne doit pas vous faire peur. Un nombre de fichiers ne doit pas vous faire peur. Après, vous allez vous retrouver, avec le nom des classes, le nom des patterns, vous allez vous retrouver tout seul. Donc déjà, là, sur un chantier, quelqu'un qui connaît l'objet, il ne va même pas vous poser la question où est-ce que tu as mis ça. Ok, c'est le design pattern factory. Pas 50 require, non, pas 50 require. Un namespace, enfin dnspace, un autoludder, un composer. Ça, c'est des choses que vous devez connaître, je pense composer un petit peu. Autoludder, vous avez certainement dû en entendre parler. Namespace, c'est un mot de clé, un mot de clé, objet, qui va un peu, c'est une histoire de bibliothèque. Donc on va démarrer avec mon Namespace Worldcamp. Là, c'est comme si tout le CAP 15, c'est mon Namespace Worldcamp. Ici, on est dans Namespace, ça le deux. D'autres côtés sont ça le un. Et je vais mettre ma classe en-dessous de mon Namespace. Donc ma classe, c'est une bière, je la mets dedans. Donc je la catégorise, je la mets quelque part. Ensuite, j'écris mon petit composer. Là, ce qui nous intéresse, c'est la partie, donc autolud PSR4. Donc c'est la norme PSR4. En premier, on met Worldcamp le nom d'une Namespace, avec deux antislages, c'est la norme de Namespace. Et ensuite, on met la source. Où est-ce qu'il se trouve ce Namespace ? Il faut bien lui dire où est-ce qu'il faut qu'il commence à chercher le Worldcamp. C'est pareil. C'est la même chose. Donc là, mon composer est à la racine. Mon Namespace démarre aussi à la racine. J'ai un dossier Worldcamp. Et c'est parti. Il peut aller les chercher dedans. Je lance la commande ComposerDump. Il me génère des fichiers autolud. Et j'ai plus qu'à faire ça. Je démarre mon plugin. Tout en haut, je dis à mon odeur, tu me récroyes l'autolude. Et vous avez plus qu'à utiliser. Plus un seul récroyeur. Ça ne sert plus à rien. Use Worldcamp une bière. Vous utilisez, dans le Worldcamp, je veux une bière. Elle se situe dans le Namespace Worldcamp. Je vais la chercher. Et vous pouvez faire bière. Vous avez installé votre bière. Vous n'avez pas de récroyeur. Vous n'avez pas besoin de chercher. Pourquoi, ou comment il la récroyeur ? Est-ce que je les récroyeur au bon moment ? Ça, on ne sait pas. Le problème numéro 2. On parle de services. On parle de beaucoup de services. Mais on ne sait pas quand on va les insancier. Il y en a qui mettent du statique. J'ai discuté cette semaine avec Julien Maury, qui avait mis deux statiques sur son plugin. J'ai réussi à le convaincre. Pourquoi il ne fallait pas en mettre ? Le statique, c'est une vraie utilité. Ne mettez pas de partout. Avec du statique, vous perdez le fait de pouvoir faire des expressions. Vous perdez plein de choses. C'est un contexte. Si vous démarrez statique, vous continuez tout statique. Parce que sinon, c'est vraiment le boxon. Et d'autres qui vont dire, « Bon, au final, ma classe toute première qui va être insanciée, je lui insancie tous les services. Comme ça, je les ai toutes dans le constructeur et je ne me pose pas la question. Si vous faites ça, c'est que vous n'avez pas compris d'ailleurs sur les services indépendants et compagnie. C'est le temps de comprendre. Donc on appart les services par l'on-service-conteneur. Tout bêtement, c'est ça. Si vous avez votre grosse boîte bleue, vous mettez tous vos services dedans. Imaginez qu'à l'entrée de votre petite boîte bleue, vous avez un petit interphone qui dit « Je veux services qui préparent des boissons. Je veux mon service qui fait si je veux mon service comptabilité. Et ce service va vous fournir la classe. Il va l'instancier s'il n'existe pas. S'il n'existe, il ne va pas s'amuser et il n'a rien instantié, ça n'a pas de sens. Surtout en PHP. Il va vous la donner et vous pourrez travailler avec votre service. Donc ça c'est avant. C'est plutôt joli. Mais ça ne répond pas au principe d'indépendance du service et compagnie. Donc là je me suis dit, ok, j'instancis tous mes services en début. Le problème, c'est que là on n'est pas dans le principe d'injection de dépendance. Donc le fait de donner un autre service dont il a besoin. Là on ne lui donne pas, c'est lui qui le sait tout seul. C'est un catastrophe. Il n'est pas censé savoir qu'il a besoin de ce mail service. Il est censé savoir qu'il a besoin d'un mail service, d'une convention d'un mail service, mais c'est à nous de lui donner. Ce n'est pas à lui de se dire, tiens je vais le prendre. C'est-à-dire que vous êtes complètement, cette classe est totalement dépendante de ces 3 services. On ne peut pas s'en défaire. Alors je suis d'accord qu'en termes UML, composition, agrégation et compagnie vous pouvez un ordinateur, enfin un clavier a du mal à vivre sans ordinateur, mais c'est possible. Mais donnez lui ce dont il a besoin. Encore une fois même si le clavier ne vit pas sans votre ordinateur, vous pouvez très bien changer de clavier. Donc je vous donnez à votre ordinateur ce dont il a besoin. Voilà ce que ça donne après avec le service conteneur. C'est tout de suite plus léger. Plus léger et facile à lire. Je pense que quelqu'un qui n'y connaît rien devrait plus ou moins réussir à lire. J'ai plutôt mis un écrit, j'espère. On a une fonction qui prépare des boissons. Avec une certaine convention, il faut absolument qu'elle sache qu'elle connaisse cette interface. Donc déjà, vous ne pourrez pas rentrer dans cette méthode si vous n'avez pas votre interface. Ça va vous sauter à la figure, PHP va dire non, non, je ne sais pas faire. Et la fonction elle dit, je prends le service qui prépare des boissons et je prépare ma boisson. C'est lisible. C'est lisible, c'est une ligne de code. C'est maintenable. Vous revenez, tout va bien. Si vous voulez envoyer des boissons, une bière, un café, de l'eau, de ce que vous voulez il sera la préparer. Le service, il s'en fiche comment on la prépare. Lui, ce qu'il veut, c'est une boisson, c'est tout. Après, il sera la préparer. La logique sera dans la fonction préparer. Petit bonus, c'est le use container service. Très. Très, c'est un mot clé en objet aussi. En fait, c'est une classe que vous utilisez. Sur d'autres endroits. En gros, dans ce container service très, il y a toute la logique de service, dans un use, c'est une sorte d'héritage multiple. Donc c'est vraiment le mot clé très. TRIT, ça existe. Maintenant, le problème, pour moi, il n'y a plus de problème. S'il y a d'autres problèmes, ce n'est pas des problèmes liés à WordPress. Vous pouvez faire des objets, à certains endroits, ça va marcher. Si vous avez d'autres problèmes, c'est des problèmes de conception. Je vous ai bien bassiné avec mes services, mes classes et compagnie, quand est-ce que c'est difficile au début de se dire, bon, comment je vais abstraire tout ça, quand est-ce que je dois faire une classe, quand est-ce que je dois faire si, quand est-ce que je dois faire ça. Ça, travailler, travailler, travailler, coder, coder, ça va venir tout seul. Ou les aider des bouquins qui vous expliquent certaines choses ou des choses comme ça. C'est vraiment, ça sera des problèmes théoriquement de conception que vous devriez avoir. Je vais vous donner deux petits exemples. Un exemple dans WordPress où on veut exploiter mes custom post-tip. Je ne sais pas pourquoi le client veut exploiter ces custom post-tip en JSON. Il est content, il veut ça. J'ai une fonction actuellement, souvent, ce qu'on peut retrouver, qui exporte custom post-tip. J'envoie mes valeurs, mon type, par des faux JSON. Je suis gentil parce que moi, je vais faire de l'xml, donc au cas où, je vais faire un switch xml, comme ça, s'il me demande, je saurais faire. Par contre, je ne veux pas surcharger la fonction, je ne veux pas qu'elle soit trop lourde à l'air relire, donc je remets une autre fonction. Une fonction compliquée pour le xml, parce que c'est un peu plus compliqué que le JSON. Donc super, mais où est-ce qu'elle est cette fonction ? Est-ce que vous l'avez récroyé au bon moment ? Est-ce que vous avez fait ça ? C'est long, c'est lourd. Ça, moi, je n'aime pas trop. Pour faire ce genre de choses, on a ce qu'on appelle le pattern de stratégie. Donc un patron de conception qui, en fait, l'export JSON ou xml, c'est une manière d'exporter. Je vous voulez JSON, vous voulez xml, mais demain peut-être qu'il revient à vous voir un xml. Pourquoi pas ? S'il a envie, s'il paye, on va te le faire, il n'y a pas de problème. Là, on a simplifié la fonction. On fait un switch, toujours sur le type. En fait, c'est qu'est-ce JSON, ce n'est pas qu'est-ce type. What's the fuck ? Donc qu'est-ce type ? Je crée ma nouvelle stratégie. Donc, il veut un JSON, je fais New JSON Export Strategie. Il veut un xml, bah, on va mettre le xml dedans. Ça sera New, xml Export Strategie. Il veut un autre truc qui sort demain que je ne connais pas encore, bah, New autre truc qui sort demain que je ne connais pas encore. Et après, cette fonction, elle n'est pas celle qui fait ça, elle n'est pas censée savoir comment exporter. Par contre, elle a son conteneur avec elle derrière elle. Donc, elle dit, ah, j'ai appelé un service qui exporte, je vais dire, prends ma stratégie d'export, JSON ou xml, exporte ces valeurs. Elle, elle n'en a rien à faire comment ça marche. Le service, c'est un service qui sait faire, qui fait pour ça, la stratégie, on lui dit comment il va devoir le faire. Donc, il va prendre l'engrenage. Là, c'est vraiment l'engrenage. Je prends mon service qui exporte, je prends mon engrenage de la logique d'export, je lui donne mes valeurs et c'est parti. C'est facile à lire, c'est facile à maintenir et aller beaucoup plus loin. Et oui, on peut en avoir besoin, même dans WordPress. On peut exporter en JSON, on peut exporter en xml. Donc ça, c'est un développement annexe que j'avais fait. Et tout est, et tout est dynamique, c'est-à-dire que demain, la personne me demandait de faire un export CSV. J'avais juste à créer l'export CSV, j'avais juste à rajouter dans le switch la logique et tout, tout, tout se faisait tout seul. J'avais juste écrit la logique d'export. Le bouton se créait tout seul. La logique d'export se créait tout seul. L'export aussi pareil. L'export, elle vous a dit, je veux un fichier, mais si demain, elle veut vous l'envoyer par mail. La logique de téléchargement de fichiers, la logique d'envoyer d'email, c'est une stratégie. C'est une manière de faire les choses. Le choix d'une base de données aussi, c'est une stratégie. Vous avez choisi ma SQL, mais les naïfs veulent peut-être Postgre, Mongo. C'est un choix. Autre exemple, je vais avoir des règles de gestion. Tout le monde a déjà écrit ça. Peut-être parole, parce que je vous ai dit peut-être parole, mais tout le monde a déjà écrit dans sa vie, à mon avis, user role, égal, égal admin. Je suis gentil en plus, on met la triple égalité comme ça, on est sûr que c'est un string. C'est bien, mais c'est moins maintenant. Je le fais, je le fais encore aujourd'hui. Encore une fois, ça va dépendre. Il faut être pragmatique après. Est-ce que j'ai le temps ? Est-ce qu'on m'a donné le budget pour le faire ? Est-ce que c'est intéressant de le faire ? Si vous faites les choses à chaque fois en pensant, non, il n'y a pas d'essuie. On fait ce qu'on nous a demandé, en fonction de ce qu'on peut faire, du temps et de l'argent. Donc ça, c'est moins maintenant, parce qu'on est dépendant d'admin. Si mon collègue à côté, il me dit j'ai écrit admin avec deux n, il faut changer les 50 fichiers ou ce que j'ai écrit, user role, égal, égal, égal admin. Il faut retester les 50 fichiers, il faut retester vos développements, tout refaire. Pour ça, il n'y a pas d'air de spécification. Vous avez votre spec, vous créez votre spec, new et admin. C'est une classe qui n'a pas de parenthèse, ça se tend si tout seul. Vous créez new et admin. Donc la logique est dans cette classe. C'est une des classes très petites. Elle fait 25 lignes. Et je teste ma spec. Je teste si ma spec est satisfaite par la valeur que je l'envoie, par le user. Donc je l'envoie le user et tous les engrenages vont s'enchaîner pour me dire s'il est admin. Pourquoi c'est mieux que tout à l'heure ? Parce que si demain sur les 50 fichiers vous en avez un modifié et vous devez rajouter une condition, c'est aussi simple que ça. Pas de pipe, pas de truc. Vous rajoutez ou, elle conférencie par exemple. Et ça passe tout seul. Le if n'a pas bougé. Imaginez que ces deux parties de code soient séparées. Le if ne bougera jamais. Vous ne touchez pas votre code. Vous n'avez même plus à vous en soucier. C'est les specs que vous allez lui envoyer. Je lui donne ce dont il a besoin. Et ça va marcher tout seul. C'est génial. Comme ça, si le collègue d'à côté il ne s'est plus écrit admin et qu'il m'a foutu de zen, je le change dans la spec. Et ça change sur les 50, sur tous les ifs. On industrialise notre code. On maintient notre code. C'est plus lisible. C'est plus portable. C'est plus facile à versionner. C'est tout plus facile. Ce qui est plus compliqué par contre, parce qu'il y a quand même un inconvénient, c'est que c'est moins accessible au nouveau développeur. Ça demande des notions en plus. Notamment de connaître déjà la programmation d'objets. Un peu de design paterne. Un peu de tout. Mais ça, ça prend. Vous voyez qu'il y a deux ans j'écrivais encore des fichiers de fonction de 1000 lignes. Et oui, on peut en avoir besoin. Ça, c'est un exemple que vous avez sur le plugin de VP God. Vous pouvez avoir des règles pour ignorer vos fichiers. ACF, c'est pareil. Vous avez des règles. Vous connaissez mieux ACF, je pense. C'est pareil. Et bien ça, en bac, le traitement qui est fait, c'est 40 lignes et je ne les touche jamais. Je veux rajouter un select. C'est une spec. A rajouter. C'est une classe de 15 lignes. Et je ne les touche jamais. Mais vraiment. Et tout ça, c'est une factorie, un autre design pattern, qui va construire et va me dire, bon ben il m'envoie telle valeur telle condition de test, telle machin, il construit toute l'aspect et j'ai une ligne qui me dit, si oui ou non, il faut nier un fichier. If spec satisfied, bye. Et c'est terminé. Dans MyPress, architecture conseillée, donc rapidement, il me reste combien de temps ? C'est huit minutes, oui. Architecture conseillée, donc en termes d'objets, en termes de dossiers, parce que maintenant, où est-ce qu'on met tout ça ? 15 minutes, ok. Ah ben ça va, il y a le temps, on va prendre le temps. Interspace indispensable, que je pense que ça serait cool que WordPress il le met dans son corps. Il a mis un peu d'objets, j'ai des critiques sur ces objets, mais encore une fois, enfin, dès que je fais une code review, même mes propres codes reviews, moi je me critique tout seul. Toujours ce what the fuck à la minute. Alors j'en ai moins, petit à petit, mais j'en ai toujours. Un code abstrait est totalement abstrait, totalement parfait. C'est des années de développement. Par contre après, oui effectivement, je connais des gens qui sont capables de passer de symphonie à Zen dans 30 minutes. C'est génial. Mais il a mis un an. Interface indispensable, donc hooks, interface. Alors je vous ai mis hooks ou wixables si vous êtes des... vous venez de Java, si vous venez de .NET. Voilà, ça c'est l'énorme, vous faites ce que vous voulez. Moi je mets interface. C'est comme ça. Enfin ça dépend des jours aussi. Hooks font interface, hooks admin interface. Hooks, ça doit vous parler. Ce qu'on appelle les hooks dans WordPress, c'est les add-action & filter. Donc tous mes services, toutes mes classes qui vont implémenter ces interfaces, ces conventions vont avoir obligatoirement une méthode hooks. Elles n'ont pas le choix sur la convention. Ce qui fait que je vais pouvoir lancer toutes mes actions et mes filtres en une boucle. Et je différencie front et admin pour dire, est-ce que tu le lances quand t'es admin ou est-ce que tu le lances quand t'es en front ou est-ce que tu le lances quand t'es sur les deux. Activation, déactivation, c'est pour les plugins. Donc qu'est-ce que tu fais quand t'actives le plugin ? Qu'est-ce que tu fais mon service quand tu te désactives ? Les options, par exemple, les options d'un plugin, quand vous activez, vous activez peut-être des options par défaut. Vous avez un service qui sait gérer des options. Qu'est-ce que tu fais quand tu les désactives ? Est-ce que tu supprimes certaines options ? Est-ce que tu clines tout ? Et ordres interface, ça c'est pour gérer l'ordre de tout ça. Parce qu'il y a forcément des fois vous avez besoin d'un certain ordre d'exécution. Il faut que d'être là et de paniquer, j'ai fait 50 objets et en fait, ce qui m'a dit, c'est n'importe quoi. Maintenant, mettez ordres interface et une fonction, c'est un return, le numéro d'exécution et s'exécutera dans le temps qu'elle le souhaite. Le reste, c'est pour vous. Après, vous d'inventer les vôtres. Il n'y a pas de règles d'ordre là-dessus. Mais ça, je pense que c'est des interfaces qui seraient essentielles à WordPress parce que maintenant, dès que je commence un projet, je les embarque avec moi. Il y a mon plugin, la racine du plugin à cette fonction. Il a donc son container de service, donc il peut récupérer les services, il fait viz get services, il valit où. Et dès qu'il voit que c'est une instance de hooks, bah il y a hooks. Voilà. Très simple. Là, je vous ai pas mis le switch case pour instance of admin ou front. Si vous en avez peut-être pas besoin. Mais voilà, c'est pas plus long que ça et ça se fait tout seul et ça exécute les filtres. Les filtres, on n'exécute pas sur un public fonction construct. D'où un service est capable, au moment où il se construit, de faire des filtres. Ça n'a pas de sens. C'est une fonction qui fait ça et vu que c'est une fonction qu'il le fait tout le temps, bah c'est une convention. Tout ça, c'est des engrenages. Petit exemple, comment j'architecture mes dossiers? Mon name space, vous n'avez pas trop de choix. Ensuite, j'aime bien mettre, donc, dans models, je mets mes interfaces, on leur service, factory, specification, ce que vous voulez. Vous organisez, ensuite, intelligemment, en fonction de ce que vous voulez faire. Et là, je vous ai mis ensuite WordPress et vous voyez qu'il y a deux widgets. Qu'est-ce qui se passe dans WordPress? Qu'est-ce qui se passe avant? Tout ce qui est pas dans le dossier WordPress, c'est de la logique métier du code. Tout ce qui est dans WordPress, c'est de la logique WordPress du code. Donc tout ce qui est dans models, on leur service, machin, il n'y a pas de interface hooks. Elles n'en ont pas besoin. Elles vont jamais avec WordPress. C'est la logique métier. C'est un code que je pourrais prendre sur un autre projet en PHP. Ça marcherait tout seul. Ça aussi, c'est encore l'avantage. Je n'ai pas dit sur la programmation object. C'est que, une fois que vous avez développé vos outils, bah, vous n'avez plus besoin de les redevelopper. Vous avez une libraire et avec vous. Et donc, widgets, c'est parce que peut-être que widgets, j'ai la logique métier pour des widgets. Là, je n'ai pas d'exemple sous la main, mais ça peut... WordPress, comment on fichait le widget, comment il doit travailler, quel template il veut. C'est dans WordPress. Lui, il saura faire. Et donc, maintenant, c'est ce que je viens de dire. Donc, copiez-collez plus votre code. C'est dangereux. C'est vraiment dangereux. Vous faites un bouton. Vous voulez faire le même bouton. Si vous copiez-collez votre code, vous allez le modifier. Ça ne va pas être la même chose. Vous allez parfois oublier. Vous allez dire, oui, mais ce paramètre, je le supprimerai un jour. Vous le supprimez jamais. Maintenant, plus vous codez, vous faites vos stratégies et plus vous implementez, en fait, vous créez votre librairie. Moi, l'Export JSON, l'Export XML, je les ai, peut-être fait, enfin, que j'ai fait le développement. J'ai plus jamais, de ma vie, réécrit un Export JSON, un Export XML. Plus jamais. Ça ne sert à rien. Je l'ai fait une fois. Le service, il marche, et comme je vous ai dit, c'était une logique métier. L'Export JSON n'est pas lié à WordPress. L'Export XML n'est pas lié à WordPress non plus. En revanche, oui, ça l'est. Donc, lui, je ne peux pas me tremble n'importe où. Mais l'Export JSON, en tant que tel, je peux le mettre où je veux. Ça marche. Je le mets dans un projet symphonique. Ça marchera partout. C'est ça, industrieliser son code. C'est ça, d'aller beaucoup plus loin, au niveau, plutôt que le procédural. Le procédural, c'est vraiment une flèche toute droite. Et quand vous voulez faire des changements, vous copiez-collez, vous vous rajoutez, vous vous rajoutez, vous vous rajoutez. Vous écrivez du code, ça marche. C'est plus intelligemment. C'est peut-être un petit peu plus long, mais plus vous en faites, plus ça va vite. Mais après, c'est génial. C'est comme un starter-thème. Et encore, un starter-thème, quand vous le démarrez, soit des fois, vous oubliez de supprimer des fonctions inutiles, soit vous n'utilisez pas tout, soit vous l'améliorez. Donc, ce n'est pas un service. Mais vous proliez le transformement en service, maintenant, théorie, après avoir vu tout ça. Quelques ressources. Donc, vous irez sur les slides. Enfin, je tweeterai l'URL pour que vous ayez accès aux slides et donc, ressources. Librérez sur GitHub que j'ai développé, qui s'appelle Skype Press. Il y avait une première version, donc j'ai appelé Alpha il y a un an, qui est trop complexe, trop abstraite, trop compliqué à rentrer dedans. Donc, vous ne vous en souciez pas. Là, c'est un master que j'ai refait juste pour que vous ayez un exemple. Il y a le pattern de spécification. Vous pouvez l'utiliser si vous voulez le prendre. Vous pouvez refaire l'interface que je vous ai montré tout à l'heure la logique, métier, de test de condition. Et là, vous n'avez plus qu'à vous s'en servir. Mais vraiment, c'est facile. Et si vous ne comprenez pas, bien, vous pouvez me voir, vous pouvez me tweeter, vous pouvez me demander. C'est normal aussi de ne pas comprendre tout de suite. Ça peut arriver. Les deux liens en dessous, c'est des livres, des livres qui sont super cool. Un sur les designs pattern. Donc, ça y est, ce livre a été édité en 91. Je venais tout juste de naître. Vous voyez qui, ça a été fait par le gang en fort. Donc, c'est des bonhommes qui sont très forts. Et il va vous, c'est des designs pattern qui sont connus et qui sont avérés, qui ont toujours marché. Ça fait 24 ans qu'ils marchent. Et essential skill, fort agile développeur. Oubliez le mot-clé agile. Enfin, agile, c'est un peu de tendance en ce moment. Mais ça n'a rien à voir vraiment avec le fait d'être agile. Ça va vous donner des bonnes pratiques. La programmation par intention, c'est génial. Pareil, ça va vous reparler encore des designs pattern. De toute façon, si vous commencez à faire de l'objet, les designs pattern, vous allez en manger. On vous en parlera tout le temps. Voilà, n'hésitez pas à les acheter. Ce sont des liens qui vont sur Amazon. Je n'ai pas d'argent dessus, rassurez-vous. Ils ne coûtent pas bien cher et ils sont vraiment cool. Et puis, vraiment des designs pattern, une fois que vous commencez à les connaître, vous l'avez toujours sur le coût parce que je ne les connais pas. Je connais les noms, mais je ne sais pas exactement comment les implémenter, donc il faut bien les retrouver. Merci à tous pour m'avoir écouté. Si vous avez des questions, tout de suite, vous pouvez les poser. Ou après la con, vous pouvez venir me voir. Pas de soucis, ou me tweeter, ce que vous voulez. Merci Thomas. Alors, il y a-t-il des questions ? Donc, on est ici. Votre plugin, Oh My God, il est... C'est pas God Dieu. Julio m'a fait changer parce que God Dieu, ça ne marche pas en l'international. Bon, il est en... Dans votre langage, là, on peut lire, on comprend... Il faut l'acheter. Il est payant. Après, je peux vous montrer le code source si vous voulez. Mais après, c'est pareil. Je le fais, encore une fois, je le regarde maintenant, je vois des what the fuck de partout. Il y en a encore à améliorer. Mais oui, toute la logique, il y a un objet du plugin. Sinon, avec un minimum de what the fuck, aller plutôt sur Skypress, sur GitHub, enfin, sur le lien que je vous passerai. Là, c'est vraiment un objet un peu plus intéressant parce que VP God, je l'ai développé en deux semaines. Donc, il y a des choses où je suis passé autres. Même si ça n'engage que les auteurs, que pense-tu du code des, on va dire, cavaliers, les 10 plugins les plus téléchargés sur WordPress ? Versu officieuse officielle. Voilà, les deux, comme ça, se sera fait. Non, honnêtement, c'est un, un bon code. Enfin, par exemple, pour parler de roquettes ou d'imagifages ou des choses comme ça, je vais les voir le code. C'est du bon code. C'est commenté. Il n'y a pas de problème. J'ai vraiment pas de problème avec le procédural ou des choses comme ça. Même quand les gens tentent de faire l'objet, il faut bien démarrer un moment donné. Maintenant, si je dois faire une code review, oui, ça fait mal. Mais c'est pareil. Moi, mes propres codes reviews que je me fais, c'est, il y a, est-ce que on est dans l'aspect critique, est-ce qu'on cherche à faire évoluer notre code ou est-ce que, enfin, le plugin, enfin, les proquettes, même s'il n'est pas tout objet, ça marche, ça marche très bien. Si vous ne voulez pas vous casser la tête, faites du procédural. C'est pas le souci. Mais vraiment, oui, après voilà, si il faut faire toute manière, n'importe quel code review, même le code le plus parfait, on trouvera encore des trucs à redire. Mais voilà, après, parce qu'ils ont fait de l'objet, mais c'est pas du bel objet. C'est du, il y a trop de statiques. Statique, c'est un vrai, c'est un vrai sens. On fait pas du statique pour se dire, comme j'ai dit tout à l'heure, j'ai pas envie de faire un new. Moi, personnellement, une bière, si elle existe pas, je peux pas la boire. Faut bien qu'elle soit instantiée. Donc si, c'est, c'est vraiment, il y a des notions, mais voilà, c'est, c'est à voir. Merci. Bonjour. Merci pour la présentation. En fait, concernant la, le design paterne spécification, je me demande, est-ce qu'on peut instantier de manière dynamique, entre parenthèses, introspection ou réflexion, les classes spécifications? Sinon, est-ce que, bon, la ma deuxième question, est-ce que c'est, c'est classe? Est-ce qu'elle, qu'elle implémente quoi, comme interface pour être des spécifications? Alors, en interface de mémoire, bon, il y a orx, indyx, l'abstract spec, avec les méthodes spécifications, le note, pour faire l'inverse. Alors, pour revenir à la première partie de la question, c'est-à-dire dynamique, c'est-à-dire créer, par exemple, et admire dynamiquement. Oui. Ça, je n'ai pas encore le cerveau pour savoir le faire, mais peut-être que oui. Donc, je ne vais pas me prononcer là-dessus, mais c'est possible, parce qu'on peut faire de la création plus ou moins dynamique, on peut faire des classes anonymes ou des choses comme ça. Donc, ça peut être envisageable, mais à mon avis, c'est très compliqué. Par contre, sur la librairie, si vous voulez aller voir, j'ai toute une factorie, en fait, qui créé tout seul, en fonction des conditions que je l'envoie et des besoins, va créer les spécifications qui existent dans ce cas-là, mais qui va les créer et qui va faire tout de suite tout à elle seule l'aspect. D'accord. Sinon, pour la deuxième question, les interfaces que vous avez, que vous venez de citer, et sont natives en PHP ou je dois importer une? Non, faut tout refaire à chaque fois. PHP, il n'y a pas grand chose de natifs là-dessus, il faut les refaire. Mais pareil, elles sont faites une fois quelque part, vous les trouvez, vous les copiez et collez. Je parle surtout des interfaces à implémenter. Mais les interfaces, c'est vraiment, enfin, c'est des classes qui, une interface, c'est un interface indique, par hantèses, par hantèses, deux publics fonctionnent. C'est vraiment en trois lignes. Mais non, vous pouvez, pareil, encore une fois, sur la librairie, celle que j'ai mis en ligne, vous voulez prendre, il n'y a pas de soucis, ça réimplément en ligne à chaque fois. Je comprends. Merci. Oui. Merci, Thomas. Et chapeau, parce que t'es impressionnant. Il faut le dire, parce qu'à cet âge-là, on en voit pas souvent, donc chapeau. Je voulais peut-être juste compléter, parce que là, tu me montres bien ces implementations-là, comment les mettre en place dans le process et puis presque philosophiquement. Le point, chérie, le nerf de la guerre, aujourd'hui, on le connaît, c'est d'aller plus vite, à baisser les coûts. Et la force qu'on trouve dans ces outils-là, c'est la réutilisabilité et pouvoir se reposer sur des codes produits par les autres. Donc, tu vas montrer Composeur, je dirais, aller faire un tour sur package-iste, aller regarder les packages qui existent et réutiliser tous ces codes-là. Il y a des gens super intelligents, plus malins que nous encore, qui ont codé des choses et c'est vraiment, je dirais, la puissance aujourd'hui, c'est presque parfois un peu du Lego. On trouve ce dont on a besoin, on l'implémente, on lit deux-trois lignes de docs et beaucoup, et ça va beaucoup, beaucoup plus vite. Donc voilà, je veux juste apporter ce qu'on fait là. Merci. C'est vrai que c'est ça, c'est l'idée, une fois qu'il y a des libraires qui ont été faites quelque part, encore une fois, c'est des engrenages. Après, vous jouez avec l'objet. Là, dans la conf, il n'y a pas de remarques, mais il n'y a pas eu d'actions de filtres jouées avec, c'est une autre manière de jouer aussi avec WordPress et l'objet. Mais, l'objet, il en a en extase devant les actions et les filtres, mais l'objet, lui, il les fait plus ou moins tout seul. Les filtres, c'est une sorte d'injection de dépendance. Donc, WordPress n'a rien inventé, il a mis une fonction en plus pour répondre à un très problématique procédural. C'est encore moi. Peut-être que, si tu pouvais nous indiquer des sites, des tutos qui expliquent les designs pattern, en plus des bouquins, je dirais, parce que je pense que là, ils doivent bien maîtriser ces domaines-là aujourd'hui. C'est assez nouveau dans nos phénomènes. Il y a les frameworks, la Ravel Symphonique, les imprimantes plutôt bien, mais je pense qu'on gagnerait tous à monter en compétences dessus. Donc, si tu pouvais, peut-être pas tout de suite, mais si tu pouvais faire un petit recueil, nous tuer, voilà. Oui, éventuellement. Après, c'est vrai que je travaille énormément avec les livres. J'aime bien les sites internet, mais les livres, je les trouve ça aussi assez cool. On ne peut pas faire contrôlèves dessus. C'est ça qui est dommage. La phrase typique, il y a vraiment Google et votre ami, Wikipédia aussi. Wikipédia vous montre la plupart des paternes avec des exemples. Et prenez pas peur, les exemples sont rarement en PHP. C'est plus sensé, plus spruce, dans des langages plus bas niveau, plus apte à faire ce genre d'outillage. Donc voilà, c'est Wikipédia, Google, les sites. En soi, il n'y a pas vraiment si il y a le site du zéro, enfin, Open Classroom, éventuellement, qui présentent quelques dizaines de paternes, mais sinon, ils vont beaucoup plus loin. Je n'ai pas mis tous les bouquins, il y a un bouquin à l'algorithme, il fait 1000 pages. Je me suis arrêté à la 300e, après le cerveau, il ne suis plus trop. C'est assez hardcore quand même. Oui. Oui, je suis là. Bonjour. Bonjour. Moi justement, je voulais conseiller une ressource pour les gens qui veulent apprendre. Parce que la théorie, c'est bien, mais la pratique, c'est vraiment très bien et je conseille à tout le monde qui veut l'apprendre l'objet, c'est Code Academy by doing. Donc, à gauche, il explique et en fait, pour passer les étapes, il faut faire un exercice. Donc, voilà, enfin, voilà, learning by doing faut vraiment pratiquer et Code Academy est très bien pour ça. Donc je conseille à tout le monde ce site. Et c'est gratuit. Tout d'abord, merci. En fait, malgré, enfin, je ne sais pas combien d'années d'expérience tu as, mais en fait, j'apprend toujours de nouvelles choses, c'est ce qui fait évoluer les technologies dans WordPress. Il y a quelques années, il n'y avait pas d'objet dans WordPress. Je remarque, on n'apprend pas toujours nos erreurs, typiquement, symphonies, les arabes et tout, apprennent pas toujours des erreurs d'autres frameworks et en fait, j'ai peur qu'en fait, le fait d'implementer ses propres interfaces, c'est vous qui n'existent pas, en fait, actuellement dans WordPress. Soit le drame qu'on a vécu en fait en 2010, par exemple, vous pouvez voir tout réinventé, finalement, deux ans après, trois ans après, etc. Voilà. Excuse-moi. Donc, qu'est-ce que tu en penses de ça? Parce qu'en fait, par exemple, justement, nous, on utilise du statique dans nos codes. C'est bien, c'est mal. L'auto-loader, c'est pareil, on a vécu ça. Enfin, il y a des avantages, mais ça peut pourrir la mémoire derrière sur des gros sites à fort de volumétrie. Je l'ai vécu et je peux vous dire, j'ai un admisystème qui me tape donc, qu'est-ce que tu en penses avec le recul que tu as et qu'est-ce que tu pourrais en penser, vu qu'à mon avis, tu fais aussi d'autres projets qui ne sont pas que fécément souviants. Je vais toujours prêcher l'objet, déjà. Mais encore une fois, c'est en fait du bon objet ou du mauvais objet. Qu'appelles-tu le drame de symphonie 1, c'est-à-dire que tu penses que de symphonie 1 à symphonie 2, on a tout refait? Non, c'est qu'en fait, on a dû repenser le modèle justement d'objet. La portabilité du code de symphonie 1 à symphonie 2, elle n'est pas extraordinaire. Je suis passé d'un projet de symphonie 1 à symphonie 3 qui est sorti. Facile. Franchement, c'était pas grandiose. En fait, symphonie, enfin, pour moi, la grande différence c'est déjà, on va vite fermer l'apparence sur symphonie, mais pour symphonie 1 et symphonie 2, pour moi, c'est le service conteneur et l'injection de dépendance qu'ils ont rajouté. Mais j'ai envie de dire, c'est comme si on changeait la logique de certaines choses dans WordPress, il faut des choses comme ça. Maintenant, ensuite, en termes d'objets, les problèmes de performance, il y en a... tu ne dois pas, théoriquement, en avoir. Le statique peut t'emproser. Mais, pour te donner un exemple, on va parler de Doctrine. Doctrine 1.2, c'est... c'est nul. Doctrine 2, c'est mieux. C'est ce qu'on appelle, en fait, dans Doctrine 1.2, il y a l'active record. Donc, l'active record, c'est la possibilité tout seul. Pour ce qui sache faire ça, c'est qu'il doit tout embarquer. Alors, je ne te dis pas quand t'as 1000 objets qui sont instantiés à your plan, on traite 50 000 tickets. Si on est en Doctrine 1.2, 50 000 objets qui savent tout faire eux-mêmes, ah ouais, ouais, là, ça fait mal. Donc, ils ont arrêté l'active record et ils sont passés par un entity manager. Un service qui prend l'objet et c'est le service lui qui sait faire. Donc, les engrenages ne doivent pas être trop gros. Il faut savoir les limiter à certains endroits. Le service container, il sait pas tous les objets. Enfin, il a la logique en termes de code, admettons qu'il est, je ne sais pas, je veux dire un énorme chiffre, 10 000 services. Si durant une execution d'une page, il n'en a besoin que de 2, tu auras que 2 objets qui seront instantiés. Les 10 000 n'existeront pas en fait, sur ton process. En revanche, le statique, si on commence à faire du statique, c'est qu'on a besoin d'une ressource qu'on a mis ailleurs, qu'on a externalisée dans un fichier ou des choses comme ça. Donc, j'existe. Il n'a pas le choix. Une méthode statique, elle va être stockée en mémoire. La classe, si tu ne l'as pas instantielle, n'est pas stockée en mémoire. Donc, c'est ça aussi. Attention, le statique, j'en ai pas beaucoup parlé, c'est vraiment, il faut l'utiliser en tant qu'helper des codes erreurs HTTP, 500, 400, bidule, machin. Ça, ok. Une classe statique qui me dit, si j'ai le code 500, ça veut dire, peut-être truc. Mais pas un plugin. Pour donner l'exemple c'est une toute petite classe de méthodes statiques et c'est parti. C'était un petit plugin qui en fait, une librairie. Je lui ai dit, c'est bien, pourquoi pas, ça marche. Mais, moi, ton plugin, si tu me mets du statique et deux méthodes, il n'existe pas. C'est comme l'histoire de la bière. C'est pareil. Si tu fais du statique, ta classe, objectivement, n'existe pas. Tu peux l'appeler, c'est un distributant de billets. Et là, ça n'a pas de sens. Un plugin, dès lors qu'il est activé, s'il doit faire des choses, il faut qu'il existe. Donc il faut qu'il soit instanti. Donc, j'ai pas de statique. C'est plus philosophique, c'est plus une réflexion, une certaine logique que vraiment du technique. Mais, encore une fois, ça marche. Mais ça marche pas dans la logique qui est attendue, en fait. C'est... Bonjour, monsieur. C'est où ? Ah, ouais. Donc, juste, en termes d'industrialisation pour la création de thèmes et tout ça, par exemple, je crée un... quelque chose de portfolio. C'est mieux de créer un plugin que je vais installer sur chaque thème à besoin ou que je... avec... en objet ou que je le mette à chaque fois dans mon fonction PHP. C'est quoi, c'est quoi ? Donc là, c'est plus logique. Est-ce que je code dans un plugin ou un thème ? Ça, j'ai toujours pas la réponse. Non. Enfin, plugin, voilà, j'active, j'désactive. Donc, un plugin est un service. C'est un service qui doit être capable d'être indépendant. Si vous le désactivez, je considère que si vous faites quelque chose dans un plugin, si vous le désactivez, ça ne doit pas changer le fonctionnement global de votre site. Si... si votre site, par exemple, a impérativement besoin, parce que c'est un site, je sais pas, de tourisme. Il a impérativement besoin d'un custom hostile qui gère les voyages et vous le faites en plugin. Eh bien, vous croisez les doigts qui ne désactivent pas. Enfin, mettez-le dans le thème. C'est... Moi, ça, c'est malogique. Après, il y en a qui vont dire non, non, non, custom hostile, c'est un plugin. On peut parler dessus pendant une journée, mais tout ce qui est dépendant, c'est là, pareil, le site, s'il a besoin absolument de ce custom hostile, pourquoi il aurait l'autorisation de le désactiver ? Non. Là-dessus, je serai pas. Par contre, en termes d'objet, j'aurai une hybrérie, j'aurai une factory qui sait créer des custom hostile. Et la création de mon custom hostile deviendra au niveau de mon fichier de fonction. Merci, Thomas. Merci. On peut l'applaudir. Merci.