Anyway, on with the post.
The first design pattern that I’s like to cover is called the Facade. Just as an architectural facade is the face of a building, a software facade is the face of a class or set of classes. Designers use the Facade pattern to cover over or conceal the actual interface used to talk to a class. Often times, a Facade is used to provide a simple interface to a class that has a complex interface. You can also use a Facade to provide a consistent interface, or set of methods, to a class that may change.
Imagine that you are designing a software library for talking to a database. You know that you will need to expose methods for calling Insert, Update and SQL execution functions. In order to call these functions, you need to use specific function calls that are exposed by the database. At the beginning of the project, you are told that you are going to use an Oracle database, but you know that the customer is fickle and may change the database on you at any time. This is the perfect time to use a Facade.
You could design a database facade class that exposes some general database methods like insert, update and execute. Then, you can code the facade to use the appropriate calls for your chosen database. All of the code in your project that needs to talk to the database will be coded to talk to the Facade and use the general methods that you have defined.
The beauty of the pattern becomes evident when the customer decides to change the database. Instead of changing the database calls all over your application, you need only change the facade. The facade hides the complexity of it’s underlying classes and exposes a common set of methods that any user of the class would need. The users of your database facade won’t care if they are pointed to an Oracle, MySQL or SQLite database. All that they will need to know is the interface that is exposed by your facade.
So, when you are designing a system where the underlying pieces may change, consider using a Facade. Using this pattern will save you time and effort when your customer changes his or her mind, which they are apt to do.
Hi Patrick:
ReplyDeleteI just Kindled your book last night and it has gotten me straight to the point on a number of issues with iOS! Thanks for the clear writing. I clicked the acknowledgments-page's link for this blog and love the idea of discussing design patterns. I had previous exposure at my corporate job to the book but I knew right away to pick it up again once I started in on iOS programming (MVC). iOS has a sea of patterns -- and programming for ipxd (ok, the term is not really phonetic, but you get the point) really underscores the need to understand them to write good software.
Here's an example of facade that I'm using (used often in your examples!):
NSLog() is a way to write out log data to the console, but more generally -- you're using a debugging instrument to…log text. The basic idea in many patterns (and facade in particular) is to separate implementations from the abstraction and only expose the abstraction so that code is extensible, readable…etc…(-xble?). When an ipxd device is used as the target (rather than the simulator) NSLog is not compiled (I assume) but why not use a facade so that you could write a log to a UITextView and see all your log statements there if you needed?
So you could create a facade (e.g. an IOSLog class) that could be #defined out (debug vs. release) as well as redirected on target (simulator/device) to a different implementation (NSLog vs. UITextView), for example:
[IOSLog logString:@"ApplicationDidReceiveMemoryWarning"];
The key idea for me is input/output redirection…good software allows you to do this (for testing, debugging, and all the -xbles) and Design Patterns are at the heart of that understanding of course!
Bring on in another pattern!
Cheers, jwinkle