Design patterns and design problems

At the moment I’m playing with Ruby (building a Norton Commander thingy based on GTK) and one of the things I’m realizing (again) is that a lot of ‘design’ complexity disappears because Ruby, in a lot of cases, is cleaner and less verbose. For example: in Java you would have to create a Strategy (aka Policy) or Template Method if you need to inject a function, in Ruby you can use a closure. The consequence is that small grained design in Java is difficult, and this is caused by all the syntactic overhead (interface definitions, anonymous innerclasses, template-methods etc).

I don’t say design patterns are bad, but some design patterns (I would rather call them concepts) are harder to implement in some languages, and this inhibits good design: you are damned if you do, and damned if you don’t (if you don’t, your code gets ugly, and if you do, your code gets ugly).

Design pattern = Concept + Implementation
Concepts often are good, implementations often are limited by the host-language.


5 Responses to Design patterns and design problems

  1. You’re absolutely right. A lot of GoF (and other) design patterns are unnecessary in a language like Ruby. Closures help, but duck typing and open classes do too. Adapters, Decorators, etc. I also see closures as a replacement for the Visitor pattern.

  2. -FoX- says:

    Design patterns exist in different contexts. The name of design patterns are often used to beautify some ordinary hacks or workarounds. Examples of those are the fastlane reader, session facade (ejb context) design patterns. These were just used to minimize the use of those heavy EJBs. Others, those that you mention, are concepts to simplify for example certain object constructions.

    But there are also design patterns at a higher, architectural level… such as patterns to do Enterprise Integration (EAI) and I really think those help a lot to gain a deeper experience/thought on certain high-level constructs.

    But then again… do you also think that those higher-level concepts/patterns exist because of technological constraints?

  3. Design patterns are always dependent on the language. For example, implementing a DSL is done differently in RUby and Lisp. Object Orientation in C is another, etc.

    When you are working with a dynamic language, you need different design patterns, but we didn’t specified them yet

  4. Laszlo Marai says:

    I think you’ve misunderstood something. You don’t “create a Strategy to inject a function”. Design patterns are not a way to code something. They are a way to _design_ for some behaviour. Like strategy is a pattern for designing a class that has different strategies for different scenarios. If you don’t use Strategy you may end up with a huge class and a huge switch or if/elseif block in one of the methods. If you don’t use patterns where you should, your code will end up being illogical and unmaintainable.

    Actually passing a (few) function(s) in Ruby can be the _implementation_ of the Strategy (or whatever) pattern. While in Java you need to define the interface. It’s more work but saves you from writing some of the unit tests and documentation. (‘You pass a method here that accepts three arguments where the first one is an object with the following methods….’) But that’s not news, that’s one of the main differences between the two languages.

    Oh, and btw… does anyone knows why there isn’t a high quality NC clone for linux? 🙂 I mean a fully text based one for terminals like FAR for windows. MC sucks big time. I thought that most geeks use NC clones and geeks are way over represented in the linux community.

  5. Dejan Dimic says:

    A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context. – DesignPatternsBook (

    The design problems are independent of the language you use they are in a sense universal. The particular solutions can vary depend on language, framework and actual context.

    If you are a Highlander ( you are thinking of singleton.

    Even more on a everyday bases you should we aware of AntiPatterns (

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: