pouët.net

I use factories, chesire cat, raii, etc knap demos and intros :-D

I use at least factories and singletons, perhaps some other patterns as well that I don't recognize by name. That said, just do whatever works for you. I find it fun to just code stuff instead of engineering since I do that at work but of course different people get their kick from different things...

some years ago I tried to write good code when making demos but I just stopped that with my spare time for the demoscene decreasing due to studying and working. output matters more than nice code.
nowadays I just have some very, very basic classes. also, for demos I don't really code OO anymore, it's more or less procedural. which in many cases makes things easier because a demo itself is linear in its execution path.

at work things are exactly the other way round. I'm probably already notorious for being a code quality and reuse nazi :-)

factories, visitors, pools and other common sense stuff for which i don't know the names (as preacher), when it makes sense. i never use singlestons though, for some reason in my mind when i need a singleton feels like a design flow (that's cause i studied electronics instead of cs, i suppose).

that's for demos/experiments/apps etc. for intros i never needed any of those.

lol, next time i'll fix the grammar before pressing "submit"

I've seen a lot of bad code written without any visible design pattern,
I've seen a lot of bad code written that used many design patterns,
I've seen a lot of good code written without any visible design pattern,
I've not seen a lot of good code written using design patterns.

YMMV, but for me design patterns are things to integrate intellectually in your mental toolbox, it's nice to know the "official" names so you can discuss with other people and be reasonably sure that everybody talks about the same thing, but religiously deciding that everything should follow known patterns in a very strict way is a good way to build impossible to maintain cathedrals. It makes refactoring very difficult in most of the cases I had to work on. (But of course there's the occasional brilliant counter example, but it's not due to the patterns it's due to the fact that the programmer was exceptionally good at structuring and designing things in general).

Write clean code. Design well. Refactor as you see fit. All that is a continuous process. Something very close to the well-known design patterns may emerge. Just ignore that coincidence.

Apart from that, you might want to become familiar with the builder pattern, especially when using a language with a focus on visibility restrictions (like Java; "Effective Java" is a great resource of wise, sane-keeping advice).


I hereby dare to state that I'd beat you hands down regarding pedantry ;)

Also, beware of perfection: After you spent twenty years to paint your garage's inside like the Sistine Chapel, you might be surprised to find your convertible, parked outside, rotten.

Regarding demos: Good API design might not be important at all on one-shot demos, but for libraries and tools you write and are likely to reuse.

In general, write what you're comfortable with. If you at least tried to create, but don't see value in a well-structured code base, don't force yourself to it (but don't show the code to anyone ;)).

I have rule of three:
Work around bad code twice, refactor it on third time.
Get something done manually twice, create tool for third time.
etc.

Design patterns are not something meant to be used as such, but as guideline to structured code in perfect world where you don't have to worry about performance or sanity of coder..

When you replace your 4 levels of conditionals (nested conditionals are bad right) with AbstractFactoryFactoryBuilder (Super Squeeky Clean GoF-certified patterncode) that does the same thing but with classes compositing others inside each like russian dolls, you know you are doing it wrong.

Going from C to Java to ActionScript to PHP to JavaScript (node.js/mongodb) has given me healthy look at OOP in general after being almost design pattern brainwashed to oblivion about super structured codestyle with Java in corporate life.

Now I try to build code around my data input and output requirements and not worry about reusability but try to keep code terse as possible and data domain specific and optimal while retaining readability when context is known. Also nice way to ensure reusability is to create open-source modules out of code snippets, makes you code actually reusable code and not just live by ideal that all code must be reusable.

It's hard, but Design Pattern are for sure the way to go when making something, after, when worring about performance, maybe it may break it, but most of the time not. Spend time before doing something is always a gain at the end, but time heavily depends of circumstances, thats what gives experience (and gives joy).

Dbug:

This is so true!

TLM: Glad yo see I'm not the only one thinking that :)