[POO] Conception objet, les variables

Version imprimable

Bonjour,

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

Code:

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.

13/06/2009, 23h49
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
15/06/2009, 09h38
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" ?
15/06/2009, 10h04
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. ;)
15/06/2009, 10h44
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 ?
15/06/2009, 10h47
grunk

Citation:

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.

Citation:

Envoyé par keaton7

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
15/06/2009, 10h59
keaton7

Ok, mais accéder a un attribut prive via un getter (cad hors de la classe), c'est tricher non ?
15/06/2009, 11h40
grunk

Citation:

Envoyé par keaton7

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
15/06/2009, 12h12
keaton7
Citation:

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:

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 ??

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

Code:

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);
 
  }
 
}

15/06/2009, 14h27
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 ?
15/06/2009, 14h54
grunk
Citation:

Envoyé par 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 ?

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:

1 2 3 4 5 6 7 try{ $obj = new Monobjet(); } catch($e Exception) { echo $e->getMessage(); }
15/06/2009, 15h00
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 ?

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:

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 : '; $retour.= ''.$this->getMessage().' '; $retour.= 'Fichier : '.$this->getFile().' '; $retour.= 'Ligne : ' .$this->getLine().' '; $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 ^_^

15/06/2009, 16h43
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.