IT Employment

General discussion


Do you use Patterns in your sofware development work ?

By jslarochelle ·
On my <a href="">blog</a> recently I started a series on the Layers Pattern and its impact on unit tests. Also at work we started a training on Pattern that was quite popular. I find that in practice not only do Patterns help the design process but also they help in communication between developers.
I know most programmers know about Patterns but I'm curious about the impact it has in practice if any.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

I certainly use that one, it's as natural

by Tony Hopkinson In reply to Do you use Patterns in yo ...

as breathing to me.
Encapsulation/separation of concerns writ large in a way.
I'm a big fan of hiding as much as possible from everything that doesn't need to know about it, and that approach is almost self defence in terms opf unit testing.

It's not a pattern I'd but in the same class as Factory, Observer etc though.

What kills me about them, is those who approach design with patterns, instead of looking for the patterns in the design.

Knowing at least the basic patterns, (these nutters who come out with fifty or so really irritate me) is a pre-requesite for the real skill recognising them....

Collapse -

As you can guess the Layers pattern is also a favorite of mine

by jslarochelle In reply to I certainly use that one, ...

Interestingly I would also not put it in the same category as the others. Somehow it feels more fundamental. In fact in the Buschman book it is classified as an "Architectural" Pattern. I guess there is a consensus there even if the line between between Design Pattern and Architectural one is sometimes thin one. Even compared with the other architectural pattern the Layers pattern feels more fundamental so it is definitely special.
The second aspect in your comment (" with patterns, instead of looking for the patterns in the design") I don't totally agree with. I think that less experienced programmer can actually approach design with Pattern to good benefit if they learn to avoid the pitfalls of this. The main problem with this is starting to use patterns everywhere and abusing them. Some rules of thumb can help here:
Is the Pattern really simplifying my design ?
If not, does the added flexibility gained justify using the Pattern ?
Some would call it common sense but it is easy to loose sight of those when starting with Pattern.


Collapse -

Which was my point

by Tony Hopkinson In reply to As you can guess the Laye ...

You have to have a design, to make that assessment does the pattern help or not.

Some patterns are just in there. Choosing to implement instantiation with a factory pattern, isn't going to have a bad impact on a design (generally). Deciding to use a communication pattern, when you don't need one....

For what reason would choose not to layer, (how far you go with it is another question), but short of QAD I can't think of a reason not to.

Collapse -

I think we agree

by jslarochelle In reply to Which was my point

Maybe I was trying to find a nuance where there was none.
I did not have my coffee so its probably just lack of caffeine. :)

Collapse -

Yes we use some patterns

by microface In reply to I certainly use that one, ...

I continually use singletons. publish and subscribe, and factories. Everything else is pretty esoteric IMHO. Since I program a lot of image capture and processing code, I use facades to make different classes compatible with each other.
Well I guess i use more patterns than i thought!!

Collapse -

We all do.

by Tony Hopkinson In reply to Yes we use some patterns

I remember when I read the GOF's first effort, and thought yep, and yep, and done that one, and aye. Made me wonder what all the fuss was about. It's not do you use patterns, it's do you recognise them.

Look there's an Oak and there's a Pine, here's a Spruce. Hey I just invented trees.

Bloody irritating isn't it?

Collapse -

I must say that I felt a little like that at first

by jslarochelle In reply to We all do.

I was thinking: what's the big deal ?
Over the years I slowly learned to appreciate the concept of Pattern for the communication tools it gives us and also for the help it provides to less experienced programmers.
I think that just reading the GOF is not enough because it does not emphasize the underlying principal enough. Fundamental design principles like "loose coupling", "information hiding" must be presented along with the Pattern to get the best mileage.

Collapse -

I learnt coupling and cohesion well before the GOF

by Tony Hopkinson In reply to I must say that I felt a ...

their big moment. Layers, MVC were the result of coding with that in mind.

My objection to the way patterns tend to be put forward now, is I see people trying to fit them into a design, instead of sseing them in the design.
To me the former is just cookie cutting writ large.

Collapse -

Factory is another important Pattern

by jslarochelle In reply to Yes we use some patterns

When I started the discussion I was hoping people would talk about which pattern they use (or as Tony would say "recognize in their code").
One of the things that the Pattern movement brought is standard name for those recipe that experience developers had been using for years. You know how we use to have to say "well I have this class that decouples the instantiation ...". Now you can often just say "I use a Factory". If the other programmer does not know what you are talking about you can still explain of course. But the standard names is a big benefit. And you can reference the GOF (and others).
Another thing of course is knowledge of good design for the less experienced programmers. I remember that before the GOF book not many books where covering that aspect of programming. At least not in this kind of nicely packaged bits of information.

Related Discussions

Related Forums