An interesting weblog post that came across my screen this morning is Is it High Time to Get Rid of Classes?. Personally - I don't think it is. At least, not necessarily. But it is high time to go away from deep, wide, and messy class hierarchies into shallow ones, with much of the generally inherited behavior replaced by collaborating objects.
I've harped on this before, especially when comparing the ZWiki code bases from Zope 2 to Zope 3. That post compares the single-class-with-heavy-hierarchy design of ZWiki for Zope 2 (a design pattern that most of Zope 2 (at least older Zope 2 code) is also guilty of) with the collaborating object design of ZWiki for Zope 3 (the component model based Zope).
I've been applying such patterns to my Zope 2 projects, the most recent being an LDAP application. The results have been generally successful. I have an application that can be generally built out of descriptions. There's the describing of web form/validation policies, which builds a strong user interface for us without me having to deal with writing HTML forms myself. And there's describing how to map LDAP data into simple Python structures and then sending those back to LDAP so that the higher-up application components never have to think about generating an LDAP mod list.
In these situations, it's still a fair amount of work getting a lot of the core components written and working. But it's a design decision to allow new attributes to be addable later. This design allows adding new ones in by basically updating the description components. Unless there's any major new business logic involved with the new attributes, that's all that is needed. The User Interface gets rebuilt and the LDAP communication code becomes aware of a new attribute it needs to watch out for on an object class.
The application is not absent of an inheritance hierarchy, but inside of the application the hierarchy is fairly shallow, usually two deep (at the most). The common abstract base classes used inside the application plug themselves into the Zope 2 hierarchy while ensuring that their subclasses have to worry little about said hierarchy. As such, I'm getting a nice set of reusable patterns and my own little framework going here to help build new applications fairly rapidly with a lot of strengths that weren't there previously (ie - weak (unvalidated) forms, etc).