Polymorphism in Design Pattern

Question

I have observed that most of the design patterns (I refer mostly from the Gang of Four book) are all based on polymorphism. That leads me to a "enlightened" moment that OOP's polymorphism is the most important feature in the paradigm.

Some of the patterns use polymorphism are: strategy, factory, bridge...

With that, I don't understand why we are not just teaching developers really good polymorphic behavior of OOP instead of overloading them with a bunch of patterns which in fact are based on polymorphism?

Answer 1

Wouldn't

really good polymorphic behavior

actually be how to apply the Gang of Four patterns in a good way?

As in, how to apply strategy as a tool so that you don't violate SRP for example.

Answer 2

Every language has its features that are the "killer features" of the whole concept. OOP, being some of the largest and oldest branch of advanced languages has polymorphism, but I can point out other amazing features such as strong functional programming, closures, parallel execution, and other unique things to other languages that are along the same lines of amazingly-powerful features that are must-haves.
Teaching just one method quickly turns you into a one-trick-pony. A strong foundation in theory allows you to pick up a very "different" language like Lisp or Erlang and know what's going on.

Answer 3

Because, while polymorphism is used to implement the patterns in OO languages, but the patterns can be implemented without it (for example, imagine implementing a factory in C).

Additionally, design patterns are, like polymorphism, tools that help developers solve problems. Only learning a subset of the tools (eg, only polymorphism) will put developers at a disadvantage because they will need to “work from first principals“ (so to speak) instead of basing their work (and their thought) on higher level concepts (like design patterns).

Answer 4

Well, polymorphism is one of the fundamental concepts of OOP -- it's at a different level of abstraction than the more detailed patterns.

I don't think there is a problem having names for and teaching the more detailed/dependent patterns, it really does help with communication. But as you suggest, a solid understanding of polymorphism is definitely required before a developer would be able to effectively implement any of the dependent patterns.

Answer 5

This is a red herring. Some languages implement this as polymorphism. Others can implement it as interfaces. Still others can use duck-typing. Forcing readers/students into thinking "polymorphism" doesn't actually help in all situations without also being taught the other two mechanisms, which don't exist in every language. At that point it becomes noise.

Answer 6

@Ignacio Vazquez-Abrams I don't think duck-typing, interface and abstract class are different interpretation of polymorphism. If a implementation can not be determined at compile time and must be defined at runtime, it is polymorphism. You can name that concept anything you like, at the end of the day it is the definition of polymorphism. This is coined late/dynamic binding albeit the same principle.