Section 7.2. SHYNESS AS A METAPHOR FOR ADAPTIVE BEHAVIOR

7.2. SHYNESS AS A METAPHOR FOR ADAPTIVE BEHAVIOR

Knowledge relationships among software components can be understood by analogy to human organizations. Humans create hierarchiessuch as managers, group leaders, and individual workersso that changes in knowledge state follow restricted paths and so that not everyone has to know about all changes (see Figure 7-1). We relate those restrictions to shyness in human behavior.

Figure 7-1. Manager, group leaders, and workers.

This shyness has three elements:

1. Minimizing information sharing

2. Minimizing the number of communication channels

3. Reducing the scattering of communications

The structural alternative is organizational bedlam: having arbitrary people dependent on the work structure of arbitrary other people, requiring considerable routing and analysis with each change in process or organization.

Better software design mimics the shyness of good organizations rather than the disorderliness of bad ones. In object-oriented software systems, an important locus of shared knowledge is the class graph. It is better to have components that rely only on local information in the class graph than global knowledge of its structure. It is better to have shy workers and components that minimize the external knowledge of their internal behavior than ones that become trapped into the doing of something a particular way because others rely not just on the output but also on the process.

Better organizations also minimize communications channels so that not everyone is bothered by the chatter of routine activities. Similarly, better software systems follow a parallel in the Law of Demeter, which states that an object should "talk" only to closely related objects. The closely related object for a worker is the group leader, not the manager.

Finally, better organizations restructure information so that higher managers deal with summarized and coalesced versions of the raw facts. This allows high-level managers to better understand the many projects they are responsible for and to optimize with respect to the overall system behavior. The orders of high-level managers affect many worker projects. Each order cuts across one or more projects, and it is important that those orders are not too tied to the details in the projects. Otherwise, orders are brittle, and the managers would have to spend too much time writing and revising them. The same point applies to programming: Instead of sending an object a lot of individual requests, it is better to send one complex request that can be understood as a whole and that is not tied to many details in the object. Consider an SQL query as another example of a complex request. The SQL query abstracts away from the physical database organization, but the query optimizer will use it. Therefore, it is more efficient to send one complex SQL query to a database rather than 50 very simple SQL queries. The query optimizer of the database system can coordinate the responses to the simple queries, and the overall response time will be better.

7.2.1. How Shyness Relates to AP

The arguments for AP parallel those for structured organizations. Pure information hiding does not hide enough. Information hiding makes all public interfaces available, but minimizing sharing (shyness trait (a)) asserts that only an abstraction of those interfaces should be visible at higher levels. In AP, only high-level information about the class graph is visible at the (adaptive) programming level. This shields the program from many changes to the class graph in the same way that the manager is shielded from many of the changes in the workers' projects. The role of the group leader is played by the glue code that maps high-level information to low-level information and vice-versa (see Table 7-1).

Table 7-1. The Correspondence Between Management and Programs

Worker	Group Leader	Manager
Class graph	Glue code	Adaptive program

AP is related to complex requests (shyness trait (c)) by offering a declarative way of navigating through objects and executing operations along the way. This is better than sending many small data accessing requests and allows for optimal generation of correct traversal code that contains accidental details from the class graph.

7.2.2. How Shyness Relates to AOP

Aspect-oriented programming is about abstractions that cut across multiple modules [19, 34]. It can best achieve its potential if it follows the same principles as AP. Good AOP minimizes information sharing (shyness trait (a)) when aspects are only loosely coupled to base programs. Often, good aspect systems provide glue code that maps the aspect to the detailed usage context. AOP is related to complex requests (shyness trait (c)) by observing that an aspect is a complex request to modify the execution of a program. These relationships are illustrated in Table 7-2.

Table 7-2. The Relationship Between Management and AOP

Worker	Group Leader	Management
Program	Glue code	Aspect

7.2.3. Law of Demeter

An example of the overlap between AP and AOP is apparent in the Law of Demeter. The Law of Demeter [18, 20] is a style rule for object-oriented programming whose goal is to reduce the behavioral dependencies between classes. Its primary form asserts that a method M should only call methods (and access fields) on objects that are preferred suppliers: immediate parts on this, objects passed as arguments to M, objects that are created directly in M, and objects in global variables (in Java, public static fields). Limiting which methods call which other methods keeps programmers from encoding too much information about the object model into a method, thus loosening the coupling between the structure concern and the behavior concern.

To obey the Law of Demeter, methods whose ad-hoc implementation is scattered across several classes need to be cleanly localized. The result is a clean separation of various behavioral concerns from concerns about the structural information (class graph).

AP allows one to minimize the number of communication channels (shyness trait (b)) while nevertheless following the Law of Demeter. A study of three medium-sized object-oriented systems found that following the Law of Demeter can result in a large number of small methods that scatter and duplicate class graph information: In all three systems, 50% of the methods were fewer than two C++ statements or four Smalltalk lines long [38]. This can make it hard to understand the high-level picture of what a program does. Adaptive programming with traversal strategies and adaptive visitors in DAJ avoids this problem while providing even better support for loose coupling of concerns.

7.2.4. Law of Demeter for Concerns

The Law of Demeter for Concerns (LoDC [17]) is a style rule for programming, which states that an object should "talk" only to closely related objects that share its current concerns. A concern is any issue the designer is concerned with, such as a use case or the synchronization or logging policy for the system. Following the Law of Demeter induces adaptive programming, while following the Law of Demeter for Concerns induces aspect-oriented programming.