Est-ce un objet capable de se sauver dans gâte DataBase la cohésion de la classe?

Question

Pour parler en termes de conception orientée objet, pensez-vous de donner une fonctionnalité d'auto-enregistrement en base de données pour un butin d'objet le COHÉSION de la classe?

Imaginez:

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

Que pensez-vous?

Answer 1

Il n'interfère avec le principe de responsabilité unique. Le but de la classe de produits dans votre exemple est de représenter un produit et les opérations sur ce produit. Interagir avec la base de données ne fait pas partie de base de la responsabilité de la classe.

Avoir la classe ProductServices augmente la maintenabilité de votre code. Supposons que la logique pour la sauvegarde des objets dans la base de données a été de changer (ce qui peut) que vous voulez changer toutes les classes d'entités dans votre système?

Answer 2

Un objet qui peut se sauver à la base de données serait contraire SRP (responsabilité unique principe).

La persistance est une responsabilité tout seul et doit être manipulé par les classes dédiées.

Ce serait en plus d'avoir la cohésion LOW -. Les membres qui ont à voir avec la persistance ont aucun rapport avec ceux qui ne sont pas et ne seront pas utilisées dans les méthodes de la classe qui ne traitent pas avec la persistance

Answer 3

En termes de Object Oriented Design seulement alors il n'y a pas de mal de rien avec la méthode Save faisant partie de Produit . Il serait en fait la méthode préférée au sein du monde Design orienté objet. Et d'un point de vue purement OO vous ne voudriez pas brisée parce que c'est plus fonctionnel que l'objet.

Cependant, si vous croyez en principe d'inversion de dépendance qui dit modules de haut niveau ne doivent pas dépendre de modules de bas niveau; alors une méthode Save serait approprié, mais il devrait prendre un type abstrait de connexion en tant que paramètre. Cela vous donne un modèle d'objet agréable qui comprend une méthode Save mais il aurait aucune connaissance du type de connexion.