Jeremy D. Miller -- The Shade Tree Developer

Gospel vs Guidelines mentality.

A majority of our industry interprets guidelines as Gospel. Then we(coaches) spend the remainder of our time putting them through rehab.

This is why I recommend Kerievsky's Refactoring to Patterns (www.amazon.com/.../0321213351).  

From page 29: "Good designers refactor in many directions, always with the goal of reaching a better design."

The goal should never be "wow, look at all the cool patterns I used" but rather, "look how I was able to use well-known practices to create an elegant and maintainable design."  Patterns for patterns' sake is folly.

But what about the pattern thumper who has the GOF patterns memorized and strictly has a myopic view of the design.  He holds his GOF high in the air and sacrifices a key board and mouse to it every week.  All code must factor to the GOF there is no other way.  You will find peace and serenity in the GOF.  If it isn't in the GOF than you are going to hell!  Yeah that guy.

Let us pray now..... ahmmmmmmm ahhmmmmmm.

This takes him out of the job and goes against his very creed.

In software development as in life, many people hold the persistent belief that there is one true book out there that will tell them all they need to know. If I can just find this book all my problems will be solved! Hallelujah!

People are basically lazy and have no interest in knowing 'why'. Someone should start a crusade to burn all copies of this GOF book. The Singleton pattern is pure evil and must be stopped at all costs!!

@Jeremy - Well said.

"Value the Why over the How" should be one of the alt.net tenets. A solid principle that is misapplied has more potential to wreak havoc than all the drag-n-drop tools in the world. It also has the unfortunate side affect of turning people off to legitimate sources of knowledge like the GoF patterns because people get jaded after seeing them misapplied so often.

GoF offers a useful perspective on recurring design problems, it is not intended to be prescriptive.  If it were then I'm sure there'd be a spiffy "Refactor Now" button in your IDE to apply all of the *cough* "correct" refactorings for you.  ;-)

People often forget that Patterns came second, not first. If you could read the 'Genesis' of Patterns it would be 'In the beginning there were solutions, then people looked at those solutions, saw common ways of solving problems and thus patterns were born". The reverse which is the misconception starts with something along the lines of "In the beginning there were patterns...".

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

well said Jeremy

the Singleton pattern has singlehandedly turned the project I am working on into an horribly tightly coupled sprawling monster. its the only "design pattern" that many of the developers can name

Patterns are solutions to a problem in a particular context.

Generally some people forget the context part.

I totally agree that patterns should be treated more as principle and not as law.

For e.g., for me composite pattern is an type with the collection property of the same type, command is just a "traveling delegate" etc...

The patterns are common solutions to common problems, but they should be used only if there is no other "painless" way to do the same thing without patterns because they introduce additional complexity etc...  

Pingback from  book » Just because it's in a patterns book…

It's not about the patterns but about refactoring to them.

That's why the Kerievsky's book is so good. It really helps you to create the ability to see paths in your code, that can take you to different patterns.

And as with paths in a wood, they can take you to a very gloomy and scary places.

But seeing those paths often helps in asking yourself a question "why?" Why should I implement  this in such way? Why is this solution better then the other one?

Pingback from  ThemePassion - Best stuff about design! » Just because it's in a patterns book…