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)
• Behavioral Patterns (addressing operational and procedural problems)

Command:

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Command is used within XSPEC12 to encapsulate requests for different plots. Users input is directed to a lookup table that makes a Command object that assembles whatever is needed. This facilitates two likely future needs. First, the need to add new plotting options to the code. New Command-based types can be run-time loaded and added internally to the list of options present without risk to the existing code. Second, the Command pattern makes it particularly easy to add menu options to a GUI.

Observer (Subject/Observer, Publish/Subscribe):

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Observer is used to achieve consistency between model, data and fit as the user enters a variety of commands that might affect their contents (such as changing the number of spectra being fit, or changing responses). Generally, changes in data being analyzed are the "Subject" that is "Observed" by Model, Fit, and Plot

Strategy:

Define a family of algorithms, encapsulate each one, and make them interchangeable.

XSPEC12 has several instances which use the Strategy pattern (and one or two where it might have, but didn't...). Minimization algorithms and objective functions are implemented as strategies for the Fit object and the base class of each, FitMethod and StatMethod respectively, holds a list of subclasses which can be added to at run time. Two side effects of this for code development are that the code for driving the fit and the strategy code can be developed independently; also, the program does not impose a particular programming language on the strategies provided they can be made to look like C to the compiler. In fact, both of XSPEC's Fit strategies available at the initial release are tried and tested fortran77 algorithms.]

Another important example is the plotting package, which when wrapped as a subclass of a well-defined interface base class is a (or one of several possible)  Strategy object(s) of the Plot implementation.

Template:

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

Template is another pattern that is ubiquitous within XSPEC12 wherever a class hierarchy exists. It is used, for example, in CCfits to implement reading table headers using the same outline code whether the FITS extension is an ASCII or Binary table. More importantly perhaps it makes most of the machinery required for computing derivatives of objective functions reusable:  this involves looping through the arrays to be summed to produce (say) derivatives of Chi-squared or the Cash Statistic, which differ from each other by only some tens of lines of code in several hundred.