Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Abstract factory pattern on top of IoC?

People also ask

Is IoC a Factory Pattern?

The conclusion that i have come up with is that an IoC container is an architectural pattern, not a design pattern. In other words, no class should be aware of its presence and the container itself should be used at the application layer to stitch up all components.

When should we use Abstract Factory pattern?

When to Use Abstract Factory Pattern: The client is independent of how we create and compose the objects in the system. The system consists of multiple families of objects, and these families are designed to be used together. We need a run-time value to construct a particular dependency.

Does Abstract Factory pattern has multiple factory implementation?

Java. The main difference between a “factory method” and an “abstract factory” is that the factory method is a single method, and an abstract factory is an object. The factory method is just a method, it can be overridden in a subclass, whereas the abstract factory is an object that has multiple factory methods on it.

What problem does Abstract Factory pattern solve?

The Abstract Factory design pattern solves problems like: How can an application be independent of how its objects are created? How can a class be independent of how the objects it requires are created? How can families of related or dependent objects be created?


As you have already figured out, Dependency Injection (DI) itself is only a collection of patterns and techniques.

At the root of the application we wire up all necessary object graphs. This place is called the Composition Root, and we can use a DI Container to do this wiring for us, or we can do it manually (Pure DI).

The point is that there's only one place in your application where there's a strong reference to a particular piece of technology (your DI Container). The rest of the app is blissfully unaware of how the object graph was wired up - all that matters is that all required dependencies were correctly injected (and you can use Constructor Injection with Null Guards to guarantee that this is so).

The Abstract Factory pattern is a very useful pattern when it comes to DI. In essence, use Abstract Factory when:

  • You need to supply one or more parameters only known at run-time before you can resolve a dependency.
  • The lifetime of the dependency is conceptually shorter than the lifetime of the consumer.

Examples and more information is available here:

  • Is there a pattern for initializing objects created via a DI container
  • Can't combine Factory / DI
  • Which DI container will satisfy this
  • Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
  • Design - Where should objects be registered when using Windsor

Well at the top most part of your application you will need a Bootstrap class that loads the IOC context. This context then will provide the actually instantiated objects and therefore acts as a factory.

But this should only happen with very few objects and the user of your Bootstrap/Factory class should know as little about the underlying architecture as possible. For example if you configured a HTTP server object completely via IOC and you want to start it your Bootstrap class only needs to provide a getHttpServer() method. Then your programs main method only needs to call Bootstrap.getHttpServer().start() to get it running.

The wiring of your other objects has already been done by the application context e.g. you configure Object A via IOC which is part of Object B so you configure Object B with the reference to Object A. None of them usually need to know neither about the container nor the factory.