2

Are design patterns (e.g. factory pattern, observer, etc...) required to be known to write good code?

I often have no idea of what people mean when they talk about inserting pattern name here pattern and sometimes I realize I‘ve implemented that pattern without knowing it even had a name.

I‘m a self-taught programmer so I try to learn about patterns as I go, but are they necessary?

I find them over-engineered sometimes, like just fancy design concepts that programmers sometimes overestimate and force themselves to use them even if they can write clean and working code that is however not a common pattern.

superM
  • 7,363
  • 4
  • 29
  • 38
user39517
  • 113
  • 3
  • Another related one: [How to determine whether Design Pattern is implemented correctly?](http://programmers.stackexchange.com/questions/157343/how-to-determine-whether-design-pattern-is-implemented-correctly). – Joachim Sauer Jan 21 '14 at 15:36

3 Answers3

9

Design patterns are not required in order to write good code.

They are names given to certain known good solutions to common programming problems. Chances are good that you have in fact used some design patterns without known (for example - the iterator pattern is built into several languages as it is so prevalent).

Knowing the names and meanings of design patterns is simply an aid to professional conversation (and for naming of variables and methods) - when you and the other party are familiar with design patterns, it is clearer what is going on.

What you shouldn't do is look for ways to implement a specific design pattern - you should be looking in the other direction - finding the patterns that already exist in the code and optionally, rename the code if they make it clearer.

So, you don't have to study or know the patterns and their names in order to be a good coder - if you are a good coder, however, chances are good that you are already using many patterns without knowing so.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • 2
    Studying patterns is something one generally only does before a job interview.. particularly for a Java gig. Like Oded said, you've probably used many common 'patterns' without realizing it, but you need to know what their names are :) – James Adam Jan 21 '14 at 15:15
  • `Design patterns are not required in order to write good code.` You only explained how knowing their names is not mandatory, but it doesn't mean they're not required or at least highly recommended. – Pierre Arlaud Jan 21 '14 at 15:16
  • @ArlaudPierre - you can write good code without knowing the details of design patterns. Are you saying that people did not write good code before the GoF book came out? – Oded Jan 21 '14 at 15:19
  • 1
    @JamesAdam: Or, if you're old enough, you answer the interviewer with, "Look, sonny, I was doing this long before anyone came up with fancy names for common solutions to problems. Let me put my teeth in and tell you all about it." :-) – Blrfl Jan 21 '14 at 15:21
  • I have to add that the Design Patterns book itself details additional concerns that you have to take into account when using the patterns. Sure you may be using the design patterns accidentally but you may be forgetting the edge cases that are covered in the book! Design Patterns the book is only useful if you read it and apply what's in there, otherwise yes design patterns are only good for interviews ;) –  Jan 21 '14 at 15:38
  • @Oded: I'm rather saying that design patterns existed before the GoF came out. – Pierre Arlaud Jan 21 '14 at 16:02
  • 2
    @ArlaudPierre, I think Oded is trying to point out the difference between Design Patterns (as espoused by GoF) and design patterns(the good code we have been writing for years without putting a name on it). Good algorithmic solutions to common problems have existed for a very long time. However, putting formal names on them and arguing about Patterns and Anti-Patterns, etc. has changed the discussion landscape. Personally, I think we have put too much emphasis on Design Patterns instead of design patterns. – cdkMoose Jan 21 '14 at 17:06
1

Yes, patterns are essential. I'll refer you to What if I will not use Software Design Patterns? by Eric Lippert in which he points out:

Variables are a design pattern.

Methods are a design pattern.

Operators -- addition, subtraction, etc -- are a design pattern.

Statements are a design pattern.

Values are a design pattern.

References are a design pattern.

Expressions are a design pattern.

Classes are a design pattern.

Everything you do in programming at all times is a design pattern. Most of the time the pattern is so ingrained into your thinking that you've stopped thinking of it as "a design pattern". The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.

This goes to your point of that you've used design patterns without even knowing its name. You've also used ones that you did know had names but didn't realize they were patterns.

The key is how people think about patterns... and to an extent I blame education (or maybe the lack of) at times where they expect Design Patterns to be like Legos - "we'll get a Abstract Factory, and Flyweight, and a Singleton and a Facade... and it will all just fit together." One can often see this in questions asked "What pattern do I need for problem XYZ" before they've really started coding or thinking about the project as a whole.

Looking at the original book A Pattern Language (wikipedia) about building architecture, a Pattern is something that you use to solve a particular design. You want to put a window in a stud wall? Well, then you put in some cripples and a header and a bottom plate and so on (wikipedia). This is a pattern and you do it because you want to put in a window in a wall.

Note that in the above example, the problem came first, then the design pattern. I need this, this is is how I'll fix it. The other way around "I'll put some cripples, bottom plate and so on here so that I have a window because I'll need a window" is the wrong way to go about the pattern of a window. Likewise, it's the wrong way to go about using patterns in software development.

The other thing to realize is that if you have two people working on putting in a stud wall, they can quickly communicate and understand what is going on when they put in a window. They both know and understand the problem and the pattern and how to apply it. The same is again true with software. We've got a problem that we need too many Integer objects being created? We'll put in a Flyweight. And thus, two programers have communicated, and know how to solve the problem because they are able to speak of Patterns.

Community
  • 1
0

No. Patterns are best applied to write code that others (and yourself down the road) can understand.

Applying a pattern willy nilly will make it a fancy design concept, but when a pattern fits a problem it is better to use than come up with a creative solution.

Patterns are generally cliches, they work and you likely have used quite a few without realizing it, but this is not an excuse to ignore learning about them as you will find some that you don't know of and it will broaden your own knowledge of programming rather than figuring out everything yourself. As a self-taught programmer this is a vital piece of development to come to terms with

Kevin
  • 798
  • 3
  • 7