Design pattern as (missing) language feature

views:

answers:

+1 Q:

Design pattern as (missing) language feature

Sometimes people refer to design patterns as missing programming language features. To avoid the debate about what is a design pattern, let's say we only consider the original GoF patterns. For instance, the singleton pattern vanishes in Scala which supports singleton objects using the keyword object.

There are few resources around about this, notably Are Design Patterns Missing Language Features from the C2 wiki, or Are design patterns really language weaknesses? from SO. But I couldn't find an non-opinionated, objective and comprehensive coverage of this question.

Ideally, I would like a matrix with the GoF design patterns (row) and some mainstream programming languages (columns), where each cell would refer to a discussion about the pattern in the specific programming language.

To avoid the debate about what PL to consider, we can also fix this and pick: Java (as an statically typed OO representative), Smalltalk (as a dynamically typed representative), Haskell (as a functional representative), Scala (as a hybrid oo/functional representative), Lisp (as a meta-programming representative), JavaScript (as a prototype-based representative). And leave other PL for side notes or comments. I know we can argue about this choice, but that would already but really interesting to have that for these languages.

This will anyway always be an open question, but I feel like asked as it is, this is focused enough to have one best answer.

Maybe this matrix already exists somewhere? Or somebody has enough knowledge to craft it? Or somebody is keen enough to start and make it a wiki answer so that other can continue?

+2 A:

The patterns in Design Patterns are a subset of the ever-growing set of patterns people use when programming in different languages. The authors are very clear that those patterns only apply to OOP languages, so many of them won't make sense outside of that context.

At the same time, there are plenty of patterns in other languages that aren't needed in an OOP language. Consider that objects themselves are a pattern when implemented in C or Scheme. In assembly, a call stack is a pattern.

munificent 2010-10-27 01:45:45

+1, I've written OO C code (and state machine C code, which can be really quite similar). I would say that on any device with more than 100K of code space, a call stack written in assembly is a cry for help more than a pattern though.

detly 2010-10-27 01:54:34

Right, some pattern don't apply in other context. It's also fine to me to skip patterns which are not relevant at all, or mention when a pattern doesn't make sense at all in another language/paradigm. But I feel like the following patterns would deserve a discussion outside of the OO context: Adapter, Decorator, Proxy, Command, Interpreter, Observer, State, Strategy, Visitor. And yes, there are plenty of patterns, and language, so I have to somehow restrict the scope of the question.

ewernli 2010-10-27 02:13:10

+1 A:

I personally, after spending some years of doing OOP have found that the problem with design patterns, is that they do highlight the problems with OOP and how hard it is to see patterns in data that is so related to the domain in which it is being modelled. It is very hard sometimes to see the wood for the trees. Some artefacts in OOP simply are there to cure the problems that exist when thinking in that particular paradigm or getting around the encapsulated state and access.

I think that design patterns are great and I use them, however they have been regarded as the fix to a problem that may exist in the inability of OOP to be objective about data structures and functions, so that tried and tested formula can be applied. A simple example would be the Singleton Object. This just disappears when using functional languages and is not an issue.

As one gentleman on SO said when I asked about about UML and if it could be used to model Functional Languages, he said that the modelling language of functional programming languages is maths. I think that this is the key to understanding why patterns are not relevant to functional programming languages, as the theory behind them is steeped in the structures of mathematics.

I can't help you with a crib sheet, but I can be pretty certain that the GOF patterns do not apply to functional programming languages, as they go straight to the real patterns of mathematics as the beauty of functional languages is that they map directly (in most cases) to many many years of solving problems in mathematics. Maybe a brash statement is that the design patterns of functional languages are mathematical theorems with a one to one relationship where OO has a form of artificial abstractions that sometimes gets in the way.

I think that there are some design principals that cross against all languages such as MVC, multi-tiered architecture, scaling out and scaling up. But these I would regard as not being design patterns, more of good software design practices.

WeNeedAnswers 2010-10-27 02:54:10

What you actually say is that some pattern vanish when using other language and it is actually what I would like investigate. Maybe I should however start first by extracting the problem that the GoF pattern solve, and then see how the problem is solved in other language. E.g. the problem of object or data structure uniqueness is solved with the singleton in OO, and disappear in strict functional language. Or is there a kind of conceptual relationship between a Haskell type class and the composite pattern? Sure, I'm a bit comparing apples and oranges, but that's what's interesting.

ewernli 2010-10-27 16:13:35

Or the fact that to interpret an AST in OO you use visitor while you don't need that in functional because of overloading (see the expression problem). Or the interpreter pattern which disappear is the PL support meta-programming. Or the Adapter if you have something like Scala's implicit and extractors, etc.

ewernli 2010-10-27 16:16:27

Yes I am interested in the comparison too. GOF patterns do relate to Object Oriented Design, I don't think what they represent is anything new but they did make the patterns/algorithms accessible to the everyday joe like myself. In all ignorance I just took them on as guidelines, but after looking at the functional style in depth of late, I am beginning to realise that there is a lot more depth to them. The visitor pattern is a classic OO example of what basically is a function that converts one form into another.

WeNeedAnswers 2010-10-27 16:26:22

I would be very interested in a lispers take on patterns. AST is core to the language with no sophistry and not that much sugar coated goodness. I think that we all do patterns in our day to day programming, many of them without even knowing that we are doing them. I was doing the IOC/Injector pattern for years, then I read Fowler and thought, well what do you know! :)

WeNeedAnswers 2010-10-27 16:29:33

ansaurus

tags:

views:

answers:

Design pattern as (missing) language feature

related questions