Muhammad Shoaib Anjum, Ultimus Pakistan
Design Patterns – I always skipped this book while browsing the shelf in library. Yeah, c’mon man, programming is about guts. These bookish theories and methodologies have no use when it comes to breaking the nut. These software engineering guys, I used to wonder, why God created them. I mean weren’t programmers, yeah the smart chaps, enough for computer science to live in this world? I wondered.
And one day, God listened. He responded to my amusements. He told me, although you can run bare footed quite fast, but wearing joggers save your feet from bleeding, and make you run even faster. He told me that although your 4wheel drive can ride the rough terrain but a paved road will surely help.
So if you are a programmer, Design Patterns are your joggers and your paved road. You surely can make without these, but using these will save your feet from bleeding, will make you run faster and will surely help in a smooth-going, up the hill.
Its like, if you have played a strategic game, and you have cleared a tough level more than once, and you have tried different strategies every time, and you know which strategy is better, and you tell that strategy to all the people who want to clear that particular level of game. Now people can, and will, be able to clear the level without following your strategy, but if they follow it, they will be able to clear it quickly and cost effectively, without burning too much of their energy. Software Engineering, or development for that matter, is a strategic game. If you follow proven strategies, you have more chances to win. And yet there are people who do not follow proven strategies; they prefer creating their own, and sometimes end up adding to the pool. But, sometimes.
Let’s talk about some simple patterns. You might already be using some of these, knowingly or unknowingly.
This is one of the most commonly used patterns. If you have used STL, you’d have used iterators. Yeah, you got it rite. An iterator is used to iterate, or traverse, through a collection of objects. Yes you can surely traverse the collection using a for-loop, and accessing each item by index or key. Then why do we need an iterator? Well an iterator provides you abstraction. You forget about the collection; whatever it was. Was it index based or key based? Was it key-value or a list? Whatever its internal implementation was; a tree, an array or something else, you have an iterator, which will provide you with the objects in the collection, and that’s the end of the world.
You have used internet proxy, right? What does it do? It provides access to internet, a resource. Being a provider of access, it has control over access; it can apply restrictions, it can share and balance the bandwidth etcetera etcetera.
Same is the case with Proxy pattern with respect to objects. It is used to provide and control the access, to an object.
For example, if you instantiate a COM server as LocalServer, it is loaded by a separate process “dllhost.exe”. This separate process is called a proxy, or a surrogate. The object returned by instantiating a COM server as LocalServer is a proxy object, an object of surrogate process. You access the actual COM object through this proxy.
Chain of Responsibility
“Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.”
Your operating system and the applications that run in it are good examples of Chain of Responsibility. When you double click on a file, it checks file extension and gets the application which has registered itself as responsible for this type of files. OS then forwards the file to that application. Suppose the file was an MS Word document, and it opened in MS Word. Now if you press a shortcut key, its command handler will be invoked. It will receive the command message and find out the piece of code responsible for that command. This piece of code can either handle the command itself or forward it further by opening a form to the user, to take some further input, and it continues.
You’d have studied in detail about the TCP/IP protocol stack in your Data Communication course. It has 5 layers; Application Layer, Transport Layer, Network Layer, Data Link Layer and Physical Layer. When a packet is received or transmitted, every layer receives the packet, does its share of manipulation and forwards the packet to next layer up or down the ladder. It was very much possible to unpack the packet at a single layer, extract all the data and booom, but it was layered, with every layer responsible for its particular task. This is Chain of Responsibility.
You can relate this to modularization as well. We separate the distinct pieces of logic into separate modules. Every module does its job or forwards.
Its as simple as that. So next time when you plan for a solution, keep at least these 3 in mind; these can be handy.
Let’s call it a day for now. We have been through three very simple design patterns. We have seen the conceptual part with the help of examples. I will come to the implementation part in my next article on Design Patterns. Till then, bye bye!!
Search Engine Terms: Design Patterns, GoF (Gang of Four)
 Design Patterns: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)