Classes d'usine [fermé]

Voici une véritable usine en direct de ma base de code. Il est utilisé pour générer une classe d'échantillonneur qui sait comment échantillonner des données à partir d'un ensemble de données (il est à l'origine en C#, donc excusez tout faux-pas java)

class SamplerFactory
{
  private static Hashtable<SamplingType, ISampler> samplers;

  static
  {
    samplers = new Hashtable<SamplingType, ISampler>();
    samplers.put(SamplingType.Scalar, new ScalarSampler());
    samplers.put(SamplingType.Vector, new VectorSampler());
    samplers.put(SamplingType.Array, new ArraySampler());
  }

  public static ISampler GetSampler(SamplingType samplingType)
  {
    if (!samplers.containsKey(samplingType))
      throw new IllegalArgumentException("Invalid sampling type or sampler not initialized");
    return samplers.get(samplingType);
  }
}

Et voici un exemple d'utilisation:

ISampler sampler = SamplerFactory.GetSampler(SamplingType.Array);
dataSet = sampler.Sample(dataSet);

Comme vous le voyez, ce n'est pas beaucoup de code, et il pourrait même être plus court et plus rapide juste à faire

ArraySampler sampler = new ArraySampler();
dataSet = sampler.Sample(dataSet);

Que d'utiliser l'usine. Alors pourquoi ai-je même pas la peine? Eh bien, il y a deux raisons fondamentales, qui s'appuient sur chacune autres:

1. Tout d'Abord, c'est la simplicité et la maintenabilité du code. Disons que dans le code appelant, le enum est fourni en tant que paramètre. C'est-à-dire si j'avais une méthode qui doit traiter les données, y compris l'échantillonnage, je peux écrire:

   void ProcessData(Object dataSet, SamplingType sampling)
   {
     //do something with data
     ISampler sampler = SamplerFactory.GetSampler(sampling);
     dataSet= sampler.Sample(dataSet);
     //do something other with data
   }
   

   Au lieu d'une construction plus lourde, comme ceci:

   void ProcessData(Object dataSet, SamplingType sampling)
   {
     //do something with data
     ISampler sampler;
     switch (sampling) {
       case SamplingType.Scalar:  
         sampler= new ScalarSampler();
         break;
       case SamplingType.Vector:  
         sampler= new VectorSampler();
         break;
       case SamplingType.Array:
         sampler= new ArraySampler();
         break;
       default:
         throw new IllegalArgumentException("Invalid sampling type");
     }
     dataSet= sampler.Sample(dataSet);
     //do something other with data
   }
   

   Notez que cette monstruosité devrait être écrite chaque fois que j'ai besoin de moi un échantillon. Et vous pouvez imaginer à quel point il sera amusant de changer si, allons disons que j'ai ajouté un paramètre au constructeur ScalarSampler ou ajouté un nouveau SamplingType. Et cette usine n'a plus que trois options, imaginez une usine avec 20 implémentations.

2. Deuxièmement, c'est le découplage du code. Lorsque j'utilise une usine, le code appelant ne savent ou doivent savoir qu'une classe appelée ArraySampler existe même. La classe pourrait même être résolue au moment de l'exécution, et le site d'appel ne serait pas le plus sage. Donc, par conséquent, je suis libre de changer la classe ArraySampler autant que je veux, y compris, mais sans s'y limiter, la suppression pure et simple de la classe, si, par exemple, je décide que le ScalarSampler doit également être utilisé pour les données de tableau. J'aurais juste besoin de changer la ligne

   samplers.put(SamplingType.Array, new ArraySampler());
   

   À

   samplers.put(SamplingType.Array, new ScalarSampler());
   

   Et cela fonctionnerait comme par magie. Je n'ai pas besoin de changer une seule ligne de code dans les classes appelantes, ce qui pourrait se compter par centaines. Effectivement, l'usine me permet de contrôler quoi et comment l'échantillonnage se produit, et tous les changements d'échantillonnage sont efficacement encapsulés dans un seul classe d'usine qui est interfacée avec le reste du système.

Personnellement, j'utilise le modèle d'usine lorsque l'implémentation d'une interface est inconnue au moment de l'exécution ou qu'elle peut être rendue dynamique.

Cela signifie qu'en tant que développeur, je travaille contre une interface connue pour l'instance de l'objet, mais je ne suis pas préoccupé par le fonctionnement de l'implémentation.

Prenez, par exemple. Vous pouvez utiliser un modèle d'usine pour vous fournir des objets à partir d'une base de données. Vous ne vous souciez pas si cette base de données est un fichier plat, une base de données utilisateur locale/unique, un serveur base de données ou ressource web, seulement que l'usine peut générer et gérer ces objets.

Je détesterais avoir à écrire des implémentations pour chacun de ces cas: P

Du livre Java efficace de Joshua Bloch, partiellement réécrit par moi:

1) Les méthodes d'usine statiques (SFM), contrairement aux constructeurs, ont des noms.

public static ComplexNumber one () {
    return new ComplexNumber(1, 0);
}

public static ComplexNumber imgOne () {
    return new ComplexNumber(0, 1);
}

public static ComplexNumber zero () {
    return new ComplexNumber(0, 0);
}

2) Il n'est pas nécessaire de créer un nouvel objet à chaque fois SFM est/sont appelés

public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE; 
}

3) SFM peut renvoyer un objet de n'importe quel sous-type de son type de retour.

4) SFM réduisez la verbosité de la création d'instances de type paramétrées.

public static <K, V> HashMap<K, V> newInstance() {
    return new HashMap<K, V>();
}

Map<String, List<String>> m = HashMap.newInstance();

Pour compléter la réponse de Thilo, supposons que vous ayez un objet qui n'a qu'un booléen en tant que constructeur: ce serait un gaspillage total d'en construire un à chaque fois, car il n'a que deux valeurs possibles.

Dans ce cas, vous pouvez créer des méthodes d'usine statiques. La classe Boolean de Java est un exemple: Boolean.valueOf().

L'usine en elle-même ne montre pas sa beauté si facilement. Est-ce que lorsque vous le combinez avec d'autres modèles lorsque vous voyez les avantages réels par exemple, si vous souhaitez utiliser le motif décorateur, l'instanciation directe d'un objet peut ajouter un couplage supplémentaire à votre code. Comme le dit le professeur de POO, le couplage est mauvais :) donc si vous instanciez l'objet décoré et que vous ne voulez pas augmenter le couplage, vous pouvez utiliser une usine.

Vous pouvez vous référer au wikipedia, mais l'idée de base de la plupart des modèles de conception est d'introduire une certaine abstraction pour obtenir une meilleure maintenabilité et/ou réutilisabilité. Le modèle de méthode d'usine ne fait pas exception, ce qu'il fait est d'abstraire la complexité de la création du code.

Pour un cas simple, il semble inutile d'utiliser un motif d'usine, un simple new suffit. Mais lorsque vous avez besoin de plus de flexibilité ou de fonctionnalité, ce modèle peut vous aider.

Par exemple, à moins qu'un une nouvelle instance est requise, la fabrique statique valueOf(boolean) est généralement un meilleur choix que new Bealean(boolean), car elle évite de créer des objets inutiles. Le modèle de méthode d'usine est également connu sous le nom de Virtual Constructor . Comme nous le savons, le polymorphisme est l'une des principales caractéristiques de la POO, mais le constructeur ne peut pas être polymorphe, cette lacune peut être surmontée par le modèle de méthode d'usine.

En substance, instancier un objet directement (généralement via new) est à peine une implémentation concrète , alors que le modèle de méthode d'usine protège un volatile mise en œuvre par un stable interface (non limitée au interface en Java), poussant la logique de création d'objets derrière une certaine abstraction pour assurer un code plus maintenable et réutilisable.

En dernier mot, pour bien comprendre les avantages du modèle de méthode d'usine et d'autres modèles de conception, il faut saisir l'essence de la POO, y comprisabstraction de données , abstraction polymorphe et SOLIDE principe.