[POO] Organisation des classes PHP

Bonjour tout le monde,

Voilà, donc ce matin journée normal je me lève et je vais au taff...
Là je commence à développer une nouvelle classe php pour un client et là
bim
une question me vient à l'esprit :

- Est ce mieux de mettre la connection à la base en dehors ou en dedans une classe php ?
- dans le cas ou elle serait en dehors ... faut il extend toutes les classes à la classe de gestion de la BD ? ou juste les include ?

- une dernière question :
si j'ai une classe "message" par exemple symbolisant un message laissé par un client sur un serveur, pour afficher tous les messages est-il plus efficace de faire une fonction de la classe message : afficherTousMessages();
ou alors de faire une boucle sur une fonction afficherUnMessage() ??

Voilà merci de votre aide :p
A très bientot

- Il vaut mieux privilégier la composition plutôt que l'héritage car la dépendance est moindre dans le premier cas. Cependant, en OOP, aucune règle n'est figée dans le marbre...

- Regarde du coté des itérateurs

je ne vois pas trop ce que tu veux dire par "regarde du coté des itérateurs "?

Citation:

---

Envoyé par AsQuel

si j'ai une classe "message" par exemple symbolisant un message laissé par un client sur un serveur, pour afficher tous les messages est-il plus efficace de faire une fonction de la classe message : afficherTousMessages();
ou alors de faire une boucle sur une fonction afficherUnMessage() ??

---

Un itérateur pourrait être utile dans ce cas. :mouarf:

je me suis renseigné sur les itérateurs php
étant donné que la version php sur laquelle tourne le client est la 4, il n'y a pas d'itérateurs déjà fait.
Alors j'ai regardé un peu et j'ai pris deux classes itérateurs, une abstraite et une classe extend l'abstraite .
Mais est ce que cela apporte vraiment de la rapidité ?
Quel est l'intéret réel des itérateurs ?

L'intéret des itérateurs c'est d'offrir une interface simple pour parcourir un container. L'utilisateur n'a plus besoins de connaître les méchanismes internes du container pour accéder et parcourir ses éléments (container pouvant être un array, un objet etc).

Par exemple ta classe gère une liste de messages. Ces message peuvent être réunis dans un array, un fichier, un document xml en mémoire etc. Sans itérateur, l'utilisateur de ta classe serait obligé de connaître non seulement ton moyen de storage mais aussi ses particularités pour accéder à ses éléments (traverser un array ne se fait pas de la même façon que pour un fichier ou un DOM). Par contre si ton objet fournit des méthodes simples telles que next(), previous(), current() pour accéder à ses messages, alors il n'y a plus besoins de se soucier des détails techniques d'implémentation. Tu peux même changer de moyen de storage en cours de route, ça sera transparent pour l'utilisateur.

Niveau performance, en php ça va généralement pénaliser d'un function call pour chaque élément accédé (ce qui est généralement sans conséquence pour la plupart des scripts). Par contre niveau utilisation, c'est tout bénef.

hum oui pas mal en effet
j'y avais pas pensé en plus je les utilise sans m'en soucier en java lol
merci pour toutes ces infos