Jeff wrote:
But I have two specific issues with the book: 1. Design patterns are a form of complexity. As with all complexity, I’d rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.
Design patterns are only a form of complexity when viewed at a code level. When viewed in the abstract, they are a source of simplicity because they provide the ability to understand the forest without knowing the details of every tree. The problem with “simpler [code] solutions” is that the code is the only way to understand what is going on and that breaks communication of ideas because those ideas can only be communicated at the code level. This makes it harder for the rest of the team, QA, Program/Product Management, Other Development Teams, … to understand what is going on inside the box.
It is true that rabid adherence to every gory detail of the patterns in Design Patterns can lead to overly complex code but, as others have said, these patterns are to be adjusted to the needs of the task at hand. If the full power of the Abstract Factory or Factory Method is not needed then simplify them down to the core idea which is “place construction code in a separate method so it doesn’t clutter up the mainline logic”. If you aren’t bridging two different inheritance hierarchies, don’t use the bridge. If the target API is close to the needs of your project, use a facade to wrap it - don’t bother with the adapter.
In arguing for his point, Jeff shows that his argument wears no clothes (to paraphrase an earlier point). Jeff and another individual shared these thoughts:
Who are these architects that I always hear about that blindly apply the Gospel of the Design Patterns instead of thinking? I’ve not seen them, and the GoF book doesn’t seem to advocate it as far as I can tell.
Indeed. Ever read “The Bible”, or “The Quran”? Strangely, those books don’t advocate a lot of the things you’ll see people doing in the name of them, either.
The Bible and The Quran are often used as justification for strange arguments - that doesn’t make those arguments right. Those who apply the gospel of Design Patterns instead of thinking are not right either. In condemning the book because it is a source of unnecessary complexity, Jeff seems to be saying that because some zealots misinterpret its intent, the book is bad. But his counterargument above seems to imply that, despite being misinterpreted by some zealots, The Bible and The Quran are not bad. Was the cake tasty Jeff? Do you still have it around? You can’t have it both ways.
Now perhaps I am misinterpreting Jeff’s intent since he doesn’t seem to disagree with the idea of patterns, just the overreliance of some in the software industry on this one book instead of the ideas that were embraced by Mr. Alexander years ago.
My concern with Jeff’s post here is more that it will be used as ammunition for those who don’t want to design, who don’t want to worry about future changes that are known to be coming down the requirements pipe, those who will argue that a “simpler solution” is better. I worked with people like that. One very senior developer (senior in years, not skill in my humble opinion) argued that design patterns would do us no good - that you could not come up with a solution as elegant as the one he came up with without playing with the code for a while. It turns out that the elegant solution he came up with, after six months of uncontrolled coding because managers were afraid to interfere with “the great one” (eyes roll, sarcasm spews from mouth), was simply the interpreter pattern and I showed it to him in a book in 5 minutes once he finally was willing to discuss his grandiose project. All this work of his was justified by the argument of “simpler solutions”. Other work of his and his team that was justified by “simpler solutions” included a 40000 line class, some 2000 line methods in which the set of variables that tracked the state of the operation changed as you proceeded through the code, methods with cyclomatic complexity in excess of 60, etc. Because their code was “simple” it could not be discussed outside of the code - and therefore there were no sanity checks to stop these debacles.
Design patterns is an excellent book and should be on every developers shelf. It enhances team communication, it provides a source of inspiration when one is confronted by a tough problem, it allows developers to avoid six month ratholes because they are convinced nobody else can help them or they are too proud or arrogant to ask around. Because a few zealots overuse the book and religiously adhere to what it says does not mean the book does not provide a valuable service.
