Reflection Docs: Extends and Implements Behavior in Depth
Since the concept of a Class is fairly abstract, the ComponentClass implementation can represent both components and interfaces. That being the case, it's important to understand the ComponentClass behavioral differences when dealing with both constructs.
Extending / Subclassing
Subclassing, a.k.a. extending is a perfect place to start this conversation. In the cases of ColdFusion components, a CFC can extend another - making it a subclass of a parent class (right in line with one of the core OO mantras - inheritance). ColdFusion CFC's can extend one and only one other CFC. The Class API provides a couple of useful methods that provide meaningful information about CFC's that exhibit such behavior; isSubClass() and getSuperClass() - both are self-explainatory. Invoking the getSuperClass() method on a Class instance who's representative CFC does not extend another will return an undefined value - or null, otherwise it will return another instance of Class that represents the current classes superclass.
More than one Super Class?
If you did your homework, you'll notice another similar looking method exposed on the Class interface; getSuperClasses(). As its name implies, you would expect this method to return more than one Class instance - right? This is where component and interface behavior diverge - for good reason. ColdFusion interfaces can extend any number of other interfaces. Again, because Class can represent both components and interfaces, the API must account for this inheritance behavior. So yes, you can expect to get an array of Class instances (as in zero or more) when you invoke the getSuperClasses() method on a Class instance that represents an interface - but of course, only if that interface extends other interfaces. Invoking getSuperClass() on a Class instance that represents an interface will always return null. The getType() method makes this much less of a guessing game as it will return either "component" or "interface" depending upon the type of it's representative component.
Implementing
Components can implement one or more interfaces, which is why both the isImplementing() and getInterfaces() methods exist within the Class API as well. If the representative component implements one or more interfaces, you can return an array of Class instances representing each interface by invoking the getInterfaces() method. isImplemeting() will return true or false depending upon whether or not the CFC implements any interfaces at all.
Class Hierarchy
Class hierarchy is an array comprised of any and all super classes of the current Class instance. For instances of Class that represent a component, class hierarchy is linear, meaning the current Class can have one and only one super class, that super class can have one and only one super class of it's own and so on. That being the case, the getHierarchy() method will simply return an array of Class instances represeting the hierarchical structure of that class - with the most immediate ancestor in the first position of the array. This is not the case with Class instances that represent interfaces. As we discussed in the previous paragraph, an interface can have more than one super class because it can extend more than one other interface - interfaces exhibit multiple inheritance behaviors. Needless to say, interface hierarchies are non-linear and can branch N times whenever a super class extends more than other interface. This is why a call to getHierarchy() on a Class that represents an interface will return an array of structures. Each array element will contain a structure that represents a hierarchical ancestor (extended interface) of the current Class. Each structure contains two keys to encapsulate that information; "class", which contains a reference to the actual Class instance of that ancestor, and "hierarchy", which will contain another array of structures representing that elements hierarchical structure.