Buddha443556 wrote:What I've been noticing at Sitepoint and in the open source community is that patterns seem to be driving design. Design was rather out of vogue for a while in this age of extreme and agile programming and here it is sneaking to the forefront again with patterns.
I'm not sure which thread/s you're referring to but I can think of one major design effort which isn't necessarily exemplary code, at least in my opinion.
Requirements rather than patterns should drive design; patterns should just pop into your head when faced with a coding problem. If you study all the pattern resources you can find they'll eventually get absorbed into your unconscious coding brain.
Xp encourages you to focus strictly on the requirements - but
what are the requirements...?. The lesson here seemed to be that programmers should be prepared to make intelligent additions to client requirements if required - and that might mean looking ahead. Once these are properly stated, then it's XP just-enough-code as normal. At least that's how I intrepreted it.
I think you might have been referring to a thread where the mandate is to design an MVC framework. Is that a good requirement? It's certainly not as tightly focussed as a client provision such as "show a list of all creditors more than three months overdue". It's hard to code to requirements which are as vague as this.
Perhaps creating a framework is the most difficult thing of all. Ideally it should be slim; it shouldn't do anythig you don't always need to do. On the other hand it must be sufficiently powerful to cope with whatever type of problem you might need to solve. These two pressures are pulling in different directions and perhaps there is no perfect way to resolve them. Perhaps the art of a framework author is to make best guesses and intelligent compromises in order to create something which will work well for the most common cases or in a chosen domain.
MVC itself isn't that important - and probably gets first prize as the most misunderstood design pattern around (is Ruby rails really MVC for example?). The really important thing is to separate presentation and domain whether or not you also split presentation into controller and view a la MVC.