in Search

Do you Twitter? Follow us @CodeBetter

David Hayden [MVP C#]

.NET Tutorials, Patterns, and Practices

Response to Design Pattern Comments on Jay's Post

I was 3 paragraphs deep into writing a comment to Jay's earlier post, Starting to come out of my funk, when I thought it might be useful to just make my comment a post.

A couple of the comments to Jay's post about design patterns are similar to the flame-type posts you get when people start to argue VB.NET vs. C#, Stored Procedures vs. Dynamic SQL, etc. These types of comments concern me, because they start getting less about the facts and more about someone's religious-like preference or bad experience that causes them to get angry. I normally stay away from commenting on those posts, because by doing so you risk the chance of having your mamma being mentioned a few times.

I encourage you to read all the comments about Design Patterns on Jay's post, but Don's comment pretty much says it all with respect to Design Patterns:

Don's Comment

"Design Patterns are more then just how to write code. They are a great way to explain your problem space to a 3rd party that doesn't know your app. I think the line in Fowler's book was that he just wanted to come up with a common language to express the different ways he was implementing some OO stuff. Since a lot of what we do as coders is pretty repeatative, having a common name and description for solving a problem space sure makes it easier to communicate with others. [ Don Demsak ]."

I really don't need to expand on this as it pretty much says it all, but I will, because I have those 3 to 4 paragraphs sitting in notepad that seem such a waste to delete :) Most of it is in response to comments in Jay's post, so read those for more context.

My Thoughts

Design Patterns are not only a list of solutions to common programming problems, but a good way to communicate your design to other people who are not familiar with it.

Nobody is suggesting that design patterns are the Holy Grail and that if a person doesn't use them he/she is inadequate. And, vice versa, just because you can spout off a couple of design patterns doesn't mean you are a good developer.

For me, they are like coding standards. If everyone practices a similar coding standard, it makes it easier for anyone to jump into the code and easily recognize it. No, you don't have to use coding standards to write good code. And no, using standard coding guidelines doesn't mean you are a great coder. But, following coding standards sure does help Jay's coworkers if Jay leaves the company and now someone else is responsible for maintaining his code.

The same is true of design patterns. If Jay tells me he is using the Observer Pattern for xyz, even without looking at the code I can get a feel for why he used it and what he is trying to accomplish. Since I also have an idea on how the Observer Pattern is usually implemented in .NET (at least with VB.NET and C# anyway), I also have an idea of what to look for when reading his code.

I think it really is that simple and nobody should look at the use of design patterns as some measure of programming skill. However, totally writing them off as useless does seem a bit ignorant / arrogant.

But as I mentioned in a previous post, Design Patterns and Agile Software Development, design patterns are a solution to a real problem. If you don't run across a problem that a design pattern solves while coding, there is no reason to use a design pattern. Not all applications will or should use them.

And although I think you can learn a lot from the GoF book and others, I have personally found that the best way to learn about design patterns (and best practices in general) is to poke around some of the open-source code written by people who have a wealth of experience. If I had to pick one open-source solution that immediately comes to mind, the Enterprise Library source code is teeming with design patterns.

And, for a book, I haven't read it, but the Head First Design Patterns book has received a lot of good reviews and I believe has won a few awards. Another book that is just a good all around text on OOP, Patterns, and Agile Development is Applying UML and Patterns by Craig Larman (3rd Edition).

Like Jay, I recognize my weaknesses and strive to learn something new every day. Eric Sink said it best with his article on Career Calculus and constant learning.

Published Jun 01 2005, 06:20 PM by David Hayden

Filed under: Design Patterns

Comments

Jay Kimble said:

BTW, I don't want any of my co-workers understanding my code... I leave a wake of chaos behind me when I change jobs... I want people to fear me leaving after they'vehired me...<grin />

# June 1, 2005 7:13 PM

Sam said:

Head First Design Patterns is actually kinda "meh" in my opinion. When I first read the sample chapter I was all psyched up, and ordered a copy straight away. While it's an entertaining read, it's actually pretty light on content.

If the GoF book is on the dry side, then Head First Design Patterns is on the airy side, and the POEAA is somewhere in between. If you have to have just one patterns book, the POEAA has got to be it. Chock full of content, but a pretty easy read too.

As far as knowing patterns... I think being able to hold a conversation on them, even if you don't agree with them, think they're over-hyped, or whatever, is one of the easy ways to pick the programmers who are just there for a pay-check from the ones who actively try to advance their skill-sets.

Not to say that if you can't spout off a few patterns and their usage you aren't a good coder, but it can be hard sometimes to tell, and as a generalization it holds up well enough in my anecdotal experience. (Which doesn't mean much I suppose.)

"If you don't run across a problem that a design pattern solves while coding, there is no reason to use a design pattern. Not all applications will or should use them."

I have to respectfully disagree. :) I can't think of anything I would actually term an "application" (as opposed to some quick scripting work) that couldn't benefit from at least 1 of the 40 some odd (IIRC) POEAA patterns. Perhaps you implement it unawares that it's a pattern, but it's still good code. That I could believe. But even a modest web-application that talks to a database, with not so much as a Singleton?

# June 1, 2005 9:31 PM

Scott said:

I'd agree with Don, too. A key to success in software development is communication, and it's difficult to communicate about hunks of code in a high level sense. To me, patterns are more about vocabulary than implementation.

# June 2, 2005 6:03 AM

David Hayden said:

Sam,

I agree with you, but my purpose for suggesting that all applications will or should not use design patterns was to reinforce my belief that design patterns should be thought of as a solution to a problem that occurs during development / refactoring. If you don't come across a problem that a design pattern solves, using one is creating some unnecessary complexity. This might be pushing the pendulum to the other extreme a bit, but in general I think this is a healthier stance on design patterns than just tossing them in to future-proof an application from any change, whether realistic or not.

With ASP.NET 2.0, however, you can put together some drag-and-drop web applications using the new SqlDataSource Controls and GridView, etc., without even writing a single line-of-code. Although I know it isn't quite up-to-par with what we are talking about here with applications, one has to realize that there will be a lot of smaller- and medium-sized web applications out there where nobody has written a single line of code (only the IDE).

And with the use of the Microsoft Application Blocks, code generation tools, and various frameworks, a lot of people are only writing the glue that binds the pieces together and none of the advanced logic. One could make a good living doing that without even knowing how to spell design patterns.

# June 2, 2005 8:22 AM

Scott said:

hehe, looking at my comment it might sound like I'm dismissive of patterns. I'm not, but the reason the patterns came about in the first place was to solve specific problems while coding in a generalized fashion. I believe whether or not you are aware of the patterns, you will write code that solves those same problems. Often times your code will correspond with the patterns. If you are "pattern aware" (to quote Zelazny) you spend less time thinking about how to solve those problems. But too many people pick a pattern and go looking for the problems to solve. That being said, I still believe the only reason Microsoft is hyping the patterns so much is because their "Mort" languages (C# and VB.NET) now support them much better than they previously did

I like the "common vocabulary" thought that Don XML verbalized. That sums them up nicely. He should put that on a T-shirt.

# June 2, 2005 10:19 AM

David Hayden [MVP C#]

Response to Design Pattern Comments on Jay's Post

Comments

Jay Kimble said:

Sam said:

Scott said:

David Hayden said:

Scott said:

This Blog

Syndication

Recent Posts

Tags

News

Florida .NET Developer

Other Links

Patterns & Practices

Teas

Archives