Prioritizing Forces in Software Design

By: A. Cockburn
Published in: PLoPD2
Pages: 317-333

General principles for software design.

Category: Architectural

Summary: General principles for software design.

Pattern: Protected Variations

Pages: 321-322

Protect system integrity from change by identifying areas of predicted variation and creating a stable interface around them.

Pattern: Persistence Accessors

Pages: 322-324

When the interface to the persistence infrastructure is likely to change, use persistence accessor methods. These are owned by the infrastructure, not the domain, and may be regenerated at any time.

Category: Architectural, Client-Server, Persistence

Pattern: Skill Mix

Pages: 324-325

When team membership is likely to change, separate subsystems by staff skill requirements. This allows specialists to work in their area of expertise and enables successors to see the results of these special abilities in isolation.

Category: Organization and Process

Pattern: Three Subsystems

Pages: 325

You're developing workstation application software. Create three subsystems: infrastructure, user interface, and application domain. User interface experts can concentrate on human factors and user interface programming; application domain experts can concentrate on application requirements, data needs, and model object behavior; and infrastructure experts can concentrate on system structure.

Category: Architectural, GUI Development

Pattern: Generic UI, Specific UI

Pages: 325-326

When a team has a high percentage of novices, create two class layers in the user interface subsystem. Use highly skilled developers for the generic classes, and novices for the specific classes. Let the generic user interface developers create frameworks, and the specific user interface developers use them.

Category: GUI Development, Organization and Process

Pattern: Generics and Specifics

Pages: 326-327

When a team has a high percentage of novices, create two class layers for the problems in the system. Use experts to design the generic parts, and novices to design the specific parts.

Category: Architectural, Organization and Process

Pattern: Application Boundary

Pages: 327

To protect system integrity from changing external components, define the user interface to be outside the application proper. Make all functions of the application accessible through a program-driven interface.

Category: GUI Development

Pattern: Split Validation

Pages: 328

Should input validation be performed before the application is called, or should it be performed by the application itself? Perform entry validation in two steps. Keystroke validation is performed in the user interface, and value validation is performed by the application.

Category: GUI Development

Pattern: Edits Inside

Pages: 328-329

When a user can cancel a transaction after making changes but before committing, the most efficient way of editing is to keep two copies of the object, the safe copy and the editing copy.

Category: Transaction Processing

Pattern: Subclass per Team

Pages: 329-330

When there are conflicting design issues for a class, assign designers in conflict to work on different layers of the class hierarchy.

Category: Organization and Process

Pattern: Model Hierarchy

Pages: 330-331

Validation, domain, and persistence are the three parts of any persistent domain object. When they are designed by different teams following Skill Mix, the class hierarchy for persistent domain classes consists of Model (for the common domain issues), ValidatedModel (for the validation issues), and PersistentModel (for the persistence issues). Model and ValidatedModel can be merged or broken apart, depending on the design.

Category: Architectural, Persistence, System Modelling

Pattern: Facade

Pages: 331

Provide a single point of call to volatile interfaces. This protects developers from massive rework if an interface changes and provides a unified interface to a set of interfaces.

Pattern: Domain Intercepts

Pages: 331-332

To protect developers from massive rework due to persistence layer interface changes, the user interface should never call the persistent subsystem layer directly. Instead, it calls a domain object, whose superclass provides a single point of implementation for the service.

Category: Architectural, Persistence