Sunday, November 10, 2002

I want to step away from coding, talking about .NET altogether, and talk about abstraction, domain engineering, generic programming, and design paradigms for a bit. In 1999, I read a book by Jim Coplien, “Multi-Paradigm Design for C++”, which forever changed the way I looked at design paradigms. Lately, while reading Andrei Alexandrescu’s “Modern C++ Design: Generic Programming and Design Patterns Applied”, combined with doing a lot of “Modern C++”, I had several awakenings those shook up things for me even more.             For years now, it seems to me, we have had many design “gurus” repeating a mantra “Object Oriented Design good, all other techniques  bad”, to the extent that for many developers and designers, that is the only paradigm that they use and even know. Abstraction is one of the key tools for managing the ever-increasing complexity of modern software. As Coplien says, “The common answer to what is abstraction usually has something to do with objects, thereby reflecting the large body of literature and tools that have emerged over the past decade to support object-oriented techniques.” Even more so, frameworks, languages and abstractions like .NET’s BCL and most of Java is only OO based (yes, I had been thinking about this for 2 weeks now, before Microsoft’s vapor announcement of future generic programming features in .NET). Java is touted, rightly or wrongly, as completely OO such that everything must be in a class. NET’s BCL is mostly only OO. Both of these, for the most part, wrap your abstraction and your way of thinking in object-oriented ways. Yes, there are exceptions (no pun intended!), but for the most part, most of the world thinks in objects. Well, that’s goodness, right? After all, it models the real world and builds abstractions much better, right? Well, yes and no. There’s no denying the vast benefits of OO but the key message in these books, and particularly Coplien’s book, is that Object Oriented Design is just one subset of the solution domain and not always appropriate for the problem at hand.  {READ MORE...} 3:03:16 AM