| I found the presentation quite useful, and have a few thoughts on the points I found. First, my thoughts on Design Patterns as defined by the GoF. As recurring concepts which have been identified, named, and allow for higher-level discussion and solving of software architecture and design problems (I think this view of mine might be a bit short-sighted), they are great tools and vocabulary. However, they are known to reflect shortcomings, specially in object-oriented languages as opposed to functional ones (haven't read much about them, and I don't know much about functional programming and haven't yet read my copy of SICP, so I probably lack some fundamentals on the subject). I like the point about design patterns not being "patterny" enough, I think that was one point in the presentation. Although design patterns sure aren't too be taken simply as implementation recipes (is it too far a stretch if I think of them as a kind of "framework" or "frameworks"? Not sure about the inversion of control aspect, though) and there is no fixed Observer, or name-your-pattern implementation, it certainly would be more useful if they could be implemented only once instead of repeatedly for each new project. This is not "human", and that sounds fair enough to me. Some are actually reusable, such as certain library implementations or language constructs (I'm thinking of Java's foreach, I'm not familiar with Perl). I think that depends a lot on what constructs or building blocks the language provides. The first few pages of SICP make such a point about powerful languages. So it would be great if design patterns could be provided and reasoned upon as powerful language constructs (i.e. which are provided by the syntax). The higher level we can reason upon and solve problems, the better. So many things are patterns beyond the GoF ones. Paradigms, for one thing. Variables. The other point I found is about how Christopher Alexander wanted the clients of the building to reason upon architectural issues at various levels and how this also applies to software development. This could map either to the developers or to the end-users in my opinion (not to mention the hardware designers). Either way, I think this emphasizes the importance/need of higher-level constructs (such as the concept of information hiding applied to higher-level building blocks) than we usually reason upon when developing software. These were the useful points I could find. I'm afraid, though, that I don't have enough conceptual building blocks myself to reason further upon it. Finally, sorry about the lots of "reasoning upon". |