Bug 135522

Summary: [refactoring] replace inheritance by delegation
Product: [Eclipse Project] JDT Reporter: NoName <utilisateur_182>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: ASSIGNED --- QA Contact:
Severity: enhancement    
Priority: P3 CC: b.muskalla, daniel_megert, david, deepakazad, eclipse, markus.kell.r, steimann, stevemash
Version: 3.1.2   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description NoName CLA 2006-04-07 08:40:15 EDT
Hello,

Let's take an example, the aim is to be able to refactor and change between 1/ and 2/ :

1/ super class
public class A extends B {
  public int foo() {
    // super is here only for explanation
    return super.bar() + 1;
  }
}

2/ field to delegate
public class A {
  protected B b = new B();

  public int foo() {
    return b.bar() + 1;
  }
}

I hope you like the idea, and that it's not too hard to do :)
Comment 1 Martin Aeschlimann CLA 2006-04-10 16:16:17 EDT
ok, I see. That would be nice to have. But we will have to see if we find time for new refactorings. Help is always welcome!
Comment 2 Benjamin Muskalla CLA 2008-08-17 09:48:37 EDT
I just stumbled across a paper by Hannes Kegel and Friedrich Steimann.
They created a eclipse-based plugin for this refactoring (see http://www.fernuni-hagen.de/ps/prjs/RIWD/ )

I just added them to CC so maybe they can give a little feedback if it would be possible to contribute their work to JDT.
From the source files I can't see any license of the tools so maybe they can elaborate on that too.
I would be really interested to see this refactoring to be part of JDT itself. 
Comment 3 Friedrich Steimann CLA 2008-08-18 04:37:47 EDT
There are no licensing problems, just the usual obstacles of making it a contribution (Junit tests etc.). If the UI team can compile a list of TODOs, I can find someone to do it. Ideally, the list would be exhaustive and its processing sufficient for inclusion.

The refactoring is already in resonable shape; it can be dowloaded from 

http://www.fernuni-hagen.de/ps/prjs/RIWD/#Installation

PS: IntelliJ IDEA also offers RIWD, but our implementation is far better ;)
Comment 4 Dani Megert CLA 2008-08-18 04:52:32 EDT
>If the UI team can compile a list of TODOs
There's no complete list. Important is to provide the work as CVS patch(es) using the projects code styles (formatter, naming conventions etc) and make sure the UI fits into the other existing refactorings. Besides that, tests need to be provided (org.eclipse.jdt.ui.tests.refactoring project). Also, each new file needs to get your copyright header and touched files need to get an entry about your work.
Comment 5 Dani Megert CLA 2011-07-19 02:44:10 EDT
*** Bug 111810 has been marked as a duplicate of this bug. ***
Comment 6 Dani Megert CLA 2011-07-19 02:45:30 EDT
Friedrich, is there some chance that you might contribute this?
Comment 7 Friedrich Steimann CLA 2011-07-19 03:55:06 EDT
Not currently, unfortunately. Hannes had looked into it when he was doing his thesis work, and the hurdles were too high, then.

I'd be happy to provide you with the sources, though (Adam Kiezun looked into them at that time and said they were OK), perhaps it still works?

What is the general Eclipse development policy regarding refactorings, anyway? Are there any resources attached to improving the current state of implementations?

I am only asking since we are still working on refactorings for Eclipse (see, eg, http://doi.acm.org/10.1145/1985793.1985854), but implementing correct refactorings remains difficult. One technical problem is the API -- necessary program analyses are often difficult to implement using the Java Model and Search function.
Comment 8 Dani Megert CLA 2011-07-19 06:21:17 EDT
(In reply to comment #7)
> Not currently, unfortunately. Hannes had looked into it when he was doing his
> thesis work, and the hurdles were too high, then.
> 
> I'd be happy to provide you with the sources, though (Adam Kiezun looked into
> them at that time and said they were OK), perhaps it still works?
> 
> What is the general Eclipse development policy regarding refactorings, anyway?
> Are there any resources attached to improving the current state of
> implementations?
Yes, if we already own it. If a new refactoring gets contributed we prefer contributors who are also willing own/maintain the code later and not just throw it over the fence. In such cases we would also offer help to some extent.