AntiPatterns

Description

The Software Patterns Criteria Proposed Definitions for Evaluating Software Pattern Quality Version 10.2 June 2, 1998 Background: Achieving a standard definition of "What is a software pattern?" is an important goal of the software patterns community. This proposed definition is the result of a single draft review process on the software patterns community email lists. Note: These criteria apply to the evaluation of an individual pattern. A Pattern Lifecycle Model is also documented below, as a non-normative explanation, supporting the criteria. Perspective: To define priorities for the software pattern criteria, it is appropriate to make the stakeholder perspective explicit. In this case, the stakeholder represents working software practitioners, including software architects, software designers, and programmers. The importance of standard criteria: Standards for documenting software patterns are important to enhance the quality of documented patterns knowledge. Quality provides tangible value towards the satisfaction of human needs. The "humans" in this case are the principal pattern stakeholders: the software practitioners (See Perspective above). For example, consistency may be a quality of software patterns. Software practitioners often synthesize system solutions, combining the knowledge of multiple patterns and catalogs. Consistent pattern documentation standards are helpful for software practitioners who are using multiple pattern catalogs from different authors. ESSENTIAL CRITERIA The following criteria are essential requirements for all software patterns. The ordering of the essential criteria is not important, since they are all mandatory requirements. 1. RULE OF THREE: A software pattern documents a recurring solution. The pattern solution abstracts three or more experiences. The solution is something which is regularly applied or practiced by some community(s) of sophisticated developers and architects. The logical basis for the rule of three is: the first occurrence shows the design can work, the second occurrence is interesting, and the third occurrence suggests that the design might be worthy of being a pattern because it appears to have a wider applicability. Non-normative comment: The informal concept behind the rule-of-three is: the first occurrence is an event, the second occurrence is a coincidence, and the third occurrence may be a pattern. 2. PATTERN NAME: A software pattern has a name corresponding to the documented solution. Within a pattern catalog, this name is unique. 3. DOCUMENTATION: A software pattern is a literary form which contains a documented solution to a software problem and associated design forces. 4. TEACHING: A software pattern contains both solution and teaching elements. The teaching elements address the "why?" questions, including the justification and rational explanation of the pattern. The teaching elements include a discussion of context and forces

Products & services

Similar companies nearby