Object Appearance

It would be difficult to talk about objects without talking about the graphical user interface (GUI). The Star project at Xerox PARC simultaneously advanced local area networking, GUI design, Smalltalk (object-oriented programming), and alternative input-output (I/O) modes (notably the mouse). Networks and I/O were sufficiently esoteric and close to hardware design that they went their separate ways, post-PARC. GUI design and objects, however, emerged so tightly coupled that it s often assumed that the primary (if not exclusive) use of object design and object programming is the construction of graphical interfaces.

Visual development environments (such as Microsoft Visual Basic) managed to convey the impression that objects were the same as the GUI widgets that appeared in the interface design toolbox. Once you had those widgets in place on your form object, you did real programming ”sans objects. (Yes, it s true that the objects are still there, but they are not emphasized or enforced, with the net effect that most Visual Basic programs tend to be event-driven procedural in nature and not OO.) Even Smalltalk IDE tools such as Parts (an extension for Digitalk Smalltalk) and VisualAge (IBM) emphasized the utility of objects for GUI building with far less emphasis on the objects behind the  interface.

A worse error was propagated when many of the early tutorials on object programming introduced a misconception by suggesting a method colloquially referred to as cocktail napkin design. It was suggested that the correct way to design an application was from the interface in; that is, sketch your interface on a cocktail napkin and then find the objects necessary to implement that interface. The GUI became a straitjacket to which objects had to conform. This, in effect, meant that object design and implementation were little more than the hard-coded reflection of the specific and idiosyncratic design of a set of visual interfaces. Change the visual interface, and you had to change the object. Not only did this make for a lot more work, it meant that objects were not reusable in different contexts if those contexts defined visual interfaces in an alternative fashion.

Note  

You can t emphasize this point enough, suggests Ken Auer, speaking about the danger of GUI-in design. In my early days of OO, if you talked to someone who had been using Smalltalk for 1 to 3 years, you could almost rely on the fact that they ˜got it. After the advent of Parts, VisualAge, and (to a slightly lesser extent) VisualWorks, I had many interviews with programmers who had been ˜programming with Smalltalk for 2 or more years and didn t realize there were supposed to be some objects other than the GUI and the database. Even the ones that recognized this tended to have a poor handle on how central the domain objects should be because they probably spent a good two- thirds or more of their time dealing with GUI and/or DB issues. Ken s comments support a basic premise of this book: object thinking is most easily corrupted by reverting to old, familiar forms of thought. Laying out widgets on a form and objects as data entities are but two examples.

Object thinking acknowledges the special relationship between an object, X , and some group of other objects whose role is to represent, visually or otherwise , object X . At the same time, it suggests some important differences in the way that relationship is discovered and implemented.

Occasions Requiring an Appearance

While engaged in the task of discovering objects and responsibilities, we told stories about object interactions. Among the interactions in those scenarios were instances of an object displaying itself to a client. An example might be a character displaying itself on some medium for the benefit of an observing human being. What actually appears on the medium is not the character object; it is a representation of some aspect of that object (its visual appearance but not its behavior, or dynamics, or soul ), just as your photograph is not you but a representation of some part (the surface part) of you.

The converse of displaying oneself to a client is to display the void at the core of your essence when you have yet to be instantiated . This time you display the void as a kind of request for service, asking a human user to please provide substance (a value) that will make you a fully instantiated object. An entryField widget consisting of a simple white rectangle and perhaps a blinking cursor within the bounds of that rectangle is an example of an object displaying its void and requesting the human user to fill that void with a value. A hybrid of both display and request is a display of your current value with the implicit request to change that value if appropriate.

Even the simplest object might have multiple representations of itself, just as you probably have more than one photograph of yourself. A character, for example, might have a boldfaced appearance and an italicized appearance. In cases in which an object has multiple appearances and can be asked to switch from one to the other, it s necessary to add messages to the protocol that make this ability evident. For example, a date object might have two messages in its protocol ” displayUS and displayEurope ” the difference between the resulting display being a transposition of the day and month values.

Most objects are compositions of simpler objects. Remember that every instance variable an object might have contains another object. If an object with instance variables has a gestalt (view of the whole) appearance, that gestalt is necessarily a composite of the appearances of itself and all of its contained objects.

It s easier to illustrate ideas about an object having multiple appearances by using visual metaphors. But visual representations are not the only appearances an object might have. Imagine an object that needs to store itself in a relational database. The relational database management system (RDBMS) cannot accept the object in its natural glory , so the object must marshal ^[1] itself into a stream of bits that can be accepted and held by the RDBMS. The resultant stream of bits constitutes an appearance of the object but is not the object itself, any more than a visual representation is.

Glyphs

The application of object thinking to the issue of text characters , numbers , and graphical symbols should lead to the recognition that all of these are really just instances of a single kind of thing: a glyph. A glyph object would have one major responsibility: to display itself. To fulfill that responsibility, it would need to know

• Its origin, a point used in the definition of its extent and in placement of its value on a medium.

• Its extent, an area (not necessarily a regular area, but likely some sort of polygon).

• Its scaling factor, an analog of point size , some constant that would allow it to occupy greater or lesser extent.

• Its orientation, a radian (used if the glyph is to be laid out other than horizontally).

• Its value, something as primitive as a bitmap or, more likely, an algorithm (vector) that results in the generation of colored pixels on a medium that is the actual appearance of the glyph.

• Its ASCII value, a bit stream.

• Its EBCDIC value, a bit stream.

• Its Unicode value, a bit stream.

  The message protocol for a glyph would include the display message (the glyph would use values in all the appropriate variables to create the  bit stream sent to a printer or graphics card that actually generates the display) and getter and setter messages for each of the instance variables listed in the foregoing list.

  If glyphs existed in typical information system applications, it would not have been an issue when a certain rock star changed his name to a Celtic-Egyptian symbol.

 

The separation of objects and views or appearances of objects is essential. This separation of objects and views has also been addressed ”but incompletely ”in a number of different ways in programming languages and architectural patterns (for example, model-view-controller).

Object thinking would suggest that every object will have a collection of appearances, will advertise (as a responsibility/service/message) its ability to appear in different guises as well as variations (point size, for instance) of a single guise. Each object will transfer to its appearance object (for example, a glyph, as described in the sidebar Glyphs ) responsibility for acquiring and maintaining the information required to effect each appearance.

An elementary object, such as a character, might have a small set of appearances each of which is a simple glyph. The appearance of a more complicated object, such as a string, a date, or a number, would be a composite (an ordered set of appearances of each of its constituent parts): each character in a string, each number and symbol in a date, each integer and symbol in a number. A still more complicated object, such as a form, would be a composite of its own appearance (a boundary perhaps) plus the composites of each of the elements appearing on the form plus the composites and glyphs of each member of each element that appears on the form.

Keeping track of this apparent complexity is relatively straightforward: you simply apply the composite pattern. Composite is one of the 26 patterns in the first pattern book, Design Patterns . Applied to appearances, the composite pattern asserts that every appearance is made up of glyphs or appearances. A  glyph is defined as a leaf node in the hierarchy; an appearance is defined as an instance of appearance, which in turn is made up of appearances, glyphs, or a combination. To display an appearance, you use recursion to traverse the hierarchy, displaying all glyphs and decomposing all appearances into glyphs and appearances until you reach a level containing nothing but glyphs.

Widgets, Forms, Reports

Visual programming languages typically provide a number of different widget types to be used in collecting and displaying bits of information. A character widget, a number widget, a date widget, and a currency widget are examples. Object thinking suggests that there is a need for only one type (class) of data entry widget. A dataEntryWidget would have an appearance, the simplest form of which would be a simple rectangle or a bit of underlining. It would have behavior that would include signaling whenever it has been changed (a person entering a value in the box or on  the line). It would also possess a set of rule objects that it could use to validate its own contents. An example of a rule might be valueEntered is a date; if true, return True; else return False. Another example: valueEntered is between minValue and maxValue . Because the rules are objects and because each widget has a collection of rules that it can apply to itself ”a collection that can be modified at any time with add, delete, or replace messages ”creating any type of specialized widget is trivial. (See the discussion of self-evaluating rules in Chapter 10, Supplemental Ideas. )

A form, in light of object thinking, is nothing more than an ordered collection of elements. An element might be a string or a dataEntryWidget . A form would have responsibilities to display itself, collaborating with its elements; update itself (add and delete elements); effect different instances of itself (fill itself in, collaborating with its dataEntryWidget objects); and validate itself, working with its own collection of rule objects. Form validation rules exist for ensuring consistency among the values stored in dataEntryWidget objects (each of those widgets having already validated its contents according to its own set of rules). For example, a form validation rule would ensure that the value stored in the Zip Code widget is consistent with the value stored in the State widget.

A report is similar to a form in that each comprises a collection of elements. The form adds and deletes elements to become different instances of the form. The form displays itself by asking each element to instantiate itself (obtain a value for itself) and display itself. Each element has its own set of appearance rules, which it uses to display itself. An example of an appearance rule is My point size is 1.5 times the default point size for this report.

Both reports and forms make use of the glyph and composite patterns discussed earlier in this section.

 

^[1] Marshaling involves the object taking itself apart, asking each part to convert itself into bits, and then asking each part to line up in some kind of order. The process is analogous to a modem converting an analog signal to digital (and eventually back again).