I have given the concept of design patterns some thought and stumbled upon the classification used by the Gang of Four:

Creational Patterns

Structural Patterns

Behavioural Patterns

Since design patterns are intended to be solutions for common design problems, the classification should apply to not only to the patterns but to the underlying problems as well.

Somehow the classification seems to make sense and I find it hard to figure out a design problem that cannot be put into one of these categories. On the other hand I find it somehow arbitrary.

Isn't creation a kind of behaviour? Doesn't it sometimes depend on the point of view if something classifies as behavioural or as structural? Why are there creational patterns but no 'destructional' ones?

Is this classification an invention of the Gang of Four or has it been used before? Can it be derived from some theory? Are there alternatives?

While this question is related to my previous one, it differs in two aspects:

It is about the classification scheme and not about the patterns themselves.

It is not about patterns but about the design problems intended to be solved by patterns.

"Is this classification an invention of the Gang of Four" Yes. "Can it be derived from some theory? Are there alternatives?" No and No.
– EuphoricNov 27 '16 at 19:29

Could you split your question into several different questions so it is not so broad?
– Tulains CórdovaNov 27 '16 at 23:33

1

Martin Fowler had been collecting software patterns for many years, so: on one hand, we now know more design patterns than the ones described in GoF, and on the other hand, new patterns keep coming up (some of them enabled by technological breakthroughs such as cloud computing and massive solid state persistent memory), so the list of software patterns will never be complete. Do not confuse software patterns with computer science algorithms.
– rwongNov 28 '16 at 0:21

I think the reason that you can't find any problems that don't fit these groups is that "behavioural problems" is an extremely vague catch-all... if a problem doesn't encompass behaviour at least in some fashion, it wouldn't actually be a problem, because we wouldn't care about it ... because at the end of the day, we write software for the behaviour it produces. If some code doesn't produce a behaviour we want, we wouldn't write it, because it would be useless.
– Periata BreattaNov 28 '16 at 10:58

3 Answers
3

The fundamental misconception is that for a given problem there is a given pattern.

Patterns are not lessons about how to code. They are a vocabulary we use to describe patterns we recognize in code.

I can solve any problem in a way that avoids any currently documented pattern. If I do that though I'm going to have a tough time explaining how my code works to anyone else.

It's true that pattern choices are impacted by the problem, but they are also impacted by the language (and it's deficiencies), but mostly they are a mater of personal style.

Any collection of patterns is incomplete precisely because anyone can create a new one. What you've been learning are simply the popular ones.

The popular ones are good to know because I can tell you: "oh, that class is a decorator, you know, the decorator pattern?" without having to go into details about function composition, interfaces, and delegation.

Creational just means the point of these patterns is to construct (initialize) some object.

Structural just means the point of these patterns is to create some data structure.

Behavioral just means the point of these patterns is to behave the way some use case needs the program to behave.

These are very different goals that have nothing to do with classifying a problem. They are parts of solving one. If the problem is getting from point a to b these tell you ways to build a car, navigate a map, and get a drivers license.

Software eats the world. Hence, your challenging question sound like cutting the universe into predefined lego pieces. Different authors have different views about what these pieces could be:

GoF used 3 main categories that address usual class design problems

Martin Fowler wrote a book entirely dedicated to "Patterns for Enterprise Application Architecture", that identifies different categories of patterns for designing business software architectures. These are split into specific categories such as domain logic, data source, object-relational mapping, metadata mapping, web-presentation, etc...

Programming languages come also with some idioms that could be viewed as low-level patterns (e.g. RAII in C++, or Input/output streams in C++, Java and other object oriented languages).

The thing is that these categorizations are not all at the same level of abstraction. They may further overlap.

Finding a general categorization of all software problems seems therefore as ambitious as finding a general programming language that would ideally fit all the programming needs. Or a universal software analysis methods that could decompose any programming problem into predefined pieces.

This just ain't possible : this could be made for known problems as these books have shown. But there are so many new areas or technologies in SW development and so many interaction between all the different parts. I'm afraid you will not find such a general categorization.

" patterns are workarounds for deficiencies in certain programming languages" Once again with that misinformation. Patterns are ubiquitous in all languages. Its just different languages (or different paradigms) have different patterns.
– EuphoricNov 27 '16 at 20:22

4

@JacquesB: The Builder Pattern is a good example of a workaround in Java. It's completely unnecessary in C#, because C# provides optional constructor parameters with default values.
– Robert Harvey♦Nov 27 '16 at 20:37

5

@RobertHarvey: to be fair, that is not the only problem a Builder can solve, which makes this pattern not unneccessary in C#, only less frequently applicable. Builders are useful when the construction process for an object so complex they justify a class on its own. And I don't see how this could be compensated by a language feature which is currently missing.
– Doc BrownNov 27 '16 at 21:45

2

@RobertHarvey Agreed on the enormous complexity. Builder should be a last resort, and shouldn't be used unless all other alternatives had been exhausted. But I have seen a few situations where it's genuinely needed. If you ask whether software patterns are dangerous, I would compare that to asking whether car driving is dangerous. There are experienced and inexperienced car drivers, on the same road, and you can't immediately tell who is the inexperienced until bad things happen.
– rwongNov 28 '16 at 0:52

2

It's the Josh Bloch Builder that simulates named parameters in Java. The GoF builder is a different beast that delegates to lower classes the details of exactly what type to build when asked. These are not the same thing. It's unfortunate that the patterns have such similar names but that's the way it goes in this business.
– candied_orangeNov 28 '16 at 1:08