Vexations

Sometimes you just can t do the right thing. Or, more accurately, other considerations make doing the right thing very hard. However diligent an object thinker you become, you will encounter situations that tax your skills. The most commonly encountered examples: the necessity of object applications using relational databases for persistence and object-human communications via graphical user interfaces.

The Impedance Mismatch Problem

Traditional computer thinking treats data as passive and helpless, manipulated and moved by active procedures. Procedures, being a bit unruly, have been known to abuse data, to make it something it shouldn t be. Procedures also tend to be egocentric and think that all data, its definitions and its values, are properly determined by the procedure currently using that data. The result is data that is inconsistent in definition, inconsistent in value, inaccessible because some other procedure has possession, or needlessly duplicated .

The solution to these problems was to create a single repository for all data ”the database ”and create one master procedure ”the database management system, or DBMS ”to manage the data and protect it from abuse by unruly application functions. Database philosophy is almost totally inconsistent with the philosophy behind object thinking.

Databases violate the axiom that everything is an object. They violate the principle that no object can do things to another object. Databases celebrate centralized control. And relational databases, especially , are totally enamored of the idea that everything can be formalized . It s not surprising, therefore, to find that objects and databases are frequently in conflict with each other.

Some examples of the kinds of problems encountered when mixing objects and relational databases are as follows . (Extended relational and object databases have been modified and extended in their capability to ameliorate most of the problems noted.)

Objects are not defined based on their attributes, but entities and the tables that they inhabit in a database are defined in precisely that manner. Objects can store, in a variable, objects whose primary purpose is to provide a calculation or a service rather than to embody a piece of data. The rules that you follow to make something persistable vary radically between the object world and the database world.
Objects have variables that can contain arbitrarily complex objects, including collections and multivalued constructs. Databases can store only a defined, and limited, set of primitive types. For an object to be stored in a database, it must be disassembled and translated, making both storage and retrieval complicated and error-prone processes. Several companies have made significant amounts of money providing special-purpose object-relational mapping software that solves this disassembly-and-translation problem.
If a running application uses objects that persist in a database, there is no assurance that an object s value in the application is consistent with its value in the database. Other applications might be updating the database, and there is no way for the database to notify the object that its persistent value has changed through intervention by another program. (Extended relational databases now have the ability to notify objects of this kind of event.)
Databases do not preserve the encapsulation of an object. While an object is persistent (in the database), all of its contents, the objects stored in the object s variables and in some cases even the object s methods , are available for direct access by any other program using that database. This leads to all kinds of potential coupling between objects (based on program-specific contexts), which interferes with (destroys) the modularization arising from good object design in the first place.

In an ideal object world, there would be no need for databases. Every object would have its own URL. ^[1] Persistent storage devices would offer nothing more than space and a path extension for the object s URL so that it could be located when necessary. The object would serialize itself (marshal itself into a bit stream) and de-serialize itself in order to reside on the storage medium. ^[2] The object would also register its location with a white pages object so others could find it when necessary. (The white pages would function much as the domain name servers employed to match text and numeric URLs for the Web ”that is, they would be hierarchical and replicated for efficiency of access.)

Why Databases?

Persistence is not the only reason for using a database. Databases also offer computational advantages for certain application needs. For example, they provide functions for efficiently and quickly tabulating and computing across large collections of instances (tuples, or rows, in database vernacular). If I had a large collection of customer objects (a few million, say) and wanted to know which of them lived in a particular postal code, I would have to ask each object in turn where it lived and have it report to an output collection if it lived in the specified postal code. This would take a long time. If that same collection were stored as tuples in a relational database, a simple vector operation would extract the relevant objects in short order. On the other hand, storing a complex object ”say the bill of materials for a passenger jet, perhaps ”in a set of relations in a database and then asking that database to print a list of all components used to build that airplane would take a long time for the database but would be a relatively trivial operation for the object. In the main text of this section, concern is focused on persistence. But object thinking designers need to give attention to the functional advantages of databases as well as their persistence services.

Services that a database is supposed to provide to data ”access control and enforcement of integrity constraints, for instance ”would be assumed by each object. An object could queue messages or simply indicate a busy signal if it received multiple messages simultaneously . Each object could carry within itself its own set of rules (self-evaluating rule objects) that would ensure the integrity of its value and allow it to reject messages from sources that have not been given access authorization. (Think in terms of access tables maintained by most operating systems that allow some users access to files while denying it to others. The entries in such tables are merely transferred to the objects instead of being maintained in a central place.)

Until the object vision is realized in full, it will be necessary to compromise and accommodate and make use of existing database systems. Treating the database as a great big object ” employing the concept of putting an object wrapper around a nonobject thing ”is one way to effect that compromise.

A Problem with GUIs

As noted previously (sidebar, Chapter 8), the advent of graphical user interfaces promoted object thinking while simultaneously distorting what it meant to be an object. The primary problem was trying to design object applications from the interface in. The first step advocated by many object enthusiasts was to sketch or prototype the application interface and then figure out what kind of objects were needed behind the scene. This kind of thinking also reflects pre-GUI computer thinking, wherein it was common to design the (character-based) forms and reports before writing the application code that would use them for input and output.

Object thinking says that a view (sometimes called an interface) ^[3] ”graphical or otherwise ”is a means for an object to communicate with another object and nothing more. The need for a view arises when an object needs to present itself in a non-native form to some other object (usually a human being) or application (for example, an XML view for data objects being shared across platforms).

Discovery of the need and the parameters that must be satisfied by a view is manifest in the scenarios in which the object participates. Whenever an object is asked to display itself, it must use a view ”a representation ”appropriate for the sender of that display message. If, for example, an object is trying to instantiate itself (get a value for itself), it must present a view of itself as an implicit request to a human being (or other service-providing object) for a value. If we are building a GUI that will serve as an intermediary between a software object and a human object, we will use glyphs for display purposes and widgets for interaction purposes.

But which glyphs and widgets need to be included in the GUI? Only those necessary to complete the scenario or scenarios ^[4] of immediate interest as the application runs. This perspective is counterintuitive for most developers because it suggests that a GUI be defined from the application out.

As an example, consider a brewery. Off to one side are vats filled with beer. At the other side are trucks waiting to take cases of brew to avid customers. In between is a complex production line consisting of bottle washers , filler stations , capping machines, and package assemblers. Above it all is a control station that monitors the brewery and notifies human managers of status and problems. Traditional developers are likely to begin their analysis and design of a brewery management system from the point of view of the control panel. This is analogous to designing from the interface in.

Object thinking would suggest, instead, that you consider which object is the prime customer of the brewery and all its myriad machines. On whose behalf does the complex maze of equipment exist? The correct business answer is, of course, The customer. But an answer more reflective of object thinking is, The beer. All scenarios are written from the perspective of the beer, trying to get itself into a bottle, with a cap, placed in a package, and resident in a truck. The control panel is a passive observer ^[5] of the state of the brewery. If the beer encounters a problem at some point, it s the responsibility of the beer to request intervention of the human operators by sending a message to the control panel (or machine-specific control panels) requesting an intervention service.

This perspective will simplify GUI design and, more important, eliminate the host of manager and controller objects that seem to inevitably arise when designing from the control panel s (GUI s) perspective.

Other vexations for object thinkers include programming language implementations that do not allow direct expression of object concepts or that impose safety and control structures that are antithetical to object thinking. Operating systems and hardware also present situations forcing compromise of object principles in order to get anything done. Dealing with these vexations in the most efficacious manner possible requires application of object philosophy, metaphor, and principles.

Dealing with negativity is no way to end a book on object thinking, so we will redirect our attention to some issues that extend the ideas presented in earlier chapters.

^[1] URL ”Uniform Resource Locator ”is a technical term for the address of resources on the Web. I am using it more colloquially, still meaning a unique address with the implication that such an address would be as simple as a URL and be independent of physical implementation (i.e., not rely on platform-specific offsets and extents).

^[2] The object-relational mapping software mentioned in this section provides a kind of marshalling where the serialization results in SQL or proprietary data manipulation statements rather than a bit stream suitable for writing to magnetic media.

^[3] The term interface is used, unfortunately , in more than one way. It refers to the object-specific message protocol plus event notification information as recorded on sides 5 and 6 of an object cube. It also means the form assumed by an object in order to present itself to a human user or another application object. We are using the second sense of the word in this section.

^[4] In most applications, several objects will be simultaneously presenting themselves to or requesting interaction with the human user. The totality of the GUI will therefore be composed of multiple object views. This was noted in the discussion of the MVC architecture in Chapter 9.

^[5] In an experimental microbrewery, the panel (in conjunction with the brewmeister) might be more than a passive observer. It might also be a source of instruction to the beer to modify its behavior. It is still not a controller ”merely another interested player that provides services to the beer in its effort to be the best brew it can be.