Many students of the art hold out more hope for object-oriented
programming than for any of the other technical fads of the day.
I am among them.
Mark Sherman of Dartmouth notes that we must be careful to distin-
guish two separate ideas that go under that name: abstract data types
and hierarchical types, also called classes.
The concept of the abstract data type is that an object's type should
be defined by a name, a set of proper values, and a set of proper
operations, rather than its storage structure, which should be hidden.
Examples are Ada packages (with private types) or Modula's modules.
Hierarchical types, such as Simula-67's classes, allow the definition
of general interfaces that can be further refined by providing
subordinate types.
The two concepts are orthogonal — there may be hierarchies without
hiding and hiding without hierarchies.
Both concepts represent real advances in the art of building software.
Each removes one more accidental difficulty from the process, allowing
the designer to express the essence of his design without having to
express large amounts of syntactic material that add no new
information content.
For both abstract types and hierarchical types, the result is to
remove a higher-order sort of accidental difficulty and allow a
higher-order expression of design.
Nevertheless, such advances can do no more than to remove all the
accidental difficulties from the expression of the design.
The complexity of the design itself is essential; and such attacks
make no change whatever in that.
An order-of-magnitude gain can be made by object-oriented programming
only if the unnecessary underbrush of type specification remaining
today in our programming language is itself responsible for nine-
tenths of the work involved in designing a program product.
Object-oriented programming.
Many students of the art hold out more hope for object-oriented programming than for any of the other technical fads of the day.
I am among them.
Mark Sherman of Dartmouth notes that we must be careful to distin- guish two separate ideas that go under that name: abstract data types and hierarchical types, also called classes.
The concept of the abstract data type is that an object's type should be defined by a name, a set of proper values, and a set of proper operations, rather than its storage structure, which should be hidden.
Examples are Ada packages (with private types) or Modula's modules.
Hierarchical types, such as Simula-67's classes, allow the definition of general interfaces that can be further refined by providing subordinate types.
The two concepts are orthogonal — there may be hierarchies without hiding and hiding without hierarchies.
Both concepts represent real advances in the art of building software.
Each removes one more accidental difficulty from the process, allowing the designer to express the essence of his design without having to express large amounts of syntactic material that add no new information content.
For both abstract types and hierarchical types, the result is to remove a higher-order sort of accidental difficulty and allow a higher-order expression of design.
Nevertheless, such advances can do no more than to remove all the accidental difficulties from the expression of the design.
The complexity of the design itself is essential; and such attacks make no change whatever in that.
An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary underbrush of type specification remaining today in our programming language is itself responsible for nine- tenths of the work involved in designing a program product.
I doubt it.