Mike Borozdin's Blog

A blog about programming, web and IT in general

Design Patterns are not a Silver Bullet and the State of the Programming Blogosphere

Design patterns are not a universal tool that can be applied to any project or be used with any programming language. Quality code can be produced without implementing any pattern or even without using OOP. One shouldn’t think of their colleagues as of bad developers if they don’t know the names of fancy design patterns. Moreover, not any single programming project is a business application.

Recently I have read so many blog posts where authors ranted about design patterns, test-driven development and similar stuff. It feels like many people approach design patterns as a silver bullet that will help them to solve any tricky problem they may encounter. Furthermore, the same people become really angry if somebody thinks out of the box and simply disagrees with their ideals. I don’t imply that the majority of programmers think so, but the blogosphere tend to be in such a state. At least, the blogosphere I’m circulating in, being mainly a web developer I mostly read about web related technologies. Sometimes, it’s even amusing to read people’s reaction to the opposite opinions, especially if an opinion is expressed by Joel Spolsky. Frankly, it looks like almost every programming blogger feels honoured to disagree with Mr Spolsky.

Anyway, design patterns don’t deserve that buzz they are getting. Most of design patterns are so obvious that it is even silly to read or write about them. For instance, I’ve come across a great number of articles about Dependency Injection that in fact is a pretty trivial thing. Every smart developer is able to come up with it when he needs it. There is no point of trying to memorise every single pattern, because it can lead to its stupid implementation when it’s completely undesirable, for example, in small projects where the patterns implementation code can become bigger than the code performing some real job. Of course, I don’t think that it is bad if a common programming technique has finally got the name, but it is stupid to think that if somebody doesn’t know what “dependency injection” is, then he will never produce good code. “Dependency Injection” is hardly more than just a name.

In addition, design patterns and even OOP are not universally applicable. There are many programming projects besides business applications and often you are limited by the resources you have. Many popular applications that are used by everyone are written in pure C which doesn’t support OOP. However, this doesn’t mean that the code written in C is bad or “smells” as some design patterns followers would say. There is a great presentation called “The (lack) of design patterns in Python” on this topic.

Also, a gap between different worlds of programming often leads to misunderstandings when, for example, somebody tries to prove that everyone should do test-driven development even when programming with a Assembly language. It’s usually the design patterns adepts who can’t imagine that programming isn’t all about writing custom business applications.

Indeed, even if we are just web developers we are still fascinated with other stuff, like computer games with mind blowing graphics or convenient operating systems or precise search engines and a lot more, but when people create all that software they think not about design patterns but about useful and fast algorithms.


Posted by Mike Borozdin on Monday, January 04, 2010 3:45 AM GMT
  Shout it Kick it!  
Permalink | Comments (8) | Post RSSRSS comment feed

Comments

DotNetKicks.com

Monday, January 04, 2010 3:47 AM GMT

trackback

Design Patterns are not a Silver Bullet and the State of the Programmi

You've been kicked (a good thing) - Trackback from DotNetKicks.com

DotNetShoutout

Monday, January 04, 2010 5:58 AM GMT

trackback

Design Patterns are not a Silver Bullet and the State of the Programming Blogosphere

Thank you for submitting this cool story - Trackback from DotNetShoutout

topsy.com

Monday, January 04, 2010 7:32 AM GMT

pingback

Pingback from topsy.com

Twitter Trackbacks for
        
        Design Patterns are not a Silver Bullet and the State of the Programming Blogosphere
        [mikeborozdin.com]
        on Topsy.com

uberVU - social comments

Monday, January 04, 2010 8:08 AM GMT

trackback

Social comments and analytics for this post

This post was mentioned on Reddit by pilt: I hate when people think the strength of a design is a function of how many design patterns are implemented. An application won't come out awesome because you implement the repository pattern, the blackboard pattern, and the limp dog pattern.

Marcelo L United States

Monday, January 04, 2010 1:58 PM GMT

Marcelo L

Fantastic. Every so often a little sense into every paradigms posterior must be introduced.

You, Sir, will be tweeted about !

Carfield Hong Kong S.A.R.

Tuesday, January 05, 2010 7:33 PM GMT

Carfield

Excellent observation!! I think "smell" from book refactoring is a more useful element of design to focus on.

Christian Toivola United States

Wednesday, January 06, 2010 12:01 PM GMT

Christian Toivola

Nobody said design patterns are a silver bullet. They are called design "patterns" because 1) programmers are stuck with the expressive limitations in their respective programming languages and 2) certain programmers care enough about their code to eliminate "smells" (smells=indications of code that benefits from refactoring/redesign) to make their code easier to read, maintain or more efficient and 3) these solutions to particular problems tend to converge, thus making it useful to come up with a uniform naming convention and describe the solutions. There is nothing to loathe here except for your close-mindedness, which quite frankly is appalling and stereotypical of .NET developers. If you cared to look further, you will find that all the patterns in the GoF book are, in fact, "pretty trivial" (tm).

As a Python developer, I can tell you that most of the cases that I end up using design patterns, it is in statically typed languages and 90% of the time its to compensate for the awkward polymorphic behavior. Python is dynamic, has support for multiple inheritance, uses duck typing, functions are first-class objects and these plus many other qualities make it much easier to write elegant, reusable code without having to resort to conventional design patterns as described in GoF. The point I am trying to make is this: if you write java, VB, C++ or C#, then chances are that design patterns will facilitate the speed with which you program because if you are familiar with them, then you can immediately identify if a particular design pattern is applicable to the problem you are trying to solve. Sounds like a win-win, no?

Mike Borozdin United Kingdom

Wednesday, January 06, 2010 1:22 PM GMT

Mike Borozdin

Christian,

Thank you for your thoughts.

First of all, I don't consider myself to be a .NET developer, even though I'm using it, at the same time I do use another platforms and languages as well.

Then, I wouldn't say that refactoring necessarily leads the usage of design patterns. Refactoring is just used to make code better, more maintainable, to put it precisely. Design patterns could be used if they are appropriate to a problem, of course.

Note, I didn't say design patterns are bad. I just don't like the design pattern obsession I can see while reading some other blogs.

Comments are closed