Il y a cinq bonnes raisons pour lesquelles les applications PHP orientées objet ont du sens et pourquoi vous devriez vous soucier d’écrire vos applications dans un style orienté objet.
1. Les objets sont extensibles.
Il devrait être possible d’étendre le comportement des objets à la fois par la composition et l’héritage, permettant aux objets de prendre une nouvelle vie et une nouvelle utilité dans de nouveaux contextes. Bien sûr, les développeurs doivent être prudents lorsqu’ils étendent des objets existants, car la modification de l’API publique d’un objet crée un tout nouveau type d’objet. Mais, si cela est bien fait, les développeurs peuvent revitaliser les anciennes bibliothèques grâce au pouvoir de l’héritage.
2. Les objets sont remplaçables.
L’intérêt du développement orienté objet est de faciliter l’échange d’objets les uns contre les autres. Le principe de substitution de Liskov nous dit qu’un objet doit être remplaçable par un autre objet du même type et que le programme doit toujours fonctionner. Il peut être difficile de voir l’intérêt de supprimer un composant et de le remplacer par un autre composant, surtout au début du cycle de vie du développement. Mais la vérité est que les choses changent ; besoins, technologies, ressources. Il peut arriver un moment où vous devrez intégrer une nouvelle technologie, et avoir une application orientée objet bien conçue ne fera que rendre cela plus facile.
3. Les objets sont testables.
Il est possible de tester les applications procédurales, mais pas bien. La plupart des applications procédurales ne disposent pas d’un moyen simple de séparer les composants externes (comme le système de fichiers, la base de données, etc.) des composants testés. Cela signifie que dans les meilleures circonstances, tester une application procédurale est plus un test d’intégration qu’un test unitaire. Le développement orienté objet rend les tests unitaires beaucoup plus faciles et plus pratiques. Puisque vous pouvez facilement simuler et remplacer des objets (voir Mockery, une excellente bibliothèque d’objets fictifs), vous pouvez remplacer les objets dont vous n’avez pas besoin et tester ceux que vous utilisez. Puisqu’un test unitaire ne doit tester qu’un seul segment de code à la fois, les objets factices et stub rendent cela possible.
4. Les objets sont maintenables.
Il y a quelques problèmes avec le code de procédure qui le rendent plus difficile à maintenir. L’un est la probabilité de duplication de code, ce parasite insidieux de non-maintenabilité. Le code orienté objet, d’autre part, permet aux développeurs de placer facilement le code au même endroit et de créer une API expressive qui explique ce que fait le code, même sans avoir à connaître le comportement sous-jacent. Un autre problème que la programmation orientée objet résout est le fait que le code procédural est souvent compliqué. Plusieurs instructions conditionnelles et des chemins variables créent un code difficile à suivre. Il y a une mesure de complexité – la complexité cyclomatique – qui nous montre le nombre de points de décision dans le code. Un score supérieur à 12 est généralement considéré comme mauvais, mais un bon code orienté objet aura généralement un score inférieur à 6. Par exemple, si vous savez qu’une méthode accepte un objet comme l’un de ses arguments, vous n’avez pas besoin de savoir comment cet objet fonctionne pour répondre aux exigences. Vous n’avez pas besoin de formater cet objet ou de manipuler les données pour répondre aux besoins de la méthode ; à la place, vous pouvez simplement passer l’objet. Vous pouvez encore manipuler cet objet en toute confiance, sachant que l’objet validera correctement vos entrées comme valides ou invalides, sans que vous ayez à vous en soucier.
5. Les objets produisent des erreurs capturables (et récupérables).
La plupart des développeurs PHP procéduraux sont passablement familiarisés avec le lancement et la capture d’exceptions. Cependant, les exceptions sont destinées à être utilisées dans le développement orienté objet, et elles sont mieux utilisées comme moyen de récupérer de divers états d’erreur. Les exceptions sont attrapables, ce qui signifie qu’elles peuvent être gérées par notre code. Contrairement à d’autres mécanismes en PHP (comme trigger_error()), nous pouvons décider comment gérer une exception et déterminer si nous pouvons avancer (ou terminer l’application).