Discussion :

[Kevin-lourenco]

Oui Lucky ! Enfin quelqu'un qui comprend vraiment !!!

Mais la question à 100 000euro et que personne ne semble pouvoir répondre est: qu'est-ce que peux bien être ce petit quelque chose ??

Si ça a été créé c est bien pour quelque chose, mais j ai l impression que beaucoup de codeur l utilisent sans trop savoir pourquoi et pourquoi pas (Je reste toujours sur l exemple du PHP. Je ne parle pas de tous les languages, certains n'était tant orienté que objet.).

[Luckyluke34]

Et quand je parlais de cette même conception objet pour la fonction ba celon la définition de steave job qu'un objet est un bloc ou le codeur n à pas besoin de comprendre ce qui a été fait pour l utiliser c est le cas également des fonctions.

Donc si une fonction est bien réfléchis elle fait parti intégrante d une conception objet (et n est pas un objet comme je l ai écris sans le vouloir)

Oui, ça s'appelle l'abstraction et ce n'est pas effectivement le propre de l'orienté objet. Mais il y a d'autres critères distinctifs (remonter au début de ce thread qui a fortement dérivé...)

[Kevin-lourenco]

Ba le post n a pas tant dévié que ça, je reste toujours sur la définition de la programmation orienté objet.

Si les méthodes procédurales, fonctionnelles et objets permettent de réaliser la même chose la conception objet se résume bien à ma définition.

Si les méthodes objets sortent bien du lot avec un quelque chose en plus alors je reverrais sûrement ma définition de la conception objet. Mais pour l'instant ce n'est pas le cas

[Luckyluke34]

Oui Lucky ! Enfin quelqu'un qui comprend vraiment !!!

Heu non, je dis juste que ta définition ne caractérise pas l'OO de manière satisfaisante mais qu'il existe bien une différence (cf http://c2.com/cgi/wiki?AlanKaysDefin...ObjectOriented).

Le reste du débat a dérivé sur des détails techniques anecdotiques (C++ vs PHP, manière de stocker les données) ou n'ayant rien à voir avec la question d'origine (frameworks, pages web, base de données orienté objet...)

[Kevin-lourenco]

Non mais justement c'est la ou je veux en venir par le bais d'exemples !

Une conception objet ce n'est pas forcément utiliser les méthodes dites objets des languages.

On peut très bien faire du procédural et que cela soit considéré comme une conception objet.

[Luckyluke34]

Si les méthodes procédurales, fonctionnelles et objets permettent de réaliser la même chose la conception objet se résume bien à ma définition.

Non, il existe des passerelles entre une fonction ou une procédure et un objet très éphémère qui effectuerait le même traitement, mais l'inverse n'est pas vrai.

En particulier, en fonctionnel une fonction doit être référentiellement transparente, c'est à dire que X appels de la fonction avec la même valeur en entrée doivent retourner X fois le même résultat. On peut substituer complètement l'appel d'une fonction avec le résultat de cette fonction. Ce n'est pas le cas d'un objet dès qu'il a un état interne qui persiste entre deux messages passés à cet objet. La possibilité de passer plusieurs messages successifs au même objet est d'ailleurs aussi ce qui différencie objet et procédure ou fonction.

Donc non, tous les objets ne peuvent pas être traductibles en fonctions ou procédures.

[Kevin-lourenco]

Si tu as le temps peux tu me donner un code exemple afin de mieux visualiser ?

[Luckyluke34]

Difficile de donner un exemple dans un langage de programmation que tout le monde connaitra. Mais pour faire une analogie, c'est comme la différence entre une calculatrice et une table de multiplication.

• La calculatrice stocke le dernier résultat calculé, ce qui fait qu'à chaque instant tu peux par exemple passer le message "X 3" à la calculatrice pour obtenir la dernière valeur multipliée par 3. A chaque fois la calculatrice va modifier son état interne pour stocker le nouveaux résultat. Deux passages de message "X 3" successifs ne retourneront pas le même résultat (sauf si la valeur d'origine est zéro). La calculatrice encapsule la donnée et le traitement.

• Une table de multiplication n'a pas d'état, elle est figée. Tu dois t'y référer à chaque fois que tu veux multiplier un nombre par 3 et elle te donnera à chaque fois le même résultat pour le même input.

La calculatrice serait un objet et la table de multiplication, une fonction (oui, l'analogie a ses limites mais c'est ce que j'ai trouvé).

Il est intéressant de noter que dans le cas de la table de multiplication, tu es obligé d'avoir ta propre feuille de papier à côté où tu écris l'état courant de ton calcul. C'est un peu ce qu'on fait en fonctionnel en séparant bien l'état mutable (qui est considéré comme "impur") du coeur du système qui lui est fait de fonctions référentiellement transparentes manipulant des structures de données immuables. Il n'y a ici pas encapsulation. Données et algorithmes sont séparés.

[Kevin-lourenco]

A oui d accord je vois ce que tu veux dire.

Tu veux dire qu'une donnée d'un objet valent 1 à qui on applique 3 fois la méthode multiplier par 3 retournera au final 3 x 1: 3 puis 3 fois 3: 9 enfin 9 x 3: 27.

Alors que la fonction aurait bêtement écrit 3 fois le résultat 3.

C est pour ça que je parle de conception objet. Si la fonction est pensé pour, elle peut facilement faire exactement comme le premier schéma de plusieurs manières différentes.

On aurait pus très bien donc:

MultiplierParTrois($valeur)
{
$resultat = $valeur * 3 ;

Return $resultat ;
}

$donnéeDeBase = 1 ;

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 3

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 9

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 27

(une boucle est plus propre bien évidement)

À la fin $donnéeDeBase est aussi égale à 27.

[vinmar]

Oui Lucky ! Enfin quelqu'un qui comprend vraiment !!!

Merci pour les autres

Mais la question à 100 000euro et que personne ne semble pouvoir répondre est: qu'est-ce que peux bien être ce petit quelque chose ??

Bah, le "petit quelque chose" comme tu dis c'est ça :

un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait interagir avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ;

Ce qu'il y a au dessus, c'est la particularité de la programmation orientée objet. Mais tu as d'autres paradigmes de programmation :

Un paradigme de programmation fournit (et détermine) la vue qu’a le développeur de l’exécution de son programme. Par exemple, en programmation orientée objet, les développeurs peuvent considérer le programme comme une collection d’objets en interaction, tandis qu’en programmation fonctionnelle un programme peut être vu comme une suite d'évaluations de fonctions sans états. Lors de la programmation d’ordinateurs ou de systèmes multi-processeurs, la programmation orientée processus permet aux développeurs de voir les applications comme des ensembles de processus agissant sur des structures de données localement partagées.

Sources : https://fr.wikipedia.org/wiki/Progra...t%C3%A9e_objet et https://fr.wikipedia.org/wiki/Paradi...ogrammation%29

Ces sources rejoignent les dires de Luckyluke34. Et nous pouvons tous constater que tu préfères la programmation fonctionnelle.

Si ça a été créé c est bien pour quelque chose, mais j ai l impression que beaucoup de codeur l utilisent sans trop savoir pourquoi et pourquoi pas (Je reste toujours sur l exemple du PHP. Je ne parle pas de tous les languages, certains n'était tant orienté que objet.).

Un paradigme est une représentation du monde, une manière de voir les choses, un modèle cohérent de vision du monde qui repose sur une base définie

Voilà pourquoi les développeurs utilisent l'orientée objet : parce que c'est un paradigme informatique qui permet de représenter le vrai monde qui lui est composé d'objets qui interagissent entre eux. Lorsque je code un logiciel pour gérer des stocks de boulons, bah j'aime bien avoir dans mon programme un "bout de code" (pour rester abstrait) qui représente au mieux mon boulon => c'est la programmation orientée objet

[Luckyluke34]

$donnéeDeBase = 1 ;

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 3

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 9

$donnéeDeBase=MultiplierParTrois($donnéeDeBase) ;

// $donnéeDeBase= 27

Exactement, mais ceci est une approche plutôt fonctionnelo-procédurale. Il y a absolument zéro conception objet dans ce code. Maintenant, enveloppe ça dans une classe avec un membre privé pour stocker l'état du calcul, garde la méthode en enlevant le paramètre $donnéeDeBase et tu as un objet avec une membrane, une cloison, donc une approche orientée objet.

Evidemment qu'une solution OO et une solution fonctionnelle peuvent arriver au même résultat, mettre en oeuvre les mêmes algorithmes. Mais ça n'en fait pas pour autant des paradigmes identiques. C'est dans la façon de découper son programme, dans la manière d'articuler données et traitements que tout est différent.

[I_Pnose]

Mais la question à 100 000euro et que personne ne semble pouvoir répondre est: qu'est-ce que peux bien être ce petit quelque chose ??

Si ça a été créé c est bien pour quelque chose, mais j ai l impression que beaucoup de codeur l utilisent sans trop savoir pourquoi et pourquoi pas (Je reste toujours sur l exemple du PHP. Je ne parle pas de tous les languages, certains n'était tant orienté que objet.).

Durant ces "quelques" pages certains ont mis l’accent sur l’encapsulation et la séparation des responsabilités, mais il y a également le polymorphisme (selon lequel un objet peut appartenir à plus d’un types) qu'il convient de mettre au crédit d'une approche orientée objet ; une façon façon parmi d’autres de procéder (qu’on retrouve dans la plupart des langages OO) c’est d’utiliser l’héritage.

Un exemple qui vaut ce qu’il vaut (mes excuses aux puristes =P)

Une classe Vehicule (la sempiternelle) :

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
    public class Vehicule
    {
        public byte NombreDePlace { get; protected set; }
        public Reservoir Reservoir { get; protected set; }
        
        public void Avancer()
        {
            // Do stuff.
        }

        public void Freiner()
        {
            // Do stuff.
        }

        public void RemplirReservoir()
        {
            Reservoir.Remplir();
        }
    }

On peut voir que cette dernière possède un membre de type Reservoir et qu’elle peut interagir avec celui-ci :

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
    public class Reservoir
    {
        public int NiveauActuel { get; private set; }
        public int Contenance { get; private set; }

        public Reservoir(int contenance)
        {
            Contenance = contenance;
        }

        public void Remplir()
        {
            NiveauActuel = Contenance;
        }
    }

Vient ensuite la classe Voiture qui vient spécifier un véhicule, cette classe a donc des propriétés propres (en plus de celles du véhicule). En d’autres termes, une voiture est un véhicule particulier (avec un nombre donné de places et de portes par exemple) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
    public class Voiture : Vehicule
    {
        public byte NombreDePorte { get; private set; }

        public Voiture(byte nbPlace = 5, byte nbPorte = 5)
        {
            NombreDePlace = nbPlace;
            NombreDePorte = nbPorte;
            Reservoir = new Reservoir(50); // Un réservoir de 50 litres
        }
    }

Même principe avec une moto qui est également un véhicule mais avec un réservoir plus petit, moins de places assises et aucune porte :

Code :

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

1
2
3
4
5
6
7
8
    public class Moto : Vehicule
    {
        public Moto()
        { 
            NombreDePlace = 2;
            Reservoir = new Reservoir(20);
        }
    }

Autre exemple d’un Monospace qui est une voiture (et par corollaire un véhicule). Le monospace est simplement une voiture avec plus de places et un plus gros réservoir (on pourrait imaginer qu’il possède d’autres propriétés propres) :

Code :

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

1
2
3
4
5
6
7
8
    public class Monospace : Voiture
    {
        public Monospace()
        {
            NombreDePlace = 8;
            Reservoir = new Reservoir(80);
        }
    }

Enfin on a une StationService qui va pouvoir interagir avec un véhicule (peu importe qu’il s’agisse d’une moto, d’une voiture, etc...) :

Code :

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

1
2
3
4
5
6
7
    public class StationService
    {
        public void FournirCarburant(Vehicule vehicule)
        {
            vehicule.RemplirReservoir();
        }
    }

On peut alors imaginer un programme qui joue avec tous ces modules :

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
26
    public class Program
    {
        public static void Main()
        {
            var station = new StationService();

            var vehicules = new List<Vehicule>
            {
                new Voiture(), 
                new Moto(), 
                new Monospace()
            };

            foreach (var vehicule in vehicules)
            {
                vehicule.Avancer();
            }

            var moto = vehicules.FirstOrDefault(v => v is Moto);

            if (moto != null)
            {
                station.FournirCarburant(moto);
            }
        }
    }

Maintenant la vraie question à 100 000 euros : peux-tu faire aussi modulable et structuré que ça avec une approche procédurale ?

(Désolé pour le code, ce n’est pas du PHP –pas ma tasse de thé– mais j’ose espérer que le code est lisible).

[Kevin-lourenco]

Maintenant la vraie question à 100 000 euros : peux-tu faire aussi modulable et structuré que ça avec une approche procédurale ?

CHALLENGE ACCEPTED !

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// On ne va prendre que le premier exemple de la voiture donc on ne va pas prendre en compte le type mais directement la taille du réservoir spécifiée.
$monAppareil = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Voiture'
	'nombreDePorte' => 5, 
	'NombreDePlace' => 5,
	'CapaciteReservoir' => 50, 
	'ReservoirActuel' => 0
) ;


// Le réservoir est à plat, allez vite il faut le remplir ! 
$monAppareil = RemplirReservoir($monAppareil) ; 

// La fonction doit être créée avant d'être appelée, mais dans un soucis de lisibilité des étapes je l'écris ici
RemplirReservoir($monAppareil)
{
	// Une petite condition, ça fait pas de mal pour voir si la personne à vraiment besoin de remplir son réservoir
	if($monAppareil['ReservoirActuel'] < $monAppareil['CapaciteReservoir'])
	{
		// Hop on rempli le réservoir jusqu'au maximum
		$monAppareil['ReservoirActuel'] = $monAppareil['CapaciteReservoir'] ; 
	}

        return $monAppareil ;
}

//Et si j'avais voulu mettre un autre véhicule tout simple : 

$monAppareil2 = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Moto'
	'nombreDePorte' => 0, 
	'NombreDePlace' => 2,
	'CapaciteReservoir' => 20, 
	'ReservoirActuel' => 5
) ;

// Exactement de la même manière
$monAppareil2 = RemplirReservoir($monAppareil2) ;

On aurait même pu pour quelqu'un qui ne sait pas faire de tableau ou bien où trouver les données à entrer dans celui-ci créer une fonction pour lui !

Code :

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

1
2
3
4

$monAppareil = CrerMonAppareil('Voiture') ;
// Une fonction qui va créer le tableau désiré

[vinmar]

CHALLENGE ACCEPTED !

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// On ne va prendre que le premier exemple de la voiture donc on ne va pas prendre en compte le type mais directement la taille du réservoir spécifiée.
$monAppareil = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Voiture'
	'nombreDePorte' => 5, 
	'NombreDePlace' => 5,
	'CapaciteReservoir' => 50, 
	'ReservoirActuel' => 0
) ;


// Le réservoir est à plat, allez vite il faut le remplir ! 
$monAppareil = RemplirReservoir($monAppareil) ; 

// La fonction doit être créée avant d'être appelée, mais dans un soucis de lisibilité des étapes je l'écris ici
RemplirReservoir($monAppareil)
{
	// Une petite condition, ça fait pas de mal pour voir si la personne à vraiment besoin de remplir son réservoir
	if($monAppareil['ReservoirActuel'] < $monAppareil['CapaciteReservoir'])
	{
		// Hop on rempli le réservoir jusqu'au maximum
		$monAppareil['ReservoirActuel'] = $monAppareil['CapaciteReservoir'] ; 
	}

        return $monAppareil ;
}

//Et si j'avais voulu mettre un autre véhicule tout simple : 

$monAppareil2 = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Moto'
	'nombreDePorte' => 0, 
	'NombreDePlace' => 2,
	'CapaciteReservoir' => 20, 
	'ReservoirActuel' => 5
) ;

// Exactement de la même manière
$monAppareil2 = RemplirReservoir($monAppareil2) ;

On aurait même pu pour quelqu'un qui ne sait pas faire de tableau ou bien où trouver les données à entrer dans celui-ci créer une fonction pour lui !

Code :

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

1
2
3
4
$monAppareil = CrerMonAppareil('Voiture') ;
// Une fonction qui va créer le tableau désiré

Désolé de te dire ça mais si tu trouves que ce que tu viens de faire est aussi modulable et structuré que l'exemple d'I_Pnose, mieux vaut en rester là...

[AoCannaille]

Désolé de te dire ça mais si tu trouves que ce que tu viens de faire est aussi modulable et structuré que l'exemple d'I_Pnose, mieux vaut en rester là...

Merci de mettre des mots sur une pensée que je n'ai pas réussi à formuler diplomatiquement...

[Kevin-lourenco]

Alors nous en resterons là

[AoCannaille]

Alors nous en resterons là

Avec ton implémentation, comment modéliserai-tu "proprement" une donnée spécifique à un un type de véhicule?

Par exemple, CouleurDeLaSelle pour une moto ?

[I_Pnose]

CHALLENGE ACCEPTED !

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// On ne va prendre que le premier exemple de la voiture donc on ne va pas prendre en compte le type mais directement la taille du réservoir spécifiée.
$monAppareil = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Voiture'
	'nombreDePorte' => 5, 
	'NombreDePlace' => 5,
	'CapaciteReservoir' => 50, 
	'ReservoirActuel' => 0
) ;


// Le réservoir est à plat, allez vite il faut le remplir ! 
$monAppareil = RemplirReservoir($monAppareil) ; 

// La fonction doit être créée avant d'être appelée, mais dans un soucis de lisibilité des étapes je l'écris ici
RemplirReservoir($monAppareil)
{
	// Une petite condition, ça fait pas de mal pour voir si la personne à vraiment besoin de remplir son réservoir
	if($monAppareil['ReservoirActuel'] < $monAppareil['CapaciteReservoir'])
	{
		// Hop on rempli le réservoir jusqu'au maximum
		$monAppareil['ReservoirActuel'] = $monAppareil['CapaciteReservoir'] ; 
	}

        return $monAppareil ;
}

//Et si j'avais voulu mettre un autre véhicule tout simple : 

$monAppareil2 = array(
	'Famille' => 'Vehicule' , 
	'type' => 'Moto'
	'nombreDePorte' => 0, 
	'NombreDePlace' => 2,
	'CapaciteReservoir' => 20, 
	'ReservoirActuel' => 5
) ;

// Exactement de la même manière
$monAppareil2 = RemplirReservoir($monAppareil2) ;

Avec ton approche, tes fonctions n’ont absolument aucun scope ; rien ne t’empêche de remplir le réservoir d’une voiture, d’un chien ou d’un arbre (et dans ces deux derniers cas ça n’a aucun sens).

Il n’y a absolument aucune encapsulation des propriétés de tes objets tableaux ; c’est littéralement open-bar.

Comment je fais pour créer un monospace avec ton approche (je veux qu’il soit de type Monospace, Voiture ET Vehicule). Et, surtout, demain j’aurais peut-être besoin de manipuler un type MonospaceTunning (qui sera de type MonospaceTunning, Monospace, Voiture ET Vehicule... et qui possèdera une propriété Neons et une autre Falmming par exemple).

Sans compter que si tu souhaites avoir un traitement différents sur le comportement "Avancer" en fonction du type de véhicule, tu vas devoir faire une horrible fonction de 6 kilomètres avec des if/else (ou switch) à rallonge ou bien démultiplier des fonctions à plat, sans aucun scope (encore une fois il sera alors possible de faire voler une moto ou bien rouler un hélicoptère, sans que cela ait le moindre sens), alors qu’avec une approche objet le comportement Avancer d’une Voiture est clairement défini dans sa classe (via une surcharge de la méthode Avancer de la classe de base Vehicule).

Bref, non, je ne suis pas convaincu par ta façon d’organiser/structurer tes données.

[Kevin-lourenco]

La manière la plus simple est de l'ajouter directement !

$monAppareil = array(
'Famille' => 'Vehicule' ,
'type' => 'Voiture'
'nombreDePorte' => 5,
'NombreDePlace' => 5,
'CapaciteReservoir' => 50,
'ReservoirActuel' => 0
'CouleurSelle' => 'null'
) ;

Ok, on voit qu'ici ça peut polluer de mettre des attribues qui ne seront pas pour d'autre appareil. Donc si on veut que ça reste lisible toujours en PHP :

1/ Reprendre la structure de base du tableau similaire à tous les véhicules.
2/ Y ajouter la donnée en question en plus

Code :

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

1
2
3
4
5

$donnees_en_plus = array("CouleurSelle"=>"Bleu", "CouleurDuCoffre"=>"vert" ); 

$monAppareil = array_merge($monAppareil, $donnees_en_plus);

Pour éviter de recréer la méthode on peut simplement utiliser une condition toute simple lors de la création de l'appareil (si c'est une moto on rajoute la couleur de la selle sinon on ne met pas la donnée dans le tableau) ou on créer une fonction pour pouvoir ajouter des données à tous moments dans un objet.

La dernière solutions étant encore mieux pour pouvoir quand on veut ajouter des attribus :

Code :

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

1
2
3
4
5
6
7
8
9
10
11

ajouterAttribusAppareil($monAppareil  , $attribus , $valeur)
{
   $donnees_en_plus = array($attribus => $valeur); 

    return $monAppareil = array_merge($monAppareil);
}

// C'est simple
ajouterAttribusAppareil($monAppareil  , 'CouleurSelle' , 'bleu' ) ;

Et rien ne nous empêche d’exécuter une fonction dans une fonction, donc banco ! On peut donc dès la création du véhicule voir si c'est une moto :

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
CrerMonAppareil($type)
{
	$monAppareil = array(
		'Famille' => 'Vehicule' , 
		'type' => 'Voiture'
		'nombreDePorte' => 5, 
		'NombreDePlace' => 5,
		'CapaciteReservoir' => 50, 
		'ReservoirActuel' => 0
	) ;
	
	if($type == 'moto')
	{
		$monAppareil = ajouterAttribusAppareil($monAppareil  , 'CouleurSelle' , 'bleu' ) ;
	}
	
	return $monAppareil ; 
}

[Kevin-lourenco]

Je ne suis moi-même pas convaincu de l'efficacité apparente de ta méthode par rapport à la mienne. Je l'utiliserais surement dans un prochain nouveau projet pour ne pas mourir idiot mais surement pas dans un projet existant, ce serait une perte de temps.