A Full Stack Engineer's Perspectives on Technology, Startups, Software Engineering, and UI Design

Design Patterns: GoF Masterpiece

Posted: January 14th, 2012 | Author: | Filed under: General | No Comments »

So I felt like writing a new blog post rather than using tumblr or any of the billion other micro blogging or knowledge services out there. I still think there’s space for a blog, where blogs function as journals more than as primary communication devices. So I’ll start using it as that (and as tutorials like my other popular posts).

Computer Science Shift

Three months ago I moved from my agency-getting-things-done job to a start up working mainly with comp sci guys from some of the best schools in the world. This change has been full of new and interesting terms from clean code to hadoop. I’ve mainly worked on the client (Flash for our team) and a little bit on the server (PHP/MySQL/CI). Since joining, I’ve thought carefully about what it means to support millions of users and have boiled it down to a few select ways (which I can highlight in another post). Anyways, the change has been immense and I’ve studied very consistently since then. I’ve read a couple of code related books while keeping up with my regular readings. Most recently, I’ve finished a book on design patterns — yes the original GoF one. It’s come up throughout the last two years a number of times so I felt it was pretty important to read now that I’m in full blown comp-sci. Here’s a brief summary and opinion:

Design Patterns: You Shouldn’t Live Without ‘Em

If you are programming, or learning to program, and want to build scalable software, I urge you to read the original design patterns book (or something similar). Within the book, they talk about two dozen or so patterns that help organize common issues in software design. I found it immensely valuable to be able to talk about these design patterns with teammates and other professionals and why we choose certain ones over others. Here’s a list of the design patterns that interest me and what they do:

Creation Patterns 

  • Builder – This pattern helps you create objects a certain way and then change them by using inheritance. You code out how you build a certain object in a class by using methods (build legs, build arms, etc.) and then extend that class and override those specific methods for various implementations. This is the same to me as using a similar pattern called template methods…
  • Factory Method – A pattern that uses a method to create objects. I never embraced this enough until reading this. We use it in our code quite frequently and having something control the creation of your objects is powerful. Combining this with a singleton and other patterns allows you to determine at runtime which class should be used based on which class it’s being used by. Look up the term single dispatch as well (interesting concept), and if you can do double/multi dispatch with this, great.
  • Prototype – An object you “clone” to create other objects with different behavior. Think events in flash; they have clone functions. Clone it, change properties, and send it out again is how I’d use them.
  • Singleton – I heart singletons. Although they can be called “global” variables, they are safer to use than static classes and very necessary in almost every application. When there really should only be one instance, this is your friend. Unfortunately there’s so many ways of faking enforcement of a singleton in flash. I’ll be trying Casalib’s way for my next project. In full-blown OO where constructors can be private (like in Java and PHP), Singleton’s are even cooler.

Structural Patterns

  • Adapter – The concept behind changing an interface of someone else’s library so that you can use your library to “plug” into it.
  • Bridge – Separates implementation from abstraction. I loved the diagram in this book. If you have a multi-OS application, and need to separate how windows are treated, you can use a bridge to communicate between your windows and their implementations where the bridge is used to communicate to device specific implementations. I’d wager that most multi-platform dev kits use something similar.
  • Composite – A base object that can contain other base objects. Think DisplayObject, NSView, whatever — every advanced visual language supports this concept. Parent -> children.
  • Decorator – Adding functionality to something without having to change the original object. Their example was putting a border around a UI element. You can wrap an entire element to manage it as well and still be a decorator (managing many objects = mediator).
  • Facade – I build “facades” to make using larger systems easier. It’s part of making coding intuitive. If something can be made simpler, it can very well be worth while to create a facade to interact with a whole system. I love using tool sets that accomplish certain tasks really well for example. And without having to build an Adapter, I can just create a facade that makes it easier to use it.
  • Proxy – A proxy object is basically something that can 1) be used in place of something else, or 2) an object that communicates between two objects. I like that first point, that it can be used instead of something else. If something hasn’t loaded, you can use a proxy object to keep it’s place for fluid layouts or just to hold data until it’s loaded.

Behavioral Patterns

  • Chain of Responsibility – Passing objects until someone interested does something with it. Think event dispatcher in flash. You pass objects from parent to child or child to parent while anyone along the chain has the option to stop it (stop/prevent propogation in JavaScript and AS3), handles it, or ignores it.
  • Command – The command pattern is a very useful pattern to wrap requests to a server or servers (think p2p). By siphoning all logic directed outside an application through a pattern of objects, you have a very powerful, centralized hub to control communication (think control tower). This pattern is a must have for most applications.
  • Interpreter – This pattern is very interesting in it that it allows you to create your own notation that gets parsed by an “Interpreter” that then opens windows, runs commands, etc.  Think regular expressions on steroids.
  • Mediator – A mediator is a useful UI pattern that can be used to handle communication and states between multiple objects without violating encapsulation (i.e. those objects don’t know each other, only the mediator knows them all).
  • Memento – Wicked name for a simple concept – a pattern that uses objects to store the state of an object so you can return to it later. Use mementos with commands to do undo and redo logic.
  • Observer – A pattern that allows multiple objects (observers) to listen to a specific object for changes. Think binding in flex or the model to view or controllers in mvc, where the view or controller can act as observers. I loved CakePHP for this kind of observer behavior.
  • Strategy – I love the strategy pattern. Consider you have an advanced algorithm and you don’t think it’s the best in all situations. You can wrap it in a strategy style pattern and build out another algorithm in another strategy and decide at run-time which strategy to use. It’s technical term would be separating an algorithm’s context from the algorithm itself so you can create different algorithms for a single context, vice versa, or many-to-many.
  • Template Method – A template method is used when you write a base class with a certain sequence of methods being called in a certain order. The class is designed so that when you inherit from it, you can overwrite certain methods (called template methods) to present different functionality but keep the general structure in order. We use this all the time, everywhere (in good and bad ways).
  • Visitor – Finally, I’ll talk about the visitor pattern. This pattern allows you centralize a certain behavior where you might want to create an object that scans other objects for certain parameters to do a certain thing or compute a certain result. The object is said to be called a visitor where it visits other objects to look for properties of interest.
There were a few that I didn’t write about that I don’t use so much and aren’t interesting for various reasons. Regardless, if you aren’t using design patterns in your small or larger projects (much less likely), get on that ship as it could save you an unforeseeable amount of time down the road (more team members, selling your product, version 2, etc.). Chances are though, you are already using it and you either know it or you don’t. If you don’t, I’d recommend the read. It took me a month and a half of light train reading, but it is well worth it.


You are probably using them already

Although I’ve used design patterns before, many of the former unknown design patterns I used instinctively when designing previous applications. This could be due to my experiences with Papervision, Away3D, AS3, CakePHP, CodeIgnitor, Objective-C, Java (each one brings a few patterns to mind). But after reading this book, it all makes a little more sense.
Happy coding.


Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

No related posts.

Leave a Reply