Software design patterns, as they exist in their prosaic form today, are too abstract. Describing the purpose of a relationship between entities, the pattern's defining text cannot adequately specify all manifestations of the pattern. The practice of applied computer science requires the identification and, as much as is practically useful, the definition of design pattern realizations, or allotropes.
An allotrope is an alternative form of a basic substance. Graphite, coal and diamond are all carbon allotropes. Allotropic forms are wildly different in form and structure, though they share the same basic constituent. The alternative realizations of software design patterns often are so different from each other, both in terms of behavior and physical structure, as to exhibit allotropy, so the term allotrope seems appropriate.
For example, in Java (as well as all similar high-level OO languages) there are dozens of possible realizations of the GoF Factory Method pattern. Simply saying a class FooFactory implements the Factory Method pattern doesn't tell you much; does FooFactory implement a polymorphic factory interface, as required by the original GoF definition, or is it a degenerate form in which client code must couple directly to the concrete creator, which is a very common "factory" implementation? (Here is such an example, which has many significant deviations from the original Factory Method definition but which is still recognizable -- an examplar of software design pattern allotropy.) Can the factory be used to create many different types of products, or just one? If more than one, then what's the difference between that and an Abstract Factory? Do the factory method(s) support parameterization (passing input parameters influencing the state and behavior of created products)? What programmatic or environmental configuration, if any, influences the factory's behavior? These are all questions a developer who is using the factory allotrope would ask.
By way of analogy, imagine what it would be like if the realm of building and construction relied solely on the abstract building patterns Wall, Column, Floor, Staircase, etc., without a common understanding of specific concrete instances such as "Wood-framed load-bearing wall", "Wrought-iron spiral staircase", "Decorative Ionic column", and so on? You grok a basic understanding of a building's structural design using the abstractions, but to actually build the structure you need the concrete definitions.
The next step in the integration of software design patterns in to common software development practices must be to identify and catalog design pattern allotropes. When we speak of a factory, an object pool, a chain-of-responsibility, or any other design pattern realization we must be able to exchange practical, meaningful, specific information about style and structure without a ton of prose.
12:15:16 PM 
|
|
