There are several issues that exist around Object Subclassing in CybOX:
Excessive sub-classing. Objects such as the Windows Driver are three levels deep in their respective class hierarchy, which means that changes to any of their parents cascade to their "leaf" Objects. Accordingly, this makes maintenance and versioning difficult, as it means that the version of any "leaf" Objects needs to be updated in conjunction with their parents. Accordingly, if one considers the future potential for CybOX to incorporate additional types of system-specific Objects (e.g., Android, iOS), etc., this could lead to even more complicated and deep Object hierarchies.
Inconsistent class-based design. Currently, CybOX is inconsistent with the way it uses sub-classing in its Objects. For instance, there are cases (such as with the Windows Thread Object) where a parent Object should be defined (i.e., a Thread Object) to serve as the base class and yet is not. Conversely, there are cases where a parent Object is defined only to serve as a base class and is unlikely to be ever used by itself, such as with the GUI Object.
Restrictive classing. The nature of sub-classing means that when creating content, an Object is either an instance of one class or another - it cannot be both. For instance, one cannot define an instance of an Archive File with Windows-specific properties, since these Objects do not inherit from each other.
Accordingly, it may make sense to deprecate Object subclassing in favor of an extension-based approach.
There are several issues that exist around Object Subclassing in CybOX:
Accordingly, it may make sense to deprecate Object subclassing in favor of an extension-based approach.