This is in continuation to the previous post. Please note that this post will be long one, so if you have time keep reading
It states that “Simplifying the communication between a higher level interface with the complex sub-system”. What it means is that in many complex system, there are bunch of sub-systems lying around which are an important components. Now each of those sub-systems do communicate on their own to the outside world or other bunch of sub-systems in some ways. The way of communication could be via 1-1 or via other components specifically designed for that.
Now having such many complex sub-systems in a system and handling the communication between them is not easy as you might think. The easy way to solve the problem of communication between the sub-system components with the outside world is to have 1:1 link. But don’t you think its very complex and tedious to have this kind of connections? Doesn’t this remind you of old aged telephonic operator switching systems?
Yes 1:1 is highly impossible and having a system like that designed does require a lot of work to be done plus maintenance cost is very huge. Other way is to have a component specifically designed to act as a mediator between the 1:1 link so that we can reduce the direct dependency. But think realistically, you have to design or customize many such independent components which has to co-exists with these sub-system in order to just facilitate the mediator job. When you read these lines, please think of real world complex software projects like telephone switching system, network management, supply chain management, stock markets, etc.
By using this pattern, we are able to develop complex system having complex sub-systems which can communicate well and easily with other systems/sub-system thus reducing the over all complexity as well as less dependency among them. With out this pattern, as said above our software structure would grow enormous and very complex.
You might first think that divide and rule concept might sound fine where in you can divide complex sub-systems into simpler sub-systems and then have communication with them or with others. But i must tell you here that no matter to what level you bring down the structure of complexity into simpler sub-components, your increasing the communication network between them. A complex system is of no use if sub-systems inside it does not communicate well right?
Based on the requirement, your sub-systems should communicate well with others any where or every where. If communication is not given much importance then your whole system fails because either you have made their communication network so ugly which intern yourself failed to understand or due to it’s over complexity they are not communicating properly, which again boils down to not understanding ourselves to identify the problem if there is.
I remember an example for having simplistic communication between the complex sub-systems while i was watching a rocket development show on discovery, where in a failure of communication between 2 different communication sub-systems lead to a disaster as per NASA. It was learned later that by not having a proper flow of communication between them which is more simplistic and less tight coupled could have reduced the over all complexity in developing the rocket (i guess Apollo 2, not sure) itself and understanding the work flow.
Let see a sample code simulating this pattern, as always i wrote very simplistic program.
As you can see from the above code, its pretty obvious that i have taken a car manufacturing management software as an example here. So as per that, we have a Car body sub-system class which has AddCarBody() method which in turn does some very complex process like body type, color, chassis, interiors, etc. stuffs which are not exposed outside.
Next i have another sub-system called Car Engine Sub system as shown:
As you can see from the above code, the EngineSubSystem has AddEngine method which is public. But this method does much more complex work which is not exposed outside for example: fuel injection, piston monitoring, air filtration process, etc. sub-systems. Which independently are complex in nature.
Let me take another complex sub-system in this management software called ShippingSubSystem as shown:
As per the above code, this ShippingSubSystem exposes only a method called ShipToCargo() method, which internally does a lot more process like Billing, Inventory update, Packaging, Distribution, etc.
So now to make all these complex sub-systems work together easily and simplistically as per this pattern, lets look at the code below:
As you can see from this class, the communication between this sub-system and the other sub-systems viz CarBody, Shipping, Engine, etc. has been greatly simplified. At this point of time one need not to know how each of those sub-systems works in detail. There can be much more sub-systems which can be integrated as and when needed in this class with out changes in anywhere else in the system. Thus we have achieved a big leap in simplifying the communication between these sub-systems and reduced much tight integration between other sub-systems, thus reducing over all complexity of the system.
Now lets see the usage code part of it, by now you would have already guessed it. Still let me show you just to make it complete.
static void Main(string args)
ICarFacade carInterface = new CarFacade();
A picture speaks more than words, so let me show you a pic which sums up pretty much about where it can be used, already the above HOW section would have given you a fair idea. One more example would be better i feel with a difference of having this pattern and with out it.
As you can see from the above image, typical system having complex sub-system objects would look like this. In this structure the Facade pattern is not implemented. So as i have shown in the picture, these sub-systems can be a part of finance management system or a shopping system like Amazon, ebay, etc. where in any transaction from the client objects would require to update Billing process, ordering system and other sub-systems. If there was no pattern implemented (as shown in this picture), then the client object would have been tied hard to these sub-systems thus every client object will have knowledge on the internal structures of the system’s sub-system modules.
As you can see, not only the over all structuring looks complex, even the communication pattern as well looks messy, thus having many draw back in this design, like every new client object requires to have in-depth knowledge on the system it is talking to. If you require to remove a sub-system, you need to change even the client objects as well which is nearly impossible. Any small modification to either side of this system leads to a major chaos.
After introducing facade pattern the above image gets simplified to:
Hope you understood the effect of the Facade pattern in the above image. In this design model, every thing is very flexible in structure. The client objects need not to worry about to whom it is interacting with and the same with the Facade system. Even the internal communications structure is also minimized.
So, the bottom line is now the structure of the system look very clean and crisp. Even the internal sub-systems can be changed without worrying about the outside world. If there is any removal of the sub-system components in this case Ordering System (may be a down time or out of scope reasons) only the Facade component needs to be notified and not all the client objects. The same w.r.t client object changes.
Another example would be:
- Customer Service Support System
- Library management system
- Bank Accounting System
- Business Processing System
- Employee hiring process system
Well, that’s all dear friend i can talk about this pattern. I am sorry if it’s too lengthy, but i wanted to make every point clear.
Look out for my next post in continuation to this.
P.S: Your valuable comments, votes are well appreciated.