Benefits of Object-Oriented Approach
Object-oriented databases make the promise of
reduced maintenance, code reusability, real world modeling, and improved
reliability and flexibility. However, these are just promises and in the real
world some users find that the object-oriented benefits are not as compelling as
they originally believed. For example, what is code reusability? Some will
say that they can reuse much of the object-oriented code that is created for a
system, but many say there is no more code reusability in object-oriented
systems than in traditional systems. Code reusability is a subjective thing,
and depends heavily on how the system is defined. The object-oriented approach
does give the ability to reduce some of the major expenses associated with
systems, such as maintenance and development of programming code. Here are some
of the benefits of the object-oriented approach:
The primary goal of object-oriented
development is the assurance that the system will enjoy a longer life while
having far smaller maintenance costs. Because most of the processes within the
system are encapsulated, the behaviors may be reused and incorporated into new
Object-oriented system tend to model
the real world in a more complete fashion than do traditional methods. Objects
are organized into classes of objects, and objects are associated with
behaviors. The model is based on objects, rather than on data and processing.
Improved Reliability and Flexibility:
Object-oriented system promise to be far more reliable than traditional systems,
primarily because new behaviors can be "built" from existing objects. Because
objects can be dynamically called and accessed, new objects may be created at
any time. The new objects may inherit data attributes from one, or many other
objects. Behaviors may be inherited from super-classes, and novel behaviors may
be added without effecting existing systems functions.
High Code Reusability:
a new object is created, it will automatically inherit the data attributes and
characteristics of the class from which it was spawned. The new object will
also inherit the data and behaviors from all superclasses in which it
participates. When a user creates a new type of a widget, the new object
behaves "wigitty", while having new behaviors which are defined to the system.
The downside of the Object Technology
There are several major misconceptions which
must be addressed when considering the use of an object-oriented method:
Object-oriented Development is not a panacea
- Object-oriented Development is best
suited for dynamic, interactive environments, as evidenced by its widespread
acceptance in CAD/CAM and engineering design systems. Wide-scale
object-oriented corporate systems are still unproved, and many bread-and-butter
information systems applications (i.e. payroll, accounting), may not benefit
from the object-oriented approach.
Object-oriented Development is not a technology
- Although many advocates are religious in their fervor for object-oriented
systems, remember that all the "HOOPLA" is directed at the object-oriented
approach to problem solving, and not to any specific technology.
Object-oriented Development is not yet
completely accepted by major vendors
- Object-oriented Development has
gained some market respectability, and vendors have gone from catering to a
"lunatic fringe" to a respected market. Still, there are major reservations as
to whether Object-oriented development will become a major force, or fade into
history, as in the 1980's when Decision Support Systems made great promises,
only to fade into obscurity.
Cannot find qualified programmers and DBA’s
When one investigates the general acceptance of
object-oriented systems in the commercial marketplace, you generally find that
most managers would like to see an object technology approach, but they do not
have the time to train their staffs in object-oriented methods. Other will say
that the object-oriented method is only for graphical workstation systems, and
that there is no pressing need for object-oriented system within mainstream
Even though commercial object-oriented
programming languages have been on the market for several years, systems written
with object-oriented languages comprise less than 1% of systems today.
Once a major vendor begins conforming to a
standard, it can become impossible to retrofit their standard to conform to
another standard. When the American Standards Committee came out with a
standard character set for computers (ASCII), IBM disregarded the standard and
proceeded with their own character set, called the Extended Binary Character
Data Interchange Code (EBCDIC). Even thirty years later, there has still been
no resolution between ASCII and EBCDIC, and data transfers between ASCII and
EBCDIC machines continue to present problems. For example, the EBCDIC character
set has no characters for "[" and "]", and ASCII has no character for the "cent"
When one strips away all of the confusing
acronyms and jargon, the object technology approach is nothing more than a
method, an approach to systems design which can be implemented without any
changes to existing software technology.
Here is an actual example from the popular IDMS
MOVE 'JONES' to
ORDER-LOOP UNTIL END-OF-SET.
NEXT ORDER WITHIN CUSTOMER-ORDER.
ORDER-NBR TO OUT-REC.
The equivalent in SQL:
Customer_name = ‘JONES’
c.cust_nbr = o.cust_nbr
o.order_nbr = l.order.nbr
l.product_nbr = p.product_nbr