Abstract Factory design pattern to create objects? Why can’t we just use the new operator?

Question

why do we need a Abstract Factory design pattern to create objects? Why can’t we just use the new operator? answer is, to avoid tight coupleing of the objects. But I didn't understand how ? can anyone explain with code (will be very useful).

what makes abstract factory design pattern useful and when.

Thanks in advance. Harsha T

Answer 1

If you use the new operator, you have to specify which exact type you want. Sometimes you want to be more generic, for example because you want to be able to change that instantiated type in all the codebase quickly.

Answer 2

Here you'll find a good explanation with examples:

• Abstract Factory Design Pattern

Answer 3

An abstract factory design pattern is designed to create an object with a specific setup at initialization time. For example if you have a lot of similarly connected classes, rather than repeating the same 4+ lines [and using copying and pasting], the abstract factory would allow for you to keep the 4+ lines in a single location and reduce the amount of changes needed.

Reference For Abstract Factory

Answer 4

There's a rather good C# example on Wikipedia. It keeps your application-level code from having to know which implementations it's getting. The factory takes care of it.

Answer 5

Using an abstract factory, you can create objects without knowledge of the actual type. Let's say you need a IDictionary. You could either create a new instance of a binary-tree-class that you happen to know, or you could tell the IDictionary-factory that you need a new instance. Then someone else could create a factory implementation that returns hash-tables, but everything on your side will still work the same way.

Answer 6

• first of all you don't need to know the specific type of object your factory is instantiating,
• then you can plug your factory classes around your project letting them instantiating objects for your components without having to use new in your code. The factory already do its dirty work
• it conceptually separates the instantiation of object from their usage, keeping things decoupled

Answer 7

Here's a simple example derived from a version independence layer I built for our product:

interface ICadSystemFactory
{
    ICadSystem GetSystemInstance();
}

class 3dCadSystemVersion1 : ICadSystemFactory
{
    ICadSystem GetSystemInstance()
    {
        return new 3dCadSystemWrapperVersion1(new 3dCadSystemVersion1());
    }
}



class 3dCadSystemVersion2 : ICadSystemFactory
{
    ICadSystem GetSystemInstance()
    {
        return new 3dCadSystemWrapperVersion2(new 3dCadSystemVersion2());
    }
}

Where the 3dCadSystemWrapperVersionX objects implement the ICadSystem interface. I use a Registry object to decide what base factory I want to create based on certain version identifiers. This allows me to plug in new versions as needed without disturbing the existing infrastructure, which turns out to be useful in this case. It would, in fact, allow me to plug in whole new products if I needed to, which could generally be useful but in my case isn't worth the implementation effort.

Answer 8

If you have :

class Foo implements DoSomething {...}
class Bar implements DoSomething {...}

obj = new Foo();
obj.doSomething();

Everywhere in your code, once you want to change all instances of Foo to use instances of Bar, are you really going to do search/replace ?

---

If you have :

obj = DoSomethingFactory.create();
obj.doSomething();

Inside the DoSomethingFactory, you can return any object you want that implements the DoSomething interface.

By using a Factory, you have the control over all the objects that are created by it.

If you decide to change the way the Factory creates objects, the changes take effect immediately in the code that uses the Factory.