The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Super Patterns og "Patterns of Patterns"

As an Enterprise, Application Architect with a love for SOA and a tendency to write  code when ever I can find an excuse and the time for it, I just love software Patterns. My life would just not be the same without them. Having been buried in work doing SOA for a couple of banks during the last couple of years, I have really not updated my knowledge on Patterns very much, but usually go with the patterns presented by GoF back in the 90', and a few other patterns that I find very useful in relation to web services, handling XML and SOA.

Then today as a subscriber to Grady Booch's blog, I followed his link to with a catalog of patterns (You have to register to se the catalog). The list is now more than 1200, and Grady claims that the list is far from complete, as well as he has a few hundred that he has not yet added.

I used to love frameworks, but as frameworks expanded and increased in both complexity and abstraction, I felt that the advantage of using frameworks declined. At least that was how I felt, but I was not alone. Remember "Why I Hate Frameworks" by BenjiSmith?

Well to get to the point, with many thousands software patterns, I believe that it’s just a matter of time before we will start seeing, “Patterns of Patterns”, abstracting the use and implementation of patterns. It could even be the next big buzz word. “Super Patterns”! But will this really add value to that way we use and implement patterns, or will I once again be left behind, with the feeling that things get so abstract and distant from the actual implementation, “The code that compiles and fulfills its purpose”, that I no longer will be able to see the added value from these “Super Patterns”. Also just looking at the list with over 1200 patterns, I already feel overwhelmed with having to descide what pattern to use where. Wonder if there is any patterns or framework for selecting the right pattern for the job? I mean there is no way that I will be able to know all of them in enough detail to know for sure that I have chosen the best pattern for the job.

So what do you think?  Do you think the value of patterns is on the rise or is it declining? Is there something new going on in the world of patterns that I am missing, that can help me in finding my way around in thousands of patterns? In what direction is the concept of patterns moving, will it be Super Patterns, patterns for selecting patterns or some grand Framework to handle all the patterns?
ThMoJe Send private email
Thursday, October 05, 2006
I think there are a lot of people who use patterns for their own sake or because they want to collect the set, rather than using them as a means to an end for solving appropriate problems.
John Topley Send private email
Thursday, October 05, 2006
Patterns describe precisely those things that the implementation language is failing to provide more elegantly.  Over time, languages need to absorb these ideas into 'first class' language features.  They're just the crutch we have to put up with in the meantime.  So, super-patterns are just proof that language design is super-behind where it should be by now.
Notorius L
Thursday, October 05, 2006
As a developer I like the idea of patterns getting absorbed into languages over time. But as an architect my use of patterns is different. And as more and more developers use patterns and get to work with their own set of favorite patterns, I as an architect tend to spend more and more time on deciding what patterns to apply where. Also, as an Architect I can not allow all developers to just use their favorite patterns to solve recurring problems7challenges, as I need to account for both reusability and maintainability long after a creative developer leaves the company, and leaves behind code that implement some unknown pattern that no one know how to maintain or re-use.
ThMoJe Send private email
Thursday, October 05, 2006
Super patterns are here - MVC is an extension of Observer, and there are more.

Some people love to write patterns, some love to write programs. Looking for patterns is good brain trainer.

"I as an architect tend to spend more and more time on deciding what patterns to apply where" - I use another approach sometimes. I write code first and make it work. I refactor to patterns after. Remember - Friendster abandoned Java in favor of PHP!
Denis Krukovsky Send private email
Thursday, October 05, 2006
Ugh. Twelve hundred patterns? That's just the paragon of stupidity.

The whole point of the pattern concept is to provide a lexicon of software engineering metaphors, so that engineers can communicate with one another using a small, manageable, and agreed-upon set of abstractions.

How is anyone supposed to keep a lexicon of 1200 patterns in his head? And, if there are 1200 different patterns in this lexicon, how likely am I to re-use those metaphors and abstractions on multiple subsequent projects?


How many copies of his book would Steven Covey have sold, if it had been called "The Forty-Eight Million Habits of Highly Successful People"?

There are only seven habits (few enough for everyone to memorize), and furthermore, they're just overall guiding principles, rather than rigid structures of behavior.

Likewise, software patterns are not supposed to be rigid logical structures. (Whenever I hear someone saying they want to "comply" with some pattern or another, a little piece of my soul dies.) Instead, patterns are just guiding principles for organizing software. You don't have to "comply" with a pattern. A pattern is just a nugget of accumulated wisdom about a technique that has worked well for some common situations in the past.

One of my simulation applications contains a ProbabilisticChooser class (for choosing between N elements in an unordered set, where all of the elements have a different likelihood of being chosen). Should that class be a part of an official Pattern Repository somewhere? It's a second-cousin of an Iterator, so it's really at the same level of abstraction. Should I quiz interview candidates at my company about the new ProbabilisticChooser pattern?

Personally, I find the whole pattern craze nearly as maddening as the framework fad.
BenjiSmith Send private email
Thursday, October 05, 2006
+1 for "The whole point of the pattern concept is to provide a lexicon of software engineering metaphors, so that engineers can communicate with one another using a small, manageable, and agreed-upon set of abstractions."

It's just too difficult to choose a pattern for any given situation -- at least for me. It needs a lot of experience.
hobit Send private email
Thursday, October 05, 2006
Personally when I am building an application which contains a lot of transactions I find that design patterns are the wrong level of abstraction. I often find myself copying an existing transaction which works on tableA so that the copy will do exactly the same thing on tableB. The only difference between the two transactions is that one works on tableA while the other works on tableB, so the similarities form a repeatable pattern. I can now use that pattern to create similar transactions for tableC, tableD, tableE, and so on.

Each transaction may implement any number of low-level design patterns, but that is irelevant. When designing and buildng an application which needs sets of transactions to deal with each of its numerous database tables it is far, far easy to approach the problem from the perspective "which single transaction pattern do I need here?" rather than "which group of design patterns do I need here, and how do I join them together?"

Read here for more:
Tony Marston Send private email
Friday, October 06, 2006
>Do you think the value of patterns is
>on the rise or is it declining?

Actually I would hate to see that as a buzzword technology.

Even if the GoF wrote in the their book that there ARE more patterns than discussed, I am sure that the 1200 patterns are 95% other names for the existent 90 patterns in the GoF book.

A valuable software engineer knows patterns and might know some of the very exactly. But the important thing is:

You need to get a feeling for that and adapt concepts for your own. Use a pattern, modify it to your needs, but don't create a new name for it.

How do you search for the exact pattern you need? The time you need to find it is possibly higher than just creating your own concept, if you are a bit experienced.

And everytime a co worker is proposing to use a this and that framework for something I am askung for the purpose.

Example: I once wrote an very simple XML lexer/parser in C. It is fast, small (about 60 lines of code) but of course lacks of all features like DOM/DTD/Schema etc.

We are using libxml2 now to read an (compiled to a C array) config file. It costs at least 300ms to create the DOM of it, but my parser runs all in 15ms.

For my purpose, it is better to re-use the small code fragment as using an full spec lib.

All of the framework/superpattern/stiffystuffy sourceforge boiling is overrated.

Know your tools and be bold enough to make your own.
Usually this is much more powerful than knowing buzzword interfaces (see CS students.... argl)
Husker Send private email
Saturday, October 07, 2006
I forgot one:

Relying everthing on Frameworks and stuff is often enough serving one hidden purpose:

-> Shift the responsibility to someone else.
Husker Send private email
Saturday, October 07, 2006
I can't wait for the day when all of those evil and defective "patterns" become pure and noble "first class language features".

Once all known problems are implemented in the ultimate language, then all code will be reduced to "dwim" and the compiler will run and produce perfect code when it realises that I need it.

But until that day we'll be forced to actually waste our time solving problems, and some sick people will write down a description of a problem, a solution, and enumerate the trade-offs involved in the solution given. And then they'll be told they're worthless because a real language would have included the solution to their problem as a first-class feature.

Even with your favourite managed and/or functional programming language, there are still problems that need to be solved using those languages, and it's usually helpful to be able tolearn from the work of others.

(Also, relying on "operating systems" and "compilers" and "interpreters" and "databases" and even "hardware manufacturers" and all that is just "shifting responsibility" too. Sometimes responsibility needs shifted.)

(And for the newbies amongst us, dwim means "Do What I Mean" and is the ultimate goal of having a telepathic sentient AI instead of these clunky and obtuse programming languages like python/haskell/java/C++/lisp/ruby/etc/etc)

Monday, October 09, 2006
>(Also, relying on "operating systems" and "compilers"
>and "interpreters" and "databases" and even "hardware
>manufacturers" and all that is just "shifting
>responsibility" too. Sometimes responsibility needs

yes, you are right. "sometimes" is the key word here.
Husker Send private email
Tuesday, October 10, 2006
So there are really  no “Super Patterns” or what?

We just have:

“Wanna-be patterns” – Patterns that really is just a special case of temporary patterns.

“Temporary Patterns” – Patterns that only exists because today’s programming languages and compilers does not (yet) have the feature to handle the task.

“Genuine Patterns” – Solutions to programming problems so complex, that no programming language or compiler will ever be able to handle the task.
Alternatively, “Emerging patterns”, given one believe that no problem is to complex for a future programming language/compiler to handle it.

So overall, the whole pattern thing is just about someone noticing a recurring problem, finding a way to manually handle the recurring problem, and then some one makes the machinery to automate the handling of this recurring problem. In the meanwhile, other machinery builders plans and makes a 95% look-a-like.

Hmm, I think I have seen this kind of pattern before…
ThMoJe Send private email
Tuesday, October 10, 2006
This seems like pointless quibbling.

If the GoF had chosen to use the word "concept" instead of the word "pattern", would we really be having a conversation about how many concepts there really are, or whether it's possible for some conecepts to contain other concepts?
BenjiSmith Send private email
Tuesday, October 10, 2006
life has more than 1600 'patterns', why can't software - its dynamic & creative - an expression...don't put down something you can't comprehend, understand the principles, ie. encapsulation/composition, rtc...
Sunday, October 22, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz