- Pas besoin de vérifier les données qui viennent de la db, pas besoin de passer par les setters donc

La classe ne sait pas d'où proviennent les données qui peuvent être injectées via le constructeur, c'est pour cela qu'il vaut mieux passer leur affectation par les setter (c'est leur spécialité)
Quand un constructeur souhaite affecter des données dans les propriétés, il vaudrait mieux passer par les setter au lieu de réécrire du code redondant.

Par contre ça va à contre sens de la sécurité qu'apportent les setters non ?
Si l'on est plus obligé de passer par eux pour instancier un objet, on est donc plus obligé de vérifier les données... ?

Dans tous les cas, ni le constructeur, ni les setter ne peuvent empêcher l'instanciation de l'objet. La vérification des données (spécialité des setter) doit déclencher quelques exceptions au niveau de l'objet pour avertir de son état erroné. Comme ça, le programme manipulateur sera au courant et prendra les mesures adéquates. Par exemple, dans ton cas, tes setter évitent les valeurs nulles et retournent un code retour "false" au programme manipulateur pour que ce dernier sache que la donnée qu'il essaye d'affecter à l'objet est refusée. De même, si le constructeur appelle les setter, il peut exploiter leur code retour pour justifier une exception (erreur) et la retransmettre au programme déclenchant l'instanciation. Peut être par un "return" ou alors en levant une exception (à voir: la gestion des Exceptions), ou encore en mettant à jour une propriété "état".

Par exemple, en utilisant la gestion des Exceptions:

<pre>
<?php
class definition{
    private $id;
    private $libelle;
    private $valeur;

    // setter
    public function __construct($id=null, $libelle=null, $valeur=null){
        $this->setId($id);
        $this->setLibelle($libelle);
        $this->setValeur($valeur);
    } 
    public function setId($value){
        if($value == null){
            throw new Exception('Id Manquant');
        }
        $this->id = $value;
    }
    public function setLibelle($value){
        if($value == null){
            throw new Exception('Libellé Manquant');
        }
        $this->libelle = $value;
    }
    public function setValeur($value){
        if($value == null){
            throw new Exception('Valeur Manquante');
        }
        $this->valeur = $value;
    }

    // getter
    public function getId(){
        return $this->id;
    }
    public function getLibelle(){
        return $this->libelle;
    }
    public function getValeur(){
        return $this->valeur;
    }
}

// test
// Erreur sur Id
try { 
	$d1 = new definition(null, 'LAN', 'Réseau local (Local Area Network)');
	echo '<br />Contenu de $d1: '; print_r($d1);
}
catch (Exception $e) {
	echo 'Erreur: ' . $e->getMessage();
}
// Erreur sur Libellé
try { 
	$d1 = new definition(1, null, 'Réseau local (Local Area Network)'); 
	echo '<br />Contenu de $d1: '; print_r($d1);
}
catch (Exception $e) {
	echo 'Erreur: ' . $e->getMessage();
}
// Erreur sur Valeur
try { 
	$d1 = new definition(1, 'LAN', null); 
	echo '<br />Contenu de $d1: '; print_r($d1);
}
catch (Exception $e) {
	echo 'Erreur: ' . $e->getMessage();
}
// Pas d'erreurs
try { 
	$d2 = new definition(1, 'LAN', 'Réseau local (Local Area Network)');
	echo '<br />Contenu de $d2: '; print_r($d2);
}
catch (Exception $e) {
	echo 'Erreur: ' .  $e->getMessage();
}
?>
</pre>

Pour revenir aux classes de gestion, j'ai assez de mal. Par exemple si je devais placer une méthode "crypter valeur" ( totalement ionutile mais c'est pour l'exemple ), devrait-elle faire partie de la classe definition ou gestionDefinition ?

Merci encore pour les explications

Si le cryptage des valeurs est réutilisable avec d'autres classes qui communiquent avec la classe définition, il vaudrait mieux le placer (le cryptage) dans les setter de la classe définition. Sinon, si le cryptage est spécifique à des traitement attachés au rôle de la classe "gestionDéfinition" et notamment la communication avec la base de données, il vaut mieux spécifier le cryptage à ce niveau sans le généraliser au niveau de la classe "définition".
Par exemple, pour un mot de passe ou des données sensibles, le cryptage doit être centralisé au niveau de la classe métier principale comme ta classe définition. Car toutes les classes ayant des relations fonctionnelles avec la classe principale se verront obligées d'utiliser des données cryptées, en amont (interface utilisateur) comme en aval (base de données) ou vis-versa.[/url]