2010-02-13 7 views
3

J'ai une classe qui doit extraire les informations produit de la base de données d'un système et les enregistrer dans la base de données de produits d'un autre système.Aide pour la conception de classes

Je vais appeler un produit du premier système Produit A et l'autre produit B. Les données du produit B dépendent des paramètres sélectionnés d'un utilisateur.

Donc produit B peut avoir une méthode GetDescriptions qui ressemble à un paramètre utilisateur qui dit utiliser la variable Description1 de produit A ou ils peuvent choisir la description 2 ou ils pourraient utiliser la description déjà produit B.

Ceci est bien , mais il y a beaucoup de paramètres et de façons d'obtenir une description. C'est le problème, j'ai beaucoup de méthodes qui semblent toutes se rapporter au produit B. Méthodes comme GetDescription, GetName, GetSku, qui sont tous définis en fonction des paramètres de l'utilisateur et tous dépendent du produit A.

Bien qu'ils tous semblent se rapporter au produit B, la classe devient très grande et je veux déplacer certaines méthodes hors de la classe dans une autre classe. Je pensais à utiliser le motif Factory. Quelque chose comme ci-dessous (code juste une idée rapide)

public class ProductBuilder 
{ 
    public ProductB BuildProduct() 
    { 
      SkuBuilder.BuildSku(ProductB,ProductA); 
      ProductDescriptionBuilder.BuildDescription(ProductB,ProductA); 
    } 
} 

Mes questions sont: Qu'est-ce qu'un bon design pour cela? La méthode que j'ai proposée ci-dessus est-elle acceptable? Voyez-vous des problèmes potentiels avec cette conception?

Répondre

3

Ceci est une variante du motif de l'usine, et c'est une forme très utile de conception. Ce que vous avez écrit suggère une conception à trois classes soignée: ProductA contenant des méthodes et propriétés seulement concernant A, ProductB avec des méthodes et des propriétés relatives à B, et ProductBuilder qui vous construit un B basé sur une A.

La seule les pièges de ceci sont des problèmes de conception OOP généraux. Assurez-vous que ProductConverter ne dépend pas de la connaissance interne de A ou B - en d'autres termes, assurez-vous que l'interface publique vers A et B est suffisamment riche pour que le ProductConverter fasse son travail. Seul A doit se connecter à la base de données de produits A et seul B doit se connecter à la base de données de produits de B. Évitez les singletons et l'état global. Ce sont des choses que vous feriez dans presque toutes les applications, mais elles seront des pièges spéciaux dans ce genre de système.

1

Je ferais la suggestion de travailler avec l'abstraction dans votre ProductBuilder directement avec ProductA et ProductB ... De cette façon, vous pouvez changer d'implémentation sans douleur plus tard. Utilisez l'interface ou la classe abstraite ...

Il sera également plus facile de tester et de railler.