Design Patterns – Are They Independent of Programming Languages?

design-patternsduck-typingdynamic-typingobjective c

I have been recently working on Objective C and came across use of Delegate pattern.

I had seen most of the common patterns theoretically in Java, thanks to the Head First book.

But at times looking at differences in Dynamic and scripting languages I get confused about need of certain design patterns.

For example lets take example of Adapter pattern.

It already has two implementations : Object adapter[java] and Class Adapter[C++].
depending on whether the language has supports for Multiple inheritance or not.

But with dynamic languages like Objective-C, duck-typing is possible and also we have methods like respondsToSelector to check if an object actually supports a method or not.
So why do we have protocols here even if we need to use a delegate pattern ?

If we can assume anything to be anything.in a dynamic language, do we need concept of abstract class or interface at all to implement few patterns ?

they more look like tools for statically typed languages to give dynamic behavior.
specially I dont understand the need for abstract keyword in PHP.

Can anyone point out some important details, I am relatively new to this.

Best Answer

If I understand your question correctly, the answer boils down to this:

TLDR

The reason for having things like abstract classes and interfaces/protocols in a dynamic language like Objective-C are mainly simplicity and cleanliness of code.

The longer version

As cool as duck-typing is, it's actually a huge hassle if you cannot make any assumptions on the type of an object:
every respondsToSelector: line in your code messes it up. It adds noise that obfuscates what you are actually trying to accomplish for little to no benefit.

Besides, it's shit-work.

So if you provide an API contract by loosing some dynamism, using a more statically typed model it's almost always a win:

  • Replacing multiple respondsToSelector: methods with a single conformsToProtocol: is a win.
  • Having a succinct and clear listing of the necessary methods in the protocol definition is a win. (Writing that definition in and of itself is shit-work as well, but it keeps you from doing more shit-work in a number of places, so that's tolerable.)
  • Based on that, having the compiler warn you if you omitted implementing any one of those methods is a huge win.
  • And: Not having to write a single respondsToSelector: or conformsToProtocol: message at all, because the compiler can now warn and tell you where you messed up, is the biggest win of all.

If you can go further than that by providing a common foundation of actual implementation, creating an abstract class might be an even bigger win (probably not so useful in the context of delegation...) — after all, repeating yourself in implementation is the worst case of shit-work, as every change will result in more shit-work to keep things consistent.

So yes, dynamism is a cool and useful thing to have, as it allows you to pull off all kinds of fun tricks. But in practice, getting rid of some of that (where appropriate) can make your life much easier and keep you from doing shit-work — like writing respondsToSelector:.

Related Topic