I'm noticing that, more and more lately, people are throwing out inheritance, as is demonstrated by this StackOverflow thread.
I'm still trying to concede my opinion on this. If the proponents of this attitude did not have "use delegation" up their sleeves I would say they are all either nuts or completely clueless about how good OOP can be written.
I think inheritance is a fabulous thing and in well-designed systems is even more important than interfaces, particularly in fundamental, framework scenarios like visual/UI controls, ORM, I/O base classes, and the like. It's also great for application design--three different account types, for example, each with a different subset of behavior but all sharing a lot of commonalities (all being accounts).
I imagine, however, that most of these folks have experienced the real world in team environments wherein bad OOP implementations of inheritence have resulted in unmaintainable code. In such cases, I can certainly see how interfaces, as a compromise, forces team members to stick to the testable specs rather than futz with the legacy. I most definitely cannot fathom how such environments are productive; reimplementing interface behavior everywhere just sounds atrociously bogged down, nothing gets done in such environments.
Delegation as an alternative to inheritance, however, makes sense in the area of code reuse. Compositing behavior services and providers in a composite class that implements multiple interfaces and hands off the implementations of those interfaces' members to the composite members is a great way to reuse code, should inheritence be avoided. A sealed composite delegation class does not, however, support is-a relationships, only behaves-like-a relationships via interfaces. Using interfaces alone, we again go back to procedural code and lose the great benefits of OOP and replace it with OBP (objects-based programming), a la COM. VB6 supported polymorphism as such, and its value stopped there. I have hardly used VB6 since C#, the true OOP language, became available to me as a Microsoft tools user.
Actually, a good persuasive article lies over here http://weblog.raganwald.com/2008/04/is-strictly-equivalent-to.html in favor of composition / decorator patterns. It's so persuasive, actually, that I personally think the C# 4.0 team should consider making composition / decorator pattern as easy to implement as inheritance.