The program would favor more of the former approach than the latter approach.
For example, let's say we have a class called Cls1 that has a method called SquareRoot( aRealnumber ) that was implemented as a standard, plain-old method. Using this program to apply a strategy pattern would ideally encapsulate the plain-old method into a member of a new Strategy class---let's call it StandardSquareRootStrategy::SquareRoot( aRealNumber ). This new Strategy class would inherit from an abstract class called AbstractSquareRootStrategy. Furthermore, this program would rewrite Cls1 to include a new attribute called "SquareRootStrategy" complete with accessors and mutators that would have a type of AbstractSquareRootStrategy (*not*StandardSquareRootStrategy!) and would rewrite the constructor to properly initialize the new attribute with an instance of StandardSquareRootStrategy. Finally, the Cls1::SquareRoot( aRealNumber ) would be rewritten to call this->SquareRootStrategy->SquareRoot( aRealNumber ). In short, this program would ideally turn 15-20 minutes of tedious and error-prone work into 5-15 seconds of easy, less error-prone code generation. The biggest problem with this grand vision is how grand it is and how much would be asked of a mere program to do. I'm also not sure where to begin with such a massive undertaking as modifying a source code tree in such extreme and potentially destructive manners. The first thing I would look at, though, is how Visual Studio 2008 implements its refactoring tools. Another avenue is to use ANTLR and StringTemplates to do all the heavy lifting of lexing and parsing the target language into an intermediate representation and writing the modified code to disk. On Mon, Dec 7, 2009 at 1:24 AM, Michael Tison <[email protected]> wrote: > On Sat, Dec 5, 2009 at 11:56 AM, Robert Miesen <[email protected]> > wrote: > > I don't know if this is the right place to make an announcement like > this, > > but it couldn't hurt any. > > > > I've been interested for a long time in writing a program that automates > the > > application of certain design patterns to a software project (ex. > changing > > the implementation of a plain-old method into a Strategy Pattern). I > don't > > want to attempt such a massive project on my own and, to my knowledge, > the > > closest anyone has come to implementing a design pattern automation > project > > are the authors of the GoF add-in to StarUML. > > > > Would anyone here be interested in joining me in starting such a major > > endeavor? > > So it would refactor your code for you into whatever pattern you > suggest or it would create an outline for the pattern suggested? (I'm > guessing the latter because the former would be difficult but > interesting) > > Michael > -- Luck is believing you are lucky. -- Tennessee Williams _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
