Recently it came to my attention that hierarchical inheritance may be a relic of thinking of classes as "structs with functions" rather than a product contract-driven mentality.
Consider, as a simple specimen the implementation of "Unmodifiable Iterator" from Guava. http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/UnmodifiableIterator.html It's an iterator which throws an "UnsupportedOperationException" on invocation of remove().
Now, I'm sure most people would agree that implementing a contract and then having one of its methods always throw an exception is bad form -- when you implement a contract you're implicitly guaranteeing that all the methods would work. Yet, what are our options here? We could declare an interface which does not contain the remove method but that would render our return type incompatible with all methods which work on iterators. We could blame the Java API designers for forcing the remove() method to be a part of every iterator, rather than moving it to a higher level interface such as "RemovableIterator".
If they did that it would indeed avoid some problems but let's say we need an iterator which can also set values called "SettableIterator" (implements setValue(T) ) and also a resettable iterator. If we require a combination of these functionalities we are forced to declare an interface for every combination. RessetableSettableIterator, RessetableRemovableIterator, RemovableSettableIterator , etc. The combinations grow exponentially to the extra features we add to the interface.
What we are usually trying to express is something like 'this function requires a parameter which is Iterable, Settable and Ressetable' or 'this function returns a value which is Iterable and Resettable'. Yet languages like C#, Java and C++ do not allow us to do this without very awkward use of generics.
Are there recent methods that make this kind of design obsolete?