07-02-2008, 01:05 PM
keke, je vais défendre la POO en PHP 
facilité de modification :
_ on modifie une méthode ( objet ) ou une fonction ( procédural avec fonctions ) et ça revient au même;
_ si les arguments de la fonction changent, on doit tracer son utilisation dans tous les scripts et modifier cela. avec une approche objet, les arguments peuvent changer sans que l'appel à la méthode soit changé
=> on a surtout un avantage basique de l'OO : l'encapsulation des données.
moins de lignes :
_ c'est plus long ( verbeux ? ) d'écrire une classe que des fonctions, mais on obtient moins de lignes dans le script utilisateur qu'avec un code classique sans fonctions / classes. c'est dans ce sens là qu'il faut comprendre "moins de lignes"
facilité de compréhension :
_ c'est jamais simple de reprendre un code
_ ça dépend de la documentation inline et hors du code : les tests unitaires permettent de documenter par des exemples d'utilisation des méthodes
lourdeur et rigueur :
_ oui, c'est une syntaxe à apprendre, mais à l'utilisation on y gagne sur tous les plans
ralentissement d'exécution :
_ faux débat : qu'est-ce qui coute le plus cher : un dev de qualité, débugguer du paté ou un serveur un peu plus puissant ?
le coût se situe du coté du développement, et les performances de l'objet en PHP sont bonnes comparé aux fonctions et au paté, et même très bonnes si on considère les bonnes pratiques OO vs le code paté à débugguer.
pour les tests unitaires en PHP, SimpleTest propose un environnement fort sympathique et complet, facile à prendre en main.
ce sujet de discussion est une approche de l'objet en PHP, on ne parle pas encore de conception objet, de design patterns, de composition, d'interfaces ... mais on pourra y venir sur d'autres sujets.
A+
Pascal
facilité de modification :
_ on modifie une méthode ( objet ) ou une fonction ( procédural avec fonctions ) et ça revient au même;
_ si les arguments de la fonction changent, on doit tracer son utilisation dans tous les scripts et modifier cela. avec une approche objet, les arguments peuvent changer sans que l'appel à la méthode soit changé
=> on a surtout un avantage basique de l'OO : l'encapsulation des données.
moins de lignes :
_ c'est plus long ( verbeux ? ) d'écrire une classe que des fonctions, mais on obtient moins de lignes dans le script utilisateur qu'avec un code classique sans fonctions / classes. c'est dans ce sens là qu'il faut comprendre "moins de lignes"
facilité de compréhension :
_ c'est jamais simple de reprendre un code
_ ça dépend de la documentation inline et hors du code : les tests unitaires permettent de documenter par des exemples d'utilisation des méthodes
lourdeur et rigueur :
_ oui, c'est une syntaxe à apprendre, mais à l'utilisation on y gagne sur tous les plans
ralentissement d'exécution :
_ faux débat : qu'est-ce qui coute le plus cher : un dev de qualité, débugguer du paté ou un serveur un peu plus puissant ?
le coût se situe du coté du développement, et les performances de l'objet en PHP sont bonnes comparé aux fonctions et au paté, et même très bonnes si on considère les bonnes pratiques OO vs le code paté à débugguer.
pour les tests unitaires en PHP, SimpleTest propose un environnement fort sympathique et complet, facile à prendre en main.
ce sujet de discussion est une approche de l'objet en PHP, on ne parle pas encore de conception objet, de design patterns, de composition, d'interfaces ... mais on pourra y venir sur d'autres sujets.
A+
Pascal