arborint wrote:I am regularly confused by these converstations. It sounds like you are saying that because best practices are not "be-all, end-all" that you should choose worse practices?
Thats not what I mean when I say the same thing...
Design patterns are just that, their patterns, not strict implementations or holy bibles to build software by. I find you overly zealous towards their promotion and practice, nothing wrong with that. However my point is, you may see myself as naive to their cause, but in the same light I may see you as just the opposite. See where I'm coming from?
As an experienced developer I can see their use and have even reviewd many existing frameworks developed by the best programmers in the world and have be able to map some similarities to existing patterns to their design. But often, in my own cases and others those design patterns are broken (when someone is as strict about their use or definition as you are).
I often get the impression you are suggesting anyone who follows a design, but not *exactly* as Martin Fowler explains it is doing wrong and is clearly an inexperienced developer. Making me wonder who you or Martin Folwer are
Tony Marston(sp?) has recived flack by many a developers because of his implementation of OOP and yet he been a professional developer for something like 20 years, which is a long time. So I'm sure he knows what works and what doesn't.
Just recently (as you may recall) I was working on an MVC framework in which I wanted to somehow support both model 1 and model 2 paradigms. That was the end goal as supporting both would likely seem the best idea. However after some thought it appeared to be impossible to implement strictly following design pattern guidelines, as a page controller and front controller are quite different.
So I modelled my software *after* known existing patterns as opposed to following them 100% to definition, thus I was capable of supporting both a model 1 and model 2 using the same codebase, basically using an extended version of the base class.
This is an excellent example of where academia and real world collide. It was practical for me to support both models, not one or the other, but following strictly what design patterns dictate would have required more likely than not a slightly different codebase to suport both, whereas I managed to implement model 1 as a base class and model 2 as an extended class of the base class so using one over the other is as simple as deriving your class from the appropriate model1 or mode2 classes.
That switch is crucial as I want it to bes as seamless as possible to switch from one model to the other for client developers.
ASP.NET forces you into using a page controller design, whereas many PHP frameworks support front controller design. I wanted to support both!!! I should note I have found an article on implementing front controller in ASP.NET but it's alot of additional work.
Anyways, my point is, my experience has taught me, that every situation is different and every developer is different. I have good ideas too, some are damn good ideas others are complete failures. I have spent years toiling over how to best design or implement a solution, maybe even as long as Fowler has, who knows (likely not he appears quite old). I can't personally follow in the foot steps of someone just because.
I have read much of design patterns lately, UML, TDD, etc...and none of it is really *new* or amazing, in fact, it's just formalized what I've already pretty much done for the last 15 or so years I've been seriously into programming.
Methodologies are hard pressed to be rapdily adopted, not because they don't make sense or because they go against existing known knowledge, but becayse, their nothing new to an experienced developer (hence the old timers reluctance I imagine) just refined ways of doing something. So many are forced to ask the question:
"Should I spend time formalizing what I already know"
Well, for a young programmer like me, the answer was 50/50 yes and no...so I'm absorbing it slowly, learning as much as nessecary to better understand what it is i'm doing. Others maybe not.
The point is, their patterns, not blue prints like some articles or books may suggest. They are quasi-models which are likely best for new programmers to observe, as experienced developers should already have many of them hammerd out and just need formalizing for the sake of nomenclature

Vocabulary is important when trying to describe something and is what I have found most udeful in learning design patterns, no longer am I stuck spending greats deals of time toiling over commenting code sections. Another thing I have learned over the years is that techniques change faster than my socks, so to obsess with any one model or method is pointless - because next year Joe Blow will propose an entirely different outlook on things and make the exact same claims about how it will change they way you do business.
Cheers
