Extensions

One of the tenets of extreme programming involves the avoidance of premature abstraction . Abstraction, as they are using the term , is a kind of optimization that arises from refactoring code. It s not necessary, however, for every abstraction to be rediscovered every time it s used. Abstractions, once discovered , can be remembered and applied in similar circumstances in the future. This has the effect of accelerating thought and thereby accelerating development ”something quite consistent with XP principles and values.

For example, the stereotypes discussed as part of side 2 (the description) of an object cube are abstractions. If you are developing a financial system and encounter an object named portfolio , your knowledge of collections ”an abstraction ”should lead you to discover that a portfolio is just a collection with some added behavior. Patterns and architectures are another form of abstraction that you can learn, as abstractions, and then apply as you think about design and implementation. ^[6] In Chapter 9, some architectural abstractions were introduced (for example, MVC, blackboards , pipes, and filters). Patterns have also been introduced ”for example, the discussion of blind dispatching , which is an example of the observer or publish-and-subscribe pattern ”but a full exploration of patterns is best pursued in the patterns literature itself. (See the bibliography for starting points.)

Frameworks

A framework is another kind of abstraction, somewhere between a design pattern and a full architectural pattern. Frameworks are organizational abstractions that provide a set of objects with expected behaviors and the relationships that enable them to interact in order to achieve some collective goal. Good frameworks provide the essential core of a programming solution. Extension of the framework by adding other objects and other relationships is expected. However, a good heuristic is to demand unassailable justification before accepting any addition to the framework. See if the unaltered framework can solve your problem before you embellish it. Following are some examples of frameworks.

Composable Document

A composable document has variable content and constraints on the appearance of the content, which are sometimes determined by the presence or absence of other content. A report is a kind of composable document. A legal form, like a loan disclosure document, is another.

The composable document framework (Figure 10-1) suggests that a composableDocument is a collection of elements (which means it has the behavior of adding, deleting, and providing access to the collected elements) that can identify itself, describe itself, and display itself. Display requires collaboration with elements, which can display themselves . Both the document and its elements have extent (the amount of space occupied by the element ”for a document, usually the two-dimensional area), which can be reported and, in the case of the document, allocated to an element.

Figure 10-1: Composable document framework.

Both elements and the document must satisfy certain composition rules, which are embodied in self-evaluating rules. (The composition of a rule as a collection of variables , constants, and operators is shown in Figure 10-1.) This framework provides all of the objects necessary to model the construction of any form or report. (Actual display requires a host of additional objects, glyphs, bitmaps, vector graphics, and so on ”a vexation in that way too much work is required to paint a screen than would be the case if object thinking had guided the developers of operating systems and graphics libraries.)

Object Routing and Tracking

The object routing and tracking framework (Figure 10-2) is useful as an abstraction for the core description of systems as disparate as a network packet manager and a UPS package delivery system.

Figure 10-2: Object routing and tracking framework.

This framework suggests that an object has an originLocation , a destinationLocation , a description, and a unique ID. It obtains a route from a network (an object that specializes in solving np-complete (traveling salesman type) problems. A route is simply an ordered set of nodes and links that connect an originLocation to a destinationLocation . Nodes and links have addresses and characteristics. An object obtains a route, checks with both nodes and links to track its own progress, and raises an alert if it detects a deviation from its assigned route. This alert enables making a request for an alternate route. Various parameters, which match object description with link or node characteristics, time or priority constraints, and so forth, are encapsulated in rules associated with the appropriate objects.

Resource Allocation and Scheduling

Resource allocation is important in numerous business systems. Scheduling is fundamentally nothing more than a kind of resource allocation, with the resource being time. Three objects form the core of this framework (shown in Figure 10-3):

• Resource , which can have other resources (such as a calendar with fine-grained time divisions) as part of its structure and which has a description and an identity

• Request , which can recursively be a collection of requests and which also has a description (resource requirements), an identity, and a Requester

• Reservation , which associates a resource with a request and has an identity along with references to the objects it is associating

  
  Figure 10-3: Resource allocation and scheduling framework.

Numerous other frameworks can be constructed , each of which captures and embodies the best of object thinking. These abstractions can then be used as shortcuts in future efforts to apply object thinking to solve new problems.

A very different kind of extension to object thinking arises from the principle that objects are simulations. An object does not represent, in some abstract way, a thing in the real world; it simulates that real-world thing. Objects are evocative rather than representational. This is why Alan Kay (among others) speaks of the need for objects to preserve the user illusion and behave and appear in a manner consistent with the thing being simulated. This evocative property of objects can be utilized in interesting ways ”including the depiction of system architecture .

Object-Based Evocative Architecture

Figure 10-4 is a photo of a Thangka painting on the wall of my office. This painting is an evocative model of Tibetan Buddhist cosmology and philosophy. Even a cursory glance reveals that it has some kind of structural organization, a significant amount of detail, and lots of interesting and unusual images. Less obvious is that it is a very good object model. The images on the painting are representational in part. Each icon and each organizational segment of the whole can be seen as representing a particular deity or circumstance, but that is almost coincidental ”a case of convenient labeling. The real purpose of the painting as a whole, and of each individual element of the painting, is to evoke memories, primarily memories of stories the viewer of the painting was told as he or she grew up in a Tibetan household. As complex as the painting itself appears to be, that complexity pales in contrast with the volume of memories and intertwined stories that the painting recalls in the mind of the viewer.

Figure 10-4: Thangka painting.

Given that XP eschews the development of formal representational architectures as a prelude to development and that some kind of holistic view of the system to be built is desirable, perhaps an evocative model patterned after the Thangka painting and reflecting the simulation aspect of objects will provide a useful informal tool.

Essential elements of the painting that would have equivalents in the XP architectural model include

• A center circle with icons recalling to mind the driving forces behind the system under development. In the painting, these are icons reminding us of attachment, greed, anger, and so on. In a system model, these would remind us of the importance of money (almost inevitable), a particular client (a CEO perhaps) who will pass final judgment on our work, a customer, or a service.

• A large segmented circle, each segment representing some kind of portioning of the system, preferably isomorphic to some degree with the actual portioning of the business for which the system is being built. In the painting, these are the various realms of existence ”for example, heaven, hell, material world. In our model, these might represent realms such as order entry, inventory, accounting, and manufacturing; or segments of a smaller-scale system ”data entry, back-end processing, backup and recovery, and so forth.

• Icons of various sorts arranged in a tableau evocative of the stories that relate those icons to one another. Each icon evokes a specific story or set of stories about a particular element of the overall system. Icons can appear in more than one segment.

• A narrower outer circle, also segmented, with each segment representing a stage in the circle of life. This circle, in the painting, is the progress from birth to death that each of us traverses. In a system architecture, each segment would represent a stage in the processing of whatever the system is intended to support or perhaps some kind of business cycle from prospect to customer or raw material to product.

• Finally, outside the circle, icons that recall stories about outside influences, things or forces or people that can affect our system but are outside the scope of what we can actually build.

Dynamism can be added to the model in many different ways. If each icon evokes a particular story and the work required to realize that story, the orientation of the icon (down = not started, right angle left = in progress, vertical = done, right angle right = abandoned dead end) can be used to depict status. A quick glance at the model reveals a rough approximation of total effort and total achievements. This is the same information that appears on many an XP project s walls and whiteboards but in a more compact form.

The dramatic form and the unusual context behind the presentation of this architecture might obscure the fact that it s merely a pictorial representation of the way that object thinkers think of objects and applications: as stories,   la XP.

^[6] See the work of Alan Shaloway and of Josh Kerievski on refactoring to patterns and Bob Martin s Agile Software Development for discussion of how and why patterns serve as guides and targets, not as templates that get dropped into your design. Blind composition of patterns actually leads to very poor code.