Automating the Application of Design Patterns: A Refactoring Approach
Problems in Applying the Methodology
There are a number of ways in which a design pattern can be found to be less suitable for the application of our methodology. We describe them below.
Contact the author.
© Mel Ó Cinnéide 2000
- A convincing and useful precursor cannot be found. Sometimes there is no compelling way a programmer might have partially implemented the intent of the pattern without either using a poor design (an antipattern), or going the whole way and implementing the full pattern structure. We may in this case be able to work with a weak precursor that is very close to the green field starting point. This is a workable solution, but not very satisfactory, as there is little need for behaviour-preservation proofs in this case. Examples: Decorator and Observer.
- There is a compelling precursor, but it is not a structure that can easily be pointed to and identified in code, even by a programmer who knows the code well. It may, for example, contain behavioural elements that are dispersed around the code. The problem here is that this type of precursor is too inexact to be used to drive a behaviour-preserving transformation, and so is useless as a starting point for an automated approach. In some cases dynamic analysis or sophisticated pattern recognition might provide a solution, but this is beyond the scope of this work. Examples: Facade, Mediator, Interpreter and Flyweight.
- Even if a compelling and easily identifiable precursor can be found, it may be that the resulting transformation still leaves a certain amount of work for the programmer to do in order to complete the application of the pattern. Note that if the amount of work to be done is small, we may still categorise the result as excellent. Examples: Adapter, Builder, Bridge, Chain of Responsibility, Proxy and State.