Besoin d'aide pour la modélisation des classes

Question

J'ai étudié certains concepts OO, comme les modèles de conception, le code propre et d'autres choses et j'ai encore des doutes sur la façon de procéder. Par exemple, regardons mon exemple.

J'ai une classe Person qui est un modèle. Je veux ajouter quelques validations à une personne, comme vérifier si l'âge correspond à la date de naissance et vérifier si le nom contient des caractères valides.

J'ai deux approches, mais je ne sais pas laquelle je devrais utiliser.

approche un: -je créer une nouvelle classe appelée:

class ValidatePerson {} 

et la classe ont les méthodes: « validateAge() » et « validateName() » et tous les vallidation que j'ai besoin, je vais avoir implémenter une nouvelle méthode.

approche en deux: -je créer une classe abstraite appelée: ValidatePerson {} qui aura des méthodes de commum à tous la validation et la i aurait:

class ValidatePersonAge extends ValidatePerson { validate();} 
class ValidatePersonName extends ValidatePerson {validate();} 

Je veux choisir pour une approche à deux, la cause chaque nouvelle règle de validation que je devrai ajouter sera une nouvelle classe et n'affectera pas les autres. Comme, si j'ai besoin de modifier quelque chose dans la méthode commum que la nouvelle règle a besoin, je pourrais juste l'écraser. Sur la première approche, je devrais ajouter une autre méthode et ensuite créer une autre méthode ou modifier celle qui fonctionne déjà pour les autres, qui pourrait faire plantage. La chose est que je suis un peu confus à tout cela, car je suis nouveau à la programmation et je voudrais voir de l'aide et des explications à ce sujet. J'ai aussi lu que les classes devraient être fermées pour changer, mais ouvertes pour l'expansion (ou quelque chose comme ça).

Answer 1

Il n'y a pas de bonne réponse spécifique. La conception doit toujours être dans le contexte de votre domaine de problème et du contexte de l'entreprise. Voici donc les différentes options

Option 1 classe Person a une méthode vailidate() que vous pouvez appeler pour effectuer tout ce qu'il sur son état validations en cours.

Pros

• meilleure encapsulation
• changements sont localisés à 1 seule classe
• validation est effectuée après la mise en toutes les propriétés

Contre

• personne pourrait être en état invalide b vant la méthode validate() est appelée donc pas échec rapide
• ne peut pas avoir des règles différentes de validation pour le contexte différent

Option 2 Chaque propriété a sa propre méthode validateXXX() dans la classe de personne. Chaque méthode setXXX() va appeler la méthode validateXXX() correspondante.

Pros

• meilleure encapsulation
• changements sont localisés à 1 seule classe
• Fail comportement rapide-à-dire l'objet Personne ne sera jamais un état non valide

Contre

• pourrait être base de surdimension d sur le contexte
• ne peut pas avoir des règles de validation pour le contexte différent

Option 3 Vous pourriez avoir un PersonBuilder qui contient ces contrôles de validation. Le constructeur effectuera ces validations avant de créer l'objet Person. De cette façon, une fois l'objet Person construit, il vérifie toutes les validations et invariants.

Pros

• Vous avez extériorisés les validations à une classe de constructeur donc vous pouvez avoir des règles de validation pour différents contextes
• logique Construnction est séparée de l'objet de domaine
• classe personne peut être immuable une fois construit

Cons

• peut-être un surpuissant dans certains scénarios

---

Votre option 2 n'est pas correcte, car ValidatePersonAge EST PAS même que ValidatePerson. Vous ne validez pas entièrement la personne mais seulement validez son âge. Donc, ils sont sémantiquement différents.