Modèle de conception d'usine étendre

Question

Je lis Head First Design Pattern et au chapitre de l'usine. Je pense à changer mon code de travail pour l'implémenter.

D'abord, je crée IAction et ActionFactory avec GetAction, à partir de IAction, je crée UploadDatabase, CopyFile, UploadSharepoint, etc. Il est en DLL et peut être appelé depuis un exe. C'est facile et fait.

Ensuite, je prévois de créer AutoCADAction à partir de IAction qui incluent des actions telles que Imprimer, Script, etc. Ces actions ne peuvent être exécutées que dans AutoCAD.

Maintenant, j'aime créer AutoCADActionFactory avec override GetAction, il créera aussi ActionFactory et AutoCADAction. Maintenant j'ai perdu.

Voici l'exemple de code:

Dans ActionFactory.GetAction

public IAction GetAction(ActionType myActionType) 
{ 
    switch (myActionType) 
    { 
     case ActionType.UploadDatabase: 
      return new UploadDatabase(); 

     case ActionType.CopyFile: 
      return new CopyFile(); 

     case ActionType.UploadSharepoint: 
      return new UploadSharepoint(); 
    } 
} 

Comment je code mon AutoCADActionFactory.GetAction, est-ce correct?

public AutoCADAction GetAction(ActionType myActionType) 
{ 
    return Base.GetAction; 
    switch (myActionType) 
    { 
     case ActionType.Print: 
      return new Print(); 

     case ActionType.Script: 
      return new Script(); 

     ... 

    } 
} 

Merci,

Answer 1

Je ne suis pas tout à fait convaincu qu'une usine, ou plus exactement un Factory Method (comme vous semblez essayer de l'utiliser) est le bon choix ici. La raison pour laquelle je dis cela, c'est que vous semblez avoir négligé certaines choses.

En règle générale, une méthode d'usine prend tout son sens lorsque vous effectuez des opérations qui effectuent des opérations similaires, par exemple la lecture d'une image bitmap à partir d'un fichier dans différents formats. Les actions que vous avez définies semblent varier considérablement, et je ne suis pas convaincu qu'elles devraient représenter le même type d'opération (c'est-à-dire supporter la même interface). La classe Print peut implémenter à la fois IAction et IPrint), mais sans informations supplémentaires, je me demande si le design sous-jacent est aussi solide comme cela devrait être. Comme vous utilisez la même énumération ActionType dans ActionFactory et AutoCADActionFactory, vous voulez probablement/devez définir une action "null" renvoyée par ActionFactory. (Selon le contexte, vous pouvez vouloir que cette action nulle fasse quelque chose d'utile - comme faire apparaître une boîte de message disant "Cette opération n'est pas supportée dans ce contexte", mais cela pourrait aussi bien ne rien faire du tout.) L'action nulle devrait être retourné dans le cas "Default".

Comme codé actuellement, vous toujours retourner l'action à partir de la classe de base. Vous voulez sans doute quelque chose qui ressemble plus à ceci:

public AutoCADAction GetAction(ActionType myActionType) 
{ 
    switch (myActionType) 
    { 
     case ActionType.Print: 
      return new Print(); 

     case ActionType.Script: 
      return new Script(); 

     default: 
      return base.GetAction(myActionType); 
    } 
} 

Cela vous permettra de remplacer complètement l'action prévue par le ActionFactory (que j'imagine serait la chose la plus susceptible de vouloir), ou de faire des choses spécialisées comme renvoyer une action spécialisée qui effectue une opération spécifique en plus de l'action de la classe de base.

Vous pouvez également considérer le principe orienté objet commun de "Favoriser l'encapsulation sur l'héritage". Dans ce cas, je ne vois aucun avantage réel à hériter d'ActionFactory. Dans le cas d'une classe Abstract Factory, où il y a des appels séparés pour chaque type d'action, l'héritage offre un plus grand avantage.

Est-ce que cela aide?