Discussion :

[balja]

Bonjour,

jusqu'à présent, je m'étais cantonné à des réalisations très simples en objet (pas forcément simples dans le corps même de la classe mais simples en ce sens qui s'agissait de projets comportant généralement une ou deux classes n'ayant pas besoin de communiquer entre elles, tout le reste étant codé en procédural avec accès direct aux attributs et fonctions sans setters et getters par exemple).

Afin de m'imprégner un peu mieux de la logique objet, je souhaite développer à titre didactique une petite appli faisant par exemple office de correcteur grammatical et j'aimerai recueillir l'avis de gens ayant une certaine experience de la programmation objet sur mon ébauche de code :

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
class Arrangeur {
 
  private $texte; // type chaine
  private $mots;  // type tableau d'instances
 
  function __construct($texte) {
    $this->setContents($texte);
    $this->parseTexte();
    $this->getArrangement();
  }
 
  private function setContents($texte) {
    $this->texte = $texte;
  }
 
  private function parseTexte(){
    $tabMots = explode(' ', $this->texte);
    $nb = count($tabMots);
    for ($i=0; $i<$nb; $i++) {
      $this->mots[$i] = new Mot($tabMots[$i], $i);
    }
  }
 
  private function getArrangement() {
    $nb = $this->mots[0]->getNbCollection();
    for ($i=0; $i<$nb; $i++) {
      echo $this->mots[$i]->getSource();
      // fonctions de traitement à définir
    }
  }
 
}
 
class Mot {
 
  private $ordre;  // type int
  private $source;  // type chaine
  static $motsPhrase = 0;
 
  function __construct($texte, $ordre) {
    $this->setSource($texte);
    $this->setOrdre($ordre);
    self::$motsPhrase++;
  }
 
  private function setSource($texte){
    $this->source = $texte;
  }
 
  public function getSource(){
    return $this->source;
  }
 
  private function setOrdre($i){
    $this->ordre = $i;
  }
 
  public function getNbCollection() {
    return self::$motsPhrase;
  }
 
}
 
 
 
$texte = "il était une fois";
$traitement = new Arrangeur($texte);

Bon pour le moment, à part enlever tous les espaces du texte "il était une fois" et réafficher tous les mots collés les uns aux autres, ce code ne fait rien d'autre on est d'accord

Mais est ce que le probleme de conception semble correctement posé ?
Sachant que la méthode parseTexte de la classe Arrangeur sera ensuite enrichie
et que la méthode getArrangement de cette même classe ne se contentera pas d'afficher le texte mais le traitera au travers d'appels à un certains nombres d'autres méthodes (checkPluriel, checkConjugaison, etc...) qui restent à définir.

Par exemple, le $nb = $this->mots[0]->getNbCollection(); de ma méthode getArrangement me semble laid pour avoir accès à l'attribut statique de ma classe Mot mais je me voyais mal faire hériter la classe Arrangeur de la classe Mot pour y avoir acces à travers parent::

Merci de vos retours et de vos remarques.

[Tsilefy]

Ok, je me lance. C'est dans le désordre, et n'engage bien sûr que moi:
- le constructeur de la classe Arrangeur en fait trop. Le constructeur doit se contenter d'initialiser les propriétés. Il est préférable de lancer explicitement toutes les autres opérations.
- un petit sucre syntaxique (question de préférence): je retourne toujours $this dans les méthodes setXXX. Cela permet de faire des raccourcis du genre:

Code :

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

$objet->setCeci()->setCela();

- La propriété static de mots me chiffonne. Je distinguerais la classe Mots et un conteneur de mots, parce qu'un objet (Mot) n'a pas vocation à gérer une collection d'objets du même genre.
- Mot ne contiendrai que le mot/source lui-même, et toutes futures méthodes qui s'appliquent au mot.
- MotContainer, comme son nom l'indique, serait ceci:

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
//choisis ArrayAccess ou Iterator en fonction de tes besoins
class MotsContainer implements ArrayAccess, Iterator 
{
  $private container = array();
  public function offsetExists ( $offset ) { //à implémenter. Voir la doc sur ArrayAccess }
  public function offsetGet ( $offset ) { //à implémenter. Voir la doc }
  public function offsetSet ( $offset , $value ) { //à implémenter. Voir la doc }
  public function offsetUnset ( $offset ) { //à implémenter. Voir la doc }
 
//ou
  public  function current () { /*voir doc sur Iterator */}
  public  function key (){ /*voir doc sur Iterator*/ }
  public  function next (){ /*voir doc sur Iterator*/}
  public  function rewind (){ /*voir doc sur Iterator*/ }
  public  function valid (){ /*voir doc sur Iterator*/ }
}

Ce faisant, on n'utilise plus la méthode getNbCollection.
Cela changerait le code de la classe Arrangeur comme ça:

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
function __construct($texte) 
{
    //nouvelle initialisation
    $this->mots = new MotsContainer();
    //etc...
  }
 
private function getArrangement() 
{
    //$this->mots se comporte comme un array, donc on peut faire:
    $nb = count($this->mots);  //plus élégant que $nb = $this->mots[0]->getNbCollection();
    for ($i=0; $i<$nb; $i++) {
      echo $this->mots[$i]->getSource();
      // fonctions de traitement à définir
    }
 
    //ou on fait
    foreach($this->mots as $mot) {
     echo $mot->getSource();
    }
 
  }

[Benjamin Delespierre]

Tu veux faire toi même un correcteur grammatical ?

L'utilisabilité et surtout la faisabilité d'un tel projet sont très discutables... Surtout en langue française, c'est quand même un joli sac de noeuds.

Enfin bon, revenons un instant sur les remarques exprimées par Tsilefy:

- le constructeur de la classe Arrangeur en fait trop. Le constructeur doit se contenter d'initialiser les propriétés. Il est préférable de lancer explicitement toutes les autres opérations.

Le chaînage des appels est certes pratique mais je vous rappelle qu'on est pas en JavaScript. Vous devez être sûr à 100% que le retour des méthodes invoquées renverront toujours une instance (et la bonne!) sinon le script partira en FATAL_ERROR.
Maintenant, c'est vrai que déclencher les comportements depuis le constructeur, sans être faux n'est pas très esthétique: quid du cas d'erreur ? de l'exception ? Je suis d'accord avec Tsilefy sur le fait qu'il vaut mieux ne pas déclencher de traitements depuis le constructeur mais se contenter d'initialiser des propriétés.

- un petit sucre syntaxique (question de préférence): je retourne toujours $this dans les méthodes setXXX. Cela permet de faire des raccourcis du genre:

Voir ma remarque plus haut: y'a danger avec ce genre de syntaxe.

- MotContainer, comme son nom l'indique, serait ceci:

Si Motcontainer (d'ailleurs, il faudrait l'appeller soit ConteneurMot soit WordContainer - on ne mélange pas l'anglais et le français !) n'apporte aucune plus value (méthode) alors c'est un array ou un ArrayObject, pas besoin de créer un type pour ça.

Maintenant, concernant cette fameuse classe Arrangeur:

Code :

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

1
2
3
4
5
$tabMots = explode(' ', $this->texte);
    $nb = count($tabMots);
    for ($i=0; $i<$nb; $i++) {
      $this->mots[$i] = new Mot($tabMots[$i], $i);
    }

Peut $etre réduit à:

Code :

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

1
2
foreach (explode(',', (string)$this->texte) as $i => $piece)
  $this->mots[$i] = new Mot($tabMots[$i], $i);

Cette méthode ne devrait pas exister:

Code :

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

1
2
3
  private function setContents($texte) {
    $this->texte = $texte;
  }

Elle n'apporte rien de concrêt, donc on peut aussi bien passer l'attribut texte en public.

A titre indicatif, il est d'usage d'utiliser protected au lieu de private (ce qui facilite la dérivation ultérieure) et de préfixer les membres privés et protégés par underscore (_) afin d'identifier plus clairement leur visibilité lors de la lecture.

Sinon, mis à part que cette classe à une responsabilité lilliputienne, je ne vois pas grand chose à redire.