web-dev-qa-db-fra.com

Pourquoi avons-nous besoin d'un modèle de conception d'usine abstrait?

La plupart de la définition dit:

Une fabrique abstraite fournit une interface pour créer des familles d'objets liés sans spécifier leurs classes concrètes.

Quelle est l’utilisation de Abstract Factory Pattern puisque nous pouvons accomplir cette tâche en créant un objet de classe concrète lui-même. Pourquoi avons-nous une méthode d'usine qui crée un objet de la classe Concrete?

S'il vous plaît, donnez-moi des exemples concrets dans lesquels je dois implémenter un motif abstractFactory?

design-patternsabstract-factory
115
Amit

Abstract Factory est un modèle de conception très central pour Injection de dépendance (DI). Voici une liste de questions relatives au débordement de pile où l’application de Abstract Factory a été acceptée comme solution.

Autant que je sache, ces questions représentent des préoccupations ou des problèmes réels, ce qui devrait vous permettre de commencer avec des exemples concrets:

212
Mark Seemann

Un exemple concret d'utilisation du modèle Abstract Factory consiste à fournir un accès aux données à deux sources de données différentes (par exemple, une base de données SQL et un fichier XML). Vous avez deux classes d'accès aux données différentes (une passerelle vers le magasin de données). Les deux héritent d'une classe de base qui définit les méthodes courantes à implémenter (par exemple, Charger, Enregistrer, Supprimer).

La source de données à utiliser ne devrait pas changer la façon dont le code client extrait sa classe d'accès aux données. Votre Abstract Factory sait quelle source de données doit être utilisée et renvoie une instance appropriée à la demande. La fabrique renvoie cette instance en tant que type de classe de base.

22
Johannes Rudolph

Si je vous ai bien compris, la question est de savoir pourquoi nous avons à la fois la méthode Factory et les modèles de fabrique abstraite. Vous avez besoin d'une fabrique abstraite lorsque différentes classes polymorphes ont une procédure d'instanciation différente. Et vous voulez qu'un module crée des instances et les utilise, sans connaître les détails de l'initialisation de l'objet. Par exemple - vous voulez créer des objets Java), mais certains d'entre eux font partie de l'application, tandis que les autres bytecodes doivent être lus à partir de la base de données. Dans l'autre, pourquoi Il faut convenir que la fabrique abstraite la chevauche, mais dans certains cas, c’est beaucoup moins de code à écrire, moins de classes et d’interfaces facilitent la compréhension du système.

5
David Gruzman

Quelle est l’utilisation de Abstract Factory Pattern dans la mesure où nous pouvons réaliser cette tâche en créant un objet de classe concrète lui-même. Pourquoi avons-nous une méthode d'usine qui crée un objet de la classe Concrete?

En l'absence de Abstract Factory , le client doit connaître les détails des classes concrètes. Ce couplage étroit a été supprimé avec l’usine abstraite .

Maintenant La méthode d'usine expose un contrat que ce client doit utiliser. Vous pouvez ajouter plus de produits à votre usine en ajoutant de nouveaux produits, qui implémentent l'interface exposée par la méthode d'usine.

Reportez-vous à ces questions SE connexes pour une meilleure compréhension:

Quelle est la différence fondamentale entre les modèles Factory et Abstract Factory?

Intention:

Fournissez une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.

Vous pouvez comprendre Intention, structure, liste de contrôle et règles de base de Résumé Modèle d’usine de cet article création de source .

Liste de contrôle:

  1. Décidez si indépendance de la plate-forme et les services de création sont la source de douleur actuelle.
  2. Cartographiez une matrice de plates-formes versus produits.
  3. Définissez une interface d'usine qui consiste en une méthode d'usine par produit.
  4. Définissez une classe dérivée factory pour chaque plate-forme qui encapsule toutes les références au nouvel opérateur.
  5. Le client doit supprimer toutes les références à new et utiliser les méthodes factory pour créer les objets product.
3
Ravindra babu

Les usines abstraites sont idéales pour prendre en charge plusieurs plates-formes tout en maintenant votre base de code unifiée. Supposons que vous souhaitiez exécuter un grand programme Qt ou GTK + ou .NET/Mono sous Windows, Linux et OSX. Mais vous avez une fonctionnalité qui est implémentée de manière différente sur chaque plate-forme (peut-être via l'API kernel32 ou une fonctionnalité POSIX).

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

Avec cette usine abstraite, votre interface utilisateur n'a pas besoin de connaître la plate-forme actuelle.

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);
2
piedar

Si vous examinez les modèles de conception, vous pouvez presque tous les supprimer. Mais quel modèle signifie une approche couramment utilisée pour une solution à un type de problèmes similaire. Un modèle de conception vous fournit une approche ou une solution au niveau de la conception pour un ensemble de problèmes de conception similaires. L'utilisation du modèle de conception vous aide à résoudre votre problème et donc à livrer plus rapidement.

1
Kangkan

il est facile, imaginant que vous avez un code qui fonctionne avec l'abstraction, vous devez créer des abstractions et non des classes concrètes.

Vous devriez toujours travailler contre les abstractions, car vous pouvez mieux modifier le code.

Voici un bon exemple: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.2

1
Pablo Castilla

Je pense qu'il y a une place pour un motif d'usine abstrait plutôt qu'un simple motif d'usine dans des endroits où vos instanciations sont très compliquées, trop compliquées et laides pour une seule usine et trop compliquées à comprendre pour l'interface utilisateur ..

Supposons qu’il s’agisse d’une marque TYPE_A et non d’une classe unique. Admettons qu’il existe une famille de 100 types similaires de classes de Type-A et que vous devez instancier un objet à partir d’elles. Imaginez que des informations détaillées et sophistiquées soient nécessaires pour créer le bon objet à partir d'une marque de nombreux types d'objets similaires. Dans cette entité d'objet, vous devez savoir exactement quels paramètres doivent être ajustés et comment les ajuster.

Dans l'usine spéciale de cette marque, nous les ferons différencier et demanderons à l'objet exact d'instancier et également comment l'instancier. nous le saurons d’après les informations du réseau (disons quelle couleur est disponible dans la boutique en ligne), ainsi que d’autres applications et services fonctionnant en arrière-plan (paramètres non détectés par l’interface utilisateur).

Et peut-être que demain nous aurons une autre famille de disons type_B et type_C pour instancier. Ainsi, l'interface utilisateur aura le "if else" pour savoir si l'utilisateur veut un "type_A", un "type_B" ou un "type_C" - mais les classes fabriques décideront exactement quelle classe du type (de la famille) à construire, et comment l'adapter - quelles valeurs définir pour ses paramètres ou à envoyer à son contractant. Tout cela - selon de nombreux paramètres que l’UI n’est pas au courant. Tout cela sera trop pour une seule classe d’usine.

1
Udi Reshef

Je trouve le motif Abstract Factory surestimé.

Tout d’abord, cela n’arrive pas cela souvent que vous ayez un ensemble de types interreliés que vous souhaitez instancier.

Deuxièmement, le niveau d'indirection (abstraction) fourni par interfaces suffit normalement lors de l'utilisation d'une injection de dépendance.

L'exemple typique de WindowsGui vs MacGui vs ... où vous auriez un WindowsButton, un MacButton, un WindowsScrollBar, un MacScrollbar, etc. est souvent plus facile à implémenter en définissant concret Boutons, Barres de défilement, etc. en utilisant Visiteur et/ou un modèle d'interprétation permettant d'obtenir le comportement réel.

0
eljenso

Supposons que vous créez un fichier .jar et que quelqu'un d'autre utilise votre fichier jar et souhaite utiliser un nouvel objet concret dans votre code. Si vous n'utilisez pas abstract factory, elle doit alors modifier votre code ou l'écraser. Mais si vous utilisez abstract factory, elle peut vous fournir une usine et la transmettre à votre code, et tout va bien.

Version raffinée: Considérez le scénario ci-dessous: Quelqu'un d'autre a écrit un framework. Le framework utilise une fabrique abstraite et des fabriques concrètes pour créer beaucoup d'objets au moment de l'exécution. Vous pouvez ainsi facilement enregistrer votre propre usine dans le cadre existant et créer vos propres objets. Le cadre est fermé aux modifications et reste facile à étendre en raison du motif abstrait de l'usine.

0
Adrian Liu

Tout est question de dépendances. Si vous ne vous souciez pas du couplage étroit et des dépendances, vous n'avez pas besoin d'une fabrique abstraite. Mais cela importera dès que vous écrivez une application qui nécessite une maintenance.

0
Daniel

Ce modèle est particulièrement utile lorsque le client ne sait pas exactement quel type créer. Par exemple, supposons qu'un Showroom vendant exclusivement des téléphones cellulaires reçoive une requête pour les téléphones intelligents fabriqués par Samsung. Ici, nous ne connaissons pas le type exact d'objet à créer (en supposant que toutes les informations d'un téléphone sont présentées sous la forme d'un objet concret). Mais nous savons que nous recherchons des téléphones intelligents fabriqués par Samsung. Ces informations peuvent réellement être utilisées si notre conception a une implémentation en usine abstraite.

Comprendre et implémenter le motif de fabrique abstraite en C #

0
Amir Shabani

Pour répondre directement à votre question, vous pouvez probablement vous en sortir sans utiliser un tel motif.

Cependant, gardez à l'esprit que la plupart des projets dans le monde réel évoluent et que vous souhaitez fournir une sorte d'extensibilité afin de rendre votre projet à l'épreuve du temps.

De par ma propre expérience, la plupart du temps, une usine est mise en œuvre et, à mesure que le projet se développe, elle se transforme en modèles de conception plus complexes, tels qu’une usine abstraite.

0
BlueTrin