Simple Factory C

[Glauco Schlembach]

Factoryis an ambiguous term that stands for a function, method or class that supposed to be producing something. Most commonly, factories produce objects. But they may also produce files, records in databases, etc.

In reality, the creation method is just a wrapper around a constructor call. It may just have a name that better expresses your intentions. On the other hand, it may help to isolate your code from changes to the constructor. It could even contain some particular logic that would return existing objects instead of creating new.

You have to have several different constructors that have different purposes but their signatures match. For instance, having both Random(int max) and Random(int min) is impossible in Java, C++, C#, and many other languages. And the most popular workaround is to create several static methods that call the default constructor and set appropriate values afterward.

You want to reuse existing objects, instead of instancing new ones (see, the Singleton pattern). Constructors in most programming languages have to return new class instances. The static creation method is a workaround to this limitation. Inside a static method, your code can decide whether to create a fresh instance by calling the constructor or return an existing object from some cache.

The Simple factory pattern Defined in the book Head First Design Patterns. describes a class that has one creation method with a large conditional that based on method parameters chooses which product class to instantiate and then return.

People usually confuse simple factories with a general factories or with one of the creational design patterns. In most cases, a simple factory is an intermediate step of introducing Factory Method or Abstract Factory patterns.

A simple factory is usually represented by a single method in a single class. Over time, this method might become too big, so you may decide to extract parts of the method to subclasses. Once you do it several times, you might discover that the whole thing turned into the classic factory method pattern.

The Factory Method Defined in GoF book Design Patterns: Elements of Reusable Object-Oriented Software. is a creational design pattern that provides an interface for creating objects but allows subclasses to alter the type of an object that will be created.

The Abstract Factory Also defined in the GoF book. is a creational design pattern that allows producing families of related or dependent objects without specifying their concrete classes.

In this article series, we will learn about different factory design patterns. There are three kinds of factory design patterns, namely, Simple Factory Pattern, Factory Method Pattern and Abstract Factory Pattern. We will understand these three patterns in detail by learning how to implement, when to implement and subsequently we will understand the differences between those. Simple Factory Pattern is not a part of Gang of Four (GoF) book but Factory Method Pattern and Abstract Factory Patterns are part of this standard book.

In other words, we can say that Design Pattern provides proven solution to solve commonly occurring problems in software (generally big) applications. Implementation of a particular design pattern in any application increases flexibility, maintainability and readability of the application. Before implementing any design pattern in the application, first we should be clear about the problem that can be solved by a particular design pattern.

The first and most important part while working with Design Patterns is to understand the context and exact issue in application. Once the problem is identified, then it is easy to figure out which Design Pattern should be used to solve indentified problem.

According to definition from wikipedia, Factory Pattern is "A factory is an object for creating other objects". Simple Factory Pattern is a Factory class in its simplest form (In comparison to Factory Method Pattern or Abstract Factory Pattern). In another way, we can say: In simple factory pattern, we have a factory class which has a method that returns different types of object based on given input.

To understand Simple Factory Pattern practically, we take an example of Electrical Company which makes different kinds of fans, we will call it FanFactory. But first, we will implement this scenario without using Simple Factory Pattern, then will see the problems and how those can be solved with this Pattern.

The below program is a simple console application, in this program, Main method is used as client which creates a TableFan. In simplest implementation, we can see that the client is able to create a TableFan directly as per need (without any factory).

In the above example, we did not use any pattern and the application is working fine. But if we think about future possible changes and look closely, we can foresee the following problems with the current implementation:

To come out with the above problems, we can use Simple Factory Pattern because this pattern is suitable to solve the above mentioned problems. Further, we will continue with the same example and will modify the existing code.

When we implement Simple Factory Pattern, a class needs to be created which will have method to return requested instance of an object. Let's create a class called "FanFactory" which will implement an interface called "IFanFactory". This interface has a method called IFan CreateFan(FanType type); which takes enum FanType and returns respective instance of a Fan.

Now Client will not be aware about the concrete classes like TableFan or CeilingFan. Client will be using FanType enum and IFan interface. Based on passed enum as argument while calling "CreateFan" method, FanFactory will return the instance of desired fan. Following is the modified code of application:

In this article, we had a walkthrough to learn Simple Factory Pattern and its use. We understood the context of Simple Factory Pattern and how to use it to enhance maintainability of application. But it violates the Open Close Principle, so in the next article , we will see how we can have better design with Factory Method Pattern. Thanks for reading! Your comments and suggestions for improvement are most welcome.

Im trying to learn patterns and got to Factory, I understand the concept of simple factory and factory method, I know how they work, what I cant understand is what is the benefit of factory method over the simple factory. Example:

So here comes the interesting part, for the factory method we will need to use polymorphism but we will still need to instantiate depending on what type we need so I imagine we will have something like this:

So as far as I know the main idea behing design patterns is to make code more reusable and easier to extend, so imagine we need to add a new animal, say a Parrot. In both cases we create the Parrot class that extends the Animal class and in both cases we will have to go into that switch statement and add a new case "Parrot" For the simple factory we will just instantiate new Parrot directly and for the factory method we will instantiate the ParrotFactory.My question is what is the difference and why do we need the factory method pattern?

The easiest way to think about why this factory subclassing relationship would make sense is to imagine the parent Factory as part of a framework. The framework must be compatible with any Product implementation, and it expects each client to define its own concrete product. These concrete products probably don't exist at the time the framework is written.

When the Client plugs itself into the framework (via inheritance) it defines a ConcreteProduct for the framework to use. In contrast to previous answers, this has nothing to do with encapsulating creational complexity. Indeed, the factory method implementation is one line of code.

Defer is the key. Factory Method allows you to implement an API in terms of an unknown product. Inheritance is the vehicle it uses to do that. Simple Factory was published (later) in Head First Design, as a teaching aid, not really intended for production code.

Confusion arises from the assumption that a factory method must be parameterized. This assumption leads to the conclusion that the purpose of a factory is to allow clients to pick and choose amongst multiple product implementations at runtime. Note the factoryMethod() here takes no parameters.

To understand the Factory Method Pattern, consider the scenario in which there is only one concrete product, it simply doesn't exist at the time the factory method API is defined, and isn't owned by the author of the API.

the benefit is it encapsulates the logic to create dogs for example. Any modification about creational of dog only happens on DogFactory (Single Responsibility). It's a good choice when you're going to do any setup about the object, like there are any codes before you return the dog object. If you do it on simple factory it would be messed up and make the method longer. But since on your example it's only do a simple new Dog() or new Cat() I prefer simple factory. IMHO

The benefit of a Factory method is, typically, to contain the logic for a complex class (or class-hierarchy setup you require) that you don't want to obfuscate code or you don't want to create from scratch if they're used frequently. Eg. a car engine. So you extract away the messy code into a Factory to make the class-hierarchy more accessible/more reusable and to make the rest of your code more readable by hiding complex detail.

You could turn a simple factory into something that implements the factory method design pattern. Let's take your simple factory as an example. If I turn that into a class of its own, it would look something like this (I'm using PHP but syntax should be pretty easy to understand)

The Factory Method pattern takes advantage of polymorphism to allow subclasses to specify how/what concrete types of Animals to return. This means that instead of client code using the SimpleFactory directly, it would instead rely on abstraction instead. You can create something like an interface that your SimpleFactory would implement

3a8082e126