 |
 |
Tal Cohen
writes:
Patterns as problem indicators
The review above was written and published ten years ago. Since then, I have learned (and was not the first to learn) that many patterns are nothing more than indicators of problems in the programming language itself.
My own Ph.D. dissertation, which technically deals with aspect-oriented software development, presents several suggestions for design improvements in programming languages. These improvements (some minor and easy to incorporate, some more far-reaching) directly affect eight of the original 23 patterns, either rendering them superfluous or improving their usability and extent:- The factories mechanism (not to be confused with factory methods) includes both supplier-side factories and client-side factories. The former makes the Factory Method, Singleton, and Flyweight patterns redundant, and the latter makes the Abstract Factory pattern redundant. (They also obliviate the need for the well-known Object Pool pattern, although this pattern is not presented in the original Gang of Four book.)
- The shakeins mechanism can replace, or present a better implementation mechanism for, the Chain of Responsibility pattern. Shakeins can also simplify, or present a better alternative for, the Observer pattern.
- Finally, the Object Evolution mechanism completely obliterates any need for the State pattern. Combined with Shakeins, the third form of Object Evolution, known as S-Evolution, can also replace the Decorator pattern.
Complete details about each of these mechanisms can be found in the links above, or in the dissertation itself. The relation between the mechanisms and the classic design patterns is discussed in the summary chapter of the dissertation. |
©1997-2022 by Tal Cohen, all rights reserved. [About]