5

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.

Improve this question
4
  • 3
    "I had seen all the patterns theoretically in Java, thanks to the Head First book" - no, you've seen a selection of possible patterns that the authors of that book decided to write about.
    – kdgregory
    Dec 26, 2011 at 14:09
  • 4
    Design patterns often expose limitations of the specific language ;)
    – Job
    Dec 26, 2011 at 15:38
  • @kdgregory : True.
    – Amogh Talpallikar
    Dec 26, 2011 at 17:49
  • @Job: Thats what I was thinking.
    – Amogh Talpallikar
    Dec 26, 2011 at 17:49

5 Answers 5

Reset to default
2

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:.

Improve this answer
5
  • Thanks .. thats what I wanted. but then how will Obj-C have benefit over say Java. both are mixtures of objects and primitives. n Obj-C is dynamic and we cant as such leverage the benefit of it.
    – Amogh Talpallikar
    Dec 26, 2011 at 13:34
  • I honestly don't understand what you mean and what the existence of primitives has to do with it. My point was: Just because you can use duck-typing doesn't mean you always should. It's a matter of keeping things simple, predictable and thus understandable. Static typing can help here, so make use of it where it makes sense. Make use of the dynamism where that makes sense: façades/proxies, mocks — this is where it really shines!
    – danyowdee
    Dec 26, 2011 at 13:59
  • hmmm right...Totally Got ur point.
    – Amogh Talpallikar
    Dec 26, 2011 at 17:46
  • "Replacing multiple respondsToSelector: methods with a single conformsToProtocol: is a win." You can't just replace respondsToSelector: with conformsToProtocol:. respondsToSelector: works for any type that implements those selectors. conformsToProtocol: only works on types that have declared that they implement that protocol
    – user102008
    May 25, 2012 at 0:40
  • “conformsToProtocol: only works on types that have declared that they implement that protocol” Actually, that’s incorrect with the prime counter-example being proxies: In those you forward such decisions to their target(s), so that the response to that message isn’t even dependent on the receiver’s type… While respondsToSelector: is more granular, that granularity comes at the cost of clutter. In many real-world scenarios you’d need to mix and match both anyways because of optional methods in the protocol. But if the protocol is yours, why not enforce it? That was my line of argument.
    – danyowdee
    May 25, 2012 at 6:44
8

No. This is why I think the Design Patterns book is a load of crud. The thesis of the book is that some things just can't be automated: design patterns.

For example the most famous, the Visitor Pattern .. err .. in an decent language that's a fold (accumulate in C++ STL).

What's actually discovered in the book isn't Design Patterns, but Language Deficiencies.

If there's a pattern, its the goal of language designers to be able to automate it. Almost all type theory research is centered on making polymorphic type systems more expressive.

Improve this answer
3
  • I really need to explore functional programming in detail to be able to compare various patterns and languages. :)
    – Amogh Talpallikar
    Dec 26, 2011 at 17:54
  • You need to do some functional programming to dare to call yourself a programmer at all: even if you work in or prefer other systems, one cannot ignore the only paradigm with a solid theoretical basis and history going back before Euclid (mathematics is a pretty old art form).
    – Yttrill
    Jan 2, 2012 at 5:48
  • rightly said. I am very much interested in looking at functional programming in greater detail. I never had anything related to it in my curriculum. Still I have looked at UC Berkley lectures on Scheme. and I know they r not sufficient at all. anyways.. nothing is sufficient.. learning is a process of lifetime.. I shall keep learning..things as they come.. I always had love for pure mathematics..n its application. I definitely need to get strong hold on FP,DS and OOPS as well.
    – Amogh Talpallikar
    Jan 2, 2012 at 6:28
0

We all know that, specially in programming, there's more than one way to skin a cat. Modern languages are very powerful and flexible these days, and in some cases offer ways around some patterns.

Patterns and the abstract keyword in PHP any many other OO languages is more about structure and integrity. The abstract keyword, for example, gives the programmer instructions as to how to write an extension class. Look at this example: http://php.net/manual/en/language.oop5.abstract.php#example-181

Right off the bat I know:

  1. I can't use AbstractClass by itself. I must write another class that extends it.
  2. I already have the printOut() method available to me, so I don't have to re-write it.
  3. Whatever I do, I must write my own protected getValue() and prefixvalue($prefix) methods.
  4. As long as I follow these requirements, I know it's going to work. When someone else wants to extend this class, they'll know what to do.
Improve this answer
2
  • Why would you want to skin a cat? D:
    – JustSid
    Dec 26, 2011 at 12:51
  • As far as I know abstract keyword in Java,C# or similar languages is used so that we can program to it. and keep code independent of the implementation. but PHP in itself is a weakly typed language where any variable can store anything at any time. thus duck typing is possible. so I dont feel the need of programming to high level interfaces. just pass your object as it is. if it can meow like a Cat..it will definitely be a cat. why do we need to skin it ?
    – Amogh Talpallikar
    Dec 26, 2011 at 13:30
0

Yes. This is why the Design Patterns books are very important. The theses in all of these books is that some things can't be automated: good design.

What's actually discovered in the book has nothing to do with Language Deficiencies, but are patterns of good design. Some of those patterns are filled by language features. Some of those patterns are not filled by language features.

Good design is independent of language.

There are an unlimited number of distinct design patterns. A language designer can't anticipate or fill all of them.

So why do we have protocols here even if we need to use a delegate pattern ?

Because protocols are a language implementation of a good design pattern.

do we need concept of abstract class or interface at all to implement few patterns ?

A formal abstract class is always useful, even in duck-typed languages.

A formal interface is an implementation, used by some languages. The design pattern (even in duck typed languages) still exists.

Improve this answer
6
  • So all the concrete counterexamples of specific patterns being unnecessary in other languages are what, a conspiracy? Of course design patterns are band-aids to patch over language deficiencies. That might not be apparent if you've only ever worked with a single family of languages, but it's pretty damn obvious otherwise.
    – jalf
    Dec 26, 2011 at 16:24
  • "good design" is very much context-dependant. An implementation of the Visitor pattern, for example, is not "good design" in the abstract. It is good design if it is used in a context where no cleaner or simpler solution exists, and in some languages, a cleaner and simpler solution exists by definition because of the existence of fundamental language features. So while design patterns have an weak, indirect relationship with good design, they still exist to cover up language deficiencies.
    – jalf
    Dec 26, 2011 at 16:28
  • 2
    "specific patterns being unnecessary in other languages" is a simple issue of the pattern being already implemented. It's still a design pattern. It's still good design. It's not a problem or a deficiency. It's just that some languages have pre-built support for some patterns.
    – S.Lott
    Dec 26, 2011 at 17:57
  • "An implementation of the Visitor pattern, for example, ... is good design if it is used in a context where no cleaner or simpler solution exists." Correct. "in some languages, a cleaner and simpler solution exists". So? I'm not sure I get the point. Visitor is still a design pattern. It always will be. If you have a situation where you don't need it, then it doesn't go away. You just don't need it. It's a good design. Sometimes, you have a better design. Visitor is not evil; it's just not as good. Some designs are a better solution than others. That doesn't seem to be a big deal.
    – S.Lott
    Dec 26, 2011 at 18:01
  • @S.Lott: you do not understand Design Patterns. The thesis is that they cannot be automated: almost all can be implemented in Haskell, and most in Ocaml, as part of the library, so using them does not require any of the housekeeping crud which characterises a Design Pattern. You have to understand plain English here: Pattern implies redundancy. A fold encapsulates the notion of a visitor with no redundancy and so using one does not involve a Design Pattern .. it's an ordinary calculation.
    – Yttrill
    Jan 2, 2012 at 6:00
0

The main thing I get out of looking at Design Patterns is learning from other people's designs. They are not all applicable to all languages but studying them may teach you about a design you didn't understand or know before. Another benefit is, since we have named designs, we can talk about them more easily with other developers. Even if the pattern would be implemented differently in different languages it gives you tools to compare and contrast as well as present arguments on what situations work well with what designs, and maybe more importantly, which designs don't work with which situations.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.