What kind of problems may I face, if I won't use Software Design Patterns? Can you tell me about the problems of approaching the design using standard object-oriented techniques?
-
24Quite a few Software Design Patterns are fairly obvious. You would have to know them all very well to be sure you aren't using them - probably well enough that you might as well use them!– James McLeodCommented Nov 28, 2013 at 15:49
-
18As a side point to @JamesMcLeod, many "Design Patterns" are very obvious and things everyone would do anyway. Why do we give them names, then? For the purposes of communication. "I'm using the X pattern" has far greater semantic density than explaining your solution in the hopes the other end will go "Oh yeah! I've done that too, except I called my variables...".– PhoshiCommented Nov 28, 2013 at 16:18
-
7@AJMansfield Some of the worst code I've seen involved overenthusiasm for design patterns.– Erik ReppenCommented Nov 28, 2013 at 20:27
-
5@ErikReppen the blame for overuse of design patterns should be attributed to the person who does it. From my perspective, the core problem is not in design patterns itself, but over-generalization (partly due to lack of architectural oversight) and over-engineering (sometimes by committees-of-engineers).– rwongCommented Nov 28, 2013 at 20:40
-
5"Design Patterns" is a lexicon, not a technique.– Kaz DragonCommented Nov 29, 2013 at 12:15
|
Show 6 more comments
7 Answers
You're missing the point.
Design Patterns inherently exist when doing software design, just like structural patterns exist in the world. Even if you don't know the name of things, you'll eventually find that certain physical structures are well suited for certain problems. You'll find that a triangle shape of wood/metal bars/etc is a very stable structure, but only on a plane. You'll find square bricks have certain advantages over round ones...
Likewise, certain software structures are in some way unique or optimal. You'll eventually find them and use them regardless if you know the names for them. That's the core of what design patterns are - they're names for these structures that experienced programmers know and use anyways. It gives programmers the ability to communicate much more uniformly and succinctly. It also lets programmers think in the concept of patterns more consciously.
So the two key points I'm trying to make:
- You can't not use design patterns.
- By not knowing the names for the things you're using, you'll have a difficult time working in a team.
answered Nov 28, 2013 at 17:03
-
12+1: Absolutely right. I started OO development before design patterns became known or popular. Yes we also invented things like factories, singletons and something that, when you squinted at it in a bright light sort of looks like the Strategy pattern. The point is now that I know design patterns I know the the factories were OK but could have been done better, the Singletons were badly done and what might have been a Strategy pattern would have been much better if it actually had been a Strategy pattern. Commented Nov 28, 2013 at 17:20
-
3... Learning about design patterns, and learning how to use them correctly saves you so much time, you're less likely to try reinventing the wheel, stops you from leading yourself down a road towards bad design and building bad solutions. Suck it up and learn the patterns, use them when they work for you, and don't use them when they won't. Commented Nov 28, 2013 at 17:22
-
1And this sums up exactly my views on patterns. They're wonderful tools for communicating what you're doing with other people. You never build them exactly though because every problem is different. But they're a gist, a direction, and a rough set of guidelines to follow, and it makes it easy to explain to others what the heck you're doing.– Matt DCommented Nov 29, 2013 at 4:20
-
+1 for the comparison to physical structures. I would add that it helps to build a house if you already know that a "truss" is a good structure to support the load of a roof, rather than experimenting and hoping that it doesn't collapse. Commented Nov 29, 2013 at 13:35
Those who cannot remember the past are condemned to repeat it.
You will not face any specific problems other than the ones raised by your design. And in time you will end up using the patterns without being aware, you just spent time figuring them out by yourself. Knowing the patterns beforehand makes them easier to spot in the design and bear the major advantage that they are proven by a number of individuals.
Everything that's being developed today is based largely on previous knowledge, it would make no sense to ignore it. Imagine building a skyscraper today without knowing the problems faced by the people who built cathedrals some hundreds years ago.
-
10"Every quote has an equal and opposite unquote." "We must tear asunder the past if we are truly to deserve the future." (OK that one was Hitler so probably best to ignore it....)– RussellCommented Nov 29, 2013 at 1:01
What kind of problems may I face, if I won't use Software Design Patterns?
You'll have the problem of not being able to write any software.
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.
Can you tell me about the problems of approaching the design using standard object-oriented techniques?
No. I have no idea what this question means. Design patterns are "standard object-oriented techniques" -- that's what makes them design patterns. A design pattern is a standard technique for solving a particular problem, particularly (though not necessarily) in an object-oriented language.
answered Nov 29, 2013 at 3:53
-
1
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.- That's (almost) the definition of a design pattern - a flexible/easily-reusable code construct used to overcome a limitation in the language itself, that is easy to communicate to others. Once it's part of the language, it's no longer a design pattern.– IzkataCommented Nov 29, 2013 at 17:32 -
1@Izkata: So your position is that, say, the observer pattern is impossible in C# because C# has the observer pattern built into the language in the form of events? That's silly. The language-specific bit that is relevant to a pattern is the canonical way to implement the pattern in the language. Of course design patterns can be used in languages that support them directly; that's the whole point of supporting them directly! Commented Dec 2, 2013 at 14:58
-
I never said impossible, I was trying to imply unnecessary. Java, for example, does not have events so it uses the design pattern to simulate them.– IzkataCommented Dec 2, 2013 at 15:27
-
@Izkata: I'm confused then. You said that once a pattern is part of the language it is no longer a pattern. So is "the observer pattern" a pattern in Java but not a pattern in C#? Commented Dec 2, 2013 at 15:52
-
1Or to put it another way, a design pattern is anything a programmer does, than can be described in English. I'm not sure I entirely agree with the definition, but I think it accurately reflects what you're saying and at least has the benefit of no subjective judgement what counts as a pattern. It's a property of analysis of what programmers do, and of course it's not possible for a programmer to act in a way that cannot be analysed :-) Commented Feb 27, 2015 at 13:18
Understanding the point of a design pattern is more important than using it to the letter. Some patterns are, IMO, silly, at least in the language paradigms I'm accustomed to. IMO, a programmer who simply uses design patterns blindly and without really understanding them is a worse programmer than the one who would want to think through things themselves. But somebody who familiarizes themselves with the ideas and then decides for themselves whether they're worthwhile is likely to be a much stronger programmer than either.
That said, I have no !@#$ing idea what the point of flyweight is and I'm not ashamed to admit it. (see comments for another wikipedia entry that helped a lot)
I recommend wikipedia's entry on design patterns. It's very concisely and clearly written. Very helpful for getting an idea of why one might bother with a given design pattern or not. I personally tend to find the simplest ones the most useful and wouldn't think twice about modifying a given implementation of any pattern to suit my needs.
They're ideas, not blueprints. In some languages they're not very good ideas at all. In others, they're rightly seen as being kludges for overcoming a language's design weaknesses that might be better compensated for through less complexity. Regardless, it doesn't hurt to examine them and try to understand the challenges they're meant to overcome before deciding on your own preferred solutions.
What kinds of problems will you face? You might miss opportunities and spend more time on problems than you needed to unless you're a programming genius who already has it all figured out. It's important to maintain a critical eye of popular programming ideas but it never hurts to understand what it is people think they're solving because that will lend more clarity to your own preferred solutions/approaches.
-
2flyweight (not flywheel). Read the first paragraph (and only the first paragraph) of the wikipedia article and then look at Integer.valueOf(int) and consider how many times this avoids creating new integers for common values.– user40980Commented Nov 28, 2013 at 20:19
-
2@MichaelT And damn. That did spell it out a hell of a lot better than anything I've seen. Thanks. Commented Nov 28, 2013 at 20:23
-
The problem that I see with most of the design pattern instructions is that they try to give a big project view (the GoF book is all about writing a word processor - not a small task). But sometimes they're applicable to much smaller (almost 'trivial') things. 7 lines of code can cleanly describe the flyweight in something that everyone uses constantly. Much easier to understand than the big projects or contrived examples.– user40980Commented Nov 28, 2013 at 20:28
-
1@MichaelT For me it's also a good example of how getting a little clarity on something is helpful to writing code in general even if that idea has no immediate use in my primary language, JavaScript, where prototypal inheritance and closures are typically used to solve that problem. Having that a-ha moment still gave me some ideas that are relevant. Commented Nov 28, 2013 at 20:49
The main problem you'll face is that you will be reinventing the wheel. They are called patterns because they appear often and in a predictable manner.
Even if you follow the design patterns you might end up with a bad design. Design patterns are natural and you will end up using some flavour of it in your design. You will have to try really hard not to use any of the patterns. There is not reason to condemn design patterns, whats more important is to pick the right patterns for your needs
You're using design patterns all the time without realizing it. A lot of standard libraries in popular languages are designed with design patterns in mind. An example is Java's FileReader library which is designed using the decorator design pattern. Now talking about your own code, you're not forced to use design patterns (in most cases). A design pattern is a "reusable solution to a commonly occurring problem", meaning it will help you with writing cleaner more maintainable code so it's really up to you how much you want to avoid ending up with spaghetti code.
