Facade pattern in GUI design

Today's post will be about Facade pattern and its application in GUI programming.


I would assume that you guys have already know about GUI basic, like event handling (basically, it's a method that is invoked when something happen to the GUI, either by you or by God, haha). Also, if you have tried to integrate several UI (not just GUI, but include TextUI, mobile apps UI...) for your logic classes, you might see that's it is quite trouble some to keep calling methods in Logic from your GUI.
If you happen to do so, you might end up with something like this:

<Sr for the hand writing :P> Basically, each of  TextUI and GUI's event handler A and B is calling method A and B in Logic. It's a bit wrong, technically, since TextUI don't normally have handler.

This is only for 2 UI classes. imagine i you have more: mobile Apps, Web interface, embedded system interface... if you implement it this way, you will have to write the calling code again and again. Plus, if you change your Logic, then the whole code in UI classes have to change. Plus, your UI have to "know" the structure of Logic class, which is considered a bad design in software.

Instead, people have proposed a design pattern, called Facade pattern.

A "facade" class will be made and you will be calling methods in that facade class. then, the facade class will call Logic, get result and return it ot UI.
It won't shorten much of your work, though. You still have to make a call from UI to facade class and back, but it is helpful since your UI only know about the facade, which acts more or less like an API (correct me if I am wrong here :D). Then UI doesn't of whatever happen in Logic, or even if there is a Logic class at all. This will reduce your load when modifying code inside.


Basicall, it the new structure will be

<again, hand writing :P> now, event handler in TextUI and GUI will call methods from facade class, then facade class will call logic. So, if by any chance you need to modify your internal logic w/o changing API, you can do it freely. UI classes now only know up to facade class and no more.

It will be a good design :D

If you only have 2 class, then you can also consider splitting the facade in half:
GUI will have a method that receive info from Logic, then checking that info and distribute to respective UI methods
Logic will also have a method receiving info from UI, checking it and call appropriate logic methods
Logic and UI will also have a method that sends info to the other class. This method will be invoked each time info need to be passed.
Logic and UI will only be communicating through these broadcaster and listener methods

This is, in my opinion, not a recommended approach though :P but it's fast.

That's all for today :)