Thoughts on Philosophy-based Design

I read an article this morning offering an alternative way for object design it can be found here:

http://www.devx.com/dotnet/Article/47368/0/page/1

The following are my thoughts on it.



I think that you are right that philosophy can add a level of understanding as to why an object should work in the way that it does, or why it should be changed, but as a knee-jerk to what it would appear to do to how the code works or its effect on time-to-market... I'm not so sure.  Unless I've misunderstood (quite possible) the application of this design pattern makes all objects essentially generic relying on flags to define thier actions? Does this not mean that while the overall code base may be smaller, the memory footprint increases because a number of objects may have largely irrelevant properties?

While memory may be as cheap as the proverbial, it should not be used "just because it's there". 

I agree that the code base would be on the surface more manageable (possibly... with objects being so generic I think it would be easier to engineer a breaking change that effected more than it would in a more classical pattern), but manageable code should not trump performace or efficiency - as Software Developers the primary objective should be end-user usability. If that means we have to work a little harder at the code level, so be it.