Design patterns

[TheRefactornator]

I'm interested to hear opinions on the use and development of design patterns in C#.NET from a software developer standpoint. Recently I've become much more interested in patterns myself and I'm wondering about the different approaches people take with respect to design patterns in software development.

Usually in the realm of the architect / designer, my opinion is that design patterns are also very useful to the nuts and bolts developer and important when striving for reliable quality code..and I am a developer not an architect or a designer. Indeed in some cases you might find yourself in a role (I know I have) where there is no architect or designer available and these responsibilities are handed over to the developer.

This might not be the best place to ask because the answer from some might be "whatever the client wants", but I'm interested in personal opinion so with that in mind if you're a C# developer, try and fit yourself into one or more of the categories below and please explain the reasoning where possible:

• No consideration given. I look at the spec I'm given and get hands-on coding with little regard for code structure or patterns.
• I am aware of pattern theory but I only use patterns as part of the provided framework e.g. in ADO.NET use of DbConnection, DbCommand, DbDataAdapter descendants etc.
• I am acutely aware of pattern theory and always look to align my own class design against the best well known design patterns.

What say you all?

[minestrone]

The growth of design patterns was probably one of the most damaging movements to happen to software development. They were taken as verbatim on how to write code and people who read a couple of books then believed they had the tools to architect code. I still come across ObjectMediatorObserverTemplate type class names.

[TheRefactornator]

The growth of design patterns was probably one of the most damaging movements to happen to software development. They were taken as verbatim on how to write code and people who read a couple of books then believed they had the tools to architect code. I still come across ObjectMediatorObserverTemplate type class names.

I'm not sure if that is a "to be avoided like the plague" or a "to be used where appropriate" opinion.

[Dark Black]

Most design patterns are common sense / good practice anyway.

I used to work with a chap who was always spouting off about one type of pattern or another. I had a look in his book to see what the tulip he was yapping about, only to discover that I'd been using similar designs for years - I'd just used my brain and figured it out myself.

Most decent old skool software engineers won't waste their time or money on such books...

HTH

[VectraMan]

Most design patterns are common sense / good practice anyway.

I used to work with a chap who was always spouting off about one type of pattern or another. I had a look in his book to see what the tulip he was yapping about, only to discover that I'd been using similar designs for years - I'd just used my brain and figured it out myself.

My feelings exactly. I've got the book: I'm using it right now - as a monitor stand.

If you can't figure out those sorts of solutions for yourself, you've got no business calling yourself a developer. All they've really done is give new names to old concepts, which is fine except you're now expected to know the proper terminology in interviews.

[minestrone]

I'm not sure if that is a "to be avoided like the plague" or a "to be used where appropriate" opinion.

Well I cannot say do not use them as I do use published patterns myself on occasion, I also get your point about using them in frameworks and that is where I would se myself using them. I found the GoF book to be a educational book, I learned about decoupling and separation of interests massively from the book in the late 90s. People took the book to seriously and thought that it was a 'how to write software' book which I am sure the authors never intended. It almost became a religious movement in software, you had to memorise the 26(?) patterns to get a gig, I had to do that for my J2EE architect certification which was fairly pointless.

[swamp]

Some patterns are common, straightforward concepts. Like Singleton, MVC. Others are generally just common sense encapsulated in a name.

IMO patterns work best as things to refactor towards (the book "Refactoring to Patterns" explains this quite well). It's difficult to impossible to know what patterns to apply up-front in a given situation. Many patterns only become worthwhile when the code become sufficiently cluttered/messy/smelly to need that pattern. Apply a pattern when it is not needed, and it becomes an anti-pattern, and that can be a very bad thing indeed.

Interestingly, one can also refactor away from patterns if that pattern is no longer justified. For instance, your code uses the Strategy* pattern to decide what to do in a variety of situations. Then the business rules change and you're only doing one of two things. Ideally you should rip out the Strategy pattern and replace it with a simple 'if' statement.



(* I think I mean the Strategy pattern... can't be bothered to check!)

[minestrone]

For instance, your code uses the Strategy* pattern to decide what to do in a variety of situations. Then the business rules change and you're only doing one of two things. Ideally you should rip out the Strategy pattern and replace it with a simple 'if' statement.



(* I think I mean the Strategy pattern... can't be bothered to check!)

Seen a really clever implementation of the strategy pattern once, the class was called FileWalker, you passed it a Strategy class and a directory, It would recurse through the files under that directory and upon finding one pass the file to the strategy object which would, in this instance, print out all the public methods, if you wanted to do it for private methods you would just write another strategy object. Seperating different work into different classes.

Now the problem I had with that design was in that instance there was only one thing they were doing with the class, reading the public methods so I thought it was over engineered. So I get into this discussion with the architect where he asks me if I was writing a DAO would I make it adaptable to deal with multiple data storage scenarios. I said 'no, write for what you use', he said 'wrong what would I do if the software had to move from file storage to relational DB storage'. My answer was 'can you tell me in your life when you have moved a program that used file storage to DB storage. I think I won that one as he never answered.

[Dark Black]

<rant>
All those books on refactoring are another of my pet hates - frankly if you need a book like that to sort your code you have no business being a developer either...
</rant>

[minestrone]

Aye, Fowler and his constant 'continuous integration' mince.

Don't know if anyone used to read (potentially NSFW) www.bileblog.org (potentially NSFW). Fowler used to get some abuse on that site.