Understanding design patterns — what is the problem?
Bibliographic record
Abstract
SUMMARY Design patterns codify proven solutions to recurring design problems. Their proper use within a development context requires that: (i) we understand them; (ii) we ascertain their applicability or relevance to the design problem at hand; and (iii) we apply them faithfully to the problem at hand. We argue that an explicit representation of the design problem solved by a design pattern is key to supporting the three tasks in an integrated fashion. We propose a model‐driven representation of design patterns consisting of triples < MP,MS,T > whereMPis a model of the problem solved by the pattern,MSis a model of the solution proposed by the pattern, andTis a model transformation of an instance of the problem into an instance of the solution. Given an object‐oriented design model, we look for model fragments that matchMP(call them instances ofMP), and when one is found, we apply the transformationTyielding an instance ofMS. Easier said than done. Experimentation with an Eclipse Modeling Framework‐based implementation of our approach applied to a number of open‐source software application's raised fundamental questions about: (i) the nature of design patterns in general, and the ones that lend themselves to our approach, and (ii) our understanding and codification of seemingly simple design patterns. In this paper, we present the principles behind our approach, report on the results of applying the approach to the Gang of Four (GoF) design patterns, and discuss the representability of design problems solved by these patterns. Copyright © 2011 John Wiley & Sons, Ltd.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.023 | 0.060 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.004 | 0.004 |
| Science and technology studies | 0.003 | 0.011 |
| Scholarly communication | 0.015 | 0.033 |
| Open science | 0.004 | 0.005 |
| Research integrity | 0.005 | 0.008 |
| Insufficient payload (model declined to judge) | 0.005 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".