Discussion :

[yassinozi]

Bonjour,

En lisant un tutoriel sur la programmation orienté objet, j'ai vu un exemple d'une classe qui a un attribut de type objet qui est en lui-même une instanciation d'une autre classe.

J'aimerai savoir à quoi cela peut me servir exactement, dans quel contexte je peux utiliser cette technique ( des exemples concrets si c'est possible )


Merci d'avance

[dOxOb]

Bonjour,

je ne vois pas bien l'intéret d'une telle pratique dans la mesure où l'héritage te permet d'accéder aux méthodes et attributs de la classe parent.
Les méthodes static te permettent les utiliser sans intancier la classe à laquelle elles appartiennent.

D'autre part un objet instancié est consommateur de mémoire. Si bien qu'en utilisant cette technique, lorsque tu instancies ton premier objet tu en instancie en réalité deux.

Lors d'un développement, seuls les classes nécessaire au traitement voulus doivent être instanciées. Sur des applications à forte volumétrie et fort traffic, ce type de pratique est à bannir.

Cela dit s'ils y en a qui utilisent ce type de pratique, je suis curieux d'en connaitre le motif.

[ABCIWEB]

Si bien qu'en utilisant cette technique, lorsque tu instancies ton premier objet tu en instancie en réalité deux.

Deux ou plus peu importe, il faut souvent plus de deux classes pour faire fonctionner un script. Et donc ensuite c'est une question d'organisation du code mais il n'y a pas de pb particulier à instancier une classe à l'intérieur d'une autre classe. C'est même très courant dans le modèle MVC quand par exemple le contrôleur instancie les classes du modèle pour faire les requêtes, par exemple ici.

L'héritage ne résout pas tout. L'héritage multiple n'est pas nativement supporté en php (sauf en cascade). Et on hérite pas d'une classe parce qu'on a simplement besoin d'utiliser certaines de ses méthodes, il faut un rapport "filial" pour respecter la sémantique.

[dOxOb]

Je ne suis que très peu convaincu par cette utilisation qui pour moi n'est pas optimisé.
Tu vas instancier des objets automatiquement dans ton constructeur, des objets dont tu n'as pas forcément besoin, donc des possibilités d'erreur supplémentaires.

Tu peux vite arriver, par exemple, à avoir plusieurs instanciations de connexion à la base de données.

Encore une fois si tu as trois connexions utilisateur par jour, ça va. Quand tu peux atteindre une charge de 1500 utilisateurs simultannés et que ton application est en environnement mutualisé, je pense que tu auras des retours de la part de l'assistance et de l'exploit.

Chacun son expérience, je conseillerai plutot d'appeler les objets au besoin et non dans le constructeur, on maitrise ainsi sa durée de vie.

[ABCIWEB]

Quand on instancie des objets dans le constructeur c'est précisément parce qu'on en a besoin systématiquement, genre si on veut récupérer des données on aura forcément besoin d'instancier une classe modèle. Sinon évidemment on ne les instancie pas dans le constructeur mais dans une méthode annexe qui sera appelée si besoin.

Je dis pas qu'il faut faire n'importe quoi, je dis que suivant les cas cela peut se justifier pleinement sans engendrer de surcoût en performances/occupation mémoire.

Autre exemple, dans une classe pour travailler sur les fichiers d'un répertoire je ne me prive pas d'initialiser un DirectoryIterator ou un FilesystemIterator dans le constructeur. Toute la suite du code en a besoin et en dépend et donc je ne vois pas ce qui pourrait gêner. En suivant tes exigences à la lettre on arriverait vite à des lourdeurs injustifiées.

[Bisûnûrs]

je ne vois pas bien l'intéret d'une telle pratique dans la mesure où l'héritage te permet d'accéder aux méthodes et attributs de la classe parent.

Question de sémantique, tu ne peux par exemple pas faire hériter une classe Couleur à ta classe Voiture.

Sur des applications à forte volumétrie et fort traffic, ce type de pratique est à bannir.

Tu peux vite arriver, par exemple, à avoir plusieurs instanciations de connexion à la base de données.

Bof. Ca veut tout simplement dire que tu n'as pas les bonnes pratiques de développement.

Pour éviter ce genre de problème, il suffit de travailler avec des Singleton.

Exemple simple d'une classe en appelant une autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class Voiture
{
   private $_oCouleur;
 
   public function __construct( Couleur $oCouleur )
   {
      $this->_oCouleur = $oCouleur;
   }
}
 
class Couleur
{
   private $_r;
   private $_g;
   private $_b;
 
   public function __construct( $r, $g, $b )
   {
      $this->_r = $r;
      $this->_g = $g;
      $this->_b = $b;
   }
}
 
$oVoiture = new Voiture( new Couleur( 255, 255, 255 ) );

Explique moi ici, pourquoi Voiture aurait hérité de Couleur, ou inversement.

[grunk]

Bonjour,
je ne vois pas bien l'intéret d'une telle pratique dans la mesure où l'héritage te permet d'accéder aux méthodes et attributs de la classe parent.

Un héritage c'est complètement différent d'une composition. Un objet voiture ne peux pas dériver d'un objet moteur , l'objet moteur compose l'objet voiture et l'objet voiture ne peut exister sans l'objet moteur.

D'autre part un objet instancié est consommateur de mémoire. Si bien qu'en utilisant cette technique, lorsque tu instancies ton premier objet tu en instancie en réalité deux.

Et donc ? On évite pas certains principes élémentaires de la POO sous prétexte que ça consomme des ressources.
Par contre on peut éviter de l'instancier dans la classe directement pour éviter un couplage trop fort entre les deux classes et du coup on tombe dans l'association et non plus dans la composition.

Sur des applications à forte volumétrie et fort traffic, ce type de pratique est à bannir.

Cela dit s'ils y en a qui utilisent ce type de pratique, je suis curieux d'en connaitre le motif.

N'importe quel framework MVC utilise à minima de l'association pour passer un objet sql aux modèles (avec un injection de dépendance en général). Chaque modèle à donc en son sein une instance (unique) d'un objet sql.

J
Tu vas instancier des objets automatiquement dans ton constructeur, des objets dont tu n'as pas forcément besoin, donc des possibilités d'erreur supplémentaires.

Si les objets sont dans la classe c'est qu'en principe on en à besoin. On ajoute pas un attribut à une classe pour le fun.

Tu peux vite arriver, par exemple, à avoir plusieurs instanciations de connexion à la base de données.

Le singleton permet d'éviter cette problématique.

Chacun son expérience, je conseillerai plutôt d'appeler les objets au besoin et non dans le constructeur, on maitrise ainsi sa durée de vie.

Du coup je conseille la programmation procédurale , comme ça on est bien sur de pas avoir 2 objets instanciés en même temps pour pas consommertrop de mémoire


-----
Grillé sur le fil par Bisûnûrs