Design patterns - do you use them?

Question

Being an IT student, I was recently given some overview about design patterns by one of our teachers. I understood what they are for, but some aspects still keep bugging me.

Are they really used by the majority of programmers?

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but Google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look, by the way?) when you start the development? If so, this is certainly a habit that I must start to embrace.

UPDATE: I think when I ask if programmers do use them, I'm asking if when you have a problem to solve you think "Oh, I should use that pattern".

Not an exact duplicate question, but my answer would be the same. http://programmers.stackexchange.com/questions/70877/are-design-patterns-really-essential-nowadays/70893#70893 — pdr, Mar 28 '12 at 09:46
Most of that overrated, overhyped "design patterns" are only relevant to the OOP programming. And there are many good reasons to stay away from OOP for as long as possible. — SK-logic, Mar 28 '12 at 11:07
I find myself using Big Ball of Mud more often than I'd like. Just kidding. — sashoalm, Mar 28 '12 at 14:17
The only answer is yes with the conditional statement of "When appropriate" — Rig, May 16 '12 at 18:18

score 118 · Accepted Answer · answered Mar 28 '12 at 11:02

118

When I was a novice programmer, I loved design patterns. I didn't just use design patterns. I inflicted them. Wherever and whenever I could. I was merciless. Aha! Observer pattern! Take that! Use a listener! Proxy! AbstractFactory! Why use one layer of abstraction when five will do? I've spoken to many experienced programmers and found that just about everyone who reads the GoF Book goes through this stage.

Novice programmers don't use design patterns. They abuse design patterns.

More recently, I find that keeping principles like the Single Responsibility Principle in mind, and writing tests first, help the patterns to emerge in a more pragmatic way. When I recognise the patterns, I can continue to progress them more easily. I recognise them, but I no longer try to force them on code. If a Visitor pattern emerges it's probably because I've refactored out duplication, not because I thought ahead of time about the similarities of rendering a tree versus adding up its values.

Experienced programmers don't use design patterns. Design patterns use them.

answered Mar 28 '12 at 11:02

Lunivore

4,232
1
18
23

2

@schlingel - Why are you calling the OP Sir? – Oded Mar 28 '12 at 19:34
11

@Oded I reserve my right to be called "Sir" under these circumstances and enjoy it. – Lunivore Mar 28 '12 at 22:27
3

Sir, yes sir. No offence meant! – Oded Mar 28 '12 at 22:40
No offence taken, unless you particularly like TFS, in which case I'll find an excuse... – Lunivore Mar 28 '12 at 23:00
@Lunivore - lol. Have worked with TFS, can't say I miss it and its idiosyncrasies. – Oded Mar 29 '12 at 08:27
1

In Soviet Russia.. :) – Sorantis Mar 29 '12 at 11:10
5

Good answer, but in the last line you tried to be profound, but it is nonsensical. How about "Experienced programmers don't choose design patterns, they let them happen." – Garrett Hall Mar 29 '12 at 13:22
1

Thanks for the feedback @Garrett-Hall. Pretty happy with the 50+ people who liked the answer as it is though. – Lunivore Mar 29 '12 at 18:18
@GarrettHall As someone who agrees with this answer 100%, I'd have to attest that the answer seems just right as-is. – Wil Moore III Apr 02 '12 at 23:51
I'd agree with this to a point, however its interesting to see how different platform communities think of Patterns. Some communities see them as something to implement in your applications directly, whereas others see them as general solutions that should be part of the language or framework. – stevenrcfox Jul 03 '13 at 13:41
Isn't it better, though, to use well-known patterns instead of programming "blind" - especially when you are new to programming? At least when doing production-bound work. Of course experimenting to learn is a different case. – Juha Untinen Aug 16 '13 at 08:37
1

@Juha-Untinen If code has simply been developed without reference to patterns, it's unoptimized, but can be refactored without too much trouble. New devs tend to put too many patterns in, and those patterns can often be cemented in place. I'd recommend letting an experienced dev pair with a junior, or teaching them TDD which helps the patterns to emerge, rather than letting anyone program against known patterns *or* blind. And devs can experiment safely with katas, rather than production code. – Lunivore Aug 16 '13 at 09:39
(Actually, it's not just new devs - even more experienced devs overabstract sometimes. Took me a month to get Dan North's visitor pattern out of JBehave; he still tells that story!) – Lunivore Aug 16 '13 at 09:39
@AaronHall Thank you! Much appreciated; I like me some shinies. – Lunivore Aug 13 '15 at 14:23

score 44 · Answer 2 · answered Mar 28 '12 at 09:45

44

Whether one recognizes them or not, most programmers do use patterns.

On the day to day work however, one does not start programming with a pattern in mind - one recognizes that a pattern has emerged in code and then names it.

Some of the common patterns are built into some languages - for example, the iterator pattern in built into C# with the foreach keyword.

Sometimes you already know the pattern you will be using as a common solution to the problem at hand (say the repository pattern - you already know you want to represent you data as an in-memory collection).

answered Mar 28 '12 at 09:45

Oded

53,326
19
166
181

13

That's pretty much what I was going to say, patterns are a *language* to help programmers communicate design and implementation ideas, not a set of programming *lego bricks* which can be slotted together to implement a system. – Mark Booth Mar 28 '12 at 10:08
A pity that `foreach` is a blindingly stupid idea. – DeadMG Mar 28 '12 at 10:39
27

@DeadMG Why is that? – Kris Harper Mar 28 '12 at 10:50
11

@DeadMG: I must have been blinded by the blindingly stupid idea - I can't see why you think it's stupid ;-) – Treb Mar 28 '12 at 11:48
2

@root45 - You see friend, the `foreach` construct makes programming too easy. How can one feel superior to others if a complex task like iterating over a collection is easy? I for one still code in assembly for all my CRUD apps. Clearly the sentiment of @DeadMG is one of pure pragmatic genius. – ChaosPandion Mar 29 '12 at 01:14
Language grows, that isnt about stupidity.. – Independent Mar 29 '12 at 05:45
Probably because you could trivially implement a library solution using LINQ. Adding a language feature where a library solution is equally good in all cases is bad. – DeadMG Mar 29 '12 at 08:18
8

@DeadMG - LINQ wasn't around when .NET 1.0/1.1 was. `yield` didn't exist then either. Do you think that breaking old code by removing a keyword is a better option? – Oded Mar 29 '12 at 08:29
@Oded: No, the better option was to say "Gee, guys, I wonder why we're implementing a language feature to cover this one special case? Maybe it would be a better idea to simply do something more generic. Perhaps we should take inspiration from the already-existing C++ Standard Library, which does exactly this as a pure library solution, and then neaten it up a bit, cause iterators suck, and then we'd be left with something vastly more useful." – DeadMG Mar 29 '12 at 08:30
@DeadMG - I think most comments regarding your first comments are asking about this: "cause iterators suck". Can you explain your views? Why do "iterators suck"? – Oded Mar 29 '12 at 08:44
@Oded: I was referring to C++'s iterators, not iterators in general. `foreach` being stupid and C++'s iterators sucking are orthogonal things. I merely brought it up because it's obvious that any hypothetical C# committee would want to fix them and have something like LINQ instead. My point is that the need for something more generic than `foreach` is obvious and well-known for a long time, and including it rather than inventing LINQ was a mistake. – DeadMG Mar 29 '12 at 08:45
1

@DeadMG - That was very much unclear from that comment... and probably why people were asking you to clarify. – Oded Mar 29 '12 at 08:46
@DeadMG Could you provide a link which expands on your position with respect to "the need for something more generic than foreach"? I've never heard this viewpoint and would like to understand it better. – Wesley Wiser Apr 02 '12 at 17:52

score 22 · Answer 3 · answered Mar 28 '12 at 10:36

As implied by the answer pdr linked: design patterns are names given to things people were doing anyway, intended to make it easier for people to discuss those things.

In general it's worth learning them when starting out, because they give you some insight into solutions people have found to work, so you can build on years of experience, and trial & error.

The discussion of motivating problems included with patterns may give you insight into good ways to attack your problem in the first place, but unless your pattern knowledge lets you recognize there is a well-known existing solution, you still need to focus on just solving the problem first.

If it turns out to use one or more existing patterns then great, you have ready-made names that will make it easier for others to understand your code.

+1 for a significant summation of what I wanted to say: Focus on the problem, and then, and only then, if the problem looks like one a pattern solves, apply the pattern. — Joshua Drake, Mar 28 '12 at 12:39
+1 for stating the true fact that design patterns are *names given to things people were doing anyway*. — miraculixx, Dec 20 '12 at 00:27

score 12 · Answer 4 · answered Mar 28 '12 at 10:38

12

Generally speaking, no. There are times when patterns emerge from my code, but in general, I don't look for them and I certainly don't say "Oh, the Bridge Pattern would solve my problem!".

Here's the thing. Most patterns are abused and misused without people ever considering if they're good design. Patterns are not atoms. Code is not comprised of X permutation of patterns. Not to mention that not all patterns are actually good ideas, or that some languages have language-level solutions that are vastly superior to some patterns.

answered Mar 28 '12 at 10:38

DeadMG

36,794
8
70
139

+1: I agree that patterns sometimes are misused. Sometimes I see code where the programmer has used a pattern just because he or she knew it and thought it was cool, but that made the code just unnecessarily complex and hard to read. Like cracking a nut with a bulldozer. Regarding language-level solutions, isn't a language-level solution just a pattern that is directly supported by the language? Or what is the difference? – Giorgio Mar 28 '12 at 18:40
1

@Giorgio: Framed another way, some patterns are used to work around the fact that the language lacks a way to express a certain thing neatly. – Daenyth May 16 '12 at 16:38

score 8 · Answer 5 · answered Mar 28 '12 at 11:46

8

yes, most programmers I've ever encountered use the most common pattern there is, the Big Ball of Mud. They usually start out with well-designed architectures, but usually end up here, especially if they start to think "we must use design patterns" all over the place and refactor mercilessly.

answered Mar 28 '12 at 11:46

gbjbaanb

48,354
6
102
172

2

The link made my day – dukeofgaming Mar 29 '12 at 07:43
1

Ouch. That web-page needs some text formatting. – Nailer Apr 24 '12 at 14:39

score 7 · Answer 6 · edited Mar 29 '12 at 10:22

do you use them?

Yes, experienced programmers definitely do. You can avoid using most design patterns (excluding simple singleton stuff) for now; but the more you program and the more complex systems you build, the more you will feel the need to use design patterns. If you still avoid it, you will begin to feel the pain when you have to expand your system and change it as per new requirements.

If somewhere in the web I find a way to solve my problem, is this a design pattern?

Not necessarily. A design pattern refers to a specific way to design classes, their behaviours and interactions to achieve a specific goal (or avoid a specific problem). What you may have come across may not really be a design problem but a specific sequence of steps to program a certain API. For example: there is a certain sequence to establishing a socket connection. Do it wrong and your socket wont communicate. That sequence of steps does not constitute a pattern.

do you (programmers) find yourself looking for patterns

Yes. Design patterns embody the "prevention is better than cure" axiom. If you can spot a particular upcoming design problem beforehand, you can prevent massive redesigns to accommodate changes later. So it pays to know design patterns beforehand and look for places where you need to use them as you build your application.

where am I supposed to look btw?

Since you are a student you have probably not seen the typical problems that inspire design patterns. I strongly recommend that you look at Head First Design Patterns. They first present a design problem and then show how a particular pattern can solve/avoid it.

score 5 · Answer 7 · answered Mar 29 '12 at 00:36

Design Patterns were not taught when I was in school. And, for most of my programming career, I've worked with legacy, non-object oriented code. In recent years, I've tried to learn them because they sound like such a good idea. However, I must confess that every time I've ever picked up a book or tried to read a tutorial on the subject, my eyes have glazed over and I've not really learned anything practical about them at all.

I can't believe I just admitted that in public. I think I've probably just lost any geek cred I may have established over the years.

score 3 · Answer 8 · edited May 23 '17 at 12:40

Don't look for trendiness

Any standard programming solution to a certain problem can be considered a design pattern, it doesn't matter how popular they are, or if other programmers use them or not.

You might already be using a design pattern that hasn't been invented/specified yet.

Don't try using them, try thinking in their terms

The problem with design patterns is that sometimes programmers want to fit their problems into them when it is the other way around.

Remember design patterns' design convention have a typical problem to solve, you can even combine design patterns to tackle other bigger problems. This is kind of typical in Service-Oriented Architectures, just see some of the SOA patterns there are.

Look for them in the wild

There are plenty of open source projects where you will find applied design patterns. One example that comes to mind is Joomla: you will find singletons, observers. GUI libraries will have the decorator pattern, command pattern implemented, and maybe even flyweight.

There are other patterns such as data patterns, for example the Doctrine Project alone has used, the active record pattern (1.x), entity manager pattern(2.x), unit of work, repository, query object, metadata mapping, data mapping, and other more general ones like the strategy pattern, and decorator pattern.

There are just so many interesting solutions to choose. See Martin Fowler's Patterns of Enterprise Architecture, there are also data model patterns.

Just learn them for when the time comes

Learn them, know them, obsess over them and when the time comes you'll know how to solve programming problem x, you will be a better programmer already by that time.

Become an architect

I'd say that being able to think in pattern terms to solve problems, effectively turns you into a software architect. Even if you don't want to be a software architect per se, your solutions will have more technical quality, be cleaner and better scalability —in terms of design— by default.

score 1 · Answer 9 · answered May 16 '12 at 16:22

I've programmed for about 7 years in C++ and learned patterns about 2 years ago. Most patterns probably have some applications, but in my usage, some are better than others. You have to think why you are using them.

The iterator pattern has actually made my code more confusing and has added unnecessary complexity. I can get the same maintainability using typedefs for STL vector types. And any changes I make to the class being iterated I also have to make to the iterator class.

The factory method, however, has been extremely useful, based on the polymorphism it provides. I forget who said it, but the statement "reusability means that old code can use new code", is definitely true with the factory pattern.

I've used the template method pattern for years without even knowing it was a "design pattern".

The Observer pattern has been helpful in some cases, sometimes not. You have to sometimes predict complexity to determine if the overhead complexity of the Observer pattern is worth it. We have a program that uses about 10 subscribers and there could be many more, so the observer/subscriber pattern has been helpful. Another program, however, has two GUI displays. I implemented the observer pattern for this program, and it has been largely unnecessary, simply because it added complexity and I don't anticipate adding more displays.

I think those who say to always use patterns assume that your program is going to be infinitely complex, but like with everything, there is a break-even point in terms of complexity.

score 1 · Answer 10 · answered May 16 '12 at 17:30

Adding to Lunivore. Id like to quote this from the head first book

        ## **Three steps to great software** ##

Make sure the software does what the customer wants
Apply good object-oriented principles
Strive for a maintainable, reusable design

It is during the third stage, after your system is working the way it is supposed to.Its time to apply the patterns to make your software ready for years to come.

score 0 · Answer 11 · edited Mar 29 '12 at 10:13

Learning patterns is not just learning something. You learn what you can do with programming languages. I for myself learned a lot about object-oriented programming just by learning how a pattern works (the composite pattern in this case).

As mentioned by Oded, most programmers use them sometimes without even recognizing it. The beauty of patterns is that you can adress specific problems with a predefined pattern so you don't have to think a lot about architectual things.

score 0 · Answer 12 · edited Mar 29 '12 at 10:17

0

You will learn patterns as you start working with existing projects. There are so many patterns out there for you to learn, and it is not worth the time to master all of them as it depends on what project you are working on. Whenever you run into one, learn about it to see how it is used.

edited Mar 29 '12 at 10:17

Peter Mortensen

1,050
2
12
14

answered Mar 28 '12 at 18:27

Ammar

207
2
5

score 0 · Answer 13 · answered Mar 28 '12 at 18:44

Are they really used by the majority of programmers?

I would guess yes. In ADO.Net there is a DataAdapter class to give a simple example though depending on what area you want to specialize the patterns may vary.

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

No, that isn't a design pattern to my mind. A design pattern tends to have some arrangement of classes and methods that define the recipe of a pattern.

I'd prefer to think of what you did there as a common practice. Beware of copy and paste coding though.

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look btw?) when you start the development? If so, this is certainly a habit that I must start to embrace.

Sometimes as I see the same code over and over, I may find a way to refactor the code into a pattern or if I remember a solution to a similar problem involving a pattern I'll take it out and use it. Head First Design Patterns has more than a few patterns in it while Refactoring would be a suggestion for coding practices that may lead one to find various patterns. If you want another possible starting point, look at Microsoft's Patterns and Practices.