CHOKEPOINT

also known as

HEAD 'EM OFF AT THE PASS

TOLLBOOTH

TURNSTILE

AUTHORATIVE REPRESENTATION

ACCOUNTABILITY

ONE-STOP SHOPPING



When the responsibility for a particular service is dispersed, it is difficult to know where to turn to query, control, or modify the it.

[Perhaps this is too strong. If we allow a number of objects to be responsible for some service, but provide a certain means to round-up and change all these objects, is the intention of this pattern met?]

Design systems so that there is a single place to which one can turn that is guarenteed to provide an authorative view of a particular subject or service.

To design an object-oriented architecture that provides chokepoints at which particular services can be controlled can controlled, you should design the system so that there is a particular object that provides the function of interest, and provide a mechanism so that the clients can find and manipulate these authorative instances.

The knowledge that a given object is the sole locus of responsibility for some service enables the designer to wrap it or provide a substitute for it with the assurance that all traffic that goes through the chokepoint will subsequently go through the wrapper or substitute.

Chokepoints are integral to the notion of causally connected representation in object-oriented reflective metalevel architectures. If a particular language-level (or metalevel) object is defined as being responsible for providing a service, such as dispatching for a particular generic function, then changes to this object immediately affect the service the object provides. Kiczales and des Rivieres have stated this idea as follows: B is a causally connected representation of A if when you blow up B, A disappears. [Find the reference. MOP Book or Reflection '90 or '91]



In object-oriented languages that support first-class class objects at runtime, a change to a method in a class is guarenteed to immediately affect all instances of that class. The class is guarenteed to be the sole official repository of the objects that are in turn responsible for the behavior, layout (etc.) of each of the class's instances.

[There are certainly more examples...]


[Constituents go here...]


THE SELFISH CLASS

also known as

SOFTWARE SOCIOBIOLOGY

SOFTWARE DARWINISM RUN AMOK

PLUMMAGE



Software artifacts that cannot attract programmers are not reused, and die.

Software artifacts that appeal to programmers will flourish. Those that do not will not. How might a potentially reusable artifact flourish? It can be and integral part of the code for a successful application. The success of such an application will guarentee that this code will remain the focus of programmer attention. (Remember, the mere fact that thousands or millions of copies of an artifact are present in the object code of applications in the field does not help to propogate the code. Only its reincorporation into subsequent versions of the applications in which it resides, or its incorporation into new applications, allows it to "reproduce".

The FRACTAL MODEL is unique, in that rather than focusing on programmers or the software development process, it focuses on the code itself. This approach might be thought of as software sociobiology, since it takes the attitude that systems, users, and programmers exist merely as vehicles to abet the evolution of code. By analogy with the selfish gene, one might ponder the notion of the selfish class...

Species are subject, it is said to the law of the jungle. The jungle that annoints the winners and losers in the software domain is the marketplace. An inferior artifact may flourish if it is hosted by an application, that, for whatever reason, succeeds in the marketplace, which in turn makes the source code for the application containing the artifact the subject of additional development efforts.

Design artifacts that programmers will want to reuse.

The programmer with a commitment to reuse, while focusing on the problem at hand, keeps one eye towards the future, and the potential that the artifact he or she is building will find a wider audience within or beyond the applications it currently inhabits. This programmer is not content that his or her craftsmanship be know only to God, like the artisans that carved gargolyes that could viewed only from perspectives that would never be seen by mortals.



[Examples go here...]


An object that WORKS OUT OF THE BOX is more likely to appeal to programmers than one that does not.

THE FRACTAL MODEL describes how object-oriented abstract classes, components, and frameworks can evolve both within and beyond the applications that spawn them.


LOW SURFACE TO VOLUME RATIO

also known as

SIMPLE INTERFACE

INFORMATION HIDING [may be merely related]

ABSTRACTION [may be merely related]

ENCAPSULATION [in the sense of of abstraction, not protection]

HIGH LEVERAGE

Objects that allow a user to mobilize a large volume of complex machinery via a small, simple interface are more likely to flourish than those that don't. See THE SELFISH CLASS. An object with a simple interface relative to its internal complexity may be more likely to WORK OUT OF THE BOX. [Although the connection isn't necessarily direct. This link may not be justified here.]



Objects with complex interfaces that conceal few of their internals are hard to understand and reuse.

Objects that marshall the resources to perform complex tasks in response to simple external protocols provide the programmer with a high degree of leverage and power.

Design objects with low surface to volume ratios, that is, objects with small external interfaces, or surface areas, that encapsulate a large volume of internal complexity.



[Examples go here]



AGGREGATE FROM EXPERIENCE

also known as

THE MESSY KITCHEN or WORKBENCH

PLAN TO CLEAN IT UP

[Maybe this really is the MESSY KITCHEN, and defer aggregration is but one manifestation, as might be the drift of information to more global scopes. Check some of the recent exploratory phase notes about this.]

The MESSY KITCHEN.might be a good description of what happens during the Fractal Model's exploratory phase. There is often some erosion of program structure during this phase.



Prototypes are often haphazzardly structured. Program structure typically erodes during exploratory interludes.

Exploration in particular can be an entropy increasing phase. Recall that Lehman and Belady, or Brooks, observed the same increase in entropy during traditional maintenance.

As long as the erosion of structure seen during prototyping and exploration is treated as transient disorder, like that seen in a messy kitchen, the long term health of a system is not jeopardized.

In other words, PLAN TO CLEAN IT UP.



[Examples go here]


<Constituents: Not yet determined>


LINGUA FRANCA

also known as

[Insert additional information about the patterns that this pattern completes here]



Otherwise compatable data are stored in a variety of different formats. Converting among them can require, in the worst case, a conversion program for each pair of formats.

.

Allow one format to serve as a universal second language, a lingua franca. Then conversion between arbitrary formats will require only two conversions, one from the first format to the lingua franca, the second from the lingua franca to the second format.

The term lingua franca is a historic anachronism. At one time Latin and Greek played this role. These days, English has assumed the role of the lingua franca in most parts of the world. French is widely spoken only in parts of Africa, Canada, the South Pacific and the Carribean, and, of course, in France, where it is used exclusively,.

Contrast CONVERTABLE CURRENCIES and ENGLISH ONLY/STANDARD REPRESENTATION...


[This is where the EXAMPLE goes in an Alexander-style pattern...]

The portable bitmap (PBM) tools.



[Describe the patterns that complete this pattern here]

CONVERTABLE CURRENCIES


FRACTAL MODEL

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]


PROTOTYPE

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]


EXPANSION

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]


CONSOLODATION

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]




INDIRECTION

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]




SHARING

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]




SUBSTITUTION

also known as

[Insert additional information about the patterns that this pattern completes here]



Problem

Solution


[This is where the EXAMPLE goes in an Alexander-style pattern...]



[Describe the patterns that complete this pattern here]