Bon, la question est dans le titre, mais je vais tout de même
m'expliquer un peu plus.
Je me suis un peu mis à l'utilisation des objets en PHP, essentiellement
depuis que j'ai du travailler avec fpdf et jgraph.
J'ai aussi utilisé des objets pour la création d'un intranet dans laquel
on devait gérer des clients avec beaucoup d'informations, et cela a
considérablement allégé mon code.
Mais ma question est surtout de savoir à quel moment il devient plus
intéressant de passer par des objets plutôt que de traiter directement
dans le code. Est-ce purement subjectif ou y'a t'il des optimisations
réelles?
Merci bien
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.c-p-f.net
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
(¯`·..Yttrium ...·´¯)
Bjr, Je me joins à cette question, étant moi même parfois un peu effrayé par les maniaques du " Tout objet ". En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? " Sans pour autant nier l'interet et les avnatages de la POO, c'est ca systématisation que je comprend mal..
Bjr,
Je me joins à cette question, étant moi même parfois un peu effrayé par les
maniaques du " Tout objet ".
En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? "
Sans pour autant nier l'interet et les avnatages de la POO, c'est ca
systématisation que je comprend mal..
Bjr, Je me joins à cette question, étant moi même parfois un peu effrayé par les maniaques du " Tout objet ". En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? " Sans pour autant nier l'interet et les avnatages de la POO, c'est ca systématisation que je comprend mal..
ftc
Bjr, Je me joins à cette question, étant moi même parfois un peu effrayé par les maniaques du " Tout objet ". En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? " Sans pour autant nier l'interet et les avnatages de la POO, c'est ca systématisation que je comprend mal..
Tout dépend de la frontière que tu places entre simple et compliqué et de quel côté tu te places.
Pour réaliser un CMS, je touve plus simple d'utiliser la POO, pour un petit script qui sert juste à afficher la date, il est plus simple d'utiliser la programmtion procédurale.
La simplicité vient aussi de la façon de penser des programmeurs. Certains gros projets sont assez bien réalisés en programmation procédurale d'autres sont imbitables. Et c'est la même chose en POO.
La POO a été inventée pour améliorer la modularité et la réutilisation, si c'est deux points ne font pas parti des impératifs d'un projet, il faut utiliser le style de programmtion avec lequel on est le plus à l'aise.
Un autre avantage de la POO en PHP est de pouvoir avoir un pseudo espace de nomage.
Bjr,
Je me joins à cette question, étant moi même parfois un peu effrayé par les
maniaques du " Tout objet ".
En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? "
Sans pour autant nier l'interet et les avnatages de la POO, c'est ca
systématisation que je comprend mal..
Tout dépend de la frontière que tu places entre simple et compliqué et
de quel côté tu te places.
Pour réaliser un CMS, je touve plus simple d'utiliser la POO, pour un
petit script qui sert juste à afficher la date, il est plus simple
d'utiliser la programmtion procédurale.
La simplicité vient aussi de la façon de penser des programmeurs.
Certains gros projets sont assez bien réalisés en programmation
procédurale d'autres sont imbitables. Et c'est la même chose en POO.
La POO a été inventée pour améliorer la modularité et la réutilisation,
si c'est deux points ne font pas parti des impératifs d'un projet, il
faut utiliser le style de programmtion avec lequel on est le plus à l'aise.
Un autre avantage de la POO en PHP est de pouvoir avoir un pseudo espace
de nomage.
Bjr, Je me joins à cette question, étant moi même parfois un peu effrayé par les maniaques du " Tout objet ". En m'interrogeant, " Doit on faire compliqué quand on peut faire simple ? " Sans pour autant nier l'interet et les avnatages de la POO, c'est ca systématisation que je comprend mal..
Tout dépend de la frontière que tu places entre simple et compliqué et de quel côté tu te places.
Pour réaliser un CMS, je touve plus simple d'utiliser la POO, pour un petit script qui sert juste à afficher la date, il est plus simple d'utiliser la programmtion procédurale.
La simplicité vient aussi de la façon de penser des programmeurs. Certains gros projets sont assez bien réalisés en programmation procédurale d'autres sont imbitables. Et c'est la même chose en POO.
La POO a été inventée pour améliorer la modularité et la réutilisation, si c'est deux points ne font pas parti des impératifs d'un projet, il faut utiliser le style de programmtion avec lequel on est le plus à l'aise.
Un autre avantage de la POO en PHP est de pouvoir avoir un pseudo espace de nomage.
loufoque
CrazyCat a dit le 19/04/2005 à 10:53:
Mais ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code. Est-ce purement subjectif ou y'a t'il des optimisations réelles?
La POO c'est surtout bien pour les bibliothèques, les outils, le framework... Après pour le reste ça dépend des cas.
CrazyCat a dit le 19/04/2005 à 10:53:
Mais ma question est surtout de savoir à quel moment il devient plus
intéressant de passer par des objets plutôt que de traiter directement
dans le code. Est-ce purement subjectif ou y'a t'il des optimisations
réelles?
La POO c'est surtout bien pour les bibliothèques, les outils, le
framework...
Après pour le reste ça dépend des cas.
Mais ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code. Est-ce purement subjectif ou y'a t'il des optimisations réelles?
La POO c'est surtout bien pour les bibliothèques, les outils, le framework... Après pour le reste ça dépend des cas.
P'tit Marcel
CrazyCat wrote:
Re: POO: quand l'utiliser?
un avis purement subjectif d'un dinosaure :
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce qui la rend peu adapté à de petits sites ou applications.
la POO est plus adapté à une application à plusieurs développeurs (réutilisation de code, séparation entre les parties à programmmer, visibilité de code ou variables, etc.)
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
-- P'tit Marcel trolleur
CrazyCat wrote:
Re: POO: quand l'utiliser?
un avis purement subjectif d'un dinosaure :
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce
qui la rend peu adapté à de petits sites ou applications.
la POO est plus adapté à une application à plusieurs développeurs
(réutilisation de code, séparation entre les parties à programmmer,
visibilité de code ou variables, etc.)
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce qui la rend peu adapté à de petits sites ou applications.
la POO est plus adapté à une application à plusieurs développeurs (réutilisation de code, séparation entre les parties à programmmer, visibilité de code ou variables, etc.)
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
-- P'tit Marcel trolleur
CrazyCat
P'tit Marcel wrote:
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
Le fait que l'on puisse créer des objets :)
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.c-p-f.net
P'tit Marcel wrote:
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
Le fait que l'on puisse créer des objets :)
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.c-p-f.net
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
Le fait que l'on puisse créer des objets :)
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.c-p-f.net
John Gallet
Bonjour,
Mais ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code.
Facile : quand le type de ton application est une entité de l'intersection des cas où il est intéressant de faire de la POO et les cas où il est intéressant d'utiliser php.
Il ne reste plus qu'à définir la classe "POO", dérivée de la classe de base "méthodes de programation", la classe "plateforme applicative", dont PHP est une instance, et pour chacune de ces classes, la méthode booléenne "être intéressant" qui prend en paramètre une entité de la classe "application". Le TROLL obtenu devrait probablement être orienté objet, de type "à poil dur".
Blague à part, c'est quoi la POO ? Tu considères que tu fais de la POO dès lors que tu as des objets qui s'échangent des messages, ou tu considères que tu fais de la POO seulement s'il y a polymorphisme effectif ? Et dans tous les cas, ce que ça apportera sera 1) théorique 2) dépendant de l'application.
Le problème est toujours le même, on en a parlé récemment dans le thread "différentes conceptions possibles" : je ne connais pas de langage (ni de méthode de développement à part la relecture systématique par une tierce personne expérimentée) qui empêche les mauvais développeurs de pondre du mauvais code (sinon je l'aurais appris il y a longtemps ;-)! )
a++; JG -- C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow away the whole leg.
Bonjour,
Mais ma question est surtout de savoir à quel moment il devient plus
intéressant de passer par des objets plutôt que de traiter directement
dans le code.
Facile : quand le type de ton application est une entité de
l'intersection des cas où il est intéressant de faire de la POO et les
cas où il est intéressant d'utiliser php.
Il ne reste plus qu'à définir la classe "POO", dérivée de la classe de
base "méthodes de programation", la classe "plateforme applicative",
dont PHP est une instance, et pour chacune de ces classes, la méthode
booléenne "être intéressant" qui prend en paramètre une entité de la
classe "application". Le TROLL obtenu devrait probablement être orienté
objet, de type "à poil dur".
Blague à part, c'est quoi la POO ? Tu considères que tu fais de la POO
dès lors que tu as des objets qui s'échangent des messages, ou tu
considères que tu fais de la POO seulement s'il y a polymorphisme
effectif ? Et dans tous les cas, ce que ça apportera sera 1) théorique
2) dépendant de l'application.
Le problème est toujours le même, on en a parlé récemment dans le thread
"différentes conceptions possibles" : je ne connais pas de langage (ni
de méthode de développement à part la relecture systématique par une
tierce personne expérimentée) qui empêche les mauvais développeurs de
pondre du mauvais code (sinon je l'aurais appris il y a longtemps ;-)! )
a++; JG
--
C makes it easy to shoot yourself in the foot.
C++ makes it harder, but when you do, you blow away the whole leg.
Mais ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code.
Facile : quand le type de ton application est une entité de l'intersection des cas où il est intéressant de faire de la POO et les cas où il est intéressant d'utiliser php.
Il ne reste plus qu'à définir la classe "POO", dérivée de la classe de base "méthodes de programation", la classe "plateforme applicative", dont PHP est une instance, et pour chacune de ces classes, la méthode booléenne "être intéressant" qui prend en paramètre une entité de la classe "application". Le TROLL obtenu devrait probablement être orienté objet, de type "à poil dur".
Blague à part, c'est quoi la POO ? Tu considères que tu fais de la POO dès lors que tu as des objets qui s'échangent des messages, ou tu considères que tu fais de la POO seulement s'il y a polymorphisme effectif ? Et dans tous les cas, ce que ça apportera sera 1) théorique 2) dépendant de l'application.
Le problème est toujours le même, on en a parlé récemment dans le thread "différentes conceptions possibles" : je ne connais pas de langage (ni de méthode de développement à part la relecture systématique par une tierce personne expérimentée) qui empêche les mauvais développeurs de pondre du mauvais code (sinon je l'aurais appris il y a longtemps ;-)! )
a++; JG -- C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow away the whole leg.
ftc
CrazyCat wrote:
Re: POO: quand l'utiliser?
un avis purement subjectif d'un dinosaure :
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce qui la rend peu adapté à de petits sites ou applications.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité.
la POO est plus adapté à une application à plusieurs développeurs (réutilisation de code, séparation entre les parties à programmmer, visibilité de code ou variables, etc.)
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul développeur
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
PHP est un langage avec une composante orientée objet ( PHP5 surtout ) par contre ce n'est pas ub langage Objet comme Java ou Python.
Comme je l'ai dit dans un post précédent, il ne faut pas faire de l'objet pour faire de l'objet mais utiliser le style de programmation avec lequel on se sent à l'aise.
CrazyCat wrote:
Re: POO: quand l'utiliser?
un avis purement subjectif d'un dinosaure :
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce
qui la rend peu adapté à de petits sites ou applications.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture
et à augmenter la lisibilité.
la POO est plus adapté à une application à plusieurs développeurs
(réutilisation de code, séparation entre les parties à programmmer,
visibilité de code ou variables, etc.)
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul développeur
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
PHP est un langage avec une composante orientée objet ( PHP5 surtout )
par contre ce n'est pas ub langage Objet comme Java ou Python.
Comme je l'ai dit dans un post précédent, il ne faut pas faire de
l'objet pour faire de l'objet mais utiliser le style de programmation
avec lequel on se sent à l'aise.
la POO a tendance à alourdir l'écriture d'un script et sa lisibilité, ce qui la rend peu adapté à de petits sites ou applications.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité.
la POO est plus adapté à une application à plusieurs développeurs (réutilisation de code, séparation entre les parties à programmmer, visibilité de code ou variables, etc.)
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul développeur
cela dit, qu'est-ce qui te fait croire que php est un langage OOP ?
PHP est un langage avec une composante orientée objet ( PHP5 surtout ) par contre ce n'est pas ub langage Objet comme Java ou Python.
Comme je l'ai dit dans un post précédent, il ne faut pas faire de l'objet pour faire de l'objet mais utiliser le style de programmation avec lequel on se sent à l'aise.
Bruno Desthuilliers
(snip)
ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code.
Quand ça te permet de simplifier ton code sans perdre (trop) en perf. La notion de 'simplification' étant aussi polymorphe que subjective. Quelques exemples : couche d'abstraction de DB, bibliothèque de traitement nécessitant la gestion de pas mal de variables internes (en l'occurrence, l'intérêt principal est d'éviter de polluer l'espace de nommage avec des fonctions et variables internes - l'objet en question est donc plus un module instanciable qu'autre chose), utilisation de l'héritage et du polymorphisme pour factoriser du code commun.
Est-ce purement subjectif ou y'a t'il des optimisations réelles?
Si tu penses aux perfs, la réponse devrait être évidente. En tous cas, je peux au moins te dire quand ne *pas* utiliser l'OO en PHP : quand c'est pour être buzzword-compliant.
Merci bien
(snip)
ma question est surtout de savoir à quel moment il devient plus
intéressant de passer par des objets plutôt que de traiter directement
dans le code.
Quand ça te permet de simplifier ton code sans perdre (trop) en perf. La
notion de 'simplification' étant aussi polymorphe que subjective.
Quelques exemples : couche d'abstraction de DB, bibliothèque de
traitement nécessitant la gestion de pas mal de variables internes (en
l'occurrence, l'intérêt principal est d'éviter de polluer l'espace de
nommage avec des fonctions et variables internes - l'objet en question
est donc plus un module instanciable qu'autre chose), utilisation de
l'héritage et du polymorphisme pour factoriser du code commun.
Est-ce purement subjectif ou y'a t'il des optimisations
réelles?
Si tu penses aux perfs, la réponse devrait être évidente. En tous cas,
je peux au moins te dire quand ne *pas* utiliser l'OO en PHP : quand
c'est pour être buzzword-compliant.
ma question est surtout de savoir à quel moment il devient plus intéressant de passer par des objets plutôt que de traiter directement dans le code.
Quand ça te permet de simplifier ton code sans perdre (trop) en perf. La notion de 'simplification' étant aussi polymorphe que subjective. Quelques exemples : couche d'abstraction de DB, bibliothèque de traitement nécessitant la gestion de pas mal de variables internes (en l'occurrence, l'intérêt principal est d'éviter de polluer l'espace de nommage avec des fonctions et variables internes - l'objet en question est donc plus un module instanciable qu'autre chose), utilisation de l'héritage et du polymorphisme pour factoriser du code commun.
Est-ce purement subjectif ou y'a t'il des optimisations réelles?
Si tu penses aux perfs, la réponse devrait être évidente. En tous cas, je peux au moins te dire quand ne *pas* utiliser l'OO en PHP : quand c'est pour être buzzword-compliant.
Merci bien
Marc
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité. ...
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul développeur
pour ma part, il m'arrive de bricoler des scripts rapidement en procedural, et des qu'il y a quelques fonctions et des données a manipuler, ca part rapidement en vrille, et la meilleur facon de tout remettre d'equerre est tout simplement de reforger 2 ou 3 classes rapidement.
du coup, je fais exclusivement des classes, meme si c'est parfois un excercice de style.
Maintenant il faut bien penser qu'il y a 2 sortes de classes. Les classes facon Pear, qui sont des classes a instancier avec des parametres de controle assez complexes a gerer.
Il existe aussi des classes minimalistiques qui ne font presque rien, parfois simplement presenter des interfaces. Et ces classes "toutes nues" ne servent qu'a etre surclassées.
A l'usage je me sens bien mieux dans la seconde.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture
et à augmenter la lisibilité.
...
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul
développeur
pour ma part, il m'arrive de bricoler des scripts rapidement
en procedural, et des qu'il y a quelques fonctions et des
données a manipuler, ca part rapidement en vrille, et la
meilleur facon de tout remettre d'equerre est tout simplement
de reforger 2 ou 3 classes rapidement.
du coup, je fais exclusivement des classes, meme si c'est
parfois un excercice de style.
Maintenant il faut bien penser qu'il y a 2 sortes de classes.
Les classes facon Pear, qui sont des classes a instancier
avec des parametres de controle assez complexes a gerer.
Il existe aussi des classes minimalistiques qui ne font
presque rien, parfois simplement presenter des interfaces.
Et ces classes "toutes nues" ne servent qu'a etre surclassées.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité. ...
Je la trouve tout à fait adaptée même lorsqu'il n'y a qu'un seul développeur
pour ma part, il m'arrive de bricoler des scripts rapidement en procedural, et des qu'il y a quelques fonctions et des données a manipuler, ca part rapidement en vrille, et la meilleur facon de tout remettre d'equerre est tout simplement de reforger 2 ou 3 classes rapidement.
du coup, je fais exclusivement des classes, meme si c'est parfois un excercice de style.
Maintenant il faut bien penser qu'il y a 2 sortes de classes. Les classes facon Pear, qui sont des classes a instancier avec des parametres de controle assez complexes a gerer.
Il existe aussi des classes minimalistiques qui ne font presque rien, parfois simplement presenter des interfaces. Et ces classes "toutes nues" ne servent qu'a etre surclassées.
A l'usage je me sens bien mieux dans la seconde.
__marc.quinton__
ftc wrote:
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité.
pour abonder dans ton sens, on va imaginer une application de dessin, réalisé avec la librairie GD par exemple.
# creation d'un objet Image. $img = new Image(200, 200);
je veux dessiner un objet dans cette image, 2 possibilités :
$img->draw_rectangle(...);
autre possibilité beaucoup plus interessante :
$obj = new Rectangle(...); $img->add($obj); img->draw(); # img est un container et va appliquer draw() a tous les enfants
dans cette seconde forme, il sera possible de creer différents type d'objet, et pour chacun d'eu, une methode d'affichage. De meme, si on veut que les objets soit sensibles a la designation, on pourra implementer des methodes permettant de definir si un objet a été designé ; c'est a chaque objet de repondre a cette question et pas au container. un petit fragment ci-dessous (purement imaginaire, mais implementable)
class Object {
var $x, $y, $w, $h; var $color;
function selected(&$event){ if($this->in_window($event->point())) return true; else return false; }
/* virtual */ function on_clic(&$event){ touch("/tmp/pouette"); }
function draw(&$img){ $img->draw_rectangle($this->window()); } }
il est assez facile dans ce cas d'identifier les objets, les methodes. Dans une application plus reelle, il devient beaucoup moins trivial de trouver ces fameux objets.
ftc wrote:
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture
et à augmenter la lisibilité.
pour abonder dans ton sens, on va imaginer une application
de dessin, réalisé avec la librairie GD par exemple.
# creation d'un objet Image.
$img = new Image(200, 200);
je veux dessiner un objet dans cette image, 2
possibilités :
$img->draw_rectangle(...);
autre possibilité beaucoup plus interessante :
$obj = new Rectangle(...);
$img->add($obj);
img->draw(); # img est un container et va appliquer draw() a tous les enfants
dans cette seconde forme, il sera possible de creer
différents type d'objet, et pour chacun d'eu, une methode
d'affichage. De meme, si on veut que les objets soit
sensibles a la designation, on pourra implementer des
methodes permettant de definir si un objet a été
designé ; c'est a chaque objet de repondre a cette question
et pas au container. un petit fragment ci-dessous (purement
imaginaire, mais implementable)
class Object {
var $x, $y, $w, $h;
var $color;
function selected(&$event){
if($this->in_window($event->point()))
return true;
else
return false;
}
/* virtual */ function on_clic(&$event){
touch("/tmp/pouette");
}
function draw(&$img){
$img->draw_rectangle($this->window());
}
}
il est assez facile dans ce cas d'identifier les objets, les methodes.
Dans une application plus reelle, il devient beaucoup moins trivial
de trouver ces fameux objets.
Avis totalement subjectif aussi: la POO a tendance à alléger l'écriture et à augmenter la lisibilité.
pour abonder dans ton sens, on va imaginer une application de dessin, réalisé avec la librairie GD par exemple.
# creation d'un objet Image. $img = new Image(200, 200);
je veux dessiner un objet dans cette image, 2 possibilités :
$img->draw_rectangle(...);
autre possibilité beaucoup plus interessante :
$obj = new Rectangle(...); $img->add($obj); img->draw(); # img est un container et va appliquer draw() a tous les enfants
dans cette seconde forme, il sera possible de creer différents type d'objet, et pour chacun d'eu, une methode d'affichage. De meme, si on veut que les objets soit sensibles a la designation, on pourra implementer des methodes permettant de definir si un objet a été designé ; c'est a chaque objet de repondre a cette question et pas au container. un petit fragment ci-dessous (purement imaginaire, mais implementable)
class Object {
var $x, $y, $w, $h; var $color;
function selected(&$event){ if($this->in_window($event->point())) return true; else return false; }
/* virtual */ function on_clic(&$event){ touch("/tmp/pouette"); }
function draw(&$img){ $img->draw_rectangle($this->window()); } }
il est assez facile dans ce cas d'identifier les objets, les methodes. Dans une application plus reelle, il devient beaucoup moins trivial de trouver ces fameux objets.
