What if I will not use Software Design Patterns?

Question

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?

Answer 1

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:

1. You can't not use design patterns.
2. By not knowing the names for the things you're using, you'll have a difficult time working in a team.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.