The aim of this website is to constitute a spoiled pattern base. This website is collaborative. A validation committee has been constituted to validate new propositions. If you want to submit a problem, strong points, an alternative solution or a spoiled pattern, you just have to register you.
Design patterns are mainly concentrating on problems that may arise during the design phase of objects software. They limit the time needed to solve problems and improve the documentation and the maintenance of an existing system. Design patterns give a name, isolate and identify the fundamental principles of a general structure, to make it a useful way to develop a reusable object-oriented design. They determine the concerned classes and instances, their responsibilities and their cooperations. Each design pattern describes a design problem, the circumstances in which it applies, the resulting effects of its implementation, as well as the compromises implied. The most common have been proposed and arranged by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides "the GoF" (Gang of Four). They gathered in a catalog, twenty-three design patterns, corresponding to twenty-three recurring design problems.
Thus, It is possible to consider that a design pattern is a "canonical reusable microarchitecture" for a given problem type. For each design problem solved by a design pattern, the "canonical solution" is an adaptation of a design pattern to the context of the problem. Thus, "an alternative solution" is a valid solution for a given problem, but with a different architecture than the canonical solution. Thus, the requirements of the problem are respected by the alternative solution, but relations between the classes are different from the pattern, and / or there is not all the participants of the pattern. An alternative solution is an inadequate solution to a problem and is replaceable by the instantiation of the design pattern corresponding to problem type under consideration. "An instantiation" is the process of adapting a design pattern to the particular context of a problem. "An abstraction" is the reverse process of instantiation.
"A spoiled pattern" is the abstraction of a recurring alternative solution in the same way that a design pattern is the abstraction of a recurrent canonical solution. A spoiled pattern is connected to one and only one design pattern. The term "spoiled" was chosen to describe this new pattern family, because it corresponds to a degradation of the intrinsic qualities of design patterns and because they are replaceable by the corresponding design patterns. The structural differences between a design pattern and a spoiled pattern cause degradation of the efficiency to solve such problems adequately. "Strong points" of a design pattern express the criteria for architecture and software quality factors introduced by its use. These criteria are partially deducted from the result section of the GoF catalog and design defects found during the use of spoiled patterns. They explained how a design pattern is the best solution for a problem type.
This website is presented like a catalog. Each GoF design pattern is presented, with its strong points, its spoiled pattern and one or more problem solvable by the pattern. For each problem, one or more alternative solitions are associated. They solve the problem in perturbing the strong points of the pattern.
