>> Generally I try to use "real objects" instead of static methods where possible. IMO this allows for a cleaner structuring of code compared to static helper classes.

> Not always. In your case the client code becomes "harder". First create the instance and then the additional iterate/filter call. In this case I don't see why a class helps to structure better. Also you create an instance more each time you use it.

Personally I don't think that the client code is any "harder" (in particular if the class itself implements `Iterable`), but I guess that's a matter of taste. Regarding the object creation I agree, but I don't think that's really a problem, unless you create maybe millions of hierarchy objects.

>> Representing a type's hierarchy with a real object also allows for future improvements, e.g. the filter method could internally cache filtered hierarchies.

> Right, caching could come in handy, but as we know caching classes is a problem in itself. And having a static helper is not generally a stopper for caching.

Right, it isn't, but IMO it would be simpler in the context of a given object which represents the hierarchy itself.

> Why do you think the API is misleading? To me, class hierarchies are one concept of the "domain" we're dealing with, so representing them as an object seems very natural to me. 

I want a list of classes/interfaces, that's it. I can use the ReflectionHelper method w/o even looking at it, whereas the object approach I need to understand more.

You need to understand how to obtain a `ClassHierarchy` object and invoke one of its methods.  Personally I don't think that's more complicated than invoking a static helper method, in fact I think it's actually simpler since the class offers only those methods making sense to be invoked for a class hierarchy instead of a whole bunch of static methods on `ReflectionHelper`. But I guess we can agree to disagree on that :)

That said, I've created https://github.com/hibernate/hibernate-validator/pull/230 which makes it a static helper class again. I guess I can live with this as well, and if the the hierarchy class itself should not implement `Iterable` (which you seemed to dislike), then indeed the instance based approach seems less attractive to me.