My take on Design Patterns

In case you haven't filled your quota for reading sarcastic poorly written hyperbole about software construction I present my take on Design Patterns. Now with example python code.

Chapter 0: The singleton

Since the invention of the stack and data structure programmers have been hounded by people telling them not to use globals. The singleton exists to confuse people until they give up criticizing your code for the use of global variables. Use them constantly.

Chapter 1: Constructin stuff is hard.

Often times you want things but getting them is hard and fraught with complication. For example we might have a car object & constructor: Car(bankAccount). However we might want to abstract the nasty details of its construction since creating a car object should be easy: class CarFactory: def __init__(self,bankAccount): self.bankAccount = bankAccount # We could make this __call__ or even use a closure but # this confuses java & c++ programmers who are easily # frightened with out many lines of boilerplate code. def createCar(self): return Car(self.bankAccount) creditCardForCar = CarFactory(lifeSavings) # now elsewhere the nasty "details" are abstracted away myNewCarIcantAfford = creditCardForCar.createCar() As you can see this is an ingenious pattern that is clearly better than using closures or currying of constructor arguments because now I have 2x as many objects.

Chapter II: Square pegs can go in round holes

Say you are using a poorly designed library or even better several poorly designed libraries that must interact together prehaps a result of the Ballmer peak. You will often have things like OMGBestLibraryEveryString and WTFBBQLibraryString. They are both strings that do that same thing but their authors seeing the clear deficiencies of using a standard string class have chosen to write a completely new one (because new is better). Its times like these you need one of two things: a bottle of wiskey or a design pattern. Put down that single malt its time to create some facades and proxy. There are two names because it would be boring to call something a wrapper pattern. Also people might think you were saying rapper pattern which would lead to profound confusion and eventual disappointment. in this case we do the following: class FacadeWrapperProxyOfOMGBestLibraryEveryString: def __init__(self,bbqstring): self.bbqstring = bbqstring # no reimplement all 50 of bbqstring's methods # and overloads minding painful edge cases and # bugs! (you can get the wiskey out again) Now everything is wonderful again.

3: Messages and misc stuff

Turns out even though OOP is modeled after passing messages to objects methods are not suitable for publish subscribe or message passing systems. This is very fortunate because now you can write extra objects to facilitate this lack of foresight.

Chapter iv: This chapter is missing because of a race condition in the chapter singleton manager factory.

Chapter 5: Take back that CS theory

Its really annoying when you are trying to engineer software and some "computer scientist" starts talking about algorithms and uses confusing words like state machine and language translation. Fear no more! They are now patterns! If someone suggests they are not just look perturbed and hand them a copy of design patterns.