Working with Abstract Factory Pattern

Hello friends.

Today I am here to go though another variant of Factory design pattern called Abstract Factory. 

In case, you have not had a look at my previous article about Factory pattern, I would suggest you to look for them in ARCHIVES section.

Before talking about its implementation let’s try to understand the purpose of the abstract factory pattern

Abstract factory pattern is next level to Factory Method pattern where we define related factories or families of classes.

To understand this properly, let’s take the same example we took when going through Simple Factory pattern.

In Factory Method pattern, we managed all the car brands with one interface. Now let’s assume consumer or client of the car wants next level of categorization by picking any car brand. Then how will you manage?

Here comes the Abstract Factory. It creates family of classes or related factories to address the need.

Enough theory. Now let’s talk about implementation.

How to use Abstract Factory Pattern?

Let’s try to understand using simple example.

Suppose client wants to know the car details of different kinds of brands. Car detail here is about knowing economy and premium models for any brand. For that we need to define the abstract product interface as in the following.

  • interface IEconomy  
  • {  
  •     string ShowEconomy();  
  • }  
  • interface IPremium  
  • {  
  •     string ShowPremium();  
  • }  

Now since we need to show the car details by brand, we need to create concrete product classes using the interface defined above.

  • class Alto: IEconomy  
  • {  
  •     public string ShowEconomy()  
  •     {  
  •         return “Alto”;  
  •     }  
  • }  
  • class SCross: IPremium  
  • {  
  •     public string ShowPremium()  
  •     {  
  •         return “S-Cross”;  
  •     }  
  • }  
  • class Eon: IEconomy  
  • {  
  •     public string ShowEconomy()  
  •     {  
  •         return “Eon”;  
  •     }  
  • }  
  • class Elantra: IPremium  
  • {  
  •     public string ShowPremium()  
  •     {  
  •         return “Elantra”;  
  •     }  
  • }  

Now we need to define an abstract factory interface, which can accommodate the abstract product interfaces created to define car details as in the following:

  • interface ICarFactory  
  • {  
  •    IEconomy GetEconomy();  
  •    IPremium GetPremium();  
  • }  

Now the time has come to create the concrete family of classes to support different brands, of course by implementing the ICarFactory.

  • class MarutiFactory: ICarFactory  
  • {  
  •     public IEconomy GetEconomy()  
  •     {  
  •         return new Alto();  
  •     }  
  •     public IPremium GetPremium()  
  •     {  
  •         return new SCross();  
  •     }  
  • }  
  • class HyundaiFactory: ICarFactory  
  • {  
  •     public IEconomy GetEconomy()  
  •     {  
  •         return new Eon();  
  •     }  
  •     public IPremium GetPremium()  
  •     {  
  •         return new Elantra();  
  •     }  
  • }  

And now we have reached a point where we can use the setup created so far. Let’s do it as in the following:

  • Console.Title = “Abstract Factory pattern demo”;  
  • ICarFactory carFactory = null;
  • IEconomy economy = null;
  • IPremium premium = null;
  • //Maruti  
  • carFactory = new MarutiFactory();
  • economy = carFactory.GetEconomy();
  • premium = carFactory.GetPremium();
  • Console.WriteLine(“Normal car is: ” + economy.ShowEconomy() + “\nPremium Car is: ” + premium.ShowPremium()); 

Output:

run
  • //Hyundai  
  • carFactory = new HyundaiFactory();
  • economy = carFactory.GetEconomy();
  • premium = carFactory.GetPremium();
  • Console.WriteLine(“Normal car is: ” + economy.ShowEconomy() + “\nPremium Car is: ” + premium.ShowPremium()); 

Output:

Output

 And here goes the class diagram. 

As you can see in the above code that client is getting the required car factory object by just creating the instance of respective car factory brand. And then it gets the required interface object by calling it’s respective car factory method in order to further call the product interface methods i.e. ShowEconomy and ShowPremium. 

Hope you have liked the article. Look forward for your comments/suggestions. 

var keyword constraints as class fields in C#

Hello friends. Hope you are doing well!!

Wish you happy new year!!

I am here to talk about the var keyword constraint, when using it in the class level fields in C#. Sometimes , we get a question that why can’t we use var keyword in initializing the class level fields. Let’s have a look at the code snippet, given below: 

  1. class A  
  2. {  
  3.  var x; //error  
  4.  int y; //ok  
  5. }   

The above declaration of x is not right as var is not allowed to be used in the class level declaration and this is the reason, it throws the following error. 

“The contextual keyword ‘var’ may only appear within a local variable declaration or in script code.”

Clearly var is not something that can replace the data types. But why so? This is because the compiler is designed in a way that it assumes that all the class level initialization will have their type defined already. If you are interested in the detailed answer, you may want to read the post from Eric Lippert at the link:

 If you have gone through the link, mentioned above, you can understand that in order to support the var in the class fields, re-write of the compiler is required and this would be a huge change. Until that happens, keep using the var inside the methods, where it can infer the datatype at the compile time.

Hope you liked the post. Look forward to your comments.