POJOs, generics and extending them

Question

I have a POJO that returns some value, but now that value could be of a different type:

public class ContainerA {
    String value;
    public ContainerA(String value) {
       this.value = value;
    }
    public String getValue() {
       return value;
    }
    //some more methods
}

So I wanted to just replace it with this other one, but the refactoring effort would be just too great:

public class ContainerA<T> {
    T value;
    public ContainerA(T value) {
       this.value = value;
    }
    public T getValue() {
       return value;
    }
    //some more methods
}

And to avoid that large refactoring I was thinking that I could have something like this:

public interface Container<T> {
    public T getValue() {
    //some more methods
}

public class ContainerA implements Container<String> {
    String value;
    public ContainerA(String value) {
       this.value = value;
    }
    public String getValue() {
       return value;
    }
    //implementation of those other methods
}

But since most of those POJO classes will look pretty much the same and there are a bunch of other methods, so I was wondering why this would be problematic:

public class Container<T> {
    T value;
    public Container(T value) {
        this.value = value;
    }
    public T getValue() {
        return value;
    }
    //some other methods
}

public class ContainerA extends Container<String> {
    public ContainerA(String value) {
       super(value);
    }
}

Again, the idea is to add generics support and avoid the large refactor. Is there a better approach? is any of the above ok? why?

There is no problem with this; "I've never seen a solution like that" perhaps because it's often as easy to use `Container` directly as to define `ContainerA`. — Andy Turner, Apr 04 '18 at 14:30
The problem comes with the refactor... If I just do that I would have to replace about 2000 of those instances. — CCC, Apr 04 '18 at 14:32
That's simply a question of tooling, not the correctness of the approach. Note that there is nothing wrong with declaring `ContainerA`; indeed, it can be better if you have `Container`s which contain semantically-different strings. — Andy Turner, Apr 04 '18 at 14:33
Your last solution (`class ContainerA extends Container`) is a good one. It’s what I would do. I applaud you for placing high importance on backward compatibility and API stability. — VGR, Apr 04 '18 at 16:14

score 1 · Answer 1 · answered Apr 05 '18 at 10:57

This option:

public class ContainerA extends Container<String> {
    public ContainerA(String value) {
       super(value);
    }
}

Is a perfectly reasonable step in refactoring, but it's not the end goal as you don't want two ways to achieve the same thing, particularly as they are not 100% compatible.

e.g. if you have a method like so: method(Container<String> container) then that will accept a ContainerA, but the reverse is not true; method(ContainerA container) won't accept a Container<String>

So what you can do for now is you can mark the old type as deprecated and take your time completing the refactor, safe in the knowledge that, as the old code descends from the new code it is perfectly safe to use and that people will know which of the two implementations they should be using in new code:

/**
 * @deprecated Use {@link Container<String>}
 */
@Deprecated
public final class ContainerA extends Container<String> {

score 0 · Answer 2 · answered Apr 04 '18 at 14:34

I would recommend you to use an generic interface so it can be implemented as per your need.Also interfaces are good when you don't have an initial idea of your would be implementations.Another pro of using interface is you can later add methods which is useful for continuous development.

public interface MyInterface<T> {
   public void method(T object);
}

public class Car implements MyInterface<Engine> {
    public void method(Engine object) {
    }
}

Klaymen · Answer 3 · 2018-04-04T16:10:31.747

It really depends on your future plans with Container:

If you don't plan on reusing and extending the methods and properties of Container there's really no use inheriting from it*. Use an interface if you want polymorphism (you might want to keep the simple generics if you don't). An interface will provide you with capabilities similar to the ones you get from inheritance (such as polymorphism) without asking you to extend anything.

Furthermore, if I'm working in your team, when I see ContainerA, I'm not sure why to use it when my project already contains Container<>.

Inheritance is mainly used for two reasons: Polymorphism and Code reuse.
see link for discussion, although it refers C++.

POJOs, generics and extending them

3 Answers3