The notion of force generalizes the kinds of criteria that software engineers use to justify designs and implementations. For example, in the classic study of algorithms in computer science, the main force to be resolved is efficiency (time complexity). However, patterns deal with the larger, harder-to-measure, and conflicting sets of goals and constraints encountered in the development of every artifact you ever create. For example:
Correctness |
Completeness and correctness of solution
Static type safety, dynamic type safety Multithreaded safety, liveness Fault tolerance, transactionality Security, robustness |
Resources |
Efficiency: performance, time complexity, number of messages sent, bandwidth requirements
Space utilization: number of memory cells, objects, threads, processes, communication channels, processors, ... Incrementalness (on-demand-ness) Policy dynamics: Fairness, equilibrium, stability |
Structure |
Modularity, encapsulation, coupling, independence
Extensibility: subclassibility, tunability, evolvability, maintainability Reusability, openness, composibility, portability, embeddability Context dependence Interoperability ... other ``ilities'' and ``quality factors'' |
Construction |
Understandability, minimality, simplicity, elegance.
Error-proneness of implementation Coexistence with other software Maintainability Impact on/of development process Impact on/of development team structure and dynamics Impact on/of user participation Impact on/of productivity, scheduling, cost |
Usage |
Ethics of use
Human factors: learnability, undoability, ... Adaptability to a changing world Aesthetics Medical and environmental impact Social, economic and political impact ... other impact on human existence |
It is usually impossible to analytically ``prove'' that a solution optimally resolves forces. (In fact, it is hard to define the notion of ``proof'' here, or even to see what use such a proof would have.) On the other hand, it is all too easy to come up with ``just-so'' stories that provide wrong or deceptive rationales for solutions. Even the most concientious pattern authors sometimes don't fully understand why a solution works as well as it does, or appreciate its full range of applicability.
For these reasons, the patterns community expects that arguments be backed up with:
Until such evidence is provided, a pattern is sometimes called a proto-pattern -- a candidate for being a pattern.