Un objet capapble pour se sauver dans DataBase gâche-t-il la cohésion de la classe?

Question

En parlant de design orienté objet, pensez-vous donner une fonctionnalité de sauvegarde en base de données à un objet gâte la COHESION de la classe?

Imaginer:

Product p = new Product() 
      { 
      Name = "Joy Rider", 
      Price = 100, 
      Currency = "USD" 
      }; 

Pensez-vous que pour enregistrer cette page produit sur DataBase vaut mieux faire de cette façon:

p.Save(); 

ou dans une façon quelque chose comme ceci:

ProductServices.SaveProduct(p); 

Qu'en pensez-vous?

Answer 1

Il interfère avec le principe de la responsabilité unique. Le but de la classe Product dans votre exemple est de représenter un produit et les opérations sur ce produit. Interagir avec la base de données n'est pas une partie essentielle de la responsabilité de la classe. La classe ProductServices augmente la maintenabilité de votre code.

Supposons que la logique de sauvegarde des objets dans la base de données change (ce qu'elle peut) voulez-vous changer chaque classe d'entité dans votre système?

Answer 2

Un objet qui peut être enregistré dans la base de données enfreindrait SRP (principe de la responsabilité unique).

La persistance est une responsabilité à part entière et doit être gérée par des classes dédiées. Ce serait en plus d'avoir une faible cohésion - les membres qui ont à faire avec la persistance n'ont aucun rapport avec ceux qui ne sont pas et ne seraient pas utilisés dans les méthodes de la classe qui ne traitent pas la persistance.

Answer 3

En termes de Object Oriented Design alors seulement pas il n'y a rien de mal avec la méthode Save faisant partie de produit. Ce serait en fait la méthode préférée dans le monde de la conception orientée objet. Et d'un point de vue purement OO, vous ne voudriez pas qu'il soit brisé parce que c'est plus fonctionnel que l'objet. Toutefois, si vous croyez au principe d'inversion des dépendances, les modules de haut niveau ne doivent pas dépendre des modules de bas niveau; alors une méthode Save serait appropriée mais elle devrait prendre un type de connexion abstrait en tant que paramètre. Cela vous donnerait un bon modèle d'objet qui inclut une méthode Save mais il n'aurait aucune connaissance du type de connexion.