Do you guys use patterns?
Every programmer uses some form of patterns whether or not they know it you can sometimes tell who has programed a line of code how it is set up most programmers have a signature pattern I think it's more along the lines of what they know an how well they know it.
Quote:Original post by Telastyn
Sure, and then you get to implement actual behavior to make your program do something more than store ordered data. That is rather the point of design patterns, to provide a similar taxonomy to behavior as data structures have for storage.
Unless dealing with people who have never come close to anything CS related - why is it easier to talk about Composite pattern and applying Visitor, than it is about traversing a tree?
Especially since patterns are covered by one book written by IT outsourcing experts, while the CS terminology is covered by 40 years of research by people who laid the foundation of computing.
But yes, they discovered that trees, graphs and lists, as well as iteration over them is frequently used in software design. And that there are language quirks to work around.
Quote:Original post by AntheusSo functionality like serialisation, or "undo" should be built into every language??
IMHO, it makes sense to use a language which doesn't need patterns. Patterns are boiler-plate code of trying to tack an incorrect paradigm onto a language which isn't built to support it.
No.
So when building a game-level-loader, and realising that C++ requires me to implement a factory myself, I should switch to a language that has a built in factory?
No.
An "undo" system is a high-level application feature, which when implemented, could likely be similar to umpteen other implementations of the "command pattern". How does this signal a deficiency of a language?
What's wrong with giving the common name "factory" to a class that instantiates objects? What's wrong with shared vocabulary?
[Edited by - Hodgman on March 11, 2010 10:49:19 PM]
Quote:Original post by Antheus
*mumble*pitchforks*mumble*....Quote:Visitor patternsAlso called foreach.
Err.. It's been a long day, but I don't get it. How are visitor and foreach related? If anything iterator is more like foreach.
Quote:Original post by Antheus
IMHO, it makes sense to use a language which doesn't need patterns. Patterns are boiler-plate code of trying to tack an incorrect paradigm onto a language which isn't built to support it.
That's not always true. The mediator pattern is just a way of describing a certain arrangement that allows objects to talk to each other. It's hard to imagine a language that wouldn't require you to write an Adaptor at some point, even if it took the form of some static mapping between interfaces.
Design patterns were never, as far as I can tell, meant to be more than a vocabulary for describing recurring structures in code. That some of them can be implemented much more succinctly, even trivially, in some languages than others is not really a strike against them.
This reminds me of another recent thread, asking about when to use use data structures in programs.
They are simply common programming idioms. They've just been given common names so we can talk about them.
Just like named data structures and algorithms, patterns are named so we can study, reuse and take advantage of them.
We learn data structures like "linked list" and "binary tree". We learn algorithms like "quicksort", "Dijkstra's algorithm", or "A*". And we learn patterns like "factory methods", "visitors", and "command pattern".
That's really it. There is nothing fancy about it. If you learn it you will discover that your code uses patterns, even if you didn't intend to.
They are simply common programming idioms. They've just been given common names so we can talk about them.
Just like named data structures and algorithms, patterns are named so we can study, reuse and take advantage of them.
We learn data structures like "linked list" and "binary tree". We learn algorithms like "quicksort", "Dijkstra's algorithm", or "A*". And we learn patterns like "factory methods", "visitors", and "command pattern".
That's really it. There is nothing fancy about it. If you learn it you will discover that your code uses patterns, even if you didn't intend to.
Whenever I study design patterns I simply come to realise that they're just things I use every day without necessarily being able to put a name to them.
In fact I find it more useful to study anti-patterns so as to avoid them, rather than to study design patterns to simply put a name to techniques I've already discovered throughout the course of my programming career.
In fact I find it more useful to study anti-patterns so as to avoid them, rather than to study design patterns to simply put a name to techniques I've already discovered throughout the course of my programming career.
Quote:Original post by Telastyn
I agree with Hodgman, they're very useful as a communication mechanism for developers...
I've been a professional game programmer for over 20 years, and if someone looked at my code and said "ah, I see you're using the blah pattern", I'd just have to nod and dribble.
Terminology is only useful if everyone knows it. I don't and see no reason to learn. I'm sure I use a lot of recogniseable patterns in my dev, but I'd have to take other peoples words for it. I just write game code.
I guess what I'm getting at is that if you read a book or do a course on this stuff then I guess it has use in opening your eyes to ways to solve particular problems, but stay right there with it. When it comes to start designing code, do what's needed for your game, not for your pattern book.
I've never really gotten design patterns. Terminology is only useful if it is providing greater specificity than ordinary language more succinctly. I don't see design patterns doing this. It's succinct to call some class X an adaptor, say, but it isn't particularly useful. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X.
Also the whole subject seems a little confused in that in some cases patterns seem to be sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)
Anyway, if other people find the terminology useful more power to them, but personally it all seems like a lot of hot air to me, sort of like an academic fad.
Also the whole subject seems a little confused in that in some cases patterns seem to be sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)
Anyway, if other people find the terminology useful more power to them, but personally it all seems like a lot of hot air to me, sort of like an academic fad.
Quote:Original post by jwezorek
Also the whole subject seems a little confused in that in some cases patterns seem to be sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)
Why yes, of course it is! All three languages I commonly use (C++, Python, Tcl with the incrTcl extension) have RAII ... context managers in Python, the itcl::local command in Tcl. I'm sure other languages offer support for RAII as well. Personally, I consider any language that doesn't broken, which is the main reason I've never really gotten into Java.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
