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.

Design Patterns Completely Out of Hand?

Is it just me, or are Design Patterns just getting completely out of hand?  I look at an object model nowadays, and it literally takes ten minutes to find a class that looks like something that exists in reality!  All I see is factories and facades and adapters and dependency injections and strategies and visitors and mementos and bridges!  For heaven's sake, it was easier to grok Algebraic Topology because at least a compact space looked like a compact space and not fifteen visitor/memento/bridge space adapter factories.

Comments?  Concerns?
Bob
Friday, July 14, 2006
 
 
Design Patterns don't kill projects, people kill projects.

If you have a handful of people who have just figured out Design Patterns, they are likely to do stuff like this and make things a mess for everyone after them.  Alternatively, there are a handful of tools/frameworks - especially on the Java side - that seem to encourage this sort of behavior. 

One developer I know of regularly shares the latest way he's managed to abstract things and refactor out the explicit code.  While a degree of this is good and useful, at some point, it makes a system unmaintainable for others.

Oh, and don't crosspost.
KC Send private email
Friday, July 14, 2006
 
 
It's just the latest fad/iteration of programmers being given a hammer and assuming every problem is a nail.

Design patterns are intended to take complex ideas and put them into a universally friendly, easy to follow format for a very specific problem case.  When you start to take the approach of using as many of them as you can in as many places as possible you are defeating the intended purpose of the pattern.

Pick up the book on refactoring to patterns.  It's really how good software development is done.  Write it once in the simplest manner that works, when the BUSINESS NEED jumps in and complicates it, refactor to a pattern.  If the business need never comes, leave it alone.  You're wasting time, clarity, and money otherwise.
Eric Wise Send private email
Friday, July 14, 2006
 
 
I have likened design patterns to analogies; proof by analogy is fraud keep in mind...My first thought when I hear this phrase.

Design patterns are best used to describe a complex system in a universal language so that everyone is on the same page, I can not argue with that benefit.  Taking spaghetti code and turning it into ravioli code by class explosion is as insane doing "unstructured" structured programming.

If I have a sub-system that monitors a particular port for incoming data and notifies approved recipients via e-mail notificiations of errors on the delivery - I have a singleton, a vistor/observer/subscriber pattern, and in the grand scheme of things, a facade for the entire subsystem since it housekeeps the mundane and keeps quiet except on things it can't handle.  What I don't have is 200+ version of classes and subclasses based off of pattern names from the GoF and other "Patterns of Enterprise Architecture" books in the code to implement it.

I use all sorts of patterns in my day to day coding but I *rarely* deliberately subclass some class(es) in my code that is literally referred to as class AbstractFactory or ChainOfResponsibility.  Sometimes the code is clearer when doing so but often times I resort to using pattern names in the documentation that describes how a group of functions, classes, and/or modules interact.

Perhaps I don't get it either?  I don't know.  *shrugs*
Chris Send private email
Friday, July 14, 2006
 
 
This approach is totally out of academia. Coders do it *because* it makes their code impossible to understand. Some thing with the template metaprogramming crap. Take something simple and make it complex and incomprehensible. Then lord it over others who question your design as pretenders who are not leet enough.
Art Wilkins
Friday, July 14, 2006
 
 
It's always been easy to overengineer. Design Patterns (capital D capital P) are just another tool the kit.

I like to apply the Feynmann Signature Test to cases of overengineering. See http://tinyurl.com/zxzzf and search for "One time a science teacher" to read it. They are a good way to illustate absurdity while still conducting good science.
Robby Slaughter Send private email
Friday, July 14, 2006
 
 
"This approach is totally out of academia."

Bingo. Academia focuses on the abstract. They're looking for a general vocabulary that they can share regardless of the actual underlying problem.

The software developer is actually expected to translate that vocabulary into something that's meaningful within the project and by extension, see which aspects of the design pattern are really needed. For example, an observer class wouldn't be called "Observer" but rather something like "InvoiceTotalDiscrepancyErrorCatcher".

Unfortunately, a lot of developers think the design patterns are law, and if you don't do it exactly that way, the program won't work.
TheDavid
Monday, July 17, 2006
 
 
Actually, I think you'll find that most of the Design Patterns buzz originates from 'enterprise architect' types in industry, and that academics tend to sneer at them a bit too (albeit for different reasons).

That says there has been some interesting work on comparing some of the common Design Patterns with certain structures and idioms in functional programming. Often a complicated bloated great Design Pattern reduces to quite a simple concept in a functional language.
Matt Send private email
Wednesday, July 19, 2006
 
 
I observed once (http://fish37.livejournal.com/6564.html) that for some people "are not merely possible (albeit very
good) approaches to problems (and indeed are
generalizations of good approaches to common problems that
have arisen). In fact, they are the only way to solve
problems, and that they must be copied from of the book,
or else it wouldn't work. They wouldn't know a pattern
they haven't read about if it bit them on that place their
head is forever hidden in. If GoF didn't write about it,
it ain't a pattern."
DEBEDb Send private email
Friday, July 21, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz