The Good, the Bad, and the OO

Old and New OO
Object-Oriented development approaches, whether with specialized OO programming environments (e.g. Java, C#, SmallTalk), or with more general development tools like XSD/XML, offer both Good and Bad features.

Divide and Conquer
Starting with the good ones, the best has to be the problem analysis and decomposition approach, which is really what used to be called the "divide and conquer" approach, which is at the heart of OO, and which remains valid today.

Programmer Support
The other good thing, is that in relatively unchanging contexts, it can provide a relatively secure framework (e.g. cast), helping possibly experience-lacking programmers to still contribute to working applications. To achieve this, the designers of OO chose to support a simplified view of reality.

Static Typing and Classification
Then we reach the Bad or not so good, as OO is based on types or classes that need to be designed and defined before starting to operate the applications. Typically referred to as compile or schema design time classes/types, they are prevented from evolving during application operation. In other words, if a type needs to evolve, the application as to be taken off-line, modified, tested, and deployed again, after all levels of approval, of course, since even small changes to the classes/types can deeply affect the applications, typically multiplying the resulting application silos. There is nothing agile about this process.

Physical Hierarchies
More so, OO classes/types are built in typically complex hierarchies through inheritance or extension principles. These hierarchies are monolithic structures that impose monolithic silo processes adapted to the class/type structures and hierarchies. See also: Why Separate Physical and Logical Models?

Multi-Faceted Reality
Unfortunately for OO, reality is multi-faceted and ever changing. More so, all things have multiple classes/types. In fact classification is a viewpoint relative process. And viewpoints change constantly as they have to adapt to priorities, that also constantly evolve. Let's just consider an apparently simple example, a car. Some OO frameworks like NIEM, for example, define a car as a vehicle extension, a vehicle as a conveyor extension, a conveyor as a container extension, and a container as an object extension, which all seems logical in specific contexts, as through a general transportation viewpoint. OTOH, in an ecological context, a car could be scrap, a polluter, an urban disaster, or a killing or suicide machine. In a marketing context, it may be a dream, a sign of freedom or power, a life style, a design, a model, and many other things that have relatively little to do with conveyors, and where the serial number, for example, is meaningless. In a post trauma syndrome context, a car could be a nightmare, a torture device, etc.

Multiple Inheritance and Substitution Groups
To try to better deal with multiple types/classes, OO has a troublesome kludge called multiple inheritance or substitution groups. This complex, limited, ill-defined and managed, and still inflexible and static kludge, is designed to patch around OO's fixed types/classes. But here still, all possible concurrent or successive types/classes, and their respective hierarchies, have to be known, determined, and fully defined, at compile/schema design time, long before applications are put into operation. Otherwise, applications have to be retired, migrated, and redeployed, typically now incompatible with previous versions. More so, as the number of supported classes/types increases, application and maintenance complexity start growing exponentially. Even more so, every application release defines new, ever more complex, yet still limited, silos.

The issue is fundamentally simple, although useful for initial snapshot problem decomposition, OO is not designed for managing reality, or knowledge rather, as that is what we know about reality. Hence, the solution is simple also, at least in principle: use an approach based on knowledge's natural architecture, rather than an arbitrary and over-simplistic approach, as OO.

Continue to