Quels sont les avantages réels de l'utilisation de l'usine abstraite dans l'exemple suivant, au lieu de la méthode usine?

Question

Avant d'écrire la question que je lis les références suivantes:

1. Factory Method Vs Abstract Factory
2. Abstract Factory vs Factory Method (scope)
3. Abstract Factory, Factory Method, Builder
4. Factory, Abstract Factory and Factory Method
5. Differences between Abstract Factory Pattern and Factory Method

Je vois que beaucoup comme moi ont eu difficile y "saisir" les différences concrètes entre Abstract Factory et Factory Pattern. Je ne suis pas familier avec les modèles de conception, je suis tombé sur cet exemple http://www.oracle.com/technetwork/java/dataaccessobject-138824.html et j'essaie d'approfondir le sujet.

En comparant, je vois que pour 3 DTO nous avons:

1) Résumé usine

• 1 classe abstraite (avec 3 méthodes abstraites et 3 commutations cas);
• 3 classes de fabrique pour le type de persistance (chacune avec 3 méthodes pour obtenir des DAO DTO)
• 3 interfaces et 9 DAO.

2) Méthode de fabrication:

• 3 classes d'usine, une pour chaque interface (chacun avec 3 interrupteur cas);
• Peut-être que je peux créer 3 superclasses à partir desquelles étendre les classes DAO pour ne pas dupliquer le code, tel que celui pour la connexion à la base de données;
• 3 interfaces et 9 DAO.

Du point de vue de la quantité de code je ne vois pas de différences substantielles. Dans les cas où vous devez ajouter un nouveau support de persistance ou une nouvelle interface/DTO, les différences sont minimes (et complémentaires).

Du point de vue du client:

1) Résumé usine:

public static final int PERSISTENCE_TYPE = DAOFactory.ORACLE; 

DAOFactory daoFactory = DAOFactory.getDAOFactory(PERSISTENCE_TYPE); 

CustomerDAO cDAO = daoFactory.getCustomerDAO(); 
AccountDAO aDAO = daoFactory.getAccountDAO(); 
OrderDAO oDAO = daoFactory.getOrderDAO(); 

2) Méthode d'usine:

public static final int PERSISTENCE_TYPE = DAOFactory.ORACLE; 

CustomerDAO cDAO = CustomerDAOFactory.getCustomerDAO(PERSISTENCE_TYPE); 
AccountDAO aDAO = AccountDAOFactory.getAccountDAO(PERSISTENCE_TYPE); 
OrderDAO oDAO = OrderDAOFactory.getOrderDAO(PERSISTENCE_TYPE); 

Y at-il un avantage à utiliser un DAOFactory en ce qui concerne la persistance tapez et renvoie tous les DAO liés à ce support au lieu d'utiliser plusieurs DAOFactory pour chaque DTO pour obtenir le DAO pour le type de persistance utilisé? Pour l'instant, je ne vois que des différences esthétiques et conceptuelles dans l'utilisation de l'usine abstraite, y a-t-il aussi un avantage d'utilité que je ne peux pas saisir pour mon ignorance au sujet de la conception de logiciel?

Answer 1

Une remarque sur les précédentes versions de l'answear Vous pouvez lire la méthode d'usine dans Efecrive Java 2ème édition. Mais à la différence de Imagin dans le monde réel entre les modèles s'il vous plaît voir Par exemple

usine

Imaginez que vous construisez une maison et vous approchez d'un charpentier pour une fenêtre. Vous donnez vos exigences, et il construira une fenêtre. Dans ce cas, le menuisier est une usine de fenêtres. Vos spécifications sont des entrées pour l'usine, et la fenêtre est la sortie de l'usine.

Résumé usine

Considérons maintenant le même exemple de la fenêtre. Vous pouvez aller à un charpentier, ou vous pouvez aller à un magasin de fenêtre ou un magasin de PVC. Tous sont des usines de fenêtres. En fonction de la situation, vous décidez quel type d'usine vous devez approcher.

Donc conclusion - Cela dépend du problème que vous résolvez.

Answer 2

Lorsque nous disons modèle de conception d'usine, il existe trois versions sous le parapluie.à savoir

1. statique usine: où nous avons la méthode de type

   Product getConcreteProduct(Key key){ 
       if (key.equals(key1) then { 
        return ConcreteProduct1(); 
       } else { 
        //... so on 
       } 
   

   Il est utile de rassembler la création d'objets dans la hiérarchie.

2. Méthode d'usine: Ce modèle est peu difficile à apprécier, mais la clé est que nous complétons la logique métier (par exemple, calcul des paramètres de forme) dans une classe abstraite en termes de produit abstrait uniquement. nous conservons délibérément une méthode abstraite dans cette classe pour obtenir un produit concret. Il est utile de garder ce calcul générique ouvert pour que les clients puissent le réutiliser selon leurs définitions de forme. Le client peut prolonger de

   Class CircleGeometry extends GeometryMethod{ 
       Shape getShape(){ // Factory Method 
        return new Square(); // extending Shape 
       } 
   } 
   

   Rappelez-vous le code client a été par la suite écrit à la suite de type Square, qui n'a pas été existant lorsque la classe de base (calcul donnant de la zone en fonction des coordonnées par exemple) n'a pas été écrit. Ce modèle est généralement utilisé pour les frameworks.

3. Abstract Factory: Ceci est un cas général de Méthode d'usine. Disons que nous avons la classe Factory qui peut créer des formes et a des méthodes abstraites pour créer la famille de formes comme suit

   abstract class ShapeCreator{ 
       abstract Square createSquare(); 
       abstract Circle createCircle(); 
       // ... 
   } 
   

Même interface peut être mis en œuvre par deux usines de béton à savoir 1. FilledShapeCreator 2. HollowShapeCreator à la fois les créateurs concrets mettent en œuvre des méthodes pour les formes concrètes de la place s'étendant/cercle comme suit

class FilledShapeCreator{ 
     Square createSquare(){ 
      return new FilledSquare(); // extends Square 
     } 
     // ... 
    } 

sur la base de clé spécifique choix d'une usine de béton SPECIF hel ps en fournissant une gamme complète de produits de saveur différente. Encore une fois cela est également plus utile dans la définition de la logique métier sans spécifier une saveur spécifique de la famille de produit.