I was a candidate in an interview for a contract position the other day and as luck would have it, it turned out to be the type of format that I enjoy which is the one where the whole thing turns into an hour long chat about software related issues rather than some kind of technical test or one of the interviewers having a list of questions that they want to ask. This usually occurs when the interviewers are mainly techie types and I find (having been on the other side of the desk a few times) that it can be particularly effective when you're reasonably happy with the interviewee's credentials, but want to find out how they tick, and whether they would fit into the team.
At one point, the discussion moved onto Patterns, and specifically Design Patterns, which in other times I would have probably started my standard spiel about how the GoF book was required reading at Uni and that they were something that I'd found myself evangelising at places I'd worked quite early on.
But on this occasion, I didn't do that. I launched into a bit of a sermon.
The reason for that is that lately, I've started to become more and more dissilusioned with the whole Design Patterns paradigm. When trying to work out why this is I thought about the large number of projects that I have worked on recently where there has been overenthusiastic promotion of solutions containing frankly preposterous implementations of design patterns in situations where a simple, cleanly designed solution would have done the job just fine.
Some of the opponents to design patterns claim that the use of them highlights weaknesses or failures of a particular language to provide certain types of funcionality. I don't really go for that. Where I see the problem is that with relativley inexperienced developers, patterns are a toolbox of huge blunt instruments which they can use to take the lazy route to producing software. Design Patterns take a lot of the thought out of the design process round about the time when the more thought you can put into the design, the better it's going to be.
Im my own head, I see patterns as handy chunks of solution which my mind can insert into a design as a kind of box, so if the requirements state that an application needs to have pluggable components then I can automatically pull out this reusable concept of say an Abstract Factory from the pattern store rather than having to think about all the nuts and bolts of the specific implementation.
Where it goes wrong is when the requirements do not state that the application needs to support pluggable components but the developer putting together the design starts to think "we could make this pluggable, and so we'll have an Abstract Factory here, and we'll have Builders to construct the objects and this bit would be cool as a singleton, and we'll use Adapters to make them work with this part..."
What happens next is that the weaknesses of the language kick in. With C# for example, none of this comes for free, so we're talking hundreds and hundreds of extra lines of code to implement the pattern functionality which we never needed in the first place. This code has to be tested, reviewed and maintained at an additional cost, and for what? So that the hot-shot developer can show everyone how clever they are, and you can be certain that barely a line of it will live up to the subtitle of the GoF book "elements of reusable OO software."
And so I have to ask, is it about time we started to rethink our approach to design and Design Patterns and accept that they are very powerful abstractions, but come with a cost that needs to be weighed against the benefits of being able to draw a nice box on our design? We've had some fun with them, but with an increasing number of well intentioned but ill-informed PMs starting to evangelise about the benefits of Design Patterns, it's time we started to concentrate on good, solid, clean solutions, rather than working out which toys we can cram in.
No comments:
Post a Comment