如何修复客户端代码，以便通过组合获得代码重用？

Question

Here's the problem. I have one abstract base class Editor . I also have two subclasses GraphEditor and a TreeMapEditor . The implementation of TreeMapEditor basically wraps a GraphEditor and for now basically forwards all requests to the underlying GraphEditor .

class TreeMapEditor extends Editor{
 private final Editor wrappedEditor = createWrappedEditor();

 private createWrappedEditor(){
   return new GraphEditor();
 }

 public void doA(){  //This is the abstract class defined in Editor.
   wrappedEditor.doA();
 }

 public void doB(){  //This is the abstract class defined in Editor.
   wrappedEditor.doB();
 }

 public Editor getWrappeEditor(){
  return this.wrappedEditor ;
 }

}

Now my idea is to reuse the code for GraphEditor without really subclassing GraphEditor (Hence the composition) . But the client code is written to the implementation of GraphEditor and not merely Editor . How can I refactor this code here? I want all the calls belonging to Editor to go through the TreeMapEditor and only more specific calls to go through the GraphEditor .

The client code looks like this now:

public clientCode(Editor editor){
  GraphEditor graphEditor = (GraphEditor)editor;

  graphEditor .doA(); //This method belongs to Editor()
  graphEditor .doB(); //This method belongs to Editor()


  graphEditor .doC(); //This method belongs to GraphEditor() only and not to TreeMapEditor
  graphEditor .doD();//This method belongs to GraphEditor() only and not to TreeMapEditor

} 

}

Answer 1

You might want to look for a concept between GraphEditor and your other two; is there a construct within what you're doing that could be represented by a class that extends GraphEditor but is not a full-functioned GraphEditor or TreeMapEditor? IF there is, common code might go in it.

But I would be careful to keep to implementing a representation of something in your problem space, rather than just putting methods into classes in an inheritance hierarchy because that's where you need them. That bottom-up style of creating classes can lead to poor design, hard to understand until someone says "Oh, he just wanted this method available here.".