- This topic has 11 replies, 10 voices, and was last updated 15 years, 4 months ago by
.
-
Posts
-
-
Hi all,
I tune in every now and then to Christer Ericson’s Blog, as his book, Real-time Collision Detection is the best book on the subject (in my opinion), and also the fact that he works on the God of War franchise, etc.
Anyway, one of the latest threads, relates to the "Evils" of design patterns.
It is turning into a SMOKING debate, which can be read in detail here.
http://realtimecollisiondetection.net/blog/?p=81#more-81I was just interested in what the locals "round-these-parts" thought of patterns. I take Christer’s point, that there may be some amount of "overy-hype" attached to design patterns, but as I am a OO advocate, I pretty much disagree.
Why? Well for me, during Analysis and Design phases of a project, I like to be able to identify the sub-system managers as "singletons," classes responsible for creations as "factories" or "abstract factories," and maybe my steering behaviours as "flyweights." The rest of the team are well verse in this terminology, and any new members can refer to the GoF book, or Wikipedia.
I am also a big fan of UML, specifically Class diagrams, use case, activity, and state-transition diagrams.
I don’t use these terms to appear lofty, nor do I walk around patting myself on the back, because I know my GoF patterns like my ABC’s. I find they simply speed things along.
To make a comparison, I think they are useful as terms like stacks, lists, hash maps, etc. I can communicate this to a team member, or maybe something like "the shader manager should wrap an associative container…" and they understand what I mean.
Anyway, that’s where I stand.
B.
-
—
-
I don’t think you’re talking about the same thing.
Someone correct me on this if I’m wrong, but what I gathered from his blog is he is declaring hatred of a ‘ predetermined fixed solution’ to a problem, not designing a way around problems.
What you’re discussing is the analysis of the problem and designing a way around it. All you mention are common tools used to help demonstrate this design.
The blog links http://norvig.com/design-patterns/ppframe.htm as a source on what they are.
Here’s an extract:
What are Design Patterns:
Templates the describe design alternatives[/quote:761bd84bed]In other words you have a method or class already made, you see a new problem and immediately think "OHO! I can use xxx class here" So you go and use it without considering that maybe it’s not the right thing to use. You then waste lots of times forcing this ‘panacaea’ to fit your problem.
Any master programmer would know that you cannot simply dish out a small number of generic solutions for generic situations, but that every situation is (potentially) different and warrants its own (potential) solution.[/quote:761bd84bed]
-
I find myself in agreement. Design patterns assume using OO techniques are the correct basis on which to provide template solutions. But objects are just one way to skin the cat. This seems to be the source of the argument and what differentiates design patterns from plain algorithms. An algorithm has much wider and universal usage, design patterns assume a procedural oo language and are mildly performance agnostic. That’s fine if you are writing some software that has no real concern for performance (and that’s normal outside of games) and just needs to be implemented quickly with the closest fit pattern. Any well trodden algorithm, like quick sort, will have been analysed closely for memory and performance concerns and will be very language agnostic.
Having said this, I wouldn’t deny myself the knowledge of design patterns, but I’d be careful about prescribing them for a problem unless I considered them a perfect fit.
-
-
Wow. That was a pretty quick response time!
Thane XP is a software development methodology. Examples of this would be Waterfall (traditional), Spiral, Agile, etc. That is more to do with the process of building the software in terms of Analysis, Design, Implementation and Testing.
Design Patterns are like "canned" techniques, for commonly used OO situations. Examples I use include Singleton, flyweight, factory, and state.
Feral thats some great points. I was also suprised to hear the author (Christer Ericson) talk so poorly of patterns, and cite OO as a fading paradigm. I think your bang on the money when you said it is a case of "horses-for-courses" and people should be aware that these tools are available, and know when to apply them, much like traditional data structures and algorithms.
B.
-
—
-
My 2c..
Design Patterns are a very useful thing, assuming that they are being used for the right reasons with a clear understanding of why they are valuable, and not just forced by a PHB because something is buzzword of the week.
As an example, I’ve been put in situations where people have insisted on using singletons where they were completely unappropriate, and in others where I’ve used them as thread/connection pool managers (confusing people who assume they can only ever return a single instance).
The wrong tools, in the wrong hands, in the wrong situation, will do more harm than good. Understanding is key.
-
When people talk about Design Patterns now, they tend to restrict the definition to those offered by the GoF.
As jedimaster pointed out in his first post, a stack is a design pattern, as is a hashtable, as is a hinge for making doors, as is the lever for opening trapdoors under unwelcome guests. They are all around us! (Unwelcome guests that is.)
For me including the gof design patterns into normal vocab makes it easier to discuss what can be complex problems, which is a good thing.
Do I copy the pattern straight out of the book and apply it without thinking? Definitely not. I take them as examples not rules. Like in hashtables for example, there’s dozens of ways to implement hashtables, each with it’s pro’s and con’s – tweak it all you want, it’s still a hashtable. Unless of course you make it into an array, which is something different.
As for UML and big heavy design and analysis… BOOOOOOO.
Agile iterative evolving solutions… YEEEAAA!!!Anyway, design patterns – big thumbs up from me!
-
One mistake a lot of less experienced programmers seem to make is treating these subjects (such as design patterns, or Agile, or whatever) as something you have to be believe in completely, or not. Personally I don’t think religion has has any place in computer science or software engineering – you take on-board the things that are useful to you, and you leave what isn’t. It sounds obvious, but you don’t need to buy into design patterns wholesale and cram them into everything you write. There certainly are common patterns that we’re all familiar with, and there’s no harm in giving them a name, giving us a shared vocabulary and shorthand for describing complex things.
All that said, game programming is a bit of an oddity in the world of software engineering with a lot of domain-specific patterns that crop up again and again. A book on that topic would be pretty interesting I reckon. Some of the Gems book encroach upon that territory. But they’re too heavy.
PS hello!
-
It’s like anything really, too much of something is a bad thing.
Design patterns can be good for bringing structure to a program and aiding collaboration with team members, but if you were to really get into them you’d just end up with something so foul and obnoxious that only an OO anorak would be able to appreciate it. Not to mention the fact that it would make for near coma-inducing team meetings.. :D
Totally agree with the last comment, just take what you need and ditch the rest. Don’t design for design’s sake, and don’t spend all of your time on it either. The end product is what’s important, not the stuff in between!
-
PS hello![/quote:d9236f1a90]
Blimey, where you been hiding out?
-
- The forum ‘Programming’ is closed to new topics and replies.