Diferencias entre el Patrón Abstracto de Fábrica y el Método de Fábrica

Abstract factory crea una clase base con métodos abstractos que definen métodos para los objetos que se deben crear. Cada clase de fábrica que deriva la clase base puede crear su propio implementaton de cada tipo de objeto.

Factory method es solo un método simple utilizado para crear objetos en una clase. Por lo general se agrega en la raíz agregada (La clase Order tiene un método llamado CreateOrderLine)

Abstract factory

En en el siguiente ejemplo diseñamos una interfaz para que podamos desacoplar la creación de colas de un sistema de mensajería y, por lo tanto, podamos crear implementaciones para diferentes sistemas de colas sin tener que cambiar la base de código.

interface IMessageQueueFactory
{
  IMessageQueue CreateOutboundQueue(string name);
  IMessageQueue CreateReplyQueue(string name);
}

public class AzureServiceBusQueueFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new AzureMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new AzureResponseMessageQueue(/*....*/);
      }

}

public class MsmqFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new MsmqMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new MsmqResponseMessageQueue(/*....*/);
      }
}

Método de fábrica

El problema en los servidores HTTP es que siempre necesitamos una respuesta para cada solicitud.

public interface IHttpRequest
{
    // .. all other methods ..

    IHttpResponse CreateResponse(int httpStatusCode);
}

Sin el método factory, los usuarios del servidor HTTP (es decir, los programadores) se verían obligados a usar clases específicas de implementación que el propósito de la interfaz IHttpRequest.

Por lo tanto, introducimos el método factory para que la creación de la clase response también se abstraiga.

Resumen

La diferencia es que el propósito de la clase que contiene un método factory no es crear objetos , mientras que una fábrica abstracta solo debe usarse para crear objetos.

Uno debe tener cuidado al usar métodos de fábrica ya que es fácil romper el LSP (Liskovs Principio de sustitución ) al crear objetos.

La diferencia entre los patrones de diseño AbstractFactory y Factory son los siguientes:

• El método Factoryse usa para crear un solo producto, pero Abstract Factory se trata de crear familias de productos relacionados o dependientes.
• Factory Method pattern expone un método al cliente para crear el objeto, mientras que en el caso de Abstract Factory exponen una familia de objetos relacionados que pueden consistir en estos Factory método.
• Método de fábricael patrón oculta la construcción de un solo objeto, mientras que Método de fábrica abstracto oculta la construcción de una familia de objetos relacionados. Las fábricas abstractas generalmente se implementan utilizando (un conjunto de) métodos de fábrica.
• AbstractFactory pattern usa la composición para delegar la responsabilidad de crear el objeto a otra clase, mientras que Factory design pattern usa la herencia y se basa en la clase derivada o subclase para crear objeto.
• La idea detrás del patrón Método de fábrica es que permite el caso en el que un cliente no sabe qué clases concretas tendrá que crear en tiempo de ejecución, pero solo quiere obtener una clase que haga el trabajo, mientras que AbstractFactory el patrón se utiliza mejor cuando su sistema tiene que crear varias familias de productos o desea proporcionar una biblioteca de productos sin exponer los detalles de la implementación.!

Fábrica Implementación del Patrón de Método:

Implementación de patrones AbstractFactory:

Abstract Factory es una interfaz para crear productos relacionados, pero el Método Factory es solo un método. Abstract Factory se puede implementar mediante múltiples métodos de Fábrica.

Considere este ejemplo para una fácil comprensión.

¿Qué ofrecen las compañías de telecomunicaciones? Banda ancha, línea telefónica y móvil, por ejemplo, y se le pide que cree una aplicación para ofrecer sus productos a sus clientes.

En general, lo que haría aquí es crear los productos, es decir, banda ancha, línea telefónica y móvil, a través de su Método de fábrica donde sabe qué propiedades tiene para esos productos y su bastante recto adelante.

Ahora, la compañía quiere ofrecer a sus clientes un paquete de sus productos, es decir, banda ancha, línea telefónica y móvil, todos juntos, y aquí viene el Abstract Factory para jugar.

Abstract Factory es, en otras palabras, son la composición de otras fábricas que son responsables de crear sus propios productos y Abstract Factory sabe cómo colocar estos productos en más significativo con respecto a sus propias responsabilidades.

En este caso, el BundleFactory es la Fábrica Abstracta, BroadbandFactory, PhonelineFactory y MobileFactory son los Factory. Simplemente, estas Fábricas tendrán Método de Fábrica para inicializar los productos individuales.

Se el siguiente ejemplo de código:

public class BroadbandFactory : IFactory {
    public static Broadband CreateStandardInstance() {
        // broadband product creation logic goes here
    }
}

public class PhonelineFactory : IFactory {
    public static Phoneline CreateStandardInstance() {
        // phoneline product creation logic goes here
    }
}

public class MobileFactory : IFactory {
    public static Mobile CreateStandardInstance() {
        // mobile product creation logic goes here
    }
}

public class BundleFactory : IAbstractFactory {

    public static Bundle CreateBundle() {
        broadband = BroadbandFactory.CreateStandardInstance();
        phoneline = PhonelineFactory.CreateStandardInstance();
        mobile = MobileFactory.CreateStandardInstance();

        applySomeDiscountOrWhatever(broadband, phoneline, mobile);
    }

    private static void applySomeDiscountOrWhatever(Broadband bb, Phoneline pl, Mobile m) {
        // some logic here
    }
}

La principal diferencia entre Fábrica Abstracta y Método de Fábrica es que Fábrica Abstracta se implementa por Composición; pero Método de Fábrica se implementa por Herencia.

Sí, lo has leído correctamente: la principal diferencia entre estos dos patrones es el antiguo debate composición vs herencia.

No voy a reproducir aquí los diagramas UML, ya que se pueden encontrar en numerosos lugares. Quiero proporcionar ejemplos de código; sin embargo, porque creo que combinar los ejemplos de las dos respuestas principales en este hilo dará una mejor demostración que cualquiera de las respuestas solas. Además, he agregado la terminología utilizada en el libro (GoF) a los nombres de clases y métodos.

Abstract Factory

1. El punto más importante a entender aquí es que la fábrica abstracta es inyectado en el cliente. Es por eso que decimos que Abstracta La fábrica se implementa por composición. A menudo, una dependencia inyección framework would perform that task; but a framework is not required por DI.
2. El segundo punto crítico es que las fábricas de hormigón aquí son no Implementaciones de métodos de fábrica! Código de ejemplo para Factory El método se muestra más adelante.
3. Y finalmente, el tercer punto a tener en cuenta es la relación entre productos: en este caso las colas de salida y respuesta. Un hormigón fábrica produce colas de Azure, el otro MSMQ. El GoF se refiere a este producto relación como "familia" y es importante ser consciente de que la familia en este caso no significa jerarquía de clases.

public class Client {
    private final AbstractFactory_MessageQueue factory;

    public Client(AbstractFactory_MessageQueue factory) {
        // The factory creates message queues either for Azure or MSMQ.
        // The client does not know which technology is used.
        this.factory = factory;
    }

    public void sendMessage() {
        //The client doesn't know whether the OutboundQueue is Azure or MSMQ.
        OutboundQueue out = factory.createProductA();
        out.sendMessage("Hello Abstract Factory!");
    }

    public String receiveMessage() {
        //The client doesn't know whether the ReplyQueue is Azure or MSMQ.
        ReplyQueue in = factory.createProductB();
        return in.receiveMessage();
    }
}

public interface AbstractFactory_MessageQueue {
    OutboundQueue createProductA();
    ReplyQueue createProductB();
}

public class ConcreteFactory_Azure implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new AzureMessageQueue();
    }

    @Override
    public ReplyQueue createProductB() {
        return new AzureResponseMessageQueue();
    }
}

public class ConcreteFactory_Msmq implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new MsmqMessageQueue();
    }

    @Override
    public ReplyQueue createProductB() {
        return new MsmqResponseMessageQueue();
    }
}

Método De Fábrica

1. El punto más importante a entender aquí es que el ConcreteCreator es el cliente. En otras palabras, el cliente es una subclase cuyo padre define el factoryMethod(). Por eso decimos que El método de fábrica se implementa por Herencia.
2. El segundo punto crítico es recordar que el Método Factory El patrón es nada más que una especialización del Método de Plantilla Patrón. Los dos patrones comparten una estructura idéntica. Sólo difieren en el propósito. El método de fábrica es creativo (construye algo) mientras que el método de plantilla es conductual (calcula algo).
3. Y finalmente, el tercer punto a tener en cuenta es que el Creator (padre) la clase invoca su propio factoryMethod(). Si eliminamos anOperation() de la clase padre, dejando solo un método detrás, ya no es el patrón del método de fábrica. En otros palabra, Método de fábrica no se puede implementar con menos de dos métodos en la clase padre; y uno debe invocar al otro.

public abstract class Creator {
    public void anOperation() {
        Product p = factoryMethod();
        p.whatever();
    }

    protected abstract Product factoryMethod();
}

public class ConcreteCreator extends Creator {
    @Override
    protected Product factoryMethod() {
        return new ConcreteProduct();
    }
}

Misc. Patrones de fábrica & Diversos

Tenga en cuenta que aunque el GoF define dos patrones de Fábrica diferentes, estos no son los únicos patrones de Fábrica existentes. Ni siquiera son necesariamente los patrones de fábrica más utilizados. Un tercer ejemplo famoso es el Patrón de fábrica estático de Josh Bloch de Effective Java. La Cabeza Primero El libro de patrones de diseño incluye otro patrón que llaman Simple Factory.

No caigas en la trampa de asumir que cada patrón de fábrica debe coincidir con uno del GoF.

Dejemos claro que la mayor parte del tiempo en el código de producción, usamos patrón de fábrica abstracto porque la clase A está programada con la interfaz B. Y A necesita crear instancias de B. Por lo que A tiene que tener un objeto de fábrica para producir instancias de B. Por lo que A no depende de ninguna instancia concreta de B. Espero que ayude.

Comprender las diferencias en las motivaciones:

Supongamos que estás construyendo una herramienta donde tienes objetos y una implementación concreta de las interrelaciones de los objetos. Dado que prevé variaciones en los objetos, ha creado una indirecta asignando la responsabilidad de crear variantes de los objetos a otro objeto (lo llamamos abstract factory). Esta abstracción encuentra un gran beneficio ya que prevé futuras extensiones que necesitan variantes de los objeto.

Otra motivación bastante intrigante en esta línea de pensamientos es un caso donde cada-o-ninguno de los objetos de todo el grupo tendrá una variante correspondiente. En función de algunas condiciones, se utilizará cualquiera de las variantes y en cada caso todos los objetos deben ser de la misma variante. Esto podría ser un poco contra intuitivo de entender, ya que a menudo tendemos a pensar que, siempre y cuando las variantes de un objeto sigan un contrato uniforme común (interfaz en un sentido más amplio), la el código de implementación concreto nunca debe romperse. El hecho intrigante aquí es que, no siempre esto es cierto, especialmente cuando el comportamiento esperado no puede ser modelado por un contrato de programación.

Un simple ( tomando prestada la idea de GoF) es cualquier aplicación GUI que diga un monitor virtual que emula la apariencia de MS, Mac o Fedora OS. Aquí, por ejemplo, cuando todos los objetos widget como ventana, botón, etc. tener variante MS excepto una barra de desplazamiento que se deriva de la variante MAC, el propósito de la herramienta falla mal.

Estos casos anteriores forman la necesidad fundamental de Abstract Factory Pattern.

Por otro lado, imagine que está escribiendo un framework para que muchas personas puedan construir varias herramientas ( como la de los ejemplos anteriores) usando su framework. Por la misma idea de un marco, no es necesario, aunque no podría utilizar objetos concretos en su lógica. Usted prefiere poner algunos contratos de alto nivel entre varios objetos y cómo interactuar. Mientras que usted (como desarrollador de framework) permanece en un nivel muy abstracto, cada constructor de la herramienta se ve obligado a seguir sus construcciones de framework. Sin embargo, ellos (los constructores de herramientas) tienen la libertad de decidir qué objeto construir y cómo interactuarán todos los objetos que crean. A diferencia del caso anterior ( de Abstract Factory Pattern), usted ( como creador de framework ) no necesita trabajar con objetos concretos en este caso; y más bien puede quedarse en el nivel de contrato de los objetos. Además, a diferencia de la segunda parte de las motivaciones anteriores, usted o los constructores de herramientas nunca tienen las situaciones de mezclar objetos de variantes. Aquí, mientras que el código del marco se mantiene a nivel de contrato, cada constructor de herramientas está restringido (por la naturaleza del caso en sí) a usar sus propios objetos. En este caso, las creaciones de objetos se delegan a cada implementador y los proveedores de framework solo proporcionan métodos uniformes para crear y devolver objetos. Tales los métodos son inevitables para el desarrollador de framework para proceder con su código y tiene un nombre especial llamado Método de fábrica (Patrón del método de fábrica para el patrón subyacente ).

Pocas Notas:

• Si está familiarizado con el 'método de plantilla', entonces verá que los métodos de fábrica a menudo se invocan desde métodos de plantilla en el caso de programas pertenecientes a cualquier forma de marco. Por el contrario, los métodos de plantilla de aplicación-programas son a menudo la implementación simple de algoritmo específico y vacío de fábrica-métodos.
• Además, para la integridad de los pensamientos, utilizando el marco (mencionado anteriormente), cuando un constructor de herramientas está construyendo una herramienta, dentro de cada método de fábrica, en lugar de crear un objeto concreto, puede delegar la responsabilidad a un objeto abstracto-fábrica, siempre que el constructor de herramientas prevea variaciones de los objetos concretos para el futuro ampliación.

Código De Ejemplo:

//Part of framework-code
BoardGame {
    Board createBoard() //factory method. Default implementation can be provided as well
    Piece createPiece() //factory method

    startGame(){        //template method
         Board borad = createBoard()
         Piece piece = createPiece()
         initState(board, piece)
    }
}


//Part of Tool-builder code
Ludo inherits  BoardGame {
     Board createBoard(){ //overriding of factory method
         //Option A: return new LudoBoard() //Lodu knows object creation
         //Option B: return LudoFactory.createBoard() //Lodu asks AbstractFacory
     }
….
}

//Part of Tool-builder code
Chess inherits  BoardGame {
    Board createBoard(){ //overriding of factory method
        //return a Chess board
    }
    ….
}

1. Mi primera pregunta es sobre la fábrica abstracta. ¿Es su función permitirle crear familias de objetos concretos en (que pueden depender de la fábrica específica que use) en lugar de un solo objeto concreto?

Sí. La intención de Abstract Factory es:

Proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.

1. Hace el abstract factory solo devuelve un objeto muy grande o muchos objetos dependiendo de qué métodos llame?

Idealmente debería devolver un objeto por el método que el cliente está invocando.

1. Entiendo que el patrón del método de fábrica tiene una interfaz Creadora que hará que el Creador concreto se encargue de saber qué producto concreto instanciar. ¿Es esto lo que significa usar herencia para manejar la instanciación de objetos?

Sí. El método de fábrica utiliza la herencia.

1. Patrón de fábrica abstracto delegar la responsabilidad de la instanciación de objetos a otro objeto a través de la composición? ¿Qué significa esto?

AbstractFactory define un método de factory ConcreteFactory es responsable de construir un producto concreto. Simplemente siga el ejemplo de código en este artículo .

Puede encontrar más detalles en el SE relacionado mensajes:

¿Cuál es la diferencia básica entre la Fábrica y los Patrones Abstractos de la Fábrica?

Patrones de diseño: Fábrica vs método de fábrica vs Fábrica Abstracta

Para hacerlo muy simple con una interfaz mínima y por favor enfoque" / / 1":

class FactoryProgram
    {
        static void Main()
        {
            object myType = Program.MyFactory("byte");
            Console.WriteLine(myType.GetType().Name);

            myType = Program.MyFactory("float"); //3
            Console.WriteLine(myType.GetType().Name);

            Console.ReadKey();
        }

        static object MyFactory(string typeName)
        {
            object desiredType = null; //1
            switch (typeName)
            {
                case "byte": desiredType = new System.Byte(); break; //2
                case "long": desiredType = new System.Int64(); break;
                case "float": desiredType = new System.Single(); break;
                default: throw new System.NotImplementedException();
            }
            return desiredType;
        }
    }

Aquí puntos importantes: 1. Los mecanismos Factory & AbstractFactory deben usar herencia (System.Object - > byte, float ...); así que si usted tiene herencia en el programa entonces Fábrica (Fábrica abstracta no estaría allí muy probablemente) ya está allí por diseño 2. Creator (MyFactory) conoce el tipo concreto, por lo que devuelve el objeto de tipo concreto al llamante (Main); En abstract factory return type sería un Interfaz.

interface IVehicle { string VehicleName { get; set; } }
interface IVehicleFactory
    {
        IVehicle CreateSingleVehicle(string vehicleType);
    }
class HondaFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports": return new SportsBike();
                case "Regular":return new RegularBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }
class HeroFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports":  return new SportsBike();
                case "Scooty": return new Scooty();
                case "DarkHorse":return new DarkHorseBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }

class RegularBike : IVehicle { public string VehicleName { get { return "Regular Bike- Name"; } set { VehicleName = value; } } }
class SportsBike : IVehicle { public string VehicleName { get { return "Sports Bike- Name"; } set { VehicleName = value; } } }
class RegularScooter : IVehicle { public string VehicleName { get { return "Regular Scooter- Name"; } set { VehicleName = value; } } }
class Scooty : IVehicle { public string VehicleName { get { return "Scooty- Name"; } set { VehicleName = value; } } }
class DarkHorseBike : IVehicle { public string VehicleName { get { return "DarkHorse Bike- Name"; } set { VehicleName = value; } } }

class Program
{
    static void Main(string[] args)
    {
        IVehicleFactory honda = new HondaFactory(); //1
        RegularBike hondaRegularBike = (RegularBike)honda.CreateSingleVehicle("Regular"); //2
        SportsBike hondaSportsBike = (SportsBike)honda.CreateSingleVehicle("Sports");
        Console.WriteLine("******* Honda **********"+hondaRegularBike.VehicleName+ hondaSportsBike.VehicleName);

        IVehicleFactory hero = new HeroFactory();
        DarkHorseBike heroDarkHorseBike = (DarkHorseBike)hero.CreateSingleVehicle("DarkHorse");
        SportsBike heroSportsBike = (SportsBike)hero.CreateSingleVehicle("Sports");
        Scooty heroScooty = (Scooty)hero.CreateSingleVehicle("Scooty");
        Console.WriteLine("******* Hero **********"+heroDarkHorseBike.VehicleName + heroScooty.VehicleName+ heroSportsBike.VehicleName);

        Console.ReadKey();
    }
}

Puntos importantes: 1. Requisito: Honda crearía "Regular", "Deportes" pero Hero crearía "DarkHorse", "Deportes"y " Scooty". 2. ¿por qué dos interfaces? Uno para el tipo del fabricante (IVehicleFactory) y otro para la fábrica del producto(IVehicle); otra manera de entender 2 interfaces es fábrica abstracta es todo sobre la creación de objetos relacionados 2. La captura es el IVehicleFactory de los hijos que regresan y IVehicle (en lugar de hormigón en la fábrica); así que tengo padres variable (IVehicle); luego creo el tipo concreto real llamando a CreateSingleVehicle y luego fundiendo el objeto padre al objeto hijo real. Qué pasaría si lo hago RegularBike heroRegularBike = (RegularBike)hero.CreateSingleVehicle("Regular");; obtendrás ApplicationException y es por eso que necesitamos generic abstract factory que explicaría si es necesario. Espero que ayude desde el principiante hasta el público intermedio.

Ejemplo de la Vida Real. (Fácil de recordar)

Fábrica

Imagina que estás construyendo una casa y te acercas a un carpintero por una puerta. Usted da la medida para la puerta y sus requisitos, y él construirá una puerta para usted. En este caso, el carpintero es una fábrica de puertas. Sus especificaciones son entradas para la fábrica, y la puerta es la salida o el producto de la fábrica.

Abstract Factory

Ahora, consideremos el mismo ejemplo de la puerta. Puedes vaya a un carpintero, o puede ir a una tienda de puertas de plástico o una tienda de PVC. Todas son fábricas de puertas. En función de la situación, usted decide a qué tipo de fábrica debe acercarse. Esto es como una Fábrica Abstracta.

He explicado aquí tanto el patrón del método de fábrica como el patrón abstracto de fábrica comenzando con no usarlos explicando problemas y luego resolviendo problemas usando los patrones anteriores https://github.com/vikramnagineni/Design-Patterns/tree/master

Yo favorecería la Fábrica Abstracta sobre el Método de Fábrica en cualquier momento. Del ejemplo de Tom Dalling (gran explicación por cierto) anterior, podemos ver que Abstract Factory es más componible en que todo lo que necesitamos hacer es pasar una Fábrica diferente al constructor (inyección de dependencia del constructor en uso aquí). Pero el método Factory requiere que introduzcamos una nueva clase (más cosas que administrar) y usemos subclases. Siempre prefiera la composición sobre la herencia.

Permítanme decirlo con precisión. la mayoría de las respuestas ya se han explicado, proporcionado diagramas y ejemplos también. así que mi anwer sería sólo un trazador de líneas. my own words: - "abstract factory pattern agrega en la capa abstracta sobre múltiples implementaciones de métodos de fábrica. significa fábrica abstracta contiene o compuesto uno o más de un método de fábrica patrones "

Muchas de las respuestas anteriores no proporcionan comparaciones de código entre Fábrica abstracta y Patrón de Método de Fábrica. Lo que sigue es mi intento de explicarlo a través de Java. Espero que ayude a alguien que necesita una explicación simple.

Como dice acertadamente GoF: Abstract Factory proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.

        public class Client {
            public static void main(String[] args) {
               ZooFactory zooFactory = new HerbivoreZooFactory();       
               Animal animal1 = zooFactory.animal1();
               Animal animal2 = zooFactory.animal2();
               animal1.sound();
               animal2.sound();

               System.out.println();

               AnimalFactory animalFactory = new CowAnimalFactory();
               Animal animal = animalFactory.createAnimal();
               animal.sound();
            }
        }

        public interface Animal {
            public void sound();
        }

        public class Cow implements Animal {

            @Override
            public void sound() {
                System.out.println("Cow moos");
            }

        }

        public class Deer implements Animal {

            @Override
            public void sound() {
                System.out.println("Deer grunts");
            }

        }

        public class Hyena implements Animal {

            @Override
            public void sound() {
                System.out.println("Hyena.java");
            }

        }

        public class Lion implements Animal {

            @Override
            public void sound() {
                System.out.println("Lion roars");
            }

        }

        public interface ZooFactory {
            Animal animal1();

            Animal animal2();
        }

        public class CarnivoreZooFactory implements ZooFactory {

            @Override
            public Animal animal1() {
                return new Lion();
            }

            @Override
            public Animal animal2() {
                return new Hyena();
            }

        }

        public class HerbivoreZooFactory implements ZooFactory{

            @Override
            public Animal animal1() {
                return new Cow();
            }

            @Override
            public Animal animal2() {
                return new Deer();
            }

        }

        public interface AnimalFactory {
            public Animal createAnimal();
        }

        public class CowAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Cow();
            }

        }

        public class DeerAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Deer();
            }

        }

        public class HyenaAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Hyena();
            }

        }

        public class LionAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Lion();
            }

        }