Dependency Injection

RAVAGE

After several years of familiarization of the concepts of Dependency Injection (DI) and Inversion of control (IOC), I just came to know about the existence of those concepts. Thanks to Silverlight, PRISM (CAL) and MEF which made me explore the concepts DI and IOC.

Anybody who wants to write an article or explore in depth about Dependency Injection  will never fail to read Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, for which I'm no exception.

Inversion Of Control

To understand from the name, its inverting the control of creation. Let's take the case of using the framework in an application, the framework takes the responsibility of creating objects/elements and the application will be hooked up with the created object as and when needed. Fowler states this with the example of UI framework and the application/program where the UI framework holds the responsibility of creating the graphical elements and the application instead creates the event handlers for those fields/graphical elements.

Dependency Injection

Think of a scenario class A uses class B which means class A depends on class B. In order to make use of class B in class A,  usually what we do is we'll write code to instantiate class B in class A. While instantiating class B, we need to pass the values that class B expects, to be clear, we need to satisfy the dependencies of class B. Say if class B expects and depends on class C, then in class A we need to instantiate class C first and then pass it to class B. Also we need to make sure that we should satisfy the dependencies of class C if any.

Ok, now think of changing the instantiating structure of the dependency object. For that we need to change the code in all the areas where it got used. In our example if class c changes its expectation(expects different parameter), we need to change the source code in class A.

There are situations that we don't know the concrete implementation at the time of writing the code or during compile time for various reasons - like we may need the code developed to be reused and the concrete implementation will be known sometime later.

In the above mentioned cases/paragraphs, just the scenarios are mentioned and the intentions are incomplete. Are there any solution for this? If so what is it? How to handle this? Dependency Injection is one solution to handle that.

Dependency Injection Types

• Constructor injection
• Setter injection
• Interface injection

Constructor injection and setter injection are commonly used injection techniques.

As you guess for constructor injection, we need to specify the dependencies as the parameter for the constructor of the class which requires it. Since we're trying to get rid of the concrete implementation, we need to specify the type (interface) of the dependency which it confirms to.

For setter injection, dependencies are exposed as properties which will be set during the instantiation process.

Ok, who'll hold the responsibility of creating, managing and injecting these dependencies? Builder object or containers will do that for you.

Containers

Containers - Are these containers new to .Net based applications? As quoted in msdn CLR itself is a container. If you think it is more generic, let's take the case of asp.net web applications, where there are times that we've used a common base class for handling security, authentication, common functionalities, etc. These base classes can also be considered as a form of container.

Since the containers will create, manage and inject objects, it avoids tight coupling of objects with its dependencies. Containers acts as a repository or lookup manager that maintains instances. We need to map or configure the containers which instances need to be used on which context. Containers also takes additional responsibilities like managing the lifetime of the objects, so that it supplies singleton or new instances upon requests.

Microsoft patterns and practices provides a lightweight extensible container called Unity Application Block. Prism which is used to create modular WPF or Silverlight applications usually uses this Unity Application Block as container.

SUMMARY

Basically Dependency Injection containers decouples the classes from its dependencies and also the responsibility of managing the dependencies. The issues that we face with DI is it's hard to track while debugging. Also we need to make sure that the container has the ability to resolve the dependency where its required. Previously I've specified in this article that dependency injection is one solution. Other solution generally proposed for this scenario is Service Locator.

REFERENCE

http://martinfowler.com/articles/injection.html
http://msdn.microsoft.com/en-us/library/ff649378.aspx
http://msdn.microsoft.com/en-us/library/aa973811.aspx
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
http://tutorials.jenkov.com/dependency-injection/when-to-use-dependency-injection.html

Factory Method - Pattern

INTRO

Factory pattern - Here comes the most commonly quoted pattern Factory method (next to Singleton Pattern). Factory method is frequntly used in lot of real time scenarios especially in the framework libraries. While developing a reusable library which contains core/base implementation, there are times where we need to work with or maintain the relationship between objects which will be created later during the implentation of those libraries. I've discussed one such case below under the Implementation in .Net.

Ultimate aim is to create a Product object and work on it which will be available some time later (as specified above). The name Factory resembles the real-world factory since it holds the responsibility of creating the objects (Products). Simply speaking the Client uses the Factory method to create a specific type of Product.

PLOT

Creator is the one who provides the interface for creating an object by holding the Factory method with him.
Factory method in the Creator returns a specific type of object Product.
Creator delegates the responsibility of "which class to be instantiated" to its subclass ConcreteCreator.
ConcreteCreator overrides the Factory method and it is responsible for creating the ConcreteProduct that adheres to the Product type. 

 GOF STRUCTURE

IMPLEMENTATION IN .NET

IEnumerable interface in .Net exposes a Factory method GetEnumerator(). The collection classes in .Net implements this IEnumerable interface to incur enumerator for a collection. Since foreach statement evaluates the type that implements IEnumerable, most of the collection classes will make use of this IEnumerable. ArrayList, HashTable, List,Dictionary are some of the examples.

IEnumerable needs to work on object of type IEnumerator, for iterating over the collection. Object of type IEnumerator knows how to iterate over the collection object of type IEnumerable.

ArrayList implements the IEnumerable and overrides the GetEnumerator method to create the object of ArrayListEnumeratorSimple which implements the IEnumerator.

Participants mapping

Creator : IEnumerable
ConcreteCreator : ArrayList
ConcreteProduct : ArrayListEnumeratorSimple
Product : IEnumerator

SUMMARY

I've just focussed on the case of delegating the responsibility of creating the instances to the subclass. There are also cases where the factory method in the ConcreteCreator defines the default instantiation and parameterized Factory methods used to identify and create specific ConcreteProduct.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://msdn.microsoft.com/en-us/magazine/cc188707.aspx#S5
http://ondotnet.com/pub/a/dotnet/2003/08/11/factorypattern.html
http://msdn.microsoft.com/en-us/library/ee817667.aspx

Builder Pattern

Builder Pattern

RAVAGE

I had a good discussion over the Builder pattern with my friend. Always he tries to map the pattern with a real case scenario and alters the example so as to fit it. So the problem is while discussing with him we need to think more than once before answering him. Also the important part I like with his discussion is that he tries to map the pattern as a pluggable element. That is he tries to identify the extensible part (reusable part for specific abstraction or mode) in order to scale-up the implementation. Actually that extensible part will be the core use of the pattern.

PLOT

A Product that need to be built step by step plays one of core role of this pattern. The ConcreteBuilder holds the functionalities for creating each part and accumulate them into a specific Product. The AbstractBuilder should provide common behaviors that supports different ConcreteBuilders. Director is the one who constructs the Product with the help of the operations specified by the Builder.
In the GOF structure client is not specified explicitly but the client plays an important role which specifies how the internal relationship will be executed. Client takes the responsibility for selecting the particular ConcreteBuilder and sends it to the Director. So the Client knows the ConcreteBuilder, Product and the Director.

GOF STRUCTURE

Please view the GOF structure in dofactory.

MATCHING SCENARIO

To understand simply we can take the common House example specified for this pattern. House is the product that we need to build. The ConcreteBuilder holds the operation for creating part of the object. One such operation is the method for creating room (CreateRoom()). As you know the AbstractBuilder holds the abstract description (simply abstract CreateRoom() here) that mimics the ConcreteBuilder. Now comes the Director which actually constructs the object for House using the AbstractBuilder. Let us consider the Director is going to create 2 bedroom flat, then it calls the CreateRoom() method in the AbstractBuilder (builder.CreateRoom()) twice.
Ok now we concentrate on how this will be implemented. As specified earlier, Client creates an instance for the specific ConcreteBuilder. Usually that ConcreteBuilder instance will be passed as an argument to the method call to the Director which holds the construction process.

EXTENSIONS

It is clear that Client is the one who decides which ConcreteBuilder need to be called. Hence the Client obviously knows which Product will get created. So he calls the construction operation in the Director passing the ConcreteBuilder instance.
Here comes the rival. My friend wants to explain the extension of this pattern by specifying an additional point in the above scenario. In our scenario we discussed about a 2 bedroom flat. He meant to extend it with 3 bedroom flat.
I just tried to extend with builder pattern but then inferred that the 3 bedroom scenario (in addition to 2 bedroom) partially won't suit the intent.
Actually as per the Intent specified by GOF for Builder pattern, the construction of complex object need to be separated from its representation so that the same construction process can be used for different representations. In our case the construction process is meant for a 2 bedroom flat and so in order to extend that, we need to identify a scenario that fits the different representation for the same 2 bed room construction. Hence we decided to go with two different representations of the 2 bedroom flat,
1) ordinary flat - whose CreateRoom() will create wall of thickness 200mm with ceiling height 10ft 2) secured flat - whose CreateRoom() will create wall of thickness 500mm with ceiling height 16ft.
For this we simply need to add a new ConcreteBuilder for the secured flat which uses the same AbstractBuilder as before.
Fine, now let us shift our focus to the 3 bedroom flat. Whether this can't be done with builder pattern? Not like that, it can be. So only previously in this post I specified it as "partially won't suit". Just introduce a separate construction process in the Director for the 3 bedroom flat (CreateRoom() need to be called 3 times). Since the Client is the one who is going to call the Director and also he has the knowledge on ConcreteBuilder and the Product, he'll take care of it and have control over it.

SUMMARY

• Need to identify the parts for building the complex object and ConcreteBuilder should provide the basic operations for creating parts for a specific Product. 
• AbstractBuilder should be common so as to accommodate different ConcreteBuilders.
• Director will construct the object by calling the basic operations for creating the parts.
• Client will decide which ConcreteBuilder instance to be used and pass it as parameter to the operation in the Director. Also Client have the knowledge of which Product to be created.

REFERENCE

For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software
http://www.dofactory.com/Patterns/PatternBuilder.aspx

Abstract Factory Pattern

Abstract Factory Pattern

PLOT
Available are products AbstractProductA, AbstractProductB,….
 Each of the products encompasses different varieties such as ProductA1, ProductA2… for AbstractProductA and ProductB1, ProductB2… for AbstractProductB. These ProductA1, ProductA2 are referred to as related items.


AbstractFactory simply ensures the creation of products. ConcreteFactory decides which type of product instance need to be created. That is ConcreteFactory1 creates ProductA1 and ProductB1, similarly ConcreteFactory2 creates ProductA2 and ProductB2.


So the core is the client creates an instance of the ConcreteFactory (i.e., ConcreteFactory1 / ConcreteFactory2) which is responsible for the creation of product object from the related varieties of Products.


Thus the client is independent of the product got created. Also note that the Concrete subclass (ConcreteProduct) for the Product is not specified.

GOF STRUCTURE

IMPLEMENTATION IN .NET
While exploring about this pattern, though I understood the concepts clearly with some good examples, I expected a better scenario to stick determined on this pattern. At that time I came across an article that describes Abstract Factory with ADO.Net 2.0.
Namespace: System.Data.Common

Participants mapping
AbstractFactory : DbProviderFactory
ConcreteFactory : SqlClientFactory, OracleClientFactory, OleDbFactory,...
AbstractProduct : DbConnection, DbCommand, DbParameter,...
ConcreteProduct : SqlConnection, OracleConnection, SqlCommand,...

Snippet

    1     Dim factory As DbProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient")

    2     Dim connection As DbConnection = Nothing

    3 

    4     connection = factory.CreateConnection()

Line 1 - Creates an instance for SqlClientFactory (ConcreteFactory) for "factory" object. Factory pattern is made use over there which we will discuss later.
Line 2 - Defines "connection" as DbConnection (AbstractProduct).
Line 4 - factory.CreateConnection() returns a new instance SqlConnection{System.Data.SqlClient.SqlConnection} for the specific provider SqlClient.

SUMMARY
Simply without specifying the ConcreteProduct - SqlConnection, the instance got created.

REFERENCE
For references and more info:
Design Patterns: Elements of Reusable Object-Oriented Software

Design Pattern

All my posts related to design pattern will follow the GOF ideologies. I'm just going to make a note on the things that got raised during my observation and discussion. Also here I want to make note of the scenarios specified in the sites other than GOF. I'm not going to explain the patterns as most of the things will seem to be the replica as described by the GOF.
To be aware of Design Patterns, I tried lot of articles / books though I'm aware of GOF. As I'm passionate about C#, I tried to read books / Articles that explains well about the GOF patterns with C#. DoFactory site fulfilled that partially. But later one of my friend strongly argued with me and presented me with the native GOF "Design Patterns - Elements of Reusable Object-Oriented Software" book and asked me to get into that.
Really that helps me a lot and the approach of the book wins. Each and every pattern is explained by means of:

• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

 

The key items that describes the core ideology of the pattern are the Intent and Structure. Motivation is specified before the Structure which will help us to understand the Structure.

Finally I agree with my friend that to understand about the GOF Design Patterns, definitely we should first need to go through "Design Patterns - Elements of Reusable Object-Oriented Software". Then we can refer other books, articles or blogs in order to fine-tune the knowledge we acquired and to become strong in that.

To terminate the console application

To terminate the console application from the code, we can use

• Environment.Exit
• Process.Kill

Response.Redirect inside Try Catch block throws ThreadAbortException

Making use of the Response.Redirect inside the Try / Catch block, always throws ThreadAbortException.

As a workaround we can try using Response.Redirect(URL, False) in such cases (during unavoidable situations).