+91 20 24210201/301 info@genex.co.in

Factory Design Pattern

Factory Design pattern is based on Encapsulation object oriented concept. Factory method is used to create different object from factory often refereed as Item and it encapsulate the creation code. So instead of having object creation code on client side we encapsulate inside Factory method.

Factory design pattern is used to create objects and it provides loose coupling and high cohesion. Factory pattern encapsulate object creation logic which makes it easy to change it later when you change how object gets created or you can even introduce new object with just change in one class. In GOF pattern list Factory pattern is listed as Creation design pattern. Factory should be an interface and clients first either creates factory or get factory which later used to create objects.

Problem which is solved by Factory method Pattern:
Whenever we talk about object oriented language it will based upon some concept like abstraction, polymorphism etc. and on that encapsulation and delegation are important concept any design will be called good if task are delegated to different object and some kind of encapsulation is there.

Sometime our application or framework will not know that what kind of object it has to create at run-time it knows only the interface or abstract class and as we know we cannot create object of interface or abstract class so main problem is frame work knows when it has to create but don’t know what kind of object.

Whenever we create object using new() we violate principle of programming for interface rather than implementation which eventually result in inflexible code and difficult to change in maintenance. By using Factory design pattern we get rid of this problem.

Another problem we can face is class needs to contain objects of other classes or class hierarchies within it; this can be very easily achieved by just using the new keyword and the class constructor. The problem with this approach is that it is a very hard coded approach to create objects as this creates dependency between the two classes.

So factory pattern solve this problem very easily by model an interface for creating an object which at creation time can let its subclasses decide which class to instantiate, Factory Pattern promotes loose coupling by eliminating the need to bind application-specific classes into the code. The factory methods are typically implemented as virtual methods, so this pattern is also referred to as the “Virtual Constructor”. These methods create the objects of the products or target classes.

When to use Factory design pattern:

  • Static Factory methods are common in frameworks where library code needs to create objects of types which may be sub classed by applications using the framework. 
  • Some or all concrete products can be created in multiple ways, or we want to leave open the option that in the future there may be new ways to create the concrete product.
  • Factory method is used when Products don’t need to know how they are created.
  • We can use factory pattern where we have to create an object of any one of sub-classes depending on the data provided. 

    Advantage of Factory method Pattern:
  • Factory method design pattern decouples the calling class from the target class, which result in less coupled and highly cohesive code?
  • Factory pattern enables the subclasses to provide extended version of an object, because creating an object inside factory is more flexible than creating an object directly in the client. Since client is working on interface level any time you can enhance the implementation and return from Factory.
  • Another benefit of using Factory design pattern is that it encourages consistency in Code since every time object is created using Factory rather than using different constructor at different client side.
  • Code written using Factory design pattern is also easy to debug and troubleshoot because you have a centralized method for object creation and every client is getting object from same place.
Example (C#):

using System;
class Program
{
    abstract class Position
    {
public abstract string Title { get; }
    }
 
    class Manager : Position
    {
public override string Title
{
   get
   {
return "Manager";
   }
}
    }
 
    class Clerk : Position
    {
public override string Title
{
   get
   {
return "Clerk";
   }
}
    }
 
    class Programmer : Position
    {
public override string Title
{
   get
   {
return "Programmer";
   }
}
    }
 
    static class Factory
    {
///
/// Decides which class to instantiate.
///
public static Position Get(int id)
{
   switch (id)
   {
case 0:
   return new Manager();
case 1:
case 2:
   return new Clerk();
case 3:
default:
   return new Programmer();
   }
}
    }
 
    static void Main()
    {
for (int i = 0; i <= 3; i++)
{
   var position = Factory.Get(i);
   Console.WriteLine("Where id = {0}, position = {1} ", i, position.Title);
}
    }
}
 

Read More

.NET Framework 4 vs .NET Framework 4 Client Profile

In .NET Framework 4 we have introduced a streamlined subset and more compact version of the .NET Framework called the Microsoft .NET Framework 4 Client Profile (aka NET4 Client Profile). The Microsoft .NET Framework 4 which is the Full Framework (aka NET4 Full) still exists and it is a superset of the Client Profile.

What are the reasons for a Client Profile?

Although the NET4 Client Profile is smaller and faster to install compared to the NET4 Full Framework (NET4 is 7-8MB smaller in size than the Full Framework), the main reasons are not just better deployment size/time but also:

  • Reduce the Framework deployment failures.
  • By keeping ASP.Net and other components (that are mostly needed for servers) out of the Client Profile, we can reduce the attack surface and the number of future servicing events which may be caused by server component (such as ASP.Net) and are not needed for desktop scenarios.
  • Making NET4 Client Profile available on Windows Update will make sure that most desktop machines will include NET4 Client Profile over time and apps that target the Client Profile will not need to carry or install the Framework which will improve the overall deployment experience.
  • Enable us to add features and grow the size of overall Framework in future versions but still have a smaller core.
When to use NET4 Client Profile and when to use NET4 Full Framework?

NET4 Client Profile:

Always target NET4 Client Profile for all your client desktop applications (including Windows Forms and WPF apps).

NET4 Full framework:
Target NET4 Full only if the features or assemblies that your app need are not included in the Client Profile. This includes:
  • If you are building Server apps. Such as:
    1) ASP.Net apps
    2) Server-side ASMX based web services
  • If you use legacy client scenarios. Such as:
    1) Use System.Data.OracleClient.dll which is deprecated in NET4 and not included in the Client Profile.
    2) Use legacy Windows Workflow Foundation 3.0 or 3.5 (WF3.0 , WF3.5)
  • If you targeting developer scenarios and need tool such as MSBuild or need access to design assemblies such as System.Design.dll

    Reference Links:
    1) http://blogs.msdn.com/b/jgoldb/archive/2010/04/12/what-s-new-in-net-framework-4-client-profile-rtm.aspx
     

Read More