Introduction
This article is the Part 4 of the Design Pattern. Please feel free to download my free 500 question and answer ebook which covers .NET, ASP.NET, SQL Server, WCF, WPF, WWF @
http://www.questpond.com/You can visit and download the complete architecture Interview questions PDF which covers SOA, UML, Design patterns, Togaf, OOPs etc
Happy job hunting......
Design Pattern Interview Questions - Part 4
Bridge pattern helps to decouple abstraction from implementation. With this if the implementation changes it does not affect abstraction and vice versa. Consider the figure ‘Abstraction and Implementation’. The switch is the abstraction and the electronic equipments are the implementations. The switch can be applied to any electronic equipment, so the switch is an abstract thinking while the equipments are implementations.
Figure: - Abstraction and Implementation
Let’s try to code the same switch and equipment example. First thing is we segregate the implementation and abstraction in to two different classes. Figure ‘Implementation’ shows how we have made an interface ‘IEquipment’ with ‘Start()’ and ‘Stop()’ methods. We have implemented two equipments one is the refrigerator and the other is the bulb.
Figure :- Implementation
The second part is the abstraction. Switch is the abstraction in our example. It has a ‘SetEquipment’ method which sets the object. The ‘On’ method calls the ‘Start’ method of the equipment and the ‘off’ calls the ‘stop’.
Figure: - Abstraction
Finally we see the client code. You can see we have created the implementation objects and the abstraction objects separately. We can use them in an isolated manner.
Figure :- Client code using bridge
GOF definition :- A tree structure of simple and composite objects
Many times objects are organized in tree structure and developers have to understand the difference between leaf and branch objects. This makes the code more complex and can lead to errors.
For example below is a simple object tree structure where the customer is the main object which has many address objects and every address object references lot of phone objects.
Figure: - General Process
Now let’s say you want to insert the complete object tree. The sample code will be something as shown below. The code loops through all the customers, all addresses inside the customer object and all phones inside the address objects. While this loop happens the respective update methods are called as shown in the below code snippet.
foreach (Customer objCust in objCustomers)
{
objCust.UpDateCustomer();
foreach (Address oAdd in objCust.Addresses)
{
oAdd.UpdateAddress();
}
foreach (Phone ophone in oAdd.Phones)
{
ophone.UpDatePhone();
}
}
The problem with the above code is that the update vocabulary changes for each object. For customer its ‘UpdateCustomer’ , for address its ‘UpdateAddress’ and for phone it is ‘UpdatePhone’. In other words the main object and the contained leaf nodes are treated differently. This can lead to confusion and make your application error prone.
The code can be cleaner and neat if we are able to treat the main and leaf object uniformly. You can see in the below code we have created an interface (IBusinessObject) which forces all the classes i.e. customer, address and phone to use a common interface. Due to the common interface all the object now have the method name as “Update”.
foreach (IBusinessObject ICust in objCustomers)
{
ICust.Update();
foreach (IBusinessObject Iaddress in ((Customer)(ICust)).ChildObjects)
{
Iaddress.Update();
foreach (IBusinessObject iphone in ((Address)(Iaddress)).ChildObjects)
{
iphone.Update();
}
}
}
In order to implement composite pattern first create an interface as shown in the below code snippet.
public interface IBusinessObject
{
void Update();
bool isValid();
void Add(object o);
}
Force this interface across all the root objects and leaf / node objects as shown below.
public class Customer : IBusinessObject
{
private List<Address> _Addresses;
public IEnumerable<Address> ChildObjects
{
get
{
return (IEnumerable<Address>)_Addresses;
}
}
public void Add(object objAdd)
{
_Addresses.Add((Address) objAdd);
}
public void Update()
{
}
public bool isValid()
{
return true;
}
}
Force the implementation on the address object also.
public class Address : IBusinessObject
{
private List<Phone> _Phones;
public IEnumerable<Phone> ChildObjects
{
get
{
return (IEnumerable<Phone>)_Phones.ToList<object>();
}
}
public void Add(object objPhone)
{
_Phones.Add((Phone)objPhone);
}
public void Update()
{
}
public bool isValid()
{
return true;
}
}
Force the implementation on the last node object i.e. phone.
public class Phone : IBusinessObject
{
public void Update()
{}
public bool isValid()
{return true;}
public void Add(object o)
{
// no implementaton
}
}
Punch :- Decorator pattern adds dynamically stacked behavior thus helping us to change the behavior of the object on runtime.
There are situations where we would like to add dynamic stacked behavior to a class on runtime.
The word stack is an important word to note. For instance consider the below situation where a hotel sells bread meals. They have four important products and the order can be placed using the below combination:-
- Simple bread.
- Bread with Chicken.
- Bread with drinks
- Bread with chicken and drinks.
In other words the order process behavior and the cost of the order changes on runtime depending on the type of the combination.
Figure: -
Below is a simple order with only bread which has two functions ‘prepare’ and ‘calculatecost’. We would like to add new products to this basic bread order dynamically on runtime depending on what the customer wants.
Below is a simple interface which every order will have i.e. Prepare and CalculateCost.
interface IOrder
{
string Prepare();
double CalculateCost();
}
The base product is the bread which implements the Iorder interface. We would like to add new products to the bread order and change the behavior of the complete order.
public class OrderBread : IOrder
{
public string Prepare()
{
string strPrepare="";
strPrepare = "Bake the bread in oven\n";
strPrepare = strPrepare + "Serve the bread";
return strPrepare;
}
public double CalculateCost()
{
return 200.30;
}
}
We can alter the bread order dynamically using decorator pattern. To implement decorator pattern is a 5 steps process.
Step1:- Create a decorator class which aggregates the object / interface for which we need to add the behavior dynamically.
abstract class OrderDecorator : IOrder
{
protected IOrder Order;
. . . . .
. . . . .
. . . . .
}
This decorator class will house the object and any method calls to the main object will first invoke all the housed objects and then the main object.
So for instance if you are calling the prepare method, this decorator class will invoke all the prepare methods of the housed object and then the final prepare method. You can see how the output changes when decorator comes in to picture.
Figure: -
Step 2: - The housed object/ interface pointer needs to be initialized. We can do the same by using various means for the sample below we will just expose a simple constructor and pass the object to the constructor to initialize the housed object.
abstract class OrderDecorator : IOrder
{
protected IOrder Order;
public OrderDecorator(IOrder oOrder)
{
Order = oOrder;
}
. . . . .
}
Step 3: - We will implement the Iorder interface and invoke the house object methods using the virtual methods. You can see we have created virtual methods which invoke the house object methods.
abstract class OrderDecorator : IOrder
{
protected IOrder Order;
public OrderDecorator(IOrder oOrder)
{
Order = oOrder;
}
public virtual string Prepare()
{
return Order.Prepare();
}
public virtual double CalculateCost()
{
return Order.CalculateCost();
}
}
Step 4: - We are done with the important step i.e. creating the decorator. Now we need to create dynamic behavior object which can be added to the decorator to change object behavior on runtime.
Below is a simple chicken order which can be added to the bread order to create a different order all together called as chicken + bread order. The chicken order is created by inheriting from the order decorator class.
Any call to this object first invokes custom functionality of order chicken and then invokes the housed object functionality. For instance you can see When prepare function is called it first called prepare chicken functionality and then invokes the prepare functionality of the housed object.
The calculate cost also adds the chicken cost and the invokes the housed order cost to sum up the total.
class OrderChicken : OrderDecorator
{
public OrderChicken(IOrder oOrder) : base(oOrder)
{
}
public override string Prepare()
{
return base.Prepare() + PrepareChicken();
}
private string PrepareChicken()
{
string strPrepare = "";
strPrepare = "\nGrill the chicken\n";
strPrepare = strPrepare + "Stuff in the bread";
return strPrepare;
}
public override double CalculateCost()
{
return base.CalculateCost() + 300.12;
}
}
Same way we can also prepare order drinks.
class OrderDrinks : OrderDecorator
{
public OrderDrinks(IOrder oOrder)
: base(oOrder)
{
}
public OrderDrinks()
{
}
public override string Prepare()
{
return base.Prepare() + PrepareDrinks();
}
private string PrepareDrinks()
{
string strPrepare = "";
strPrepare = "\nTake the drink from freezer\n";
strPrepare = strPrepare + "Serve in glass";
return strPrepare;
}
public override double CalculateCost()
{
return base.CalculateCost() + 10.12;
}
}
Step 5:- The final step is see the decorator pattern in action. So from the client side you can write something like this to create a bread order.
IOrder Order =new OrderBread();
Console.WriteLine(Order.Prepare());
Order.CalculateCost().ToString();
Below is how the output will be displayed for the above client call.
Order 1 :- Simple Bread menu
Bake the bread in oven
Serve the bread
200.3
If you wish to create the order with chicken, drink and bread, the below client code will help you with the same.
Order = new OrderDrinks(new OrderChicken(new OrderBread()));
Order.Prepare();
Order.CalculateCost().ToString();
For the above code below is the output which combines drinks + chicken + bread.
Order 2 :- Drinks with chicken and bread
Bake the bread in oven
Serve the bread
Grill the chicken
Stuff in the bread
Take the drink from freezer
Serve in glass
510.54
In other words you can now attach these behaviors to the main object and change the behavior of the object on runtime.
Below are different order combination we can generate , thus altering the behavior of the order dynamically.
Order 1 :- Simple Bread menu
Bake the bread in oven
Serve the bread
200.3
Order 2 :- Drinks with chicken and bread
Bake the bread in oven
Serve the bread
Grill the chicken
Stuff in the bread
Take the drink from freezer
Serve in glass
510.54
Order 3 :- Chicken with bread
Bake the bread in oven
Serve the bread
Grill the chicken
Stuff in the bread
500.42
Order 4 :- drink with simple bread
Bake the bread in oven
Serve the bread
Take the drink from freezer
Serve in glass
210.42
Façade pattern sits on the top of group of subsystems and allows them to communicate in a unified manner
Figure: - Façade and Subsystem
Figure ‘Order Façade’ shows a practical implementation of the same. In order to place an order we need to interact with product, payment and invoice classes. So order becomes a façade which unites product, payment and invoice classes.
Figure: - Order Facade
Figure ‘façade in action’ shows how class ‘clsorder’ unifies / uses ‘clsproduct’,’clsproduct’ and ‘clsInvoice’ to implement ‘PlaceOrder’ functionality.
Figure :- Façade in action
Note:- You can find the façade code in the ‘façade pattern’ folder.
Chain of responsibility is used when we have series of processing which will be handled by a series of handler logic. Let’s understand what that means. There are situations when a request is handled by series of handlers. So the request is taken up by the first handler, he either can handle part of it or can not, once done he passes to the next handler down the chain. This goes on until the proper handler takes it up and completes the processing.
Figure: - Concept of Chain of Responsibility
Let’s try to understand this concept by a small sample example. Consider figure ‘Sample example’ where we have some logic to be processed. So there are three series of processes which it will go through. So process 1 does some processing and passes the same to process 2. Process 2 does some kind of processing and passed the same to process 3 to complete the processing activity.
Figure: - Sample example
Figure ‘class diagram for COR’ the three process classes which inherit from the same abstract class. One of the important points to be noted is that every process points to the next process which will be called. So in the process class we have aggregated one more process object called as ‘objProcess’. Object ‘ObjProcess’ points to next process which should be called after this process is complete.
Figure: - Class diagram for COR
Now that we have defined our classes its time to call the classes in the client. So we create all the process objects for process1 , process2 and process3. Using the ‘setProcess’ method we define the link list of process objects. You can see we have set process2 as a link list to process1 and process2 to process3. Once this link list is established we run the process which in turn runs the process according to the defined link list.
Figure: - COR client code
Note :- You can get the code for the same in C# in ‘ChainOfResponsibility’ folder.
Proxy fundamentally is a class functioning as in interface which points towards the actual class which has data. This actual data can be a huge image or an object data which very large and can not be duplicated. So you can create multiple proxies and point towards the huge memory consuming object and perform operations. This avoids duplication of the object and thus saving memory. Proxies are references which points towards the actual object.
Figure ‘Proxy and actual object’ shows how we have created an interface which is implemented by the actual class. So the interface ‘IImageProxy’ forms the proxy and the class with implementation i.e. ‘clsActualImage’ class forms the actual object. You can see in the client code how the interface points towards the actual object.
Figure: - Proxy and actual object
The advantages of using proxy are security and avoiding duplicating objects which are of huge sizes. Rather than shipping the code we can ship the proxy, thus avoiding the need of installing the actual code at the client side. With only the proxy at the client end we ensure more security. Second point is when we have huge objects it can be very memory consuming to move to those large objects in a network or some other domain. So rather than moving those large objects we just move the proxy which leads to better performance.
Note :- You can get the proxy code in the ‘Proxy Pattern’ folder.
Template pattern is a behavioral pattern. Template pattern defines a main process template and this main process template has sub processes and the sequence in which the sub processes can be called. Later the sub processes of the main process can be altered to generate a different behavior.
Punch :- Template pattern is used in scenarios where we want to create extendable behaviors in generalization and specialization relationship.
For example below is a simple process to format data and load the same in to oracle. The data can come from various sources like files, SQL server etc. Irrespective from where the data comes, the overall general process is to load the data from the source, parse the data and then dump the same in to oracle.
Figure: - General Process
Now we can alter the general process to create a CSV file load process or SQL server load process by overriding ‘Load’ and ‘Parse’ sub process implementation.
Figure: - Template thought Process
You can see from the above figure how we have altered ‘Load’ and ‘Parse’ sub process to generate CSV file and SQL Server load process. The ‘Dump’ function and the sequence of how the sub processes are called are not altered in the child processes.
In order to implement template pattern we need to follow 4 important steps:-
- Create the template or the main process by creating a parent abstract class.
- Create the sub processes by defining abstract methods and functions.
- Create one method which defines the sequence of how the sub process methods will be called. This method should be defined as a normal method so that we child methods cannot override the same.
- Finally create the child classes who can go and alter the abstract methods or sub process to define new implementation.
public abstract class GeneralParser
{
protected abstract void Load();
protected abstract void Parse();
protected virtual void Dump()
{
Console.WriteLine("Dump data in to oracle");
}
public void Process()
{
Load();
Parse();
Dump();
}
}
The ‘SqlServerParser’ inherits from ‘GeneralParser’ and overrides the ‘Load’ and ‘Parse’ with SQL server implementation.
public class SqlServerParser : GeneralParser
{
protected override void Load()
{
Console.WriteLine("Connect to SQL Server");
}
protected override void Parse()
{
Console.WriteLine("Loop through the dataset");
}
}
The ‘FileParser’ inherits from General parser and overrides the ‘Load’ and ‘Parse’ methods with file specific implementation.
public class FileParser : GeneralParser
{
protected override void Load()
{
Console.WriteLine("Load the data from the file");
}
protected override void Parse()
{
Console.WriteLine("Parse the file data");
}
}
From the client you can now call both the parsers.
FileParser ObjFileParser = new FileParser();
ObjFileParser.Process();
Console.WriteLine("-----------------------");
SqlServerParser ObjSqlParser = new SqlServerParser();
ObjSqlParser.Process();
Console.Read();
The outputs of both the parsers are shown below.
Load the data from the file
Parse the file data
Dump data in to oracle
-----------------------
Connect to SQL Server
Loop through the dataset
Dump data in to oracle
.NET Interview Question PDF
