Design patterns

[Jaws]

<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>

Judging by the quality of a lot of code I come across that statement applies to a lot of developers contractor or otherwise. I dont really see a problem in books aimed at less senior developers, there are after all numerous books on the various languages very few of which actually tell people how to code in an effective and readable manner.
That said, it appears like the people consistently delivering tulip take so little pride in their work/are so lazy that reading a book to get them past the basic "getting things to work" is unlikely. Those are my "pet hates" (perhaps I am a little sick of current contract ).

[NotAllThere]

I'm interested to hear opinions on the use and development of design patterns in C#.NET from a software developer standpoint. ..

The fact that it's C#.net should be immaterial - but I do stand to be corrected. I'm developing apps for SAP using ABAP. I've found the Head First design patterns book to be really useful. ( I also found it gratifying that I was already using certain "patterns" before I knew what they were ).

But what Minestrone says is true. When people think it's the answer to everything, then they should be taken out and shot.

Having been intensively involved in object oriented programming in the last few years, what I've found most useful is separating the different layers of the application, and abstracting where appropriate. You know when you've got it right when you have to add new functionality, or adapt existing, and it isn't difficult.

[TheRefactornator]

The fact that it's C#.net should be immaterial - but I do stand to be corrected

Yes no problem I'm aware that design patterns are language independent, but I'm specifically interested in the C# slant because this is my area - I'm not the "I can do anything and everything" type because I think it's sensible to specialize somewhere. The other thing is that the .NET community has been widely criticized as slow on the uptake of design patterns so it's interesting to hear the opinions of other .NET developers to get their "take" on it.

From the comments so far I don't see out and out pattern haters here but more like a concensus that they should be used where appropriate or they are common sense. Generally I'm trying gauge whether C# developers have patterns in mind early in the lifecycle and try to design and code to patterns from the outset or if their code just falls into design patterns by complete accident, because good code will do that and the patterns documented by the GOF and others later are just statements of the obvious.

Historically I've been in the second camp for a long time developing software for about 12 years and at least for the last 10 years or so while I've been fairly happy with the quality, reliability, maintainability of the code I've produced, I think it's healthy to have an objective opinion of your own work to be happy it's at least in the ballpark of good practice. For me I think I'll be happy to get a clearer understanding of some of more obscure patterns and have a more pattern focused approach to software development in future, but I don't think I'll ever be trying and shoe horn patterns in absolutely everywhere.

The comments swamp made about anti-patterns and factoring out were very interesting because changing requirements can have a bearing on pattern selection i.e. what was a good choice for design today maybe a bad choice tomorrow. I've certainly had first hand experience of this which is why I am TheRefactornator - the choice of name was a side effect of the gig I was in when I signed up on CUK..bad times thankfully now over.

[Jaws]

From the comments so far I don't see out and out pattern haters here but more like a concensus that they should be used where appropriate or they are common sense. Generally I'm trying gauge whether C# developers have patterns in mind early in the lifecycle and try to design and code to patterns from the outset or if their code just falls into design patterns by complete accident, because good code will do that and the patterns documented by the GOF and others later are just statements of the obvious.

I'm aware of the patterns (and a C# developer) although I generally start with the simplest solution possible and if after I've written a fair amount of the system and all the requirements are becoming crystal clear, I might refactor to some common pattern if it's not too much effort and will genuinely improve the code. There are certain patterns I tend to use without thinking (like "Template Method" if I have a lot of similar classes) but I think that is just something you'd use anyway if you have a grasp of OOP (in fact I believe that is used quite heavily in the framework itself).

It's more the overall design principles any developer should know that I concern myself with when developing rather than specific patterns.

It's quite useful knowing them in general when you have to pick up a system which someone has gone pattern mad on.

[Smurficus]

or if their code just falls into design patterns by complete accident, because good code will do that and the patterns documented by the GOF and others later are just statements of the obvious.

A good, experienced developer's code will tend to fall into patterns as they've done the trial and error themselves, this is the same reason GoF seems obvious. I see design patterns as a way of harnessing this work and passing on the information without the need to go through the trial and error again.

Patterns also provide benefits, other than code reuse, that architects and developers should be promoting:

• better communication - if all developers in the team understand what the strategy pattern is for then there is no need to describe it in detail and invite misinterpretation.
• faster training - junior developers learn from the more experienced, if everyone is talking a common language the juniors will be able to skip parts of the trial and error that those more experienced developers have had to go through.
• there are more, I just can't think at the moment...

I think that, like everyone else, they have a place in the developer's toolbox but they are far too commonly abused.

[FSM with Cheddar]

Agree with Smurficus.

It's a common language.

Also, when an architect designs a new house, they don't start from first principles, they use their experience and a number of basic design principles.

Software is no different. If you stick purely to patterns then you well stifle any creativity, however if you ignore what has already been done before, then you are wasting time.

I find the book of anti-patterns more useful, as it reminds me of design routes to avoid.

[lightng]

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

Thats like saying you've got no business fixing cars if you need to need to look at a Haynes manual. What a load of tosh!

[lightng]

I had the task of taking some VB6 / 4GL programmers though .NET on one gig. They had done a month's worth of courses but had very little understanding of OO.

Before introducing any of the GoF patterns, I made sure there was a good understanding of basic OO principles (i.e. GRASP General Responsibility Assignment Software Patterns). Once developers understand this they are most of the way there in my opinion.

There are many applications where patterns are blindly used just because they can be. I refer to these as book-keeper apps: a book-keeper can go through the mechanical process of producing your accounts but only an accountant can advise on the implications.

[VectraMan]

Thats like saying you've got no business fixing cars if you need to need to look at a Haynes manual. What a load of tosh!

I doubt any professional mechanics do refer to Haynes manuals. Workshop manuals maybe..

I see it more like saying to Paul McCartney: You don't need to think about what sequences of notes to use in songs anymore because we've written them down for you. So now you can write much better songs in half the time.

[TheRefactornator]

I see it more like saying to Paul McCartney: You don't need to think about what sequences of notes to use in songs anymore because we've written them down for you. So now you can write much better songs in half the time.

Please don't, he should not be encouraged in any way. Not even in jest.