How to use 2 classes having same methods but without a parent class?

Let's assume we have 2 classes in Java 8, ClassA and ClassB. ClassA is a dependency class which cannot be changed in any way. ClassB is kind of like a copy of ClassA but with some modifications. ClassB cannot extend ClassA, but has almost the exact same functions as ClassA.

public class ClassB {
    public ClassB(...) {}
    public int update(...) {}
    public String query(...) {}
    .
    .
    .
}

So the above structure is similarly present in ClassA as well.

Say I want to code 2 other classes ClassC that uses an instance of ClassA and ClassD that uses an instance of ClassB. ClassC and ClassD have the exact same code except for the instances of ClassA and ClassB.

public class ClassC {
    ClassA tmp;
    public ClassC(...) {
        tmp = new ClassA(...);
    }
    public void doSomething(...) {
        tmp.update(...);
        tmp.query(...);
    }
    .
    .
    .
}

public class ClassD {
    ClassB tmp;
    public ClassD(...) {
        tmp = new ClassB(...);
    }
    public void doSomething(...) {
        tmp.update(...);
        tmp.query(...);
    }
    .
    .
    .
}

From the examples, it can be seen that ClassC and ClassD have the same functions but use a different Class for tmp

Is there any way that code duplication can be avoided? Can there be some way that I can write most of the functions of ClassC and ClassD as generic code and then have ClassC and ClassD extend this generic code?

Attempts at a solution

I tried a way that basically creates an interface class in a weird way. I define a ClassE that creates abstractions of ClassA and ClassB functions and also implements all the functions of ClassC and ClassD

public abstract class ClassE {
    public ClassE(...) {}
    public abstract int update(...);
    public abstract String query(...);
    public void doSomething(...) {
        tmp.update(...);
        tmp.query(...);
    }
    .
    .
    .
}

Then basically, ClassC and ClassD extend ClassE

public class ClassC extends ClassE {
    ClassA tmp;
    public ClassC(...) {
        tmp = new ClassA(...);
    }
    public int update(...) {
        return tmp.update(...);
    }
    public String query(...) {
        return tmp.query()
    }
    .
    .
    .
}

public class ClassD extends ClassE {
    ClassB tmp;
    public ClassD(...) {
        tmp = new ClassB(...);
    }
    public int update(...) {
        return tmp.update(...);
    }
    public String query(...) {
        return tmp.query()
    }
    .
    .
    .
}

Is this the best approach to the problem? Can there be a more suitable approach?

you could create an interface, not an abstract class. A generic interface. It would be as follows:

public interface class ClassE <G> {
     int update(G attr);
     String query(G attr);
     void doSomething(G attr);
    
 }

You must create the class implements:

public class  ImplementClassA implements ClassE<ClassA> {
  public  int update(ClassA attr){
  .
  .
  .
  }
  public  String query(ClassA attr){
  .
  .
  .
  }
  public void doSomething(ClassA attr){
  .
  .
  .
  }
  
}  
public class  ImplementClassB implements ClassE<ClassB> {
  public  int update(ClassB attr){
  .
  .
  .
  }
  public  String query(ClassB attr){
  .
  .
  .
  }
  public void doSomething(ClassB attr){
  .
  .
  .
  }
  
}

In class c, interfaces could be used. In ClassC, you could use the interfaces, so you pass the instance of the type you need, be it the implementation of ClassA or ClassB

public class ClassC <G> {
    private ClassE tmp;
    public ClassC(ClassE tmp) {
        this.tmp = tmp;
    }
    public int update(G attr) {
        return tmp.update(attr);
    }
    public String query(G attr) {
        return tmp.query(attr)
    }
    .
    .
    .
}

Ex,:

ClassC<ClassA> teste = new ClassC<ClassA>(new ImplementClassA());
ClassA save = new ClassA();
teste.update(save);
ClassC<ClassB> teste2 = new ClassC<ClassB>(new ImplementClassB());
ClassB save2 = new ClassB();
teste2.update(save2);

What comes to mind here is what domain driven design calls an anti corruption layer.

Meaning: you create an abstraction around the parts you want to separate yourself from, and your code only uses your own abstractions

In your case:

• You create some interface that contains the functionality your classes C and D will want to use
• you create two implementations of that interface, one using a class A object, the other one derives its functionality from a class B object

Now your classes C and D just need to be passed the corresponding impl classes. They rely on your interface only, so you are free to refactor them as you find useful.

And note: creating your own interface is the best solution here. Your classes A and B do not have any "type" relationship. Therefore generics aren't of any help here.

I think you are probably hoping for something that is called "duck typing". That is a concept from other languages, where you say "being a duck means: it can quack() and it can walk()" for example. That would mean: when two different classes share certain methods, you can have a "view" that defines a type that has these methods, and both these classes are of that "view type". But java doesn't support that (scala does, btw), and generics don't help with that.

You can create a delegate class for ClassA and ClassB:

public class delegateAB {
  private ClassA a;
  private ClassB b;
  public delegateAB(ClassA a) {
    this.a = a;
  }
  public delegateAB(ClassB b) {
    this.b = b;
  }
  public int update(...) {
    return a!=null?a.update(...):b.update(...)
  }
  // ... other common delegated methods.
}

And then you can instantinate this class either with ClassA or ClassB, so from that point you can use the delegate class in your code, like this:

public class ClassCD {
    DelegateAB tmp;
    public ClassCD(ClassA a, ...) {
        tmp = new DelegateAB(a);
    }
    public ClassCD(ClassB b, ...) {
        tmp = new DelegateAB(b);
    }
    public void doSomething(...) {
        tmp.update(...);
        tmp.query(...);
    }
    .
    .
    .
}

It's not an exceptionally nice solution but it does the trick.