Discussion :

[keaton7]

Bonjour,

J'aimerai savoir lequel de ces 3 exemples est préférable :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// Exemple 1
$MonObjet = new MonObjet;
$MonObjet->maPropriete = 12;
 
// Exemple 2
$MonObjet = new MonObjet;
$MonObjet->attribuer("maPropriete",12);
 
// Exemple 3
$MonObjet = new MonObjet;
$MonObjet->attribuerMaPropriete(12);

D'avance merci pour vos suggestions.

[s.n.a.f.u]

Salut,

l'exemple 1 est à réserver à des petits projets en RAD. C'est juste bon à gagner un peu de temps sur le codage.

Les deux autres exemples se valent.

L'exemple 3 est celui de la rigueur absolue et le plus rigide à coder.

L'exemple 2 est assez à la mode, Et il peut ensuite revenir sur l'exemple 3 grâce à la méthode 'magique' _call

[keaton7]

Bonjour,

Merci pour ta reponse, precise, et concise.

Je travaille sur un la création d'un CMS, dont j'essaie au maximum de respecter des motifs de conceptions stricts. Ce CMS va servir a alimenter une bonne quantité de sites.

Pour le moment, j'utilise la 1ere méthode, d'après ton exemple, je devrai passer a l'une des 2 suivantes (j'ai bien fait de poser la question ^^).

Laquelle me conseillerais-tu sur ce genre de projet ?

C'est quoi un petit projet en "RAD" ?

[s.n.a.f.u]

RAD = Rapid Application Development. Du vite fait, bien fait si possible.

Le choix le plus souple est le 2.
Le choix le plus rigoureux est le 3.

You choose.

[keaton7]

Bon je vais opter pour le rigoureux, mon code est déjà loin d'être souple ^^.

Mais d'ailleurs, pourquoi l'exemple 1 est-il déconseillé ?

Il ne me semble pas que ça existe dans les langages objet cette première syntaxe ?

[grunk]

Mais d'ailleurs, pourquoi l'exemple 1 est-il déconseillé ?

Parce que comme son nom l'indique un attribut public est ... public ^_^. Et donc il peut être modifié par n'importe quoi sans aucun controle sur la modification.

Il ne me semble pas que ça existe dans les langages objet cette première syntaxe ?

Si elle existe , c'est juste que généralement on ne déclare pas des attribut public et on passe comme dans les solution 2 ou 3 par des getter/setter

[keaton7]

Ok, mais accéder a un attribut prive via un getter (cad hors de la classe), c'est tricher non ?

[grunk]

Ok, mais accéder a un attribut prive via un getter (cad hors de la classe), c'est tricher non ?

Non ça permet d'être certains des valeur que tu envoi/reçois , c'est tout
Après c'est tout l'intérêt de la 3ème méthode , c'est que les variables que tu veux laisser "intouchable" pourront l'être alors qu'avec la seconde tu pourras y accéder.

Mais plus on descend dans les example plus c'est contraignant à coder

[keaton7]

Mais plus on descend dans les exemple plus c'est contraignant à coder

Je ne cherche pas une solution facile, juste la meilleure solution

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class MonObjet {
 
  public toto;
  private tutu;
 
  // etc.
 
  public function attribuerToto($element) {
 
    $this->toto = $element;
 
  }
 
}

La solution 1 et 3 sont strictement équivalentes, puisque :

• via $monObjet->toto, je ne peux pas attribuer de valeur a une propriété privée ($monObjet->tutu afficherai une erreur)
• via $monObjet->attribuerToto(), je ne peux attribuer une valeur QUE a une propriété dont j'ai créé la méthode correspondante (dans ce contexte $monObjet->attribuerTutu() n'existerai pas)

Qu'est ce qui va faire la différence entre les 2 ??

[s.n.a.f.u]

Avec les setter, tu peux faire de la vérification de variable (par exemple)

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
 
<?php
class MonObjet {
 
  public toto;
  private tutu;
 
  // etc.
 
  public function attribuerToto($element) {
    if ( empty(trim($element))) ) throw new Exception ("tentative d'assignation vide");
    if ($element == "valeur_interdite") throw new Exception("valeur interdite");
    // etc...
    $this->toto = trim($element);
 
  }
 
}

[keaton7]

Ok, j'ai toutes les infos pour continuer a programmer dans les meilleures condition.

Merci.

Tu peux peut-être m'en dire plus sur le throw, je ne trouve pas de doc sur ce mot-cle directement, mais sur les exceptions par son biais. Le throw est-il relatif uniquement aux Exceptions ?

Je vois dans la doc des exceptions que ca s'utilise en particulier avec un try, ce qui n'a pas ete le cas dans ton exemple, pourquoi ?

[grunk]

Ok, j'ai toutes les infos pour continuer a programmer dans les meilleures condition.

Merci.

Tu peux peut-être m'en dire plus sur le throw, je ne trouve pas de doc sur ce mot-cle directement, mais sur les exceptions par son biais. Le throw est-il relatif uniquement aux Exceptions ?

Je vois dans la doc des exceptions que ca s'utilise en particulier avec un try, ce qui n'a pas ete le cas dans ton exemple, pourquoi ?

Le throw permet en effet de lancer une exception, on le retrouve généralement dans les classes.
A l'opposé les bloc try/catch vont se trouver plutot dans le code utilisant la classe pour intercépter les erreur éventuelles.

Donc dans son exemple il faudrait faire :

Code :

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

1
2
3
4
5
6
7
try{
$obj = new Monobjet();
}
catch($e Exception)
{
 echo $e->getMessage();
}

[keaton7]

Haaaaaaaaaaaaaaaaa, l'exception est non bloquante donc ! Elle n'affiche rien tant qu'on ne choisi pas de le faire ?

C'est une super gestion des erreurs ça non ?

J'ai cree un classe pour mes erreurs, mais je pourrais peut-etre la compléter avec ce gestionnaire, histoire de rendre les appels plus flexible.

C'est pas déconseillé le try en général ?

[grunk]

Non les bloc try/catch sont même plus que conseillé. Ca te permet d'avoir une gestion d'erreur plutôt fine.
C'est d'autant plus vrai qu'il te suffit d'étendre la classe Exception pour plus de souplesse.

Exemple :

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
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
class Util_ExceptionHandler extends Exception
 
{
 
	protected $image = 'erreur.gif';
 
	public function __construct($msg)
 
	{
 
		parent::__construct($msg);
 
	}
 
 
 
	/**
 
	 * Retourne la date et l'heure au format Fr
 
	 *
 
	 * @return string
 
	 */
 
	public function getTime()
 
	{
 
		return date("d/m/Y H:i:s");
 
	}
 
 
 
	/**
 
	 * Retourne l'erreur
 
	 *
 
	 * @return string
 
	 */
 
	public function getError()
 
	{
 
		header('Content-Type: text/html; charset=utf-8');
 
		$retour = '<div style="background:url('.$this->image.') right no-repeat;background-color: #FBE3E4; color: #8a1f11; border-color: #FBC2C4;">';
 
		$retour.= $this->getTime().' : Une exception à été détéctée :<br />';
 
		$retour.= '<strong style="color:red">'.$this->getMessage().'</strong><br />';
 
		$retour.= '<strong>Fichier : </strong> '.$this->getFile().'<br />';
 
		$retour.= '<strong>Ligne : </strong>' .$this->getLine().'<br />';
 
		$retour.= '</div>';
 
		return $retour;
 
	}
 
}

Idéalement on génère une classe d'exception par type de classe. Si tu as un set de classe gérant les utilisateur , tu aura alors une classe userException (exemple) , idem si tu as un set de classe de gestion d'image ou que sais je encore.

--edit-- La mis en forme du code a pris un coup au passage Win->linux->forum ^_^

[keaton7]

Ok, merci, j'ai mis la partie gestion des erreurs en standby depuis un moment, je pense que je la reprendrai sur de bonnes bases du coup. Merci.