| Previous | Table of Contents | Next |
SGML is about more than storing, formatting, and printing documents. As new kinds of media and software tools become available every month, an organization whose data is stored in SGML has a distinct advantage over the competition if it wants to take advantage of these new publishing opportunities—that is, if it can develop the applications that use this SGML data quickly enough.
Object-oriented technology has made great contributions to software development in the last 15 years. Its philosophy of treating program components and data structures as objects that send messages to each other has resulted in faster development, easier debugging, and more robust programs.
An SGML document has much in common with an object-oriented system. In addition to some key vocabulary, there are many parallels between the analysis and design processes used to develop SGML and object-oriented applications. By exploiting these common points, you can minimize the work necessary to turn an SGML system into a useful object-oriented application, which can greatly speed the work of the SGML developer. In the future, you’ll see more and more SGML tools take advantage of this common ground and more object-oriented tools, such as object-oriented database managers, that offer immediate benefits to the SGML developer. A better understanding of this common ground makes it easier to fit these tools together into a complete system as they become available.
In this chapter, you learn:
You’re probably tired of hearing people define object-oriented systems as systems in which everything is treated as an object. What is a software object, and why are the many explanations so confusing?
An object is a data structure with defined attributes and capabilities. Just as a database designer might decide on a table called Employees with columns in that table for First Name, Last Name, Hire Date, Employee ID Number, and Salary, an object-oriented developer can design a class of objects called “employee” that have attributes of first name, last name, hire date, employee ID number, and salary. When the object-oriented program creates a new employee object for Joe Smith, it’s similar to the database designer’s program adding a new row to the employee table for Joe Smith, except you’re no longer thinking in terms of rows and columns; you’re thinking of an employee object named Joe Smith.
There’s another key difference between this object and a row or record from a database: along with the data attributes, such as first and last name, it also has behavior or capabilities specified for it—in other words, what those objects can do. These capabilities may be as simple as the ability to tell you its attribute values when asked, or they may be complex operations that control other objects through the invocation of programs.
At this point, most explanations of object-oriented systems start throwing around terms like “inheritance,” “polymorphism,” and “overloading.” These are not essential to understanding objects; object-oriented developers use them as convenience features to more easily create systems with many different classes of objects.
There are two other common sources of confusion in object-oriented technology. First, during a period somewhere after the reigning popularity of artificial intelligence as the Hot New Computer Technology That Would Change All of Our Lives and before the current similar popularity of the World Wide Web, object-oriented technology held this title for several years. Because of this trendiness, software industry marketing people misuse much of the key vocabulary of object-oriented technology to make their products seem up-to-date. This misuse confuses people trying to learn about object-oriented development.
Another source of confusion is the common assertion that, in object-oriented systems, data and code are stored together. They’re not stored together; they’re defined together. The code defining the capabilities of a given class’ objects is stored with the code that defines the structure of those objects, not with the object’s data. For example, the program that inserts new employees into the personnel system or prints out employee reports is not stored with the data “Joe Smith, 2/3/96, ID3543, $30,000”—it’s stored with the code that says “an employee object consists of a first name, last name, hire date, employee number, and salary.”
Why do you hear such great claims for object-oriented technology? How does it help software development, especially the development of applications that use SGML data? It’s easier to understand if you first review the four stages of software development. These stages apply to all software development, object-oriented or not:
All software development, whether object-oriented or not, starts off as a collection of objects in the developers’ heads. Even NASA programmers working in FORTRAN thirty years ago thought about booster rocket objects with an attribute of potential thrust, or of earth and moon objects with gravitational pull as attributes. All software ends up as a series of tiny and tinier voltages that are represented with ones and zeros, which aren’t very object-oriented.
Somewhere in these four steps, the application goes from an object-oriented representation to a non-object-oriented representation. In fact, it might even go back and forth between the two as it moves through these steps. The possibility of this back-and-forth transition adds a third reason for confusion about object-oriented technology: the possibility of hybrid development systems that are object-oriented for some steps, but not others.
| Previous | Table of Contents | Next |