Defining refactoring strategies using DPL

Coordinator
Jul 26, 2012 at 7:20 AM
Edited Jul 27, 2012 at 5:32 PM

It's not so easy to create new documentation page on Codeplex, I therefore moved the DPL refactoring tools in a discussion.

How would a refactoring strategy looks like ? I can start with the most basic example: if some methods are exactly identical in the code base, first try to create an abstract method to replace them all, and if not successful try to implement an interface method.

// CONDITIONAL PATTERN
IF
{
// STEP 1: FIND ALL DUPLICATE METHODS WITH
// EXACTLY THE SAME CODE
DuplicateMethodsSet(DuplicateMethods0)
{
	DuplicateMethods = {.~.}
	CONTR(DuplicateMethods*) = {.}
}
}

THEN
{
// REFACTORING PATTERN

IF NOT {
// TRY1: REPLACE ALL METHODS BY AN ABSTRACT METHOD
AbstractClassRefactorStrategy()
{
DuplicateMethodSet0 = DuplicateMethods0#
TYPE(CONTR(DuplicateMethodSet0)*) = AbstractType
CONTR(AbstractType)={} CONTR(MethodInAbstractClass) = AbstractType DuplicateMethods0# 1~1 MethodInAbstractClass } } THEN { // TRY2: ONLY ADD A COMMON INTERFACE InterfaceRefactoringStrategy() { DuplicateMethodSet0 = DuplicateMethods0# TYPE(CONTR(DuplicateMethodSet0)*) = Interface SimilarMethodsSets = {.=.} SimilarMethodsSets# = {DuplicateMethodSet0, Interface} } } }

There is much to say about this simple code. It implies that the "DPL refactorer" will try to make the "applied patterns" true but sometime will not be able to do it and will give up. For example, in the TRY1 pattern, it will try to make all classes inherit from a common abstract class. If it cannot, it is assumed the refactorer will not go further. The refactorer won't stop there, otherwise it wouldn't compile. He will then have to delete all duplicate methods in the code, keeping only the abstract method.