|
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.
Solution
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
|
