There are times where you do something once, and it feels like an ugly hack, but then you keep doing it on other projects because you just can’t figure out a better way, and then you talk to a few more programmers, and it turns out that what you’re doing is pretty much the best approach.
I don’t think all design patterns are born this way, but that’s how this one came about. Here’s the smash and grab pattern.
Basically, when you have to interface with an external system, whether it’s a data API or more of a platform like a Facebook or Salesforce app, you want to get what you need and get out as fast as you can. Don’t try to modify everything you’re doing to suit the platform, just take the data that you require and port it over to your core framework as early as possible.
For a basic API, we’re talking about putting the data in a format that’s consistent with the rest of your application. For a more intensive app, you might be looking at a thin iframe layer or something.
It’s an extension of the adapter design pattern, basically, but adding a “take what you need and get out” mentality underlines the point that this interface is not the basis of your application (well, it likely shouldn’t be anyway) – your core business logic, other integration points, and future plans shouldn’t be relying on one interface to set the tone for everything you do.
And for the record, I’m not a design pattern guru. They influence my work and I’m sure I could explain my code using the basic styles, but I don’t approach each problem with a checklist or try to make them fit. They’re handy tools for describing core concepts, but in earlier years I found myself trying to make sure every class had at least one design pattern represented, and just like how the smash and grab reminds me that I shouldn’t rely too much on any one data source, I also need to remember not to rely on patterns for everything I consciously do.
The web’s made it easy to get design pattern information, but I’m still glad I have my Gang of Four book. For an intro to the core concepts, you could do a lot worse than Head First Design Patterns. [affiliate links]
