PDA

View Full Version : Design Patterns: Useful?


maskedMan
04-17-2009, 09:27 PM
Maybe the subject I'm about to discuss is a matter of religion, but I'm curious how those who have dealt in the subject feel about design patterns.

Today I came across a rather vitriolic blog posting by a fellow who is rabid in his hatred for design patterns, as well as languages such as C++ and Java. http://realtimecollisiondetection.net/blog/?p=44 Truly, I can see a point in his cautionary tale. At the same time, the tale has several other takeaway lessons completely separate from but ultimately just as important as the one he intends to make. For example, when you treat your subject matter / problem domain with snide derision and glance through your specifications without care, you're going to choose the wrong solution to the problem. Period.

Are there people whose paradigm centers around patterns? Of course there are. Are they uniformly bad at what they do? Judging from my peers I would say not. Is it the fault of the GoF that the ones who are bad inflict their pain on themselves and the world at large? Are they brainwashed fools who try to pound screws with a hammer because they found a hammer that looks really nifty? I cannot say I agree with the sentiment that the GoF book (nor the Head First book which are the two I have read in the most detail) make any claim that one needs to use any of these patterns. In fact, both books explicitly contain caveats that these are not the only (or even best) way to approach any given situation, and the GoF book in particular goes out of its way to explicitly list the costs along with the benefits of using any given pattern.

Are patterns just buzzword-centric attempts to rename what were already common practices that are well-known by 'any programmer worth his salt'? I think the phrase 'any programmer worth his salt' in this case more accurately translates to 'anyone with a formal education in computer science', as many of these concepts are not in the slightest bit obvious to people who are approaching code for the first time and / or from a different discipline. Is polymorphism obvious to someone who came to Flash from HTML? Is the concept of a binary tree or a linked list obvious to anyone who comes to Flash from graphic design? Perhaps actionscript.org contains a larger number of CS majors than say, a flash animation or cartooning forum but many of us arrived where we are from a very different starting point than the blog author.

Do I personally use or like design patterns? I guess that depends on the pattern. ;) More specifically though, I have found reading about them instructive in the sense that they are built heavily upon abstraction and while a house cannot be built out of air (with our current technology at least), judicious application of abstraction where implementations are likely to be volatile can save you more than a teaspoonful of heartache. Some people learn this well from classic OO books. Some people learn it from seeing an example of such an implementation in a design pattern. I'm sure that sort of lesson is very elementary to many people. To that I say, not everyone learns in quite the same way.

ASWC
04-17-2009, 10:28 PM
I do see what you mean, even though I'm still working on my B.C.S. I've been introduced to most concepts so far and met quite a few OOP crazy geek and they could all tell you their version of what is good OOP practice. Furthermore some could also tell you what is a REAL OOP language and what is not as in "C++ is the only programming language worth talking about" and other "Java is the only serious language out there". Then of course they can tell you what is the right way to write code. Listening to all that I came rapidly to the conclusion that following what these people say is exactly like following table dressing rules where it's absolutely indispensable that the red wine glass be this one and the white wine be the other, the fork MUST be in that place and in that position and so on. There's two way to go about this, either you like all these principles and you go for it or all you want is eat and drink and you don't care in wihc glass you pour your wine!

Xegnma
04-18-2009, 12:04 AM
It all boils down to a simple maxim: "Its not what ya got, but how ya use it"...Nuff said.

maskedMan
04-18-2009, 02:08 AM
On another note, I'll say that the other blog posts I've read of this fellow are pretty interesting, even if his writing style is at best acerbic.

ASWC, I've met some people like that as well. Sometimes there's an interesting idea in their zeal, so I try to listen. There is always something of value, even if you have to dig through a lot of crap/attitude to find it.

In my experience, there's always some external factor that will dictate what constitutes "good" code and "good" practice. In the world of modern video game graphics programming, efficiency and aesthetic are the Holy Grail. It would stand to reason then that someone involved in that realm would push for what makes their lives easier. This will invariably color that person's perception of what is acceptable.

In my own little corner of the coding world, the art is handled by artists who know nothing of code and the art is their purview. Likewise, we who write the code to not create the art. While there are boneheaded approaches to coding that would kill performance (many timers, enter_frame events, repeated recursions, and so forth) the vast bulk of performance hits in the projects I'm involved with come from unoptimized art. The difference in milliseconds from accessing a function vs a variable, or using Number instead of int, or Object(foo) vs (foo as Object), or even delegating responsibility of when a Class is allowed to perform some action to an aggregated policy or strategy Class simply make no difference when compared to the lag that happens when you multi-mask a million filtered movie clips, or have 5x the stage's width of graphics sitting around in the display list. The truly awful processor sinks on my end are easy enough to avoid. What makes my life easier is being able to plan a structure that is sufficiently abstract that when the project specs change arbitrarily and without warning that I'm not caught flatfooted with only half a day to make the change.

Sometimes, patterns or derivations thereof are useful for doing this.

DougyTheFreshmaker
04-18-2009, 03:04 AM
Wrestling with Sony's consoles in C++ for so long has exposed a few of his nerves, it would seem :)

I would not worry about Christer's diatribes. Design patterns are at the tip of his iceberg of disdain, the rest of which includes, but is by no means limited to, well principled object oriented design and the object oriented paradigm as a whole. It is difficult to appreciate design patterns when one rejects the philosophy on which they are based.

Two quick asides:

* Christer's book on collision detection is an *excellent* resource for anyone interested in real time simulation, including games. The book is well written, accessible, thorough, and not a fraction as opinionated and rant-y as his blog and forum posts may be. No need for OOP/OOD discussions there, for the most part!

* Second, as an opinionated rant of my own: programmers make too many ridiculous analogies. The Plank? Statistics test? Who gives a ****? If Chewbacca lives on Endor, you must not apply GoF design patterns!

My opinions, however, are in agreement with the core of his post which I take to be this: Worse, it’s pure poison to the malleable brain of a young programmer! Thinking in patterns is exactly the wrong thing to do! It makes you think in terms of the solution instead of in terms of the problem! Design patterns evolved from the repeated application of well principled design, and, in my opinion, so should a programmer's use of them. When confronted with a problem, your first thought should not be "what patterns are applicable?" Rather, your designs may begin to resemble patterns which you have seen, and at that point those patterns may be worth investigating. For the novice, in particular, the low-hanging fruit of a design pattern often leads to a bloated, complex program from which the beginner programmer gains little knowledge or skill.

A second complaint of Christer's, which I also agree with to an extent, is the idea of excessive labeling: there are patterns everywhere, but that doesn’t warrant giving them names as if they are important. We do not talk about the “handkerchief pattern” or “hammer V-claw pattern” even though the former is an accepted solution for blowing your nose and the latter is the accepted method for pulling out a nail.
This point is debatable, and I'm split on my own decision. Nomenclature is an often cited reason for the existence of design patterns, but it may be unreasonable sometimes. Many patterns differ only by "intent" or by author, clouding the purpose of giving a particular approach a well-defined name.

All of this is opinion, of course, for this religious debate.

maskedMan
04-18-2009, 03:28 AM
Thanks for the additional information. I did in fact read several of his anti-OOP rants and they're thought provoking. I don't intend to come off as dissing the man himself or his knowledge, as he's obviously highly learned. I wouldn't have written this post had I not thought the contention worth a serious examination.

I'm certain that at some point I'll be faced with many of the problems in the book you mention. I'll be sure to check it out.

yell0wdart
04-18-2009, 04:23 PM
That was an interesting post. I'm not really sure what to make of it, initially. It sounds to me like rants from a guy who's stuck on procedural development and is trying to resist OOP and design patterns with everything he's got.

I agree with a lot of what you guys have said (maskedMan, ASWC and Dougy). The results that you get when using design patterns (from a development and a professional/career) perspective, to me, more than prove their worth. Not only are they a solution to common problems (as Dougy mentioned), they offer a common language to developers. If I'm writing something in C#, I can tell a Ruby developer that I'm using an MVC pattern to achieve something... they may not understand the syntax, but they can get the gist of my chosen architecture. That, in itself, is very powerful... communicating with other developers in language-agnostic terms.

They're not the best solution to EVERY problem, more a guidepost to help you arrive at a solution. He did have a point in that "thinking in terms of solutions" can obscure the problem. That's a very important detail. I think that "thinking in terms of the problem" is the most important part of solving the problem. If a design pattern fits, great. If not, no need to force it, just keep at it... sometimes the solution is more simplistic and less convoluted than a design pattern... sometimes it's not.

I haven't encountered many of the C++ or Java purists... maybe because I didn't major in CS. My degree was in Fine Art. I taught myself how to code, all about design patterns, agile development, and good OO design practice by reading LOTS of thick books and practicing what I've learned.

I've been toying of going for my master's in CS, though... I'll be curious to see how the line of thinking differs from the "real world".

Mazoonist
04-18-2009, 11:10 PM
Consider Actionscript 3.0: Do you like the display list, with its DisplayObjects and DisplayObjectContainers? It's an example of the Composite pattern. Do you like the convenience of the event model, with its event dispatchers and event listeners? It's an example of the Observer pattern.

So if you are using Actionscript 3.0, you are already taking advantage of at least these two patterns (there may be more, I don't know), which are built in to the framework, even if you don't care to do any OOP programming yourself.

kkbbcute
04-19-2009, 03:02 AM
As a person who once hated Design Patterns just a month ago, I think I can lend some interesting insight on why many people have this extreme anti-design pattern stance and just go on ranting.

And the main problem here is this, people just try to over complicate things to look "professional". Seriously, I think Mazoonist has made my point even more clear, that ever thinks of the event model as the "Observer pattern". When you speak of event models, an average guy would know what you are talking about, but when you talk about the Observer pattern, only a select few individuals, a niche in society will understand what you are talking about. People who don't understand these points will of course find those who do, annoying, as if they are trying to look of a higher calibre by just using bug words.

And actually, wwhen I was forced to make the change to pure OOP and the supposed effective design patterns, I found them to vbe almost the same as what I've been doing for the past what, one year and three months, ever since I started using AS and Flash? So in effect, the reason why some people don't like the idea of design patterns is just that it could be made simpler, but we don't.

It's like scientists, why use large words like "Rough Endoplasmic Reticulum" to describe a part of a cell? Well, people say that it helps to be exact, to have a universally understood term, but they forget to mention the main point, universally understood by a small niche of people who are educated in that field. If we want OOP and design patterns to spread, maybe we could just start saying "Using the event model" instead of "Taking advantage of the Observer Model", and actually let a larger audience get into the idea of deisgn patterns.

yell0wdart
04-19-2009, 04:56 AM
If we want OOP and design patterns to spread, maybe we could just start saying "Using the event model" instead of "Taking advantage of the Observer Model", and actually let a larger audience get into the idea of deisgn patterns.

This is exactly the point of design patterns. Design patterns (observer) were applied in the language's syntax to achieve the event model you speak of (as you pointed out). I wouldn't say a select few understand design patterns. It's gotten to the point where it's becoming an industry standard. :)

Most developers I've worked with apply them and work with them on a daily basis. Most development shops encourage them... and many ask you design pattern related questions in the interview process. Other types of development aren't as big on design patterns and OOP (embedded systems, etc), but the industry has been moving in that direction for almost 20 years now.

I think the one of the great things about patterns (like kkbb mentioned) is that you can show people who don't understand design patterns the benefit of them by pointing out pieces of their own code where they applied a pattern without even knowing it.

When they're used correctly, they work wonders. When they're not, they can make the problem more difficult than it needs to be. However, I think the same can be said about many development practices. UML anybody? :p

kkbbcute
04-19-2009, 08:16 AM
This is exactly the point of design patterns. Design patterns (observer) were applied in the language's syntax to achieve the event model you speak of (as you pointed out). I wouldn't say a select few understand design patterns. It's gotten to the point where it's becoming an industry standard. :)

How about people who want to get into the industry, how would they blend in and accept things easily if they are all jargon? Not so easy, is it? That's why many of the people who hate OOP and design patterns are beginners, they just feel, ostracized. (I can't think of a better term)

yell0wdart
04-19-2009, 08:43 AM
How about people who want to get into the industry, how would they blend in and accept things easily if they are all jargon? Not so easy, is it? That's why many of the people who hate OOP and design patterns are beginners, they just feel, ostracized. (I can't think of a better term)

Gotta pick it up somewhere. I'm self taught as well. ;)

The thing that really made the biggest difference for me was that I had a good friend of mine who had been in the business since high school coaching me. He handed me a book on OO design principles and one on design patterns (Head First: Design Patterns). I had no idea WTF they were when I first picked it up. As I read through the books, I refactored little projects I had done to incorporate what I was learning. Did wonders.

If you're going the informal route (like many of us have/are), that's where communities like this come in. We can support each other, offer guidance, tips, tricks, etc. I've also found it very useful to network with other developers in my area (been trying to go to the various .NET user groups and functions around me... not many Flash dev ones yet, though).

On the more traditional end of the spectrum, more and more universities are teaching them. I've met quite a few folks just out of college with their CS degree that learned design patterns during their studies.

The fact that you're going through this learning process now just shows that you're WAY ahead of the game. ;)

maskedMan
04-19-2009, 03:21 PM
How about people who want to get into the industry, how would they blend in and accept things easily if they are all jargon? Not so easy, is it? That's why many of the people who hate OOP and design patterns are beginners, they just feel, ostracized. (I can't think of a better term)

Firstly, OOP and design patterns are not interchangeable. The latter is built on concepts that you implement in the former. I'd gone years knowing the basic concepts of OOP before even hearing about design patterns. I think that was probably a good thing.

Where do they learn about it if they're not already in the business? School, for one. Social interaction with people involved in industry for another. When I say school, I mean education beyond high school. I wouldn't expect high school students to be taught these things (or rather I *would* in an ideal world expect that high schoolers were educated such that these concepts were readily available to those who showed the ambition, but that's a totally separate discussion). Even if you are not in college, you could still check out books from the public library or save up your money and purchase some good ones for cheap on the internet. College and self study both can teach you a lot if you are willing to learn.

If we want OOP and design patterns to spread, maybe we could just start saying "Using the event model" instead of "Taking advantage of the Observer Model", and actually let a larger audience get into the idea of deisgn patterns.

It's not really accurate to talk about 'the event model' when you're talking to anyone outside the realm of Actionscript, though. The event model is Actionscript's built-in implementation of the Observer pattern, so when you are talking with people in a cross-discipline environment you can explain that there is an observer pattern built into the language and that they do not need to roll their own.


As for the fact that the patterns seem like complicated ways to go about doing simple things, there is truth to this. If your problem is simple, and your problem is unlikely to change, and your problem will not grow, there's no need to use them. I got by plenty well without using them formally for a long time. I don't expect that you'll find yourself in a position where taking full advantage of them will be particularly helpful until you are in a job situation where requirements and specs are highly volatile. Implementing a good abstraction (whether it is a formal pattern or not) that can easily be used with any number of concrete implementations makes your work more flexible and easier to modify.

ASWC
04-19-2009, 09:23 PM
Without mentioning that one can use OOP, use design patterns and still write poor code!

kkbbcute
04-22-2009, 05:31 AM
Without mentioning that one can use OOP, use design patterns and still write poor code!

I agree, poorly written code (and uncommented code) really frustrrates me sometimes, especially those with blocks of unused variables and uncommneted code which I don't get.

yell0wdart
04-22-2009, 06:35 AM
I agree, poorly written code (and uncommented code) really frustrrates me sometimes, especially those with blocks of unused variables and uncommneted code which I don't get.

Haha! You'd enjoy some of the code (and developers) I've had to work with in the "real world". Just wait till you get grouped up with a bunch of developers who feel that their code is "self documenting"... some people who feel that way, I've found, can have some of the nastiest spaghetti code out there. :)

There's such a thing as over-commenting, ie:


// set x to 5
x = 5;


Smart commenting can go a LONG way, though. It's good that you're getting into that habit now. The kind of comments that are the most valuable are the ones you read when you have to change code you wrote like 6+ months ago and you have to try to figure out what you were smoking when you wrote it. ;)

DougyTheFreshmaker
04-22-2009, 01:49 PM
While I would like to post dissenting opinions on the topic of commenting, I will refrain as I support the idea of one religious war per thread :p

kkbbcute
04-22-2009, 01:50 PM
@yell0wdart: I think that your example of over commenting was a hyperbole :p

But anyway, on a personal level, I feel that over commenting is usually not that much of a problem as few people bother to over comment, they are just lazy.

Mazoonist
04-22-2009, 02:01 PM
No comment.

kkbbcute
04-22-2009, 02:05 PM
No comment.

Then don't comment :p

Why do I have this feeling that this conversation is going off topic? BACK ON TOPIC!

maskedMan
04-22-2009, 02:52 PM
While I would like to post dissenting opinions on the topic of commenting, I will refrain as I support the idea of one religious war per thread :p

Oh come on. Here, let's go for the gold...


// this class is a factory for foo objects
public class FooFactory(){
//{ <-- for those who like to see a brace on the following line...

public function getNewFoo():Foo{
//{
//Make a new foo object and return it as a value.
return new Foo();
}

}

kkbbcute
04-22-2009, 03:09 PM
No, I forsee this thread going into darkness! :p

What is this?!?!?
//{ <-- for those who like to see a brace on the following line...