Breaking Down Design Patterns: Facade Pattern
The most difficult thing for me in learning design patterns has been trying to understand when and how to apply them. Another difficulty has been spotting where I am already using patterns and knowing when I am using them. I am going to start writing blogs where I look at how I use patterns in my current programming, even though I don't know it. Perhaps it will help those who are struggling to learn patterns for OO programming like I am.
When to use patterns can be tough. If you try to build your application with patterns in mind from the beginning, sometimes you can get caught overthinking your solution. A co-worker recently pointed out that you should try to apply your patterns when you are refactoring your code. Refactoring is when you go back through your application after it has been built and try to find places where you could improve your handling of objects. Perhaps some files have too much logic in them that could be broken out into multiple files, or perhaps you can spot somewhere where you have written several classes where one with minor configuration could suffice. Maybe you just are going through your application to see where you can speed it up. This is what refactoring is.
When refactoring your application, I would recommend keeping the “Gang of Four” book Design Patterns open. This way when you are going through your code, you will see places where you could apply a pattern.
The Facade Pattern is one that we all have used in one place or another. Most everyone once you have written software for long enough have learned that making all of your code open to the public is not such a good idea, especially in this era of highly visible hacks and security breaches. This can be managed by having one controlled access point to a group of classes or code that performs a global function. This can be a system to create a new user account in several places that has a single administrator function. It isn't necessary to call several different objects from your form if you are a web developer, you can just call one object that initializes many others that are private and have them create the user in their systems. That way first of all, you are only exposing one small part of your application to the client facing side of your application, and you are making things easy on yourself by having a single place to pass data into. This makes unit testing much easier also.
A good example of how not to do it is to, in ColdFusion, have five cfinvoke statements on one page, each calling a method to insert a new user into a different table on several DSNs. A better way to do it would be to have a single cfcomponent that will perform the invokes on the objects, or even better to have an init method that calls the objects, passing each of them the required parameters. This gives your application basic validation as well as increasing security and simplicity.