This discussion is a good start for this new site called Design Pattern NINJA, isn’t it?

All good software guys and girls know why design patterns were invented. Software development isn’t a full creative development process and really there’re some parts of our programs that are - sadly - almost implemented the same way. We’ve a limited margin to re-invent the wheel.

After all a design pattern is a definition of a common, reiterative and almost invariable problem and solution that you may face depending on the requirements of your project.

Sounds good

Yes, it sounds good. Nice. You should know that science has evolved accumulating knowledge. Scientists have always used to rely on others’ theories unless they could prove that those can be refuted and replaced by a more convenient theory.

While computing isn’t a science per se, computing industry is built based on science principles, and we software guys and girls should work on accumulating knowledge that may be transmitted to future generations.

In my humble opinion, this is the purpose of design patterns. While sometimes they’re unspecific to a concrete programming language or platform, they represent a simple but yet powerful textual approach to avoid the repetition of same software design discussions all over again and focus us on inventing what’s not yet invented. This remained me to the voice over of Start Trek New Generation opening:

Space: the final frontier. These are the voyages of the starship Enterprise. Its five-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no man has gone before.

Do you imagine the Enterprise starship not built based on centuries of scientific investigation? Ok, Star Trek is just a TV show, but you know where I’m going with this philosophical debate.

So why you should be against design patterns? You said that design patterns will take us to the stars…

Not exactly. This is the main issue used against design patterns! For many software guys and girls, design patterns aren’t just a tool to begin architecting a solution on top of previous community experience. Many of these have turned design patterns into a dogma.

Let’s simulate a chat about how to find a good solution to some problem:

[John] We need to start developing this new project. How we abstract our business code from the data storage technology.

[Jennifer] REPOSITORY. DATA MAPPER. DDD. SEPARATION OF CONCERNS. INTERFACE SEGREGATION PRINCIPLE.

[John] But, we don’t know the application functional requirements yet.

[John] REPOSITORY. DATA MAPPER. DDD. SEPARATION OF CONCERNS. INTERFACE SEGREGATION PRINCIPLE.

[John] REPOSITORY. DATA MAPPER. DDD. SEPARATION OF CONCERNS. INTERFACE SEGREGATION PRINCIPLE.

[John] REPOSITORY. DATA MAPPER. DDD. SEPARATION OF CONCERNS. INTERFACE SEGREGATION PRINCIPLE.

Actually… is this a discussion or just the software architecture’s Ten Commandments?.

Yes, there’re people who actually follow a new religion that we may call The Design Pattern Dogma.

Although design patterns are a representation of others’ effort on defining how to solve common problems, design patterns should never be taken as is but they should be a necessary tool when a software development team do meetings to define their product software architecture, and they should be never the definitive solution.

As I’ve already said somewhere on this post, design patterns are just there to be a starting point on your solutions. Before starting to think and design your solution from scratch, you should find if someone has already got into a similar use case like yours and the way of solving it can be a good solution for you too. If it’s not your solution, you can be very sure that, at least, it has provided some info on how others have solved your problem and it’ll definitively put you in the right track (if you want to…).

Design patterns let us take software development to a new field: software philosophy

In my case, I decided to create Design Pattern NINJA to provide a tool to both bring democracy and a spotlight to all software architects and developers around the world.

A good way of avoiding the The Design Pattern Dogma is being able to change the dogma. We can create new design patterns or we can also evolve existing ones. Ten years in the technology industry is like an entire century in other fields. Software development isn’t immutable, and design pattern aren’t a dogma: they’re a concensus.