Are Design Patterns really that bad?

icelava:

Coding Horror: Rethinking Design Patterns:

 

It's certainly worthwhile for every programmer to read Design Patterns at least once, if only to learn the shared vocabulary of common patterns. 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.
2. If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering-- it's a sign that your language is fundamentally broken.

 

Point no.1 stressed "before", which i fully agree. However, to be able to come out with something "truly simpler" is itself a tough job.

Point no.2 made sense too...the key word here is "frequent"

I agree with statement no 1. It does add complexity to the overall solution. However graceful software designs will always come at a price=> complexity. My approach is that i will always look at the requirements and analyze accordingly. If the requirements is simple and can be done quickly, why make use of design patterns then? However if requirements is complex and extensibility is an important aspect of the solutions, then design patterns are appropriate to use.

For statement no 2, I think it makes sense. Using design patterns is supposed to make future coding easier to do. If it is going to be more difficult in the future, why bother using it in the first place? However I have reservation in design patterns making future scalability more difficult. It must be due to wrong pick of patterns or "use design patterns just for the sake of using it"

Gotta remember what my main driving point was, and still is, 

icelava:

Design patterns in my understanding is about finding the simplest, most elegant way to tackle a problem. By establishing a common volcabulary and understanding of its concept, development teams can deal with them quickly and move on to handling more business/domain-oriented problems. In my experience, the lack of design pattern use resulted in monolithic, inextensible, brittle, defective implementations that is complicated and unwieldy. Both to the user and developer. I do not know how many times I saw parts of a system and went, "ouch, if so-and-so pattern was implemented here, how much simpler it would have been!"

hendry:

But for simple solutions, is it really appropriate to use design patterns?

For sure, use the simplest solution to the problem. No arguments there. My point is, what most people come up with in the end is anything but simple, when a design pattern could have been so much more effective.

Take for example, imagine a UI with a main window featuring multiple tabs. The main window has two modes of display - side info panel expanded, and collapsed. When the side panel is collapsed, there is more horizontal space for the controls so they need to be lengthened. Wouldn't it be nice to implement an Observer so that each tab is simply listening for an event from the main window on panel bar expansion/collaspe, and do whatever they need to resize the controls (I suggested anchoring for the matter)? Nope. My colleagues implemented a convoluted web for function calls from main window to tabs, and from tabs to tabs and back to main window, each then reading XML files for exact sizes for each controls. It took probably 30secs to a minute for the resizing to happen.

My angle - use the fastest straight-on approach. Do not try to feed yourself a banana by wrapping your arm around your head.