National Aeronautics and Space Administration

Design patterns can be thought of as software architectural features that solve particular engineering problems. The standard work on the subject, Design Patterns (Gamma, Helm, Johnson & Vlissides —sometimes referred to as the Gang of Four— 1994) lists 23 separate patterns divided into Creational, Structural and Behavioral patterns. XSPEC12 uses about ten of them. We describe briefly below what specific use each pattern has  and the issue within XSPEC12 that it addresses. We follow the definition of a pattern given in Gamma et al. with concrete examples from our code.

• Creational Patterns (issues in creating objects)

• Structural Patterns (putting together robust and flexible software components)

Bridge:

Decouple an abstraction from its implementation so that the two can vary independently.

Many of the classes in XSPEC12 are implemented with what has become known as the PImpl idiom (Pointer Implementation; see also this and the next paragraph) where the work of the class is actually done by a heap allocated object created on construction. Thus the idiom is an instance of the Bridge pattern. Allowing the implementation of this sub-object to be independent has several advantages, including putting up a "Compilation Firewall" so that the number of times the implementation must be #included and compiled is significantly reduced. This speeds up compilation and adds to maintainability.

The motivation behind the PImpl idiom is Exception Safety. It makes allocation of objects atomic: when an object is created it is either properly initialized or it fails outright, in which case no memory is leaked and provided exceptions are handled properly, the program can be made to return to its state before the attempt (other catch phrases here are "resource acquisition is initialization" and "commit or rollback," the latter being familiar to database programmers.

Composite:

Compose objects into tree structures to represent part-whole hierarchies.

This pattern is used during the computation of analytical models. Composite deals with situations where, to continue the tree metaphor, "branches" and "leaves" have the same interface. Outside XSPEC12 the obvious example is a UNIX filesystem where directories and simple files both understand the meaning of the "ls" command but do different things. Inside XSPEC Composite is used in the implementation of model calculations to calculate either model components or groups of model components according to users specification  Its major benefit is a somewhat improved code organization that has the side-effect of allowing (in principle) infinitely nested model expressions.

• Behavioral Patterns (addressing operational and procedural problems)