Is there a canonical or favourable classification of software design problems?

Question

The question seems to be quite vague, so let me give some background:

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.

Answer 1

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.

And that's all well and good but you can just walk if you like.

Answer 2

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...
• POSA (aka "Patten Oriented Software Architecture") is a collection of 4 or 5 books from Buschmann & al that identify architectural patterns for specific range of problems like concurrent object management, resource management, system, and distributed computing
• Numberous other books exist about specialized patterns (example software integration patterns)
• 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.

Answer 3

The GoF patterns are not a comprehensive list of software patterns, nor are they intended to provide a generalized framework for solving computing problems or writing an application.

For the most part, the GoF patterns are workarounds for deficiencies in certain programming languages, and that's all they are.

The three categories of GoF patterns:

• Creational Patterns
• Structural Patterns
• Behavioural Patterns

are merely terms that the authors made up for their book, so that they could conceptually separate the patterns into different buckets.