Object Mentor Blog: Solution Probleming

Solution Probleming

Tim Ottinger — Fri, 23 Mar 2007 11:07:00 +0000

I’ve been fortunate enough to have spent most of the past three weeks teaching advanced Object-Oriented Design with patterns. The students have been wonderful and helpful and brilliant, so the classes have gone very well.

As I introduced students to Visitors, Adaptors, Chain of Responsibility, and mult-level State patterns, I was reminded of the problem that was rampant in the 90s: Having learned a catalog of patterns, many OO designers could not wait to put them into practice. Rather than using patterns to solve problems, they began to look for ways to apply these pattern solutions.

I call it “solution probleming”, which is of course the opposite of “problem solving.”

It wasn’t just the patterns community, it was software tools and it was frameworks and languages. A company I know used to say “I don’t know what the problem is, but the solution is DB2, CICS, and COBOL.” That’s solution probleming. It’s one of the reason that so many of us strive to not be product-based consultants. We want to solve problems, not just shoehorn prefab solutions into people’s applications.

I think any well-developed software developer’s immune system should be wary of the smell of solution probleming. It’s one of the best ways I know to overcomplicate and overengineer a solution - which is one of the worst ways to develop software.

"Solution Probleming" by Tim

Fri, 23 Mar 2007 14:35:44 +0000

I don’t always do that, but I do frequently mention that some of the patterns are language-specific and some are much easier to use in dynamic languages.

It’s also not a straight patterns class, we talk more about design principles and practices, while covering a pretty decent starter-set of patterns (some advanced).

"Solution Probleming" by muumi

Fri, 23 Mar 2007 12:46:13 +0000

I hope you have emphasized also that design patterns are often to overcome the restrictness of the language used. For example, the problem of exploring a class hierarcy outside is much better done with pattern matching than visitor. See: http://www.artima.com/weblogs/viewpost.jsp?thread=166742 Also in much more detail: http://www.scala-lang.org/docu/files/MatchingObjectsWithPatterns-TR.pdf

But of course there’s always room for design patterns; but they should be focused on design, rather than implementation hacking.