Introduction
Again I repeat do not think you get an architecture position by reading interview questions. But yes there should be some kind of reference which will help you quickly revise what are the definition. Just by reading these answers you get to a position where you are aware of the fundamentals. But if you have not really worked you will surely fail with scenario based questions. So use this as a quick revision rather than a shot cut.
To give you a practical understanding i have put all these design patterns in a video format and uploaded on http://www.questpond.com/FreeDesign1.htm . You can visit http://www.questpond.com/ and download the complete architecture interview questions PDF which covers SOA , UML , Design patterns , Togaf , OOPs etc.
Design Pattern Interview Questions Part 1:- http://www.dotnetspark.com/kb/169-software-architecture-interview-questions.aspx
Design Pattern Interview Question Part 2:- http://www.dotnetspark.com/kb/170-design-pattern-interview-questions-part.aspx
Design Pattern Interview Question Part 3:- http://www.dotnetspark.com/kb/171-design-pattern-interview-questions-part.aspx
You can download the software architecture interview questions PDF
Download Software Architecture Interview Questions
Happy job hunting......
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.
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'.
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
Figure :- You can find the C# code for bridge in the 'BridgePattern' folder.
Composite pattern allows treating different objects in a similar fashion. Figure 'Uniformity' shows how different objects are called in a uniform manner.
In order to treat objects in a uniformed manner we need to inherit them from a common interface. Figure 'Common Interface' shows the objects inheriting from a common interface.
Figure: - Common interface
Figure 'Client code for composition' shows how we added all the different kind of objects in to one collection and then called them in a uniform fashion.
Figure: - Client code for composition
Note :- You can find C# code for composition in the 'Composite' folder.
Decorator pattern allows creating inherited classes which are sum of all part of the parent. For instance figure 'Decorator' has class1 which has method called as 'SomeFunction' now we inherit and add one more method called as 'SomeMoreFunction'. So Class2 is the addition of 'SomeFunction' plus 'SomeMoreFunction'.
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 '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 '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.
In template pattern we have an abstract class which acts as a skeleton for its inherited classes. The inherited classes get the shared functionality. The inherited classes take the shared functionality and add enhancements to the existing functionality. In word or power point how we take templates and then prepare our own custom presentation using the base. Template classes works on the same fundamental.
Figure 'Template abstract class' shows we have created a customer class 'ClsCustomer' which has set/get properties. Now we can inherit from this class and create add and update customer classes.
Figure: - Template abstract class
Note: - You can find the above C# source code in 'Template Pattern' folder.
.NET Interview Question PDF