[PHP 5.2] Multiples signatures d'un constructeur [Résolu]

[lamb87]

Bonjour,

Je cherche à utiliser plusieurs constructeurs dans la même classe.

J'ai réussi à l'aide de Switch et de la fonction func_get_arg(). Cependant, mon maître de stage n'approuve pas cette méthode (selon lui, le code ne serait pas en objet pur et le code ne serait pas réutilisable facilement) et me demande de le faire à l'aide de tableaux mais je ne vois pas du tout comment faire

Merci d'avance pour votre aide.

[Benjamin Delespierre]

Il n'a pas totalement tor mais je pense que c'est toi qui a raison, si tu veux réélement avoir plusieurs prototypes disponibles pour un constructeur, il vaut mieux utiliser func_get_args.

Enfin bref, ce que tu peux faire sinon (et qui est largement pratiqué dans certains frameworks comme Symphony pour les helpers de vue) c'est d'injecter un tableau, comme il le préconise, ça donne effectivement encore plus de souplesse.

Voici concrêtement à quoi ça peut ressembler:

Code :

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
class Test extends stdClass {
 
  public function __construct (array $params = array()) {
    $defaults = array(
      'a' => 1,
      'b' => 2,
      'c' => 3
    );
 
    $params += $defaults;
 
    // Attention avec extract !
    extract($params);
 
    $this->a = $a;
    $this->b = $b;
    $this->c = $c;
  }
 
  public function __toString () {
     return "A {$this->a} B {$this->b} C {$this->c}";
  }
}
 
$t = new Test;
echo $t;
 
$t = new Test(array('a' => 4, 'c' => 8));
echo $t;

Tu peux d'ailleurs "mixer" les deux formes, voici ce que ça donnerai:

Code :

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
class Test extends stdClass {
 
	public function __construct () {
		$argc = func_num_args();
		$argv = func_get_args();
 
		if ($argc == 1 && is_array($argc)) {
			$params = $argv[0];
		}
		else {
			$params = array_combine(array('a','b','c'), $argv + array(null, null, null));
		}
 
		$defaults = array(
			'a' => 1,
			'b' => 2,
			'c' => 3,
		);
 
		$params += $defaults;
 
		$this->a = $params['a'];
		$this->b = $params['b'];
		$this->c = $params['c'];
	}
 
	public function __toString () {
		return "A {$this->a} B {$this->b} C {$this->c}";
	}
}
 
// Les formes suivantes sont équilvalentes
$t1 = new Test(1,2,3);
$t2 = new Test(array('a' => 1, 'b' => 2, 'c' => 3));
 
echo $t1 . '<br />';
echo $t2;

A toi de voir

L'inconvénient majeur de ces deux formes est qu'on ne bénéficie plus du type hinting, c'est donc au constructeur de valider les données qu'il reçoit au niveau de leur typage... pas très pratique. De plus, on peut passer des arguments arbitraires complétement inutiles ou pire.

[transgohan]

C'est même moins bon je trouve car il faut aussi vérifier les index correspondant à des variables privé dont on ne doit pas modifier la valeur.

Par contre pourriez-vous détailler le pourquoi pour func_get_args() ?

[Benjamin Delespierre]

Envoyé par transgohan

Par contre pourriez-vous détailler le pourquoi pour func_get_args() ?

Bah pour avoir plusieurs signatures pour le constructeur pardi

[lamb87]

Bonjour et merci pour les réponse

@Benjamin Delespierre
Je ne comprend pas très bien désolé (je suis dans la prog objet depuis peu) mais par exemple que peut on mettre dans $param si on en a plusieurs ? Et je ne comprend pas le $params += $defaults;

@transgohan
Si ta question est "Pourquoi il ne veut pas de la fonction ?" C'est apparemment parce que le code doit être réutilisable.

[Benjamin Delespierre]

Envoyé par lamb87

@Benjamin Delespierre
Je ne comprend pas très bien désolé (je suis dans la prog objet depuis peu) mais par exemple que peut on mettre dans $param si on en a plusieurs ? Et je ne comprend pas le $params += $defaults;

Le tableau associatif $params remplace les paramètre qu'on passe sur la fonction habituellement. Les clés sont les noms des paramètres.

L'utilisation de l'opérateur + sur des tableaux à pour conséquence d'ajouter au premier les valeurs du second dont les clés ne sont pas présentes dans le premier. Dans notre cas, ça va mettre les valeurs par défaut (définies dans $defaults) là dans $params si ces valeurs n'ont pas étés spécifiées.

Un exemple vaut mieux qu'un long discours:

Code :

1
2
3
4
5
6
7
8
9
10
11
$a = array(
	'a' => 1,
	'b' => 2,
);
 
$b = array(
	'b' => 3,
	'c' => 4,
);
 
var_dump( $a + $b );

produit

Code :

1
2
3
4
array
  'a' => int 1
  'b' => int 2
  'c' => int 4

On remarque que:

• les valeurs de $b dont les clés ne se trouvent pas dans $a ont étés ajoutées
• les valeurs de $a dont les clés sont présentes dans $b ne sont pas écrasées

Pour la petite histoire, quand on veut explicitement écraser les valeurs existantes, on utilise array_merge.

[lamb87]

Mais pourquoi $b a 'int (2)' ?
Désolé mais je souhaite vraiment comprendre à fond

[grunk]

Parce que un var_dump affiche des résultat sous la forme

Code :

type (valeur)

[Benjamin Delespierre]

Quand la clé est présente dans le coté gauche, elle n'est pas écrasée par celle du coté droit tout simplement.

Si on voulait reproduire le comportement de l'opérateur + sur des tableaux de façon programmatique on ferait:

Code :

1
2
3
4
5
6
7
8
9
$a = array('a' => 1, 'b' => 2);
$b = array(          'b' => 3, 'c' => 4);
 
foreach ($b as $key => $value) {
	if (!isset($a[$key]))
		$a[$key] = $value;
}
 
var_dump( $a );

Mais on reconnaitra qu'il est plus agréable de faire:

Code :

$a += $b

non ?

Tout est expliqué ici: http://www.php.net/manual/fr/languag...tors.array.php

[lamb87]

Ah d'accord

Je te remercie amplement Benjamin pour tes réponses et merci d'avoir pris le temps de m'expliquer

[transgohan]

Je me permet de continuer un peu la discussion pour ma culture personnelle.

C'était bien entendu "en quoi c'est mal", mais je ne vois pas pourquoi utiliser cette fonction donnerai du code non réutilisable ?
Car justement j'ai tendance à l'utiliser, je trouve cela plus propre à écrire que d'utiliser un tableau. :/

[Benjamin Delespierre]

Je pense qu'il voulait plus dire "générique" que "réutilisable". Car oui, des signatures "dynamiques" de fonctions offrent beaucoup plus de flexibilité au détriment de la sécurité.

Par exemple:

Code :

1
2
3
4
5
6
7
class Test {
	public function __construct (A $a, B $b = null, array $c = array()) {
		$this->_inst_a = $a;
		$this->_inst_b = $b;
		$this->_arr_c  = $c;
	}
}

Grâce au type hinting on se fait jeter si on ne fournit pas les bons types de données à notre constructeur, ce qui nous apporte plus de sécurité.

Pour avoir un comportement équivalent avec une signature générique, il faut ajouter pas mal de code, effectuer le type hinting à la main (instanceof et is_*) et ajouter les valeurs par défaut nous même. Qu'on décide d'utiliser des tableaux ou de jouer avec func_get_args.

[transgohan]

C'est bien ce qu'il me semblait.

Par contre je viens d'apprendre qu'on pouvait typer les variables dans un prototype en PHP.

[RunCodePhp]

Envoyé par transgohan

Par contre je viens d'apprendre qu'on pouvait typer les variables dans un prototype en PHP.

Effectivement, c'est assez récent et je trouve que ça apporte un réel plus.

Cependant, ce "typage" s'arrête uniquement aux Objets et aux tableaux, et donc rien encore au niveau des integer, booléen, etc ...

Ceci dit, rien n'empêche de le faire, d'imposer les autres types.
Exemple simple :

Code :

1
2
3
4
5
 
public function uneMethode($int, $bool) {
    if (is_int($int) === FALSE) trigger_error('$int n\'est pas un integer !');
    if (is_bool($bool) === FALSE) trigger_error('$bool n\'est pas un booléen !');
}

(au lieu de lancer une erreur, on peu lancer une Exception ou faire un try/catch).

[transgohan]

Ah bah si seulement les objets sont pris en compte en effet il reste de l'évolution à attendre...
Je continuerai à faire mes tests de type renvoyant des exceptions.

[Benjamin Delespierre]

Envoyé par RunCodePhp

Cependant, ce "typage" s'arrête uniquement aux Objets et aux tableaux, et donc rien encore au niveau des integer, booléen, etc ...

Tout à fait, à moins d'utiliser l'extension SPL Types qui permet de typecaster les types natifs en objets (exactement de la même façon qu'en Java). J'adorerai que ça fasse partie du CORE un de ces 4

Allez voir par ici pour plus de détails: http://php.net/manual/en/book.spl-types.php

Par contre je viens d'apprendre qu'on pouvait typer les variables dans un prototype en PHP.

Au passage, le type hinting reconnais les ancêtres des objets passés en paramètres. Le code ci dessous est parfaitement valide:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
class A extends ArrayObject {
}
 
class B extends A implements C {
}
 
interface C extends Countable {
}
 
function do_something (B $first, C $second) {
}
 
do_something( new B, new B );

Ceci est très pratique pour demander en paramètre d'une fonction / méthode des instances dont les classes implémentent une interface spécifique.

[rawsrc]

Envoyé par Benjamin Delespierre

Tout à fait, à moins d'utiliser l'extension SPL Types qui permet de typecaster les types natifs en objets (exactement de la même façon qu'en Java).

Pour ceux qui seraient intéressés par le sujet : il faut regarder du côté de l'autoboxing:

[RunCodePhp]

Envoyé par Benjamin Delespierre

Au passage, le type hinting reconnais les ancêtres des objets passés en paramètres. Le code ci dessous est parfaitement valide:

Code :

Ceci est très pratique pour demander en paramètre d'une fonction / méthode des instances dont les classes implémentent une interface spécifique.

Ca m'a l'air bien intéressant, mais je ne suis pas certain d'avoir réellement tout compris, tout vu.

Je sais qu'on ne peux pas instancier une interface, faut créer une classe dérivée pour ça.

Cette démo serait (peut être) pour dire qu'on peut quand même créer une fonction (ou méthode de classe, peu importe) qui attendrait une interface en paramètre.
Ensuite, en pratique on passera l'Objet dérivée de cette interface.
Est-ce cela ?


Cet exemple plus simple serait il correcte ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
interface UneInterface {}
 
class DeriveeA implements UneInterface {}
class DeriveeB implements UneInterface {}
 
fonction appeler_interface(UneInterface $derivee) {}
 
 
// Appels de fonction
$deriveeA = new deriveeA();
appeler_interface($deriveeA);
 
$deriveeB = new deriveeB();
appeler_interface($deriveeB);

Est-ce que ça marche uniquement pour les interfaces, ou est-ce que ça marche quelque soit le type, c'est à dire, quelque soit le parent ? (interface, abstraction, classe)
Grosso modo : A partir du moment ou l'Objet passé en paramètre est un dérivée de celui déclaré, ça passera.

Et quelque soit la profondeur aussi ?
C'est a dire : admettons une classe A, puis une classe B dérivée de A, puis une classe C dérivée de B.
Je déclare dans la fonction le type d'Objet -> A, et je passe en paramètre un Objet C.
Ca marcherait ça ?
J'ai tendance à dire qu'il ne faudrait pas. Mais ??? (sans vraiment d'explications).


(vous allez dire qu'il suffit d'essayer )

[Benjamin Delespierre]

Cette démo serait (peut être) pour dire qu'on peut quand même créer une fonction (ou méthode de classe, peu importe) qui attendrait une interface en paramètre.
Ensuite, en pratique on passera l'Objet dérivée de cette interface.
Est-ce cela ?

C'est cela mais c'est mal dit. Certes, une interface n'est pas instanciable, il faut obligatoirement une classe concrète en dessous. On peut demander dans un prototype de fonction (ou méthode) une instance de classe qui implémente cette interface.

Est-ce que ça marche uniquement pour les interfaces, ou est-ce que ça marche quelque soit le type, c'est à dire, quelque soit le parent ? (interface, abstraction, classe)

ça marche pour tout (classe, classe abstraite, interface) et à n'importe quel niveau. En fait ça se comporte pareil que instanceof.

Vu que mon exemple n'était effectivement pas bien parlant, en voici un autre:

Code :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
interface Affichable {
	public function __toString ();
}
 
// Package Geometry
 
abstract class FormeGeometrique implements Affichable {
 
	abstract public function obtenirAire ();
 
	public function __toString () {
		return "Je suis un " . get_class($this) . " et mon aire est " . $this->obtenirAire();
	}
}
 
class Rectangle extends FormeGeometrique {
 
	protected $_width;
	protected $_height;	
 
	public function __construct ($longueur, $largeur) {
		$this->_width = $largeur;
		$this->_height = $longueur;
	}
 
	public function obtenirAire () {
		return ($this->_width * $this->_height) . ' cm²';
	}
}
 
class Cercle extends FormeGeometrique {
 
	protected $_radius;
 
	public function __construct ($rayon) {
		$this->_radius = $rayon;
	}
 
	public function obtenirAire () {
		// on va se faire ch***
		return (3.14 * $this->_radius * $this->_radius) . ' cm²';
	}
}
 
// Package Vehicule
 
abstract class Vehicule implements Affichable {
 
	abstract public function obtenirNombreRoues();
 
	public function __toString () {
		return "Je suis une " . get_class($this) . " et j'ai " . $this->obtenirNombreRoues() . " roues";
	}
}
 
class Voiture extends Vehicule {
 
	public function obtenirNombreRoues() { return 4; }
}
 
class Moto extends Vehicule {
 
	public function obtenirNombreRoues() { return 2; }
}
 
// Afficher n'importe quoi
 
function afficher_nimporte_quoi( Affichable $affichable ) {
	echo $affichable;
}
 
// Allons-y !
 
$cercle = new Cercle( 5 );
$rect   = new Rectangle( 10, 10 );
 
afficher_nimporte_quoi($cercle); echo '<br />';
afficher_nimporte_quoi($rect); echo '<br />';
 
$voiture = new Voiture;
$moto    = new Moto;
 
afficher_nimporte_quoi($voiture); echo '<br />';
afficher_nimporte_quoi($moto);

C'est à ça que servent les interfaces

[RunCodePhp]

Envoyé par Benjamin Delespierre

C'est à ça que servent les interfaces

Ca sert à afficher_nimporte_quoi() ?
Je plaisante

Merci pour ces compléments d'infos et démos

J'avais de gros aprioris à ce niveau en tout cas, je ne pensais pas qu'on pouvait déclarer le parent, voir en deçà.
Ou alors si je l'ai fais, je m'en suis même pas rendu compte.

Ceci dit, j'imagine qu'on peu aussi tomber dans la simplicité, c'est à dire qu'au final obtenir un "typage" pas si restrictif que ça si on crée à chaque fois une interface, on dérive un peu tout, et puis ...
Histoire d'éviter de se faire "taper sur les doigts", nous dire que le type ne serait pas le bon.
Mais bon ...

J'aurais bien aimé des types integer, bool, float, et compagnie, et ça nativement (sans PECL), car finalement, même pour les Objets ou tableaux, Php ne l'impose pas.
Je me dis que ça devrait venir un jour (Php 6 peut être).

Merci encore.