The way I was introduced to the Design Patterns lead me to think that those clever and neat solutions were meant to be used just in big softwares solutions. I never considered using them into the small pieces of software. What do I mean by that? Please, read on.
The Builder Pattern if defined as follows:
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Now, consider for a while the creation of an
UIAlertView in iOS.
This is a long method call, right? But really, that’s not the problem. The problem here is that our class has to conform to
UIAlertViewDelegate in order to receive the alert result. Wouldn’t be nicer to have that logic encapsulated? Well, go back and read the definition for the builder pattern, it fits like a glove, am I right?
An idea on how to wrap the builder pattern around the
UIAlertView class is as above:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Now, all that is necessary to use create an alert is:
1 2 3 4 5 6
In the past, I would have used the first approach and lived with that. Of course, showing alerts to the user is a very tiny part of a real work application. But that’s preciselly where I was wrong. This kind of applicability of the builder (among all other design patterns) is what makes software components reusable.
And there are some other places where you could apply the same principle, for example
I hope you find that useful. Builder to the rescue!
P.S: Yes, yes I know that Apple has released
UIAlertController and deprecated both
UIActionSheet. However, the idea is pretty much the same, alothough what Apple did is Factory instead of a Builder.