Menu

Refactoring Assistant release steps

Developers
2002-10-19
2002-12-06
  • Baptiste Lepilleur

    Well, here is list of release steps I have for the refactoring assistant. They are made in such a way to maximize the amount of functionnality provided in face of the amount of development required.

    1) Method refactoring:
    - InlineTemp
    - RenameTemp
    - IntroduceExplainingVariable (may be)

    Those all works at the method level and can be done by parsing only the method body (which is mostly done at the current time).

    IntroduceExplainingVariable may raise some formatting issues.

    2) Class refactoring that change only the class:
    - ExtractMethod
    - InlineMethod
    - SelfEncapsulateField
    - ConsolidateConditionalExpression
    - DecomposeConditional
    - RenamePrivateField
    - RenamePrivateMethod

    Those work on a single .cpp/.h (no project management needed yet).

    3) Class refactoring that creates new classe
    - ExtractClass
    - ExtractInterface
    - ExtractSubclass
    - ReplaceDataValueWithObject
    - ReplaceMethodWithMethodObject

    Those still work on a single .cpp/.h. On the other they creates new class and file, which make them slightly more complicated to deal with.

    4) Class refactoring that use more than one classes
    - InlineClass
    - ExtractSuperClass
    - MoveField
    - MoveMethod (using delegation)
    - PullUpField
    - PullUpMethod
    - PushDownField
    - PushDownMethod
    Those works on a specified set of .cpp/.h.

    5) Project wide refactoring
    - RenameFreeFunction
    - RenameMethod
    - RenameField
    - RenameClass
    - RenameType (typedef, enum...)
    - ...
    Those works on any .cpp/.h of a given project. We may need to introduce some form of symbol database to help performance, but we'll see when we get there.

    Notes that the refactoring listed may or may not be implemented in the specified step. The lists are just used to shape what the content of a step is.

    All those steps will allow us to make the system a little more complex at each step. When we will be done with step 4, we should have a fairly good ideas of what is needed to achieve step 5.

    Baptiste.

     
    • Sven Reichard

      Sven Reichard - 2002-10-19

      A few comments:
      My idea is to keep the number of global refactorings to a minimum, since global parsing appears more complicated to me. This may come at the price of splitting some refactoring in two parts (i.e., refactoring the refactorings).

      - Inline Method might be global if the method isn't private;
      - Refactorings in Step 4 work on 2 classes (4 files) only;
      - RenameMethod and RenameField can be thought of as working on a single class (using delegation).
      - Rename Class can be local if we introduce a global refactoring InlineTypedef (just if that's useful for anything else)
      - IMO ConsolidateConditional is method-based (usually followed by Extract Method)
      - Another Method refactoring is Split Loop

      However, it's a good list to start with.

      Sven.

       
    • Andre Baresel

      Andre Baresel - 2002-12-06

      As far as I can see (100 documents in the mailing list).
      This is the discussion of features for the refactoring operations. Correct me if there's some news about that thing...

      local renaming is in many cases only a work of search and replace ... well, just in case not so many identifier names are nearly simular.

      So global renaming is the most important thing, since this is real refactoring.

      But I understand the problems with the parsing. It could lead to a refactoring tool which is project based, and has to collect all information before it can start such operations.

      so the start with just something that works very early is a good idea - but as soon as possible there should be a decision how to handle global refactoring operations.

      but after all - first i have to look through the sources, to understand what I'm talking about ;)

      -- andre baresel

       
      • Baptiste Lepilleur

        Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.

        For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.

        This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.

        The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.

        My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).

        Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.

        Baptiste.

         
      • Baptiste Lepilleur

        Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.

        For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.

        This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.

        The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.

        My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).

        Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.

        Baptiste.

         
    • Andre Baresel

      Andre Baresel - 2002-12-06

      I was just seeing that -- "Next Attemp" Thread which also discusses my suggestions.

      I think this way of discussing really hurts, if you just come in to a project ---
      It's not really nice to read about 100 postings --- and even more if you come in later.

      -- andre

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.