Quelle est la différence fondamentale entre les motifs d'usine et les motifs d'usine abstraits?
createThing()
) et Abstract Factory utilise la composition (l'indirection est horizontale par exemple getFactory().createThing()
)
Quelle est la différence fondamentale entre les motifs d'usine et les motifs d'usine abstraits?
createThing()
) et Abstract Factory utilise la composition (l'indirection est horizontale par exemple getFactory().createThing()
)
Réponses:
Avec le modèle Factory, vous produisez des instances de mise en oeuvre ( Apple
, Banana
, Cherry
, etc.) d'une interface particulière - par exemple, IFruit
.
Avec le modèle Abstract Factory, vous fournissez un moyen pour quiconque de fournir sa propre usine. Cela permet à votre entrepôt d'être un IFruitFactory
ou un IJuiceFactory
, sans que votre entrepôt ne sache quoi que ce soit sur les fruits ou les jus.
IFruit
- elle instancie les choses qui implémentent IFruit
. Bien sûr, il n'a pas besoin de produire des instances de choses qui implémentent une interface particulière, mais c'est probablement une odeur de code si vous avez une usine qui produit des choses qui sont totalement indépendantes les unes des autres.
Source de cette information tirée de: http://java.dzone.com/news/intro-design-patterns-abstract
Les méthodes d'une usine abstraite sont implémentées en tant que méthodes d'usine. Le modèle abstrait d'usine et le modèle de méthode d'usine dissocient le système client des classes d'implémentation réelles par le biais des types abstraits et des usines. La méthode Factory crée des objets par héritage, alors que la fabrique abstraite crée des objets par composition.
Le modèle d'usine abstraite se compose d'une usine abstraite, d'une usine concrète, d'un produit abstrait, d'un produit concret et d'un client.
Le modèle d'usine abstrait peut être implémenté à l'aide du modèle de méthode d'usine, du modèle de prototype ou du modèle singleton. L'objet ConcreteFactory peut être implémenté en tant que singleton car une seule instance de l'objet ConcreteFactory est nécessaire.
Le modèle Factory Method est une version simplifiée du modèle Abstract Factory. Le modèle Factory Method est responsable de la création de produits appartenant à une même famille, tandis que le modèle Abstract Factory traite de plusieurs familles de produits.
Factory Method utilise des interfaces et des classes abstraites pour dissocier le client de la classe du générateur et des produits résultants. Abstract Factory possède un générateur qui est un conteneur pour plusieurs méthodes d'usine, ainsi que des interfaces découplant le client du générateur et des produits.
Utilisez le modèle Factory Method lorsqu'il est nécessaire de dissocier un client d'un produit particulier qu'il utilise. Utilisez la méthode Factory pour décharger un client de la responsabilité de la création et de la configuration des instances d'un produit.
Utilisez le modèle Abstract Factory lorsque les clients doivent être découplés des classes de produits. Particulièrement utile pour la configuration et la modification de programmes. Le modèle Abstract Factory peut également imposer des contraintes sur les classes à utiliser avec les autres. La fabrication de nouvelles usines de béton peut demander beaucoup de travail.
Cette spécification pour les disques pour préparer différents types de pâtes dans un fabricant de pâtes est la fabrique abstraite, et chaque disque spécifique est une fabrique. toutes les usines (disques de pâtes) héritent de leurs propriétés de l'usine abstraite. Chaque disque individuel contient des informations sur la façon de créer les pâtes, et pas le fabricant de pâtes.
L'équipement d'estampage correspond à l'usine abstraite, car il s'agit d'une interface pour les opérations qui créent des objets de produits abstraits. Les matrices correspondent à la Concrete Factory, car elles créent un produit en béton. Chaque catégorie de pièce (hotte, porte, etc.) correspond au produit abstrait. Les pièces spécifiques (c.-à-d. La porte côté conducteur pour 99 camry) correspondent aux produits en béton.
L'entreprise de jouets correspond au Créateur, car elle peut utiliser l'usine pour créer des objets produits. La division de la société de jouets qui fabrique un type spécifique de jouet (cheval ou voiture) correspond à ConcreteCreator.
Modèle d'usine: l'usine produit des implémentations IProduct
Modèle d'usine abstrait: une usine-usine produit des IFactories, qui à leur tour produisent des IProduits :)
[Mise à jour selon les commentaires]
Ce que j'ai écrit plus tôt n'est pas correct du moins selon Wikipédia . Une usine abstraite est simplement une interface d'usine. Avec lui, vous pouvez changer vos usines au moment de l'exécution, pour autoriser différentes usines dans différents contextes. Les exemples pourraient être différentes usines pour différents OS, fournisseurs SQL, middleware-pilotes, etc.
Fournir une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.
Le modèle Abstract Factory est très similaire au modèle Factory Method. Une différence entre les deux est qu'avec le modèle Abstract Factory, une classe délègue la responsabilité de l'instanciation d'objet à un autre objet via la composition tandis que le modèle Factory Method utilise l'héritage et s'appuie sur une sous-classe pour gérer l'instanciation d'objet souhaitée.
En fait, l'objet délégué utilise fréquemment des méthodes d'usine pour effectuer l'instanciation!
Les modèles d'usine sont des exemples de modèles de création
Les modèles de création résument le processus d'instanciation d'objet. Ils masquent la façon dont les objets sont créés et contribuent à rendre le système global indépendant de la façon dont ses objets sont créés et composés.
Les modèles de création de classe se concentrent sur l'utilisation de l'héritage pour décider de l'objet à instancier Méthode d'usine
Les modèles de création d'objets se concentrent sur la délégation de l'instanciation à un autre objet Abstract Factory
Référence: Factory vs Abstract Factory
Méthode de fabrique: vous disposez d'une fabrique qui crée des objets qui dérivent d'une classe de base particulière
Usine abstraite: vous avez une usine qui crée d' autres usines , et ces usines créent à leur tour des objets dérivés des classes de base. Vous faites cela parce que vous ne voulez souvent pas simplement créer un seul objet (comme avec la méthode Factory) - vous voulez plutôt créer une collection d'objets associés.
L'usine abstraite est une interface pour créer des objets associés, mais la méthode d'usine est une méthode. L'usine abstraite est implémentée par la méthode d'usine.
Différence de base:
Factory: crée des objets sans exposer la logique d'instanciation au client.
Méthode d'usine : définissez une interface pour créer un objet, mais laissez les sous-classes décider de la classe à instancier. La méthode Factory permet à une classe de reporter l'instanciation aux sous-classes
Abstract Factory : fournit une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.
Le modèle AbstractFactory utilise la composition pour déléguer la responsabilité de créer un objet à une autre classe tandis que le modèle de méthode Factory utilise l'héritage et s'appuie sur une classe ou une sous-classe dérivée pour créer l'objet
Des articles oodesign :
Diagramme de classe d' usine :
Exemple: StaticFactory
public class ShapeFactory {
//use getShape method to get object of type shape
public static Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
Un exemple d'usine non statique implémentant FactoryMethod est disponible dans cet article:
Modèles de conception: méthode Factory vs Factory vs Abstract Factory
Quand l'utiliser: le client a juste besoin d'une classe et ne se soucie pas de l'implémentation concrète qu'il reçoit.
Classe de méthode d'usine digaram:
Quand l'utiliser: Le client ne sait pas quelles classes concrètes il devra créer au moment de l'exécution, mais veut juste obtenir une classe qui fera le travail.
Diagramme de classe abstraite d'usine de dzone
Quand l'utiliser: lorsque votre système doit créer plusieurs familles de produits ou que vous souhaitez fournir une bibliothèque de produits sans exposer les détails de l'implémentation.
Les exemples de code source dans les articles ci-dessus sont très bons pour comprendre clairement les concepts.
Question SE associée avec un exemple de code:
Modèle d'usine. Quand utiliser les méthodes d'usine?
Différences:
Autres articles utiles:
méthode_usine de fabrication de source
abstract_factory de sourcemaking
modèle de conception abstraite d'usine de journaldev
Exemple / scénario pour Abstract Factory
Je vis dans un endroit où il pleut pendant la saison des pluies, la neige en hiver et chaude et ensoleillée en été. J'ai besoin de différents types de vêtements pour me protéger des éléments. Pour ce faire, je vais au magasin près de chez moi et je demande des vêtements / articles pour me protéger. Le magasinier me donne l'article approprié selon l'environnement et la profondeur de ma poche. Les articles qu'il me donne sont de même niveau de qualité et de prix. Puisqu'il est au courant de mes normes, il lui est facile de le faire. Mais quand un homme riche de l'autre côté de la rue arrive avec les mêmes exigences, il obtient un article de marque cher. Une chose notable est que tous les articles qu'il me donne se complètent en termes de qualité, de standard et de coût. On peut dire qu'ils vont ensemble. C'est la même chose avec les objets que ce gars riche obtient.
Donc en regardant le scénario ci-dessus, j'apprécie maintenant l'efficacité du commerçant. Je peux remplacer ce commerçant par un magasin abstrait. Les éléments que nous obtenons avec des éléments abstraits et moi et les riches en tant que clients en perspective. Nous n'avons besoin que du produit / article qui correspond à nos besoins.
Maintenant, je me vois facilement envisager une boutique en ligne qui fournit un ensemble de services à ses nombreux clients. Chaque client appartient à l'un des trois groupes. Lorsqu'un utilisateur d'un groupe premium ouvre le site, il obtient une excellente interface utilisateur, un volet de publicité hautement personnalisé, plus d'options dans les menus, etc. et une interface légèrement moins ergonomique. Le dernier est mon type d'utilisateur, un utilisateur de «groupe libre». Je suis juste assez servi pour ne pas être offensé. L'interface utilisateur est un strict minimum, les publicités sont tellement éloignées que je ne sais pas ce qui s'y trouve, enfin le menu ne fait que se déconnecter.
Si j'ai la chance de construire quelque chose comme ce site, je considérerais certainement Abstract Factory Pattern.
Produits abstraits: volet publicitaire, menu, peintre d'interface utilisateur.
Abstract Factory: Expérience utilisateur de la boutique en ligne
Concreate Factory: Expérience utilisateur Premium, Expérience utilisateur Gold, Expérience utilisateur générale.
Beaucoup de gens se sentiront peut-être surpris, mais cette question est incorrecte . Si vous entendez cette question lors d'un entretien, vous devez aider l'enquêteur à comprendre où se situe la confusion.
Commençons par le fait qu'il n'y a pas de motif concret qui s'appelle juste "Factory". Il existe un modèle appelé "Abstract Factory" et un modèle appelé "Factory Method".
Alors, qu'est-ce que "Factory" signifie alors? l'un des éléments suivants (tout peut être considéré comme correct, selon la portée de la référence):
Et, malheureusement , beaucoup de gens utilisent "Factory" pour désigner un autre type d'usine, qui crée une ou plusieurs usines (ou leurs interfaces). Sur la base de leur théorie:
Le produit implémente IProduct, qui est créé par Factory, qui implémente IFactory, qui est créé par AbstractFactory.
Pour comprendre à quel point c'est idiot, continuons notre équation:
AbstractFactory implémente IAbstractFactory, qui est créé par ... AbstractAbstractFactory ???
J'espère que vous voyez le point. Ne vous trompez pas, et s'il vous plaît, n'inventez pas des choses qui n'existent pas pour une raison.
-
PS : Factory for Products est AbstractFactory, et Factory for Abstract Factories serait également un autre exemple de AbstractFactory.
//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{
public Dough createDough(); //Will return you family of Dough
public Clam createClam(); //Will return you family of Clam
public Sauce createSauce(); //Will return you family of Sauce
}
class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{
@Override
public Dough createDough(){
//create the concrete dough instance that NY uses
return doughInstance;
}
//override other methods
}
Les définitions des manuels sont déjà fournies par d'autres réponses. J'ai pensé que j'en fournirais également un exemple.
Voici donc PizzaIngredientsFactory
une usine abstraite car elle fournit des méthodes pour créer une famille de produits connexes.
Notez que chaque méthode de la fabrique abstraite est une méthode de fabrique en soi. Like createDough()
est en soi une méthode d'usine dont les implémentations concrètes seront fournies par des sous-classes comme NYPizzaIngredientsFactory
. Ainsi, l'utilisation de chaque emplacement différent peut créer des instances d'ingrédients concrets qui appartiennent à leur emplacement.
Fournit une instance de mise en œuvre concrète
Dans l'exemple:
- createDough()
- fournit une mise en œuvre concrète pour la pâte. C'est donc une méthode d'usine
Fournit une interface pour créer une famille d'objets associés
Dans l'exemple:
- PizzaIngredientsFactory
est une usine abstraite car elle permet de créer un ensemble d'objets associés comme Dough
, Clams
, Sauce
. Pour créer chaque famille d'objets, il fournit une méthode d'usine.
Exemple de modèles de conception Head First
J'ai quelques points à apporter à la réponse de John comme suit:
Avec la « méthode usine » (parce que « Factory » est ambigu), vous produisez des implémentations ( Lemon
, Orange
, etc.) d'une interface particulière - par exemple, IFruit
. Cette usine pourrait être appelée CitricFruitFactory
.
Mais maintenant, vous voulez créer un autre type de fruit que CitricFruitFactory n'est pas en mesure de créer. Peut-être que le code de CitricFruitFactory
n'aurait pas de sens si vous en créez un Strawberry
(la fraise n'est pas un fruit citrique!).
Ainsi , vous pouvez créer une nouvelle usine appelée RedFruitFactory
qui produit Strawberry
, Raspberry
etc.
Comme l'a dit John Feminella:
"Avec le modèle Abstract Factory, vous produisez des implémentations d'une interface Factory particulière - par exemple IFruitFactory
. Chacun sait comment créer différents types de fruits."
Ces implémentations de IFruitFactory
sont CitricFruitFactory
et RedFruitFactory
!
Mes sources sont: StackOverflow
, tutorialspoint.com
, programmers.stackexchange.com
et CodeProject.com
.
Factory Method
(également appelé Factory
) est destiné au client de découplage d'une Interface
implémentation. Par exemple, nous avons une Shape
interface avec deux Circle
et Square
implémentations. Nous avons défini une classe d'usine avec une méthode d'usine avec un paramètre déterminant tel qu'une Type
nouvelle implémentation d' Shape
interface associée .
Abstract Factory
contient plusieurs méthodes d'usine ou une interface d'usine par plusieurs implémentations d'usine. Pour l' échantillon suivant ci - dessus , nous avons une Color
interface avec deux Red
et Yellow
mises en œuvre. Nous avons défini une ShapeColorFactory
interface avec deux RedCircleFactory
et YellowSquareFactory
. Code suivant pour expliquer ce concept:
interface ShapeColorFactory
{
public Shape getShape();
public Color getColor();
}
class RedCircleFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Circle();
}
@Override
public Color getColor() {
return new Red();
}
}
class YellowSquareFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Square();
}
@Override
public Color getColor() {
return new Yellow();
}
}
Voici la différence entre FactoryMethod
et AbstractFactory
. Factory Method
comme simplement retourner une classe concrète d'une interface mais Abstract Factory
retourner factory of factory
. En d'autres termes, Abstract Factory
retournez une combinaison différente d'une série d'interfaces.
J'espère que mon explication sera utile.
La différence majeure dans ces usines est quand ce que vous voulez faire avec les usines et quand vous voulez l'utiliser.
Parfois, lorsque vous faites de l'IOC (inversion de contrôle, par exemple injection de constructeur), vous savez que vous pouvez créer des objets solides. Comme mentionné dans l'exemple ci-dessus des fruits, si vous êtes prêt à créer des objets de fruits, vous pouvez utiliser un modèle d'usine simple .
Mais souvent, vous ne voulez pas créer d'objets solides, ils viendront plus tard dans le déroulement du programme. Mais la configuration vous indique le type d'usine que vous souhaitez utiliser au démarrage, au lieu de créer des objets, vous pouvez transmettre les usines dérivées d'une classe d'usine commune au constructeur dans IOC.
Donc, je pense que c'est aussi sur la durée de vie et la création de l'objet.
Les deux Factory Method
et Abstract Factory
garder les clients découplés des types de béton. Les deux créent des objets, mais la Factory
méthode utilise l'héritage tandis que la Abstract Factory
composition.
Le Factory Method
est hérité des sous-classes pour créer les objets concrets (produits) tandis que Abstract Factory
fournir une interface pour créer la famille de produits liés et la sous-classe de ces interfaces définit comment créer des produits liés.
Ensuite, ces sous-classes une fois instanciées sont passées dans des classes de produits où elles sont utilisées comme type abstrait. Les produits associés dans un Abstract Factory
sont souvent implémentés à l'aide de Factory Method
.
Extension de la réponse de John Feminella:
Apple
, Banana
, Cherry
Met en œuvre FruitFactory
et qui a une méthode appelée Create
qui est seul responsable de la création d' Apple ou de banane ou de cerise. Vous avez terminé, avec votre Factory
méthode.
Maintenant, vous voulez Create
une salade spéciale de vos fruits et voici votre usine abstraite . Abstract Factory sait comment créer votre salade spéciale à partir de pomme, de banane et de cerise.
public class Apple implements Fruit, FruitFactory {
public Fruit Create() {
// Apple creation logic goes here
}
}
public class Banana implements Fruit, FruitFactory {
public Fruit Create() {
// Banana creation logic goes here
}
}
public class Cherry implements Fruit, FruitFactory {
public Fruit Create() {
// Cherry creation logic goes here
}
}
public class SpecialSalad implements Salad, SaladFactory {
public static Salad Create(FruitFactory[] fruits) {
// loop through the factory and create the fruits.
// then you're ready to cut and slice your fruits
// to create your special salad.
}
}
Par définition, nous pouvons faire glisser les différences de deux:
Factory: une interface est utilisée pour créer un objet, mais la sous-classe décide de la classe à instancier. La création d'objet se fait lorsqu'elle est requise.
Abstract Factory: le modèle Abstract Factory agit comme une super-usine qui crée d'autres usines. Dans le modèle Abstract Factory, une interface est responsable de la création d'un ensemble d'objets liés ou d'objets dépendants sans spécifier leurs classes concrètes.
Ainsi, dans les définitions ci-dessus, nous pouvons souligner une différence particulière. c'est-à-dire que Factory pattern est responsable de la création d'objets et Abstract Factory est responsable de la création d'un ensemble d'objets associés; évidemment à la fois via une interface.
Modèle d'usine:
public interface IFactory{
void VehicleType(string n);
}
public class Scooter : IFactory{
public void VehicleType(string n){
Console.WriteLine("Vehicle type: " + n);
}
}
public class Bike : IFactory{
public void VehicleType(string n) {
Console.WriteLine("Vehicle type: " + n);
}
}
public interface IVehicleFactory{
IFactory GetVehicleType(string Vehicle);
}
public class ConcreteVehicleFactory : IVehicleFactory{
public IFactory GetVehicleType(string Vehicle){
switch (Vehicle){
case "Scooter":
return new Scooter();
case "Bike":
return new Bike();
default:
return new Scooter();
}
}
class Program{
static void Main(string[] args){
IVehicleFactory factory = new ConcreteVehicleFactory();
IFactory scooter = factory.GetVehicleType("Scooter");
scooter.VehicleType("Scooter");
IFactory bike = factory.GetVehicleType("Bike");
bike.VehicleType("Bike");
Console.ReadKey();
}
}
Motif abstrait d'usine:
interface IVehicleFactory{
IBike GetBike();
IScooter GetScooter();
}
class HondaFactory : IVehicleFactory{
public IBike GetBike(){
return new FZS();
}
public IScooter GetScooter(){
return new FZscooter();
}
}
class HeroFactory: IVehicleFactory{
public IBike GetBike(){
return new Pulsur();
}
public IScooter GetScooter(){
return new PulsurScooter();
}
}
interface IBike
{
string Name();
}
interface IScooter
{
string Name();
}
class FZS:IBike{
public string Name(){
return "FZS";
}
}
class Pulsur:IBike{
public string Name(){
return "Pulsur";
}
}
class FZscooter:IScooter {
public string Name(){
return "FZscooter";
}
}
class PulsurScooter:IScooter{
public string Name(){
return "PulsurScooter";
}
}
enum MANUFACTURERS
{
HONDA,
HERO
}
class VehicleTypeCheck{
IBike bike;
IScooter scooter;
IVehicleFactory factory;
MANUFACTURERS manu;
public VehicleTypeCheck(MANUFACTURERS m){
manu = m;
}
public void CheckProducts()
{
switch (manu){
case MANUFACTURERS.HONDA:
factory = new HondaFactory();
break;
case MANUFACTURERS.HERO:
factory = new HeroFactory();
break;
}
Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " + factory.GetScooter().Name());
}
}
class Program
{
static void Main(string[] args)
{
VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
chk.CheckProducts();
chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
chk.CheckProducts();
Console.Read();
}
}
Vérifiez ici: http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm il semble que la méthode Factory utilise une classe particulière (pas abstraite) comme classe de base tandis que la fabrique Abstract utilise une classe abstraite pour cela. De plus, si vous utilisez une interface au lieu d'une classe abstraite, le résultat sera une implémentation différente du modèle Abstract Factory.
:RÉ
Abstract Factory est un modèle pour créer différents types d'interfaces. Supposons que vous ayez un projet qui vous oblige à analyser différents types de fichiers csv contenant des informations spécifiques sur la quantité, le prix et l'article, comme certains contiennent des données sur les fruits, d'autres sur les chocolats, puis après l'analyse, vous devez mettre à jour ces informations dans leur base de données correspondante, maintenant vous pouvez avoir une fabrique abstraite vous renvoyant une fabrique d'analyseurs et de modificateurs, puis cette fabrique d'analyseurs peut vous renvoyer un objet analyseur de chocolat, un objet analyseur de fruits, etc. et de la même manière, la fabrique de modificateurs peut renvoyer un objet modificateur de chocolat, un objet modificateur de fruits, etc.
Je pense que nous pouvons comprendre la différence entre ces deux en voyant un exemple de code Java8:
interface Something{}
interface OneWhoCanProvideSomething {
Something getSomething();
}
interface OneWhoCanProvideCreatorsOfSomething{
OneWhoCanProvideSomething getCreator();
}
public class AbstractFactoryExample {
public static void main(String[] args) {
//I need something
//Let's create one
Something something = new Something() {};
//Or ask someone (FACTORY pattern)
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;
//Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;
//Same thing, but you don't need to write you own interfaces
Supplier<Something> supplierOfSomething = () -> null;
Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
}
}
Maintenant, la question est de savoir quel mode de création devez-vous utiliser et pourquoi: La première façon (pas de modèle, juste un constructeur simple): créer par vous-même n'est pas une bonne idée, vous devez faire tout le travail et votre code client est lié à la mise en œuvre particulière.
La deuxième façon (en utilisant le modèle Factory): vous offre l'avantage que vous pouvez passer n'importe quel type d'implémentation, qui peut fournir un type différent de quelque chose en fonction d'une condition (peut-être un paramètre passé à la méthode de création).
La troisième façon (en utilisant le modèle Abstract Factory): Cela vous donne plus de flexibilité. Vous pouvez trouver différents types de créateurs de quelque chose en fonction d'une condition (peut-être un paramètre passé).
Notez que vous pouvez toujours vous éloigner du modèle Factory en combinant deux conditions ensemble (ce qui augmente légèrement la complexité du code et le couplage), je suppose que c'est pourquoi nous voyons rarement des cas d'utilisation réels du modèle Abstract Factory.