Question What design patterns have you found most useful while coding?

[Wishbone]

This is a question to those who a) code, b) have heard about http://en.wikipedia.org/wiki/Design_pattern_(computer_science) , c) tried to use patterns in their work or hobby coding.

How much time do you reckon the application of your favourite pattern saved you?

 

[Urwumpe]

I would say about a few years... especially the singleton and the proxy pattern are pretty useful, especially if you employ both as factory class and handles.

 

[agentgonzo]

I have mixed feelings about singletons.

One of the paradigms that I stick to is 'only define something once'. Whether it be a string literal that you define as a constant or #define, 'magic numbers' or sections of code that should be subclassed, every time you copy-and-paste ANYTHING you should ask yourself whether it really is the best thing to do or are you just bring lazy. I have seen many many problems by code/variable duplication

---------- Post added at 23:45 ---------- Previous post was at 23:36 ----------

The other thing I have found useful is 'comment things that are not obvious from looking at the code for 30s'. This cuts a nice balance betweenhaving to have users study a 30-line code block for half an hour to figure out what it is doing any having i++; //increment i style comments cit also subconsciously forces people to label variables with sensible names. Having a variable named 'timeSinceScenarioInit' and uncommented is a lot easier to read than 't' used sporadically throughout a function. By forcing people to comment un-obvious code, they will often increase readability by a variable name change rather than comment it, which ultimately ends up with themost readable code

 

[Capt_hensley]

For what it's worth...

Theres a fine balance between naming variables with legible names, vs long names that still have real meaning. Short names are very easy to type and remember inside a given module of code.

Your right to say that if short named variables are used throughout a set of modules that they should have proper names with meaning. I like to prefix my variable names with the module they are from, or initials of that module, if it has a long name. Shared variables are usually globally defined and consist of not more than 16 letters.

Global dimensioning of variables can be a good thing in a small program, but to many global variables creates overhead in memory and during execution.

Using arrays, and removing them after that module is finished is a good technique to manage overhead. But it's hard to watch a particular bump when the array consists of over 30 items, in a given class.

Cutting and pasting code for ease of coding is common in hard coding of functions and modules, but can be cumbersome in the end file size. Getting the most use from a piece of code is always the hardest thing to plan for.

My pet peeve is no error handling, or no real error descriptions, just an ambiguous line references in unnamed modules or functions is a real debugging pain. Logging is OK if the execution or runtime is short and the function can be logged quickly.

Remembering to do all these things when coding on the fly is all together a different thing.

My favorite pattern is called: the successful pattern:

1: Execute
2: Run out a desirable result
3: exit with error code 0

The patterns found on Wiki, are useful in large environments, I program mostly with small apps and quick scripts. Haven't had the need to develop a resource file (DLLs) of routines as of yet.

The largest program I have single-handedly written was 30,000 lines, Jointly as a project member, I have contributed to a 4 million line project, but we had a project manager, and most coding was done in compartments.

I hate writing code, it's become very tedious for me of late.

 

[HarvesteR]

Hmm there are a number of patterns I like...

The singleton pattern is a very good one. Although lately I've been doing it a little differently.

Instead of exposing the instance reference (which I always call 'fetch') as a public static member, I leave it as a static private. Only the class itself has access to 'fetch'. Then for each property I want to expose, I create a get { return fetch.myInternalProperty; } }.

This way, all other classes only see the bits of the singleton I choose to expose. Makes for much prettier autocompletes

Another pattern I like, but very rarely get a chance to use, is Parameter Chaining.
It allows you to define parameters when constructing a new instance, but those parameters are optional and can be set in any order.

It's done like this:

class MyClass
{
    private myProp1;
    private myProp2;
    private myProp3;

    // constructor
    public MyClass()
    {
    }
    
    // setters for each property
    public MyClass setMyProp1(value)
    { 
        myProp1 = value;
        return this;
    }
    public MyClass setMyProp2(value)
    { 
        myProp2 = value;
        return this;
    }
    public MyClass setMyProp3(value)
    { 
        myProp3 = value;
        return this;
    }
}

// then, when instantiating, you can do this:
MyClass myNewInstance = new MyClass().setMyProp3('blah').setMyProp1('bleh');

It's a very cool pattern for when you have small classes and you don't want to add too many lines of code for them, or declare a lot of variables...

I did this for the Tutorial Arrows that pop up in the KSP tutorials... they have methods for setting their colors and arrow orientation, and since they're stored in a base class for later deletion, and don't do nothing by themselves after being created, I don't need to store them again in the actual tutorial extension

It's not often that one gets to use the Parameter Chaining pattern, but it's a cool one.

I'm not a huge fan of the Factory pattern... I guess it brings back memories of the J2ME classes back in college...

The Wrapper pattern is another one I like... when things don't fit, you create another class to abstract the differences, and that class has a more solid external interface.

I did this for the part sounds and effects in KSP, too... since parts are loaded in runtime, and the asset structure isn't known, I created an FXGroup wrapper class for the sounds and particle effects. This class let's you assign effects and sound to it, and provides methods to activate them all. So each part has a number of FXGroups, one for each event in which there is sound or particles. An effect might be assigned to multiple groups also, to facilitate things like RCS thrusters and stuff like that.

In fact, the whole FXGroup idea isn't actually mine. Orbiter does it. They're called ThrusterGroups. I just tweaked the concept a little

Cheers

 

[Artlav]

I find it peculiar, and potentially debilitating that blatantly obvious things are getting explicitly named and taught as if they were something special and magical. The use-patterns-because-you-should-use-patterns attitude, that is. It's like putting a toilet in the kitchen because a pattern is that an apartment should have a toilet.

So, yes i use them where they fit, without checking if ones were named before.

IMHO, it's about common sense - if you need to nail something, you hit the nail with hard object. You can use the back of the axe if no hammers are in the vicinity, but using a hammer would be the proper way. That's a pattern, not a rule.

For the question itself - one common thing i use is modularity.
Each more or less large piece of code is made in such a way that it could be used outside of a context.
So, a terrain generator can be used in Orbiter, can be used to draw a screensaver, and can be used for a voxel renderer-driven FPS without much change. Objects should be clearly incapsulated.
Or abstraction layers - a thin abstraction layer over a filesystem access, and you can have both fast access to regular files and seamless access to files in an archive or resource file. Abstraction over communications, and a renderer can work equally as well over the network and over the direct link.

That saves me a whole lot of time, since i can get a template put together in minutes and concentrate on the implementation of the idea.
That is, accelerate from zero to creativity in a blink.

 

[Moach]

I find it peculiar, and potentially debilitating that blatantly obvious things are getting explicitly named and taught as if they were something special and magical. The use-patterns-because-you-should-use-patterns attitude, that is. It's like putting a toilet in the kitchen because a pattern is that an apartment should have a toilet.

So, yes i use them where they fit, without checking if ones were named before.

IMHO, it's about common sense - if you need to nail something, you hit the nail with hard object. You can use the back of the axe if no hammers are in the vicinity, but using a hammer would be the proper way. That's a pattern, not a rule.

(...)

:goodposting::ditto::hesaid:


i find there are many ill-advised "developers" who toss about those patterns as if they ment something regardless of what is being accomplished through them :facepalm:

i blame it on Java... you don't see C++ ppl doing that :lol:

those over-OOP'd languages are breeding a race of programmers who abuse patterns to a point where their code is harder to read and understand than if it were a jumble of destructured spaghetti-work...


patterns are nice as a general guideline.... it's nice to know that there are pre-considered solutions to common problems - ok, but then, that's that... let's get down to work now...

whenever i see someone make a "IClassFactory" interface i die a little....
i have yet to find if there is any problem in this world that can be actually made SIMPLER by hiding what class should get created from the programmer...
i find this only addresses a problem that wouldn't really exist if OOP wasn't getting senselessly overdone out there...


i've been programming for several years now, in many different languages where differnt practices are due...
and i've come to one conclusion i have not yet found a reason to dismiss:


two out of each three design patterns are just procrastination :rofl:



as for the question in hand - there ARE patterns i like to use (those one-out-of-three's that actually matter)

i every so often employ a "fetch" variable to act as a singleton... in Flash (which is OOP-addicted to boot) it makes sense to have a globally accessible variable allowing "remote control" of stuff like the stage and whatever

i also find myself using state-machine designs in several occasions... producer-consumer is also one that usually finds its way into my code almost unnoticed until it's there :lol:

but i don't restrain myself to using patterns "as shown"... many times, my state-machines are just switch statements, and my producer-consumer rigs are just arrays that are fed one way and emptied the other... you won't find patterny-named constructs in my code - no sir - all my stuff is identified directly as to their purpose - and i try to keep as few layers possible between wha'ts said and what's done

 

[HarvesteR]

Hmm that is true. Have you seen the Wikipedia article on Design patterns? There are way more patterns than there are any possible uses for all of them.

But it DOES make you look busy and ramps up your line count, so I can see why there are so many out there.

A few patterns are truly useful... the least obvious ones generally, like Singleton... others are, well... line count wadding

Cheers

 

[agentgonzo]

i blame it on Java... you don't see C++ ppl doing that

Having recently started programming in java, I totally agree with you. About 10 years ago I heard about 'java beans'. About a month ago I finally found out what one was (having not cared for the intervening period) and was massively underwhelmed to find out it was something so simple that the java bods had given a 'magical' name as if it was something really special no-one had thought of before.

 

[Urwumpe]

I think you are doing Design Patterns bad justice there: they are just standard solutions for standard problems. Not more. And not less.

You sure wouldn't get far by inventing the "Artlav spinning disk of energy transfer" everyday again, when you actually just want to use a wheel. And name it so when talking about other people that have to work with you. Computer science is overly abundant with redundant terms for the same thing. No need to increase this nonsense.

PS: I have never found a design pattern yet that is without good use. You simply rarely notice that you are already using a design pattern, because your code looks different to the examples, despite having the same static structure and behavior.

 

[yagni01]

I think you are doing Design Patterns bad justice there: they are just standard solutions for standard problems. Not more. And not less.

You sure wouldn't get far by inventing the "Artlav spinning disk of energy transfer" everyday again, when you actually just want to use a wheel. And name it so when talking about other people that have to work with you. Computer science is overly abundant with redundant terms for the same thing. No need to increase this nonsense.

Excellent point. I think 80% of programming is writing for other people to read and maintain (or yourself a year from now). Using standard solutions with standard names where applicable helps that process. If I was talking to another woodworker about building something with a 'mortise and tenon' here, and a 'half-lap' there; we would understand each other without long descriptions or drawing pictures. Design Patterns are the same thing - terms in a domain-specific language.

 

[Artlav]

I think you are doing Design Patterns bad justice there: they are just standard solutions for standard problems. Not more. And not less.

I think 80% of programming is writing for other people to read and maintain (or yourself a year from now).

I certainly agree with that.
But i think these are two distinct issues.
Any solution must be documented. If it's a common solution, you document it in short sentences - pattern A, situation so and so. If it's uncommon, you document it with a nice description. And names are helpful in both cases, and even more helpful in teaching - what is obvious to one might not be so obvious to another, and looking through a book index or googling needs searchable terms.

The problem is magical attitude attached to the names. Getting back to my example, driving a hundred miles to the city and as much back to fetch a hammer exclusively for the purpose of making things the right way would be counter-productive if you just need to nail a picture or fix a door.

I've seen it a lot - you have this nicely done program, with distinct framework part, interface part and a bunch of classes in a neat pattern. But all it does is write a byte into a file to change processor clock!
A task that can be done by a two-lines script, one of which would be a comment with description.

And the opposite is quite common - you get a system that is supposed to work under load and real world (unpredictable) conditions, that is crawling slow and does not accept anything out of the ordinary without crashing. Because it's innards is a mess of loosely fitted common solutions and some glue code that noone bothered to even pick carefully. It's like someone was piling things together until it started to work and stopped there.

That's the attitude - the common solutions are Only-Things-Possible, so you fit them one by one until it works, or declare the task impossible if none do.
Do they even teach pragmatics and solution usability in programming courses?
Or even require a basic mathematics and reasoning background?

 

[Moach]

it appears we every now and then find ourselves surrounded by programmers who have little to no problem-solving skills...
they declare themselves "developers" but have little understanding of real logic and what it takes to achieve a certain task... this well noticeable as a probable education fault - isn't that how logic and "math" is taught in schools? - theres no "try to solve this", it's all "this does that, and that does that other thing" - if it ain't it the textbooks, it doesn't exist


Urwumpe is right - i have probably employed several design patterns myself without even giving it much thought... i (as most here, i suppose) usually just think up my own logic as to address the needs of the task at hand...
if it turns out there's a design pattern with some clever name out there which is just like what i did, then that's that....

but now - i had an actual programming "teacher" (notice the quotes) who advocated that the "future of OOP" would be "POP, Pattern-Oriented-Programming" :facepalm:

glorious, now i think of it... so the future is a bunch of uneducated programmers who know nothing of logic and still are expected to be wise enough to tell a computer what to do...
well, guess for us "old-schoolers", employment is guaranteed for life then :lol:

seriously - most programmers i know have no idea how binary works (i actually got this coming from a guy who majored in computer sciences) :uhh:



ok, design patterns are useful - but my point is - a brain between your ears is more so, and the former is no substitute for the latter, while the other way around can still be :rofl:

 

[HarvesteR]

:hesaid:

I remember that "teacher"... It would be funny if we weren't his students... He was a sad case. :lol:

But yeah, most "programmers" I know are limited to the very basics of programming logic 101... they have no concept of, nor will to try, anything more advanced than a ridiculously large set of nested conditions, in which they soon get hopelessly lost.

Case in point, the intranet systems in my GF's college *twitch* *twitch*... I swear I get this urge to walk up to their IT department and slap the hapless interns that coded it... It's so bad, they have to put up a video tutorial for people to learn how to assign themselves to classes... and this video is 10 minutes long and changes every semester!

I guess this is because people are not being taught to code properly anymore... they learn the syntax of their languages, and logic goes totally amiss...

A programmer who can't do anything more advanced than basic programming 101 will dig his own grave in every single project... at about 1000 lines he reaches critical complexity and just can't add anything else to the project without breaking everything else...

Oh the humanity!

Cheers

 

[Urwumpe]

I
I've seen it a lot - you have this nicely done program, with distinct framework part, interface part and a bunch of classes in a neat pattern. But all it does is write a byte into a file to change processor clock!
A task that can be done by a two-lines script, one of which would be a comment with description.

of course, it is actually just a two-lines script, if the whole file system madness is not your job anymore, but done by somebody else... likely with standard design patterns, regardless if OOP patterns or not.

Or you you have to deal with many different architectures.

The length of the code that you write yourself is of course better the shorter and the more readable it is. But you can't solve every problem with just two lines.

And of course then - the more standard patterns you use in your solution, the easier it is for somebody who also knows the standard patterns, to understand your solution.

 

[agentgonzo]

it appears we every now and then find ourselves surrounded by programmers who have little to no problem-solving skills...
they declare themselves "developers" but have little understanding of real logic and what it takes to achieve a certain task... this well noticeable as a probable education fault - isn't that how logic and "math" is taught in schools? - theres no "try to solve this", it's all "this does that, and that does that other thing" - if it ain't it the textbooks, it doesn't exist

This happens in every field. Whether it be software development, accountancy, taxidermy or unspeakable-things-with-a-horse-ing. People come along, realise that a group of people have independently started using the same pattern because it's a common sense or a good idea, they slap a name on it and then go around evangelising about how great it is to everyone within earshot even if the people within earshot are already doing it or not. They are called consultants.

 

[Moach]

(...)
And of course then - the more standard patterns you use in your solution, the easier it is for somebody who also knows the standard patterns, to understand your solution.

yes, well - provided YOU understand your solution, that is :focus:

as we were saying, so it seems, somehow design patterns have become a "valid" excuse for doing something without really knowing how it works :facepalm:


this doesn't negate the validity of patterns as a concept - it negates the validity of programmers who mindlessly abuse them in such ways as programmers :lol:


it's one thing to know patterns and what they're meant to accomplish... that's a good thing - but what we see more and more is ppl evangelizing to things which themselves don't really understand, just because it makes them sound "professional" or something....


my advice is - go, learn patterns, use them, be happy - but do not mistake those for a "shortcut to good programming" because down that road, there lies FAIL (and Java)