Are design patterns really language weaknesses?

Viewed 5310

Should today's patterns be seen as defects or missing features in Java and C++?

  • Subroutine was a design pattern for machine language in the 50s and 60s.
  • Object-Oriented Class was a design pattern for C in the 70s.
  • Visitors, Abstract Factories, Decorators, and Façades are design patterns for Java and C++ today.

    What will tomorrow's languages look like? What patterns will they have?

12 Answers

I've read somewhere something like "the more patterns you have, the less powerful your language is" and I find this definition very nice.

The reason is IMO clear: if you see a repeated pattern (or you have to use it) it means that it's a sort of copy'n paste at a logical level. Of course it's not as bad as copy'n paste of statements, but it's still redundancy. I'm still repeating myself again and again.

The more the language is expressive and the more you should be able to capture and factor this redundancy out by transforming it in reuse instead of reimplementation, and the reuse will be easier to read and understand in the source code.

Every time you find yourself doing the same thing once again (including e.g. "ok... let's implement an abstract factory here") it means that's something that should have been expressed at an higher level.

Of course sometimes you can try to capture the essence of something, but the reuse may be uglier to read than the reimplementation (I'm thinking for example to some parts of C++ "high-level" stuff in <algorithm>). This is IMO a clear sign that the language is not expressive enough.

To answer the question "What patterns will they have?":

Java haves the Singleton pattern which is implemented in Kotlin with the object keyword

I don't know if patterns are weakness of languages, but for me it's one of Kotlins strengths that it makes the use of Singletons easy.

Related