For those programmers with experience in the workforce, what design patterns do you use most frequently? Factories? Decorator? Command patterns? etc etc, I'm curious to know because I'd like to leverage nairaland to conduct a survey of what should be expected of nigerian programmers as we continue to evolve together. I know it's only a small subset of us, but it would be a good case study.

Also, if you don't know what a design pattern is, or you dont use them, it doesnt mean you arent a solid programmer, please share and discuss anyways. Or if you want to learn, ask away, professional growth in numbers serves the greater good.

When it comes to design pattern is not a question one or the other some framework comes with a combo of design patterns.Understanding and using design patterns shows how mature you are as a programmer because these patterns embodies the industry's best practice.You cann't be a good programmer if you don't know of them let alone use them.It like saying its possible to be a good football coach without understanding and using any formation or pattern.Any nontrivial application must be built with a design pattern.I personally use DAO, MVC ,Front controller,Decorator and a whole bunch of others.

You cann't be a good programmer if you don't know of them let alone use them

klass, I will respectfully disagree with the latter part of your statement. Sure, you can know about them but you don't necessarily have to use them to qualify you as a "good programmer". For one, you can always come up with your own. These patterns were developed by fellow humans. As a fellow human, nothing stops not using any one that is out there. Using your football analogy, I am aware of the various formations, but nothing should stop me from experimenting with a formation that hasn't been tested. Who knows? You might just come up with something new and have others learn from you. Or am I misinterpreting the statement? If I am, sorry about that.

To answer the question: being in the web dev realm, assuming it counts (considering this is the programmers forum), I am into the YUI design patterns.

Most of these patterns are built into a lot of widely used frameworks these days anyway so a good appreciation of what design patterns are is probably a requirement for at least those that a DECENT developers.

Well said, everyone.
I suppose, I was going beyond frameworks, and talking more about patterns you've implemented on your own from scratch.

I use the MVC framework , Cairngorm, when building desktop apps that run on AIR.
It makes use of the command, singleton, and service locator patterns, among others.
I seem to often also use:
1) Abstract Factory
2) Mediator
3) Memento Pattern

I just want to mention that , design patterns, while a good understanding of them will help you as a developer, most of them they do not come to play at all when it comes to developing procedural programs using a language like COBOL or even C for that matter. So, I would not neccesary say a COBOlLprogrammer that does not know about patterns is not a good programmer.

As mentioned, most of these patterns are built into very popular fremeworks these days. Such as struts, Hibernate,  etc.

I personally use/have used the following petterns in the web applications I develop. MVC (specifically Struts), DAO (hibernate and straight JDBC calls), service locator, View Helper, Intercepting Filter.  These also happens to be called the J2EE patterns in the "Java world"

Programming design patterns are programming design patterns. Whether they are J2EE patterns, C++ patterns, Python Patterns, etc. For example, MVC can be implemented in all of the above, and not just in the 'Java World'. In software, a design pattern is a general reusable solution to a commonly occurring problem in software design (others, dont confuse this with graphic design, it leans more toward software architecture). A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Having said that, patterns are more common in OO langugages because of their very nature: the languages were designed with code (and entity) reusability as a priority. Regardless, by the definition of what a pattern is, you can have patterns in ANY language.

Spot on! Design patterns is language independent.Best practices apply across board.If you don't know and use them, then you are doing yourself and indeed your organization a disservice.Talking of home-grown 'design pattern' and experimenting. No Sir!,not in a mission-critical project!. First why risk re-inventing the wheel in a buggy way.Second when 'Albert Einstein', is of to Tahiti on vacation or has gone for good we will have to get a rocket-scientist (from NASA) to decipher his home-grown 'design pattern'.For me best practice is sacrosanct,I don't like maverick developers who risk the success of the whole project just to prove they are 'genius'. As they say KISS (Keep It Simple & Stupid) .

Hello Fellow Guru,

I found www.freelancerafrica.com today and I thought I should share it with you, I beleive is free to bid for projects,

I agree with @prodgalson , design patterns are language independent and you can write OO programs with C and Cobol (though not an easy task)

I've use Decorator, Factory, Command, Strategy, Composite, Adapter ,

It just occurred to me that if you for instance use java, and program in a proper way one can say he has used almost all the patterns.

Once you're familiar with them you see them every where ,

@my2cents was talking about inventing his own patterns, i don't think thats really accurate. Even the GOF didn't invent patterns, they just identified it.

They're common solutions to programming problems

klassnic:

Spot on! Design patterns is language independent.Best practices apply across board.If you don't know and use them, then you are doing yourself and indeed your organization a disservice.Talking of home-grown 'design pattern' and experimenting. No Sir!,not in a mission-critical project!. First why risk re-inventing the wheel in a buggy way.Second when 'Albert Einstein', is of to Tahiti on vacation or has gone for good we will have to get a rocket-scientist (from NASA) to decipher his home-grown 'design pattern'.For me best practice is sacrosanct,I don't like maverick developers who risk the success of the whole project just to prove they are 'genius'. As they say KISS (Keep It Simple & Stupid) .

@klassnic
You have really done justice to the topic.
You may not re-invent a new design pattern entirely too, you may just extend what the GOF or magnificent seven or whoever has done.
You may also invent new patterns too, but i think what the GOF or magnificent seven have done is the base for other works, similar to what Newton and others have done to Physics.

Also, if the design pattern is well documented by stating symptoms of the problem, the solution, code samples, UML diagrams, applicability scenarios, and the pattern's anti-patterns, then the inventor may travel to wherever on vacation, and his pattern will still be used effectively (e.g. the GOF and others are not in Nigeria, but their works are being used).

But you can't think of deveoping new patterns in mission-critical assignments, you just grab the most suitable pattern in that case.

There is no "cook book" approach to software development.The developer has to adapt whatever design pattern he is using to his own peculiar situation.Its often not a "copy & paste" situation.I have seen developers stuck in generating useless artifacts while the project deadline looms dangerously near. It doesn't surprise me any more with so much For Dummies books out there.Dummies are gradually taking over the whole place.I think the watch-word is BE AGILE.Don't become a slave to your tool.As for building a "brand new" design pattern,then you must be facing a very rare problem.I honestly believe that there is nothing new under the sun,whatever design problem you are facing now might have even been addressed before you were even born!.Research man,research.

@klassnic well said!

how many programming paradigms are there?
over 3 at least. procedural, OOP, functional etc.
how do you fit design patterns to all this? code in OOP way?
what design patterns were developers using 10 yrs ago, and what about
developers who just have a tutorial and get to solving a problem??
Design patterns are not the LAW, its good to console some programmers that they are
some how locking complexity down, but as Djiskstra said , programming is complex
, u'd soon ask , if one uses UML,
boy!!
prescription methodologies will never catch on with all programmers and this rare bunch will still
get a lot done.
The ultimate design pattern is a problem solving mind.
what editor do u use- editor what ?? some use only notepad and get work done.
what debugger do u use - d- what ??
some use the command line and love it.
what new language do you know - perl ,python, any other not-older-than 3 years lang.
screw the latest language ,
some coders never left their assembler and if they did its for C , cobol etc.
and oddly they get work and lots done.
what do you say about such.

klassnic:

There is no "cook book" approach to software development.The developer has to adapt whatever design pattern he is using to his own peculiar situation.Its often not a "copy & paste" situation.I have seen developers stuck in generating useless artifacts while the project deadline looms dangerously near. It doesn't surprise me any more with so much For Dummies books out there.Dummies are gradually taking over the whole place.I think the watch-word is BE AGILE.Don't become a slave to your tool.As for building a "brand new" design pattern,then you must be facing a very rare problem.I honestly believe that there is nothing new under the sun,whatever design problem you are facing now might have even been addressed before you were even born!.Research man,research.

Right on the mark!!!

kambo:

how many programming paradigms are there?
over 3 at least. procedural, OOP, functional etc.
how do you fit design patterns to all this? code in OOP way?
what design patterns were developers using 10 years ago, and what about
developers who just have a tutorial and get to solving a problem??
Design patterns are not the LAW, its good to console some programmers that they are
some how locking complexity down, but as Djiskstra said , programming is complex
, u'd soon ask , if one uses UML,
boy!!
prescription methodologies will never catch on with all programmers and this rare bunch will still
get a lot done.
The ultimate design pattern is a problem solving mind.
what editor do u use- editor what ?? some use only notepad and get work done.
what debugger do u use - d- what ??
some use the command line and love it.
what new language do you know - perl ,python, any other not-older-than 3 years lang.
screw the latest language ,
some coders never left their assembler and if they did its for C , cobol etc.
and oddly they get work and lots done.
what do you say about such.

Tell them!!!


Having worked with various corporations out here myself. I can say without a doubt that majority of their code work is not based on Methodologies. More focus is placed on developing applications that work than it is on what pattern each developer used used to arrive at such a solution.

Having worked with various corporations out here myself. I can say without a doubt that majority of their code work is not based on Methodologies. More focus is placed on developing applications that work than it is on what pattern each developer used used to arrive at such a solution.

@Kobojunkie
Instant gratification is the evil thereof.Best practices are gear towards producing workable and maintainable and robust apps.But instant gratification is the last refuge of the lazy developer.Thats why exploits like sql-injection caused such havoc.You see some code you almost want the developer hanged for putting up such a shoddy job.I know a little about chess, the lazy player don't concern himself with opening theories he just wants to get on with the game soon he falls prey to a fools mate.Thats want you get when you go for instant gratification instead following sound practice.Talking about 'code that work',they are all over the place from the error-prone university portals to,fragile exam-bodies apps to the flashy if you click I break apps to the expensive can't do a thing apps that litter the whole place.Bro, give me a break!.Down with mediocrity!! If this sh*t continues we'll all be slaving for Indians.Doesn't surprise me no more when every other idiot you meet is floating an IT firm,lousy CONTRACTORS that just wants some piece of the government a** and IT seems to be the next big thing.It makes me puke!

Having worked with various corporations out here myself. I can say without a doubt that majority of their code work is not based on Methodologies. More focus is placed on developing applications that work than it is on what pattern each developer used used to arrive at such a solution.

@Kobojunkie
Instant gratification is the evil thereof.Best practices are gear towards producing workable and maintainable and robust apps.But instant gratification is the last refuge of the lazy developer.Thats why exploits like sql-injection caused such havoc.You see some code you almost want the developer hanged for putting up such a shoddy job.I know a little about chess, the lazy player don't concern himself with opening theories he just wants to get on with the game soon he falls prey to a fools mate.Thats whta you get when you go for instant gratification instead following sound practice.Talking about 'code that work',they are all over the place from the error-prone university portals to,fragile exam-bodies apps to the flashy if you click I break apps to the expensive can't do a thing apps that litter the whole place.Bro, give me a break!.Down with mediocrity!! If this sh*t continues we'll all be slaving for Indians.Doesn't surprise me no more when every other idiot you meet is floating an IT firm,lousy CONTRACTORS that just wants some piece of the government a** and IT seems to be the next big thing.It makes me puke!

Having worked with various corporations out here myself. I can say without a doubt that majority of their code work is not based on Methodologies. More focus is placed on developing applications that work than it is on what pattern each developer used used to arrive at such a solution.

@Kobojunkie
Instant gratification is the evil thereof.Best practices are gear towards producing workable and maintainable and robust apps.But instant gratification is the last refuge of the lazy developer.Thats why exploits like sql-injection caused such havoc.You see some code you almost want the developer hanged for putting up such a shoddy job.I know a little about chess, the lazy player don't concern himself with opening theories he just wants to get on with the game soon he falls prey to a fools mate.Thats what you get when you go for instant gratification instead following sound practice.Talking about 'code that work',they are all over the place from the error-prone university portals to,fragile exam-bodies apps to the flashy if you click I break apps to the expensive can't do a thing apps that litter the whole place.Bro, give me a break!.Down with mediocrity!! If this sh*t continues we'll all be slaving for Indians.Doesn't surprise me no more when every other idiot you meet is floating an IT firm,lousy CONTRACTORS that just wants some piece of the government a** and IT seems to be the next big thing.It makes me puke!

klassnic:

@Kobojunkie
Instant gratification is the evil thereof.Best practices are gear towards producing workable and maintainable and robust apps.But instant gratification is the last refuge of the lazy developer.Thats why exploits like sql-injection caused such havoc.You see some code you almost want the developer hanged for putting up such a shoddy job.I know a little about chess, the lazy player don't concern himself with opening theories he just wants to get on with the game soon he falls prey to a fools mate.Thats what you get when you go for instant gratification instead following sound practice.Talking about 'code that work',they are all over the place from the error-prone university portals to,fragile exam-bodies apps to the flashy if you click I break apps to the expensive can't do a thing apps that litter the whole place.Bro, give me a break!.Down with mediocrity!! If this sh*t continues we'll all be slaving for Indians.Doesn't surprise me no more when every other idiot you meet is floating an IT firm,lousy CONTRACTORS that just wants some piece of the government a** and IT seems to be the next big thing.It makes me puke!

I believe there is a difference between getting the job done and getting the job done lazily. That was exactly the problem that existed with my last project. I went in to work for one of the banks here. They hired some developers to help get things started and going, but unfortunately, these developers where too stuck on getting to decide whose pattern idea would best fit that, and making sure that it all fits into the selected pattern design, that at the end of the day, the bank had to get contractors in to get the job done fast and quick. You may use patterns but patterns are not the MUST at all, they are templates and it is usually best for you to understand that you have to create or use templates that work for your situation and not stick to what is out there just cause. If you read up on these patterns, you will realize that they are just ways people have come to organize their code for better efficiency in there situation. Does not mean you have to go around spouting that if you do not use a pattern, you are lazy and your code is any less. Even while interviewing, barely are you asked what patterns you know of or are able to use, come to think of it, I have never been asked such and it is mostly like my2Cents wrote up there.

Patterns are there for you to use when you need to use them but you need to figure out the best way to organize your own code and work based on your unique circumstance. There is NO RULE OUT THERE THAT SAYS IF YOU DO NOT USE PATTERNS BY OTHERS, MEANS YOU ARE NOT A GOOD PROGRAMMER. That is absolutely rubbish.

I myself use patterns as much as I can but I have also been exposed to situations where no specific described pattern is employed and everything works just as effectively and code remains managable. I have even worked in areas where different patterns are used by different teams and it all works fine in the end and maintainance remains easy and straight forward.

prodgalson:

It is a description or template for how to solve a problem that can be used in many different situations.
.

Exactly. Sometimes a template will work, at other times, it will not. You have to base your decision on what you currently have to work with and what is needed to a design pattern.

http://www.dofactory.com/Default.aspx

As for the sort of code you mention, eg, the university error prone portals and what not. Being that I have never seen their code from here, I will say that the problem with their application may be more of a lack of adequate testing than use of patterns. No matter what pattern you use, if you do not deal with errors, they will flood the place and if you do not test your code, you are likely to get your code crash ever so often. So it is one thing to write code and another to actually test and make sure that it works as it is supposed to. Code that crashes or is error-laden is not code that is not written using a pattern of some sort but code that is not well written, pattern or not.

Guys, design patterns are domain specific ,
I guess what we're talking about are software design patterns generally ,
If you were into concurrent programming you'd have a whole different set of design patterns (not GOF). e.g Look at the J2EE design patterns.

p.s Being lazy is not necessarily a bad quality in a programmer

Really a programmer shouldn't be thinking of pattens when solving a problem, just flow with some good OO basics,
patterns reveal themselves as the code evolves and changes become necessary (i.e refactoring) so quoting Martin Fowler, you should refactor to patterns.

For software that would have a design,development,maintenance lifecycle of more than 5 years patterns become important.
Imagine the number of developers, that would have worked on a project, many would have resigned etc. The original developers that conceived the design would have been long gone - on the other hand the software has to be able to scale to users needs, we need to be able to fix bugs etc. So patterns offer a common lingo to communicate a design.

If one understands a patterns that was used in a design extending the code becomes easy
e.g

Take the java IO class ---- (A solid implementation of Decorator)
RMI (proxy)
Comparator, sorting etc ---- (strategy)

you can use these APIs without knowing design patterns but patterns give deeper insight into the intent of the API designers hence there'll be less misuse etc.

@Kobojunkie if u think patterns are just *(^%^%^%£$££ , tell us your favourite tools,APIs or development platform and we'd dissect it and show you the patterns that make the API so great, that you love it!
Game ?

Ghenghis:

Guys, design patterns are domain specific ,
I guess what we're talking about are software design patterns generally ,
If you were into concurrent programming you'd have a whole different set of design patterns (not GOF). e.g Look at the J2EE design patterns.

p.s Being lazy is not necessarily a bad quality in a programmer

Really a programmer shouldn't be thinking of pattens when solving a problem, just flow with some good OO basics,
patterns reveal themselves as the code evolves and changes become necessary (i.e refactoring) so quoting Martin Fowler, you should refactor to patterns.

For software that would have a design,development,maintenance lifecycle of more than 5 years patterns become important.
Imagine the number of developers, that would have worked on a project, many would have resigned etc. The original developers that conceived the design would have been long gone - on the other hand the software has to be able to scale to users needs, we need to be able to fix bugs etc. So patterns offer a common lingo to communicate a design.

If one understands a patterns that was used in a design extending the code becomes easy
e.g

Take the java IO class ---- (A solid implementation of Decorator)
RMI (proxy)
Comparator, sorting etc ---- (strategy)

you can use these APIs without knowing design patterns but patterns give deeper insight into the intent of the API designers hence there'll be less misuse etc.

@Kobojunkie if u think patterns are just *(^%^%^%£$££ , tell us your favourite tools,APIs or development platform and we'd dissect it and show you the patterns that make the API so great, that you love it!
Game ?

The highlighted is exactly my point

Look,  Patterns are templates. Those guys who come up with their own templates and then write books and articles on them for you all to use are developers with one head like you and I. To suggest that the patterns should be of great focus when you are developing API's or whatever tool, is ridiculous. I happen to work on the .NET platform myself. There are tons of patterns out there and I use GOF most but when I go in to work on a project, the team is not busy shuffling and trying to figure out what template to use and what template not to use. Majority of the time, that is left to individual groups to come up with on their own based on what they know of the project and how they feel they can best tackle it.

The .Net Framework has many Enterprise patterns built-in and this basically is reason why many .NET developers do not have to write any code that implements the design pattern.
.NET already implements some major design patterns for .NET programmers in many of the programming models hence one of the reason why I believe programmers should focus more on building and building it right.

I want to disagree with a few comments here.

firstly. Being a lazy developer is actually a very good trait of an above average - expert developer. I am disagreeing on the basis of not reinventing the wheel.

For example

Should i write my own Quick sort algorithm or should i just use Arrays.sort ?
Even the Arrays.sort method in Java which was implemented by Josh Bloch was actually an implementation from the book "Engineering a Sort Function"

Should i implement a new MVC pattern for a web project am working on or should i just use Struts or Winforms ?

etc.

The idea here is that code that is in public domain would probably have been better tested by a community of users than code you have written and tested yourself

The fundamental distinction here is that there are basically two classes of developers.

There are Framework Developers and there are Application Developers.

If you are an application developer it is your duty to combine different frameworks into a workable application in the shortest possible time. That is what you are paid to do.

If you are a Framework Developer . You might want to extend the boundaries of known methodologies just to make your Framework appealing to other developers mostly Application Developers.

candylips:

I want to disagree with a few comments here.

firstly. Being a lazy developer is actually a very good trait of an above average - expert developer. I am disagreeing on the basis of not reinventing the wheel.

For example

Should i write my own Quick sort algorithm or should i just use Arrays.sort ?
Even the Arrays.sort method in Java which was implemented by Josh Bloch was actually an implementation from the book "Engineering a Sort Function"

Should i implement a new MVC pattern for a web project am working on or should i just use Struts or Winforms ?

etc.

The idea here is that code that is in public domain would probably have been better tested by a community of users than code you have written and tested yourself

The fundamental distinction here is that there are basically two classes of developers.

There are Framework Developers and there are Application Developers.

If you are an application developer it is your duty to combine different frameworks into a workable application in the shortest possible time. That is what you are paid to do.
If you are a Framework Developer . You might want to extend the boundaries of known methodologies just to make your Framework appealing to other developers mostly Application Developers.

Excellent points. I tried to point those out but you did a better job than I

Hmmm (sigh)

Nice discussion. Knowing about design patterns means one is exposed and informed about the trends of coding. Implementing them makes you an expert.

However, i fell design patterns evolve as you code. When you find out that you tend write a particular line of code often, then design patterns come in. Thats just the raw undiluted meaning of it. Its all about reusablilty of objects.

If you are an experienced programmer, of course u would use them. They could be yours and if a programmer finds them useful, he could use them too.

With design patters, u can almost rewrite a programming language (lol) because in my case, java doesnt seem to me as java anymore. I have patterns for almost everything i do. If what bores you with a language is the long lines you have to write to get something done, try design patters.e.g

Because i want to display an option pane to inform the user than an operation was successful and also to play a small audio filei have to write this annoying stuff,

playAudio("info.wav";
JOptionPane.showMessageDialog(Main.this,"Operation successful, ","APP_NAME",JOptionPane.INFORMATION_MESSAGE);
return;

But with design patterns,

alert("Operation Successful, ",1); where the ineteger value defines the type of message

where the method alert() must have been declared in a class,

Thats just an idea and u cud have patterns for even bigger stuffs like DB connections and all. I hope i used the right illustrations sha.

While its good to know about standard patterns, its not much of a big deal (just my opinion). What really matters is the overall results. Employers and business owners would be concerned about time, quality and a hitch free job. If you know about design patterns andyou produce a rubbish job, whats the essence, ?

Just my opinion sha

its real interesting the response i get here and as a nigerian based in latvia i'm impressed with this community here and wish to inform any very experienced programmer who is very very good in data base management and c++ including website design to pls inform me by sending me a message on (iamemminem@yahoo.com).i have a good deal and equally good intentions but if u not experienced pls dnt bother to reply,wouldnt be for free and for real i'm a fellow nigerian and shudnt be mistaken for a maga.help me and i pay thats all what i'm saying and there is much deal ahead so i wont be able to discuss all here plus some are biz ideas which i dnt intend to expose cheaply,thanks.

its real interesting the response i get here and as a nigerian based in latvia i'm impressed with this community here and wish to inform any very experienced programmer who is very very good in data base management and c++ including website design to pls inform me by sending me a message on (iamemminem@yahoo.com).i have a good deal and equally good intentions but if u not experienced pls dnt bother to reply,wouldnt be for free and for real i'm a fellow nigerian and shudnt be mistaken for a maga.help me and i pay thats all what i'm saying and there is much deal ahead so i wont be able to discuss all here plus some are biz ideas which i dnt intend to expose cheaply,thanks.

Because i want to display an option pane to inform the user than an operation was successful and also to play a small audio filei have to write this annoying stuff,
Code:
playAudio("info.wav";
JOptionPane.showMessageDialog(Main.this,"Operation successful, ","APP_NAME",JOptionPane.INFORMATION_MESSAGE);
return;

But with design patterns,

Code:
alert("Operation Successful, ",1); where the ineteger value defines the type of message

where the method alert() must have been declared in a class,

Thats just an idea and u cud have patterns for even bigger stuffs like DB connections and all. I hope i used the right illustrations sha.

This doesn't look like any pattern i'm familiar with, its simple encapsulation.
Design patterns is not the same thing as OO. Your example is OO. You should always use good OO when writing applications, you then refactor to patterns when the need arises (you'll know when the need arises).

I think the experience thing comes when you write code and you feel someone is standing over your neck and frowning. The experience comes in knowing that you've just implemented a quickie and would probably have to come back and reorganize the sh*t .
I recommend that guys read the book HEAD FIRST DESIGN PATTERNS, its a solid book and it'll shed some light on murky area of patterns.

It's not much about getting results now, but being able to write code that works now, and can be extensible, reusable and easily maintainable later.

When you use patterns (which rely heavily on interfaces and encapsulation), you can easily replace implementations, or reuse exisiting code and maintain existing code.

I think that is what separates a hacker, and a software architect.

A hacker just writes quick and dirty code that works now, but a software architect (programmer with experience) writes code with solid design experience in mind and uses proven patterns which makes the software easy to be extended later.

Imagine when a hacker wants to add new functionality to already made software, then he has to go into heavy brain-racking sessions, in the end patching up the code with more disorganised code till the whole project comes crashing down, and cannot be fixed any longer that you just have to abandon the software project.

In essence, patterns

-- Provide ready made solutions (not code snippets, but design ideas) that prevent you from reinenting the wheel in common recurring problems
-- Makes your code industry and standard compliant since everybody understands what trick you are trying to play in a particular code block

A good analogy is the difference between Queen's English and Nigerian English.

Though you will communicate using any of the two, but you will be conforming to standards when you speak Queen's English.

ade2kay:


In essence, patterns

-- Provide ready made solutions (not code snippets, but design ideas) that prevent you from reinenting the wheel in common recurring problems
-- Makes your code industry and standard compliant since everybody understands what trick you are trying to play in a particular code block

A good analogy is the difference between Queen's English and Nigerian English.

Though you will communicate using any of the two, but you will be conforming to standards when you speak Queen's English.

Good one. Nice illustrations.

By "Nigerian English" , of course you must mean pidgin English , else your analogy is unacceptable

If you have problems with pattern mail me on marvelindaclub@yahoo.com i have a pdf document that treats design patterns e.g singleton

@all. Just found this tread and i must say we have alot of knowledgeable people n here. I find that the issue on design patterns is misinterpreted by some in here who assume a design pattern to mean some 'black box' entity. Design patterns are said optimal ways of approaching a problem which can be coded in any language. Take for instance the Singleton pattern. It's a way of allowing the creation and existence of one instance of a variable in a program. This can be implemented as a single constant in non-OO languages like old Pascal, as an expicitly heap allocated variable in C, as a class member variable using static keyword in C++, e.t.c.
What about the Publisher-Subscriber pattern, which lets some entity(function,procedure,object) notify/call someother entity at some said event. This to can be implemented in any language regardless of what paradigm/style it supports. So it's not black boxes we talk about when we talk about design-patterns but an approach to solving a repetable problem faced by programmers that doesn't direct u in what way u should write it but in what way u should think when faced with such.
Also i'll like to say that i hope alot of us are not copy-paste programmers but thinkerers.