Object Relationship Notation


		A Journey of Zope Exploration

Object Relationship Notation
Fri, Nov 26, 1999; by Jeff Shelton.

Almost everything in an object-oriented language such as Java or Python is itself an object. Variables are objects. Files are objects. Methods are objects. If all these objects are to work together, it is necessary that specific relationships exist between objects. For documentation purposes, we have adopted certain notations to represent those relationships.

Inheritance Notation

One of the most common relationships between objects is that of inheritance. By keeping track of what class a given instance belongs to, we can traverse back up through the subclasses to find the attribute that we are seeking. When we notate a inheritence path, we are led from broad characteristics to specific characteristics as we read from left to right. So if we wanted to show the inheritence path traveled in getting to an instance method of my_chevy_cavalier.start(), we could write

vehicle.car.passenger_car.my_chevy_cavalier.start()

This notation is common to most object-oriented languages. A period is used to separate objects in the order they are traversed in getting from the most general object to the particular method of the particular instance of the particular class that we wish to execute. One of the important things to note about this convention is that there is only one way to get to a particular instance. If you start out an inheritance path with vehicle.motorcycle, it doesn't matter what follows -- you will never get to "my_chevy_cavalier", because you didn't start with vehicle.car.

An inheritance relationship also means that a specific path will be traversed when an attribute is needed. The program will start with the particular instance that has been called. If the desired attribute is not found in the instance, then the search is moved upward to the lowest subclass from which the instance was derived. If the attribute is still not found, then each parent class will be examined, in order, for the attribute that is needed. For the most part, this inheritance path is always followed in sequence (although each OOP language has its own idiosyncrasies). You don't jump from my_chevy_cavalier to vehicle without first passing through passenger_car and car on the way up the inheritance path.

File System Notation

Software files get stored all over the hard disk inside your computer. In fact, individual files often get split up into many pieces all over your hard drive. If all your files were listed in a single listing by the date created, you would spend a great deal of time trying to find any given file. So to make file identification easier, early computer operating systems came up with the concept of folders. Just as we store papers related to a common subject in a folder hanging in a file cabinet, we store software documents related to a common subject inside a folder on our hard drive.

To find any given document, we must start with the top level folder (also known as the "root" folder) and work our way down to the file for which we are looking. So to find a document called "Spam" inside a folder called "Quasi-Meats" inside a folder called "Foods," we would notate our search path as:

/Foods/Quasi-Meats/Spam

As with an inheritance path, (ignoring tricks like shortcuts and aliases) there is only one file system path that references a particular document. Unlike an inheritance path, however, no mechanism exists for searching upward through higher level folders if a particular document is not found at the specified location.

Let's stop for a second to review. Using our limited sample of two notations, it would seem that either period or slash notation indicates moving down a tree structure to check for the presence of an object. Period notation also implies that an upward search for attributes will also take place.

Object Database Notation

Just as for inherited objects and file systems, object databases (such as the one used by Zope) are tree structures. Therefore, there is only one path by which an object can be accessed. Typical notation for accessing an object "Apple" inside a folder "Fruits" that resides inside another folder "Non-Meats" would be:

/Non-Meats/Fruits/Apple

Non-Meats.Fruits.Apple

In object databases that (unlike Zope) do not support acquisition, there is no inheritance of attributes from parent objects, which are also called container objects. The folder instance Fruits is probably descended from a class FolderClass, while the fruit instance Apple is likely descended from a class FruitClass. There is no relationship in the attributes or purpose of these two objects. The only existing relationship is that one serves to hold (or "contain") the other. So using period notation is not entirely consistent in this instance, since many object databases do not conduct an upward search for requested attributes. Nonetheless, the period notation is widely accepted for expressing object database paths. The slash notation, of course, is quite consistent with its previous uses, as it only implies a container-type relationship -- just as was found with the file system paths.

Universal Resource Locator (URL) Notation

When the Internet was first being developed, URL notation was used exclusively for fetching documents out of the file system of other computers. So if you wanted a document named "Fido" from a folder named "Dogs" from a computer at Purdue University, you would issue a request on your browser that looked like

http://www.purdue.edu/Dogs/Fido

Since you were accessing a file out of a computer file system (usually Unix), it made sense to use the same slash notation for the URL that was used by the file system. Over time, HTTP servers (like Apache) allowed web hosts to redirect URL requests. So if you asked for the "Fido" file using the URL shown above, you might get back

http://www.purdue.edu/veterinary/domestic/dogs/Fido

And what do you care? If you got the information you wanted, it's not a problem that the HTTP server redirected your request. But more importantly for the purpose of our discussion, no matter how you arrived at the document "Fido," it always returned the same information. In other words, its data was static, rather than dynamic.

Common Gateway Interface (CGI) Notation

After the Internet began to gain some momentum, some enterprising programmers decided that dynamic content would be a good thing for the web. And so that all sites could use a common notation for requesting dynamic content, CGI notation was developed.

This notation built on top of the URL notation, using keywords and a question mark to identify the action that should take place. So if I go to Yahoo and search for "Fido", the notation is:

http://search.yahoo.com/bin/search?p=fido

By changing the word "fido" with some other word that we want to use for our search, we will get back different information. However, the change in information results from a change in the query string (the bit after the question mark), not changes in the base URL. So although we can change our query, we have to follow a single URL path to get to the dynamic content we desire.

So it would appear that object relationships are almost always based on a tree structure, where there is only one way to access a particular object. If you don't provide the correct path, you won't get the object you are looking for.

Acquisition, however, violates this notion of "one path, one object" by its very nature. So buckle up and prepare to learn about Acquisition Behavior.

Prev | Next | Transition to Acquisition

Search zopeNewbies:

Search zopeNewbies 2:

Last update: Friday, November 26, 1999 at 9:21:21 AM Pacific.