| I don't have a problem with design patterns as a concept. But you need to recognize them for what they are--folk wisdom. Some of it is useful, much of it isn't. If there is no theory we have to fall back to empirical analysis, and unfortunately our industry hasn't done much of that. The only thing we have to go on is the general "consensus" of the industry, which is cyclical, transient and mostly fashion. Some of the industry folk wisdom if beneficial and withstands the test of time. Most of us agree that encapsulation is nice. However, we don't agree on what form that encapsulation should take. OO programmers argue that state should hidden away inside objects, functional programmers believe that state should be explicit and we should always try for pure functions and immutable data when possible. There's very little objective data to support either side (except that functional programming languages tend to have more formal underpinnings). Mostly it falls back to personal preference, which programmer sages you trust, and what the current industry fashion is. Our industry reinvents the wheel time and again because we are slaves to the cyclical nature of the industry fashion. Relational Algebra/calculus has been formalized for decades, yet people who don't understand relational theory cried out for something "simpler" and thus NoSQL was born. Fast forward 5 years and you'll find many of the people championing NoSQL had to reinvent most of the tough problems that CS had solved decades ago. Again, there is nothing inherently wrong with craft and folk wisdom--just like there's nothing wrong with learning salary negotiation, but they don't belong in an academic CS environment. These things are best taught in an internship/apprenticeship after you've learned the underlying theory. |