I want to have an interface that returns different type of interfaces based on what is requested. To explain the issue I used a car example.
public interface ICar{
public ? getCar(String carName);
}
public class Car implements ICar{
public ? getCar(String name){
// Depending on the car name return ICommonCar or IBMW or IAudi...
return new BMW();
Or return new Audi();
...
}
And different users classes will get the ICar interface where they can invoke getCar(carName). Eg.
First class can request:
IBMW mycar = ICar.getCar(BMW);
Second class requests:
IAudi myCar = ICar.getCar(Audi);
I was thinking to use Java Generics to solve the issue but I think there is something that I am missing. My first approach was to something like below:
public class Car<T>{
public T getCar(String carName){
public T newCar;
if(carName.equals(BMW)){
T = new BMW(); // Shall I cast it T?
}else if(carName.equals(Audi))
T = new Audi();
}...
return T;
}
The code above in using Generics doesn't compile but I just put it to show the intention that I want to achieve. The problem seems simple but I found using Generics to be tricky. Is it possible to solve the above problem using Generics? Thank you in advance!
EDIT:
Please consider that in the example I did not meant to imply that IBMW & IAudi as child interfaces of the ICar interface but rather I was thinking to have the ICar as an entry point where different types of checks will be performed on the request & on the class initiating request. Then implementation of unrelated interfaces like IBMW & IAudi which are child interfaces of ICommonCar would be returned. I should have used a different example.
In order to achieve something like you describe, you are going to make the client do as much work as he would do by performing his own cast. I'm changing your class names to make more sense. To whit:
ICarFactory cf = new CarFactory();
// normal way
IAudi audi = ( IAudi )cf.getCar( "audi" );
// your way
IBMW bmw = cf.getCar( "bmw", IBMW.class );
The difference being that in the former case, you need only return ICar from getCar, whereas in the latter, you need to make the method getCar generic in a variable < T extends ICar > and then cast to T before returning your car. That may not even be legal in all cases.
Meantime you get zero help from the compiler regarding types in either case.
It looks like you are looking for a factory pattern. I try to avoid using strings to specify what I want the factory to make - enums are a good fit.
interface Car {
}
class BMW implements Car {
}
class Audi implements Car {
}
interface MakesCars {
Car makeCar() throws InstantiationException, IllegalAccessException;
}
enum Cars implements MakesCars {
BMW(BMW.class),
Audi(Audi.class);
Class<? extends Car> c;
Cars(Class<? extends Car> c) {
}
#Override
public Car makeCar() throws InstantiationException, IllegalAccessException {
return c.newInstance();
}
}
public void test() throws InstantiationException, IllegalAccessException {
Car bmw = Cars.BMW.makeCar();
}
The Java 8 version of the enum is a little more elegant.
enum Cars implements MakesCars {
BMW(BMW::new),
Audi(Audi::new);
final Supplier<Car> supplier;
Cars(Supplier<Car> supplier) {
this.supplier = supplier;
}
#Override
public Car makeCar() {
return supplier.get();
}
}
Related
Lets suppose we have 10 types of Car:Bmw, Renault etc. And we have Repo. So there are two ways for developing API of Repo:
The first way:
class Repo{
public <T extends Car> T getCarByType(Class<T> clazz){..}
}
The second way:
class Repo{
public Bmw getBmw(){..}
public Reno getRenault(){..}
...
}
Firstly I thought that I should follow the first way as it lets write less code and -> it is better for supporting. And besides, I thought that if I have 20 types of car the first way is obvious advantage (less code).
However, as the number of car is growing - you start to forget what car you have. When you follow the second way - you have clear API of the repo and the types.
So,could anyone explain when to use which method?
The first way will produce less duplicate code. But if you want to model the types of cars, you could use an enum
enum Cars {
BMW(Bmw.class),
RENO(Reno.class)
;
Class<? extends Car> type;
Cars(Class<? extends Car> type){
this.type = type;
}
Class<? extends Car> getType() {
return type;
}
}
And the access the car using this enum
public <T extends Car> T getCarByType(Cars car){
Class<T> type = car.getType();
...
}
First if your cars aren't so different you may use only one class Car that will have a type property which will allow you to make difference between cars type, however if you wan't to continue with your solution I think you may use both of the ways, you can create a generic Repo which will have all code used to get Data then you can make on top of it a specific layer that will expose methods to retrieve each car by it's type
Generic Repo
class Repo{
public <T extends Car> T getCarByType(Class<T> clazz){..}
}
RepoFacade
class RepoFacade{
public Bmw getBmw(){
Repo<Bmw> = new Repo<>();
return repo.getCarByType(BMW.class);
}
public Reno getReno(){..}
}
I would go with something simpler. No polymorphism based on brand, because it is just a label, it does not add any behavior:
public class Car {
public enum Make { BMW, ... };
public Make make;
public Color color;
public int year;
// Cars have other properties, I suppose
}
public class Repo {
private List<Car> cars = new ArrayList<Car>;
// This could also return a list of all cars of that model,
// because there is no reason to have exactly one of each make.
#Nullable
public Car findByMake(Car.Make make) {
for (Car car : cars) {
if (car.make == make) {
return car;
}
}
return null;
}
}
Providing I have an interface like:
public interface Replicateable<T> {
void replicate(T entity);
}
another one extending it
// here Identifiable is just another interface
public interface Entity extends Identifiable, Replicateable<Entity> {
//some declarations here
}
and in the end of this chain I'd like to have something like
public class ConcreteEntity implements Entity {
#Override
public void replicate(ConcreteEntity entity) {
// here goes some logic turning current entity
// to a replica of a passed one
}
}
Any ways to achieve that besides making the Entity interface generic? I'd rather avoid that.
So for I tried to
1. Leave as it is, which doesn't work since replicate() implementation requires exactly an Entity parameter, and not a concrete one
2. Add Replicateable right to entity class
public class ConcreteEntity implements Entity, Replicateable<ConcreteEntity> { ... }
which gave me 'Replicateable' cannot be inherited with different type arguments: 'Entity' and 'ConcreteEntity' (and it seems understandable why it didn't work).
3. Override replicate() in the Entity interface (with no results either, not even sure if it's meaningful at all).
4. Make a replicate() generic instead of Replicateable itself (not sure how to make it right)
Would appreciate any suggestions how to make it right.
Entity would have to be generic for the compiler to know which type can be passed to replicate:
Entity<ConcreteEntity> e = ...;
e.replicate(...); // <-- aha. Can only pass a ConcreteEntity (or a subtype of)
It might make more sense to use polymorphism:
interface Replicateable<T> {
T replicate();
}
interface Entity extends Identifiable, Replicateable<Entity> {
// Entity replicate();
}
Which could be implemented using copy constructors:
class ConcreteEntity implements Entity {
public ConcreteEntity(ConcreteEntity other) {...}
#Override
public ConcreteEntity replicate() { // <-- uses return type overriding
return new ConcreteEntity(this);
}
}
Entity e1 = new ConcreteEntity();
Entity copy1 = e1.replicate();
ConcreteEntity e2 = new ConcreteEntity();
ConcreteEntity copy2 = e2.replicate();
What you are trying to do requires making Entity generic due to the way Generics work in Java. It is a strange pattern but it comes up from time to time.
public interface Entity<T extends Entity> extends Identifiable, Replicateable<T> {
//some declarations here
}
public class ConcreteEntity implements Entity<ConcreteEntity> {
#Override
public void replicate(ConcreteEntity entity) {
// here goes some logic turning current entity
// to a replica of a passed one
}
}
However there may be a different way of designing your interfaces so that this is not required. What are you trying to do with replicate?
Your comments make it sound like you would do the following.
SomeEntity a = new SomeEntity();
// set values on a
SomeEntity b = new SomeEntity();
b.replicate(a);
IF that is what you are trying to do there several other ways to achieve that end result
SomeEntity a = new SomeEntity();
// set values on a
SomeEntity b = new SomeEntity(a); // copy constructor
SomeEntity c = a.clone(); // Clone operation
See the PrototypePattern for a more in depth overview of creating objects based upon the values of other objects.
It's not possible without making Entity also generic. You should use F-bounded types:
F-bounded quantification or recursively bounded quantification, introduced in 1989, allows for more precise typing of functions that are applied on recursive types. A recursive type is one that includes a function that uses it as a type for some argument or its return value.
In Java, F-bounded types can be expressed with a generic interface, which in your case would be as follows:
public interface Replicateable<T extends Replicateable<T>> {
void replicate(T entity);
}
public interface Entity<T extends Entity<T>> extends Replicateable<T> {
//some declarations here
}
public class ConcreteEntity implements Entity<ConcreteEntity> {
#Override
public void replicate(ConcreteEntity entity) {
// here goes some logic turning current entity
// to a replica of a passed one
}
}
Thanks everyone for your answers, they were insightful and helped me to come up with a suitable solution.
I ended up redefining replicateable interface to
public interface Replicateable<T> {
//note the boolean return type here
boolean replicate(T entity);
}
leaving it as it was in the entity interface, without making it generic
public interface Entity extends Identifiable, Replicateable<Entity> {
//some declarations here
}
which allows to not to rewrite tons of code to get rid of raw-types and doesn't break entity's generic method implementations (why it's being broken upon making Entity itself is another question out of the scope of this one.)
An the method implementation looks like
#Override
public boolean replicate(Entity entity) {
if (entity.getClass() == ConcreteEntity.class) {
// replicating logic
return true;
}
return false;
}
This method doesn't create a new object by turns an existing one to a replica of one that was passed to the method, that was the point (I should've mentioned it, my apologies for that). Otherwise I'd use Cloneable, as per some of your suggestions.
So, to sum up and generalize - it's either make Entity generic or to use Cloneable (both not my cases) or to invent a workaround, which I did. Thanks again everyone.
I'm building a sort of framework to avoid repetition of code, and at a certain point I need to convert a list of object Foo into a list of object Bar.
I have database entities that extend
public class BaseEntity {...}
And presentation objects that extend
public class BaseDTO<T extends BaseEntity> {...}
so
public class Foo extends BaseEntity {...}
and
public class Bar extends BaseDTO<A extends BaseEntity> {
public Bar(Foo entity, Locale l) {
...
}
}
Now to convert a list of Foo into a list of Bar is easy using streams
public abstract ClassThatUsesFooAndBar() {
public List<Bar> convertFooToBar(List<Foo> list) {
return list.stream().map(f -> new Bar(f, locale)).collect(...);
}
}
But, and here is the question, these Foo and Bar are actually generics (A and B), so the class that uses Foo and Bar actually is ClassThatUsesAandB<A extends BaseEntity, B extends BaseDTO>, so that function must be abstract too and implemented as boilerplate code with the correct A and B implementations because obviously you cannot instantiate generic types.
Is there a way to use generics/streams/lambdas to create a function that can be written once, so that the implementing classes don't need to re-implement it? The function signature would be
public List<B> convertAToB(List<A> list);
I hope I've been clear enough in what I need, if you need further explanations please ask
Thank you!
I think the simplest way is to use lambdas for the conversion.
public static <A,B> List<B> convertList(List<A> list, Function<A,B> itemConverter) {
return list.stream().map(f -> itemConverter.apply(f)).collect(...);
}
And then you can use it like this:
List<Bar> l = convertList(fooList,foo -> new Bar(foo.getBaz()));
Or if you want to, you can extract it in its own named class:
public class Foo2BarConverter implements Function<Foo,Bar> {
#Override
public Bar apply(Foo f) {
return new Bar(f.getBaz());
}
}
As an aside, given what we can do with streaming, it seems like a bit of a waste to create a new list just to have a materialised list of Bar objects. I would probably chain whatever operation I want to do with the list straight after the conversion.
The most difficult problem with your question is actually not the boilerplate or the streams, it's the generics. Trying to do new B is a bit of a mess. You can't do it directly, and any workaround isn't too clean.
For the boilerplate, however, you can do a bit better thanks to Java 8's default methods in interface. Consider the following interface:
public interface ConversionHandler<A,B> {
B constructB(A a, Locale locale);
default List<B> convertAToB(List<A> list, Locale locale) {
return list.stream().map(a -> constructB(a, locale)).collect(Collectors.toCollection(ArrayList::new));
}
}
The list conversion boilerplate is now done, all you have to do is implement the B construction in the subclass. However, this is still tricky if B is still generic.
public class ClassThatUsesAandB<A, B> implements ConversionHandler<A,B> {
#Override
public B constructB(A a, Locale locale) {
return null; //This is tricky
}
}
However, if the subclass is concrete, it's quite simple
public class ConverterClass implements ConversionHandler<String,Integer> {
#Override
public Integer constructB(String s, Locale locale) {
return s.length();
}
}
So the followup you may want to search for is a good design pattern for making the construction of generic objects as maintainable and readable as possible.
I would like to create a generic interface for those two classes but I'm not sure how to specify the generics the right way.
public class ThingA implements Thing {
public ThingA createCopy(ThingA original);
}
public class ThingB implements Thing {
public ThingB createCopy(ThingB original);
}
I tried it this.
public interface Thing<V extends Thing<V>> {
public V createCopy(V original);
}
But I'm still able to do things like this, which shouldn't be allowed.
public class ThingB implements Thing<ThingA> {
public ThingA createCopy(ThingA original);
}
There is no this key-word generics (nor for methods parameters and return values declaration) and thus you cannot do exactly what you want.
In other words the interface will permit to ensure all the methods in the class use consistent types, but not to reference the class type itself.
This is not possible. And it is not what Generics is for. Generics is for type safety, i.e. avoiding casts. If someone makes a class ThingB that implements Thing<ThingA> somehow, then great. It is perfectly type-safe. Why do you care? How does it impede what you are doing?
Are you looking for
public interface Thing<V> {
public V createCopy(V original);
}
? If not, can you explain in more detail what it means to you to "create a generic interface for two classes"?
In case you are free to use extension instead of implementation, then you could do that this way:
public interface Thing { ... }
public abstract class Copyable {
public final Copyable copy() {
Copyable clone = createCopy();
if (clone.getClass() != getClass())
throw new RuntimeException("Copy has wrong type!");
return clone;
}
protected abstract Copyable createCopy();
}
And then use it like:
public class Test extends Copyable implements Thing {
public String content = null;
#Override
public Copyable createCopy() {
Test clone = new Test();
clone.content = this.content;
return clone;
}
}
/*code somewhere*/ {
Test t1 = new Test();
t1.content = "Hello world!";
Test t2 = (Test)t1.copy();
System.out.println(t2.content);
}
One problem with this, is that Copyable is not an interface. However, this can be used without much pain, as seen in the example, but the class checking used is not supported on the language level. With other words, the createCopy abstract method is not restricted to the class it copies, and all that is up to the programmer who extends the Copyable class, or a class, which extends it.
The positive side, is that if you call the .copy() on the object, it must return an object same as itself. Instead of an exception you can return null, if you want. Then you got good or nothing.
But, to be honest, I don't really understand, why your createCopy local method has a parameter.
It could be then a static method ... altrough I cannot even imagine what would go into that code block:
static <X extends Thing> X copy(X object) { ... }
May you could combine the pratice with a static generic method and the result becomes a bit more friendly:
public interface Thing extends Cloneable {
public static <X extends Thing> X copy(X thing) {
Object clone = thing.clone();
if (clone.getClass() != getClass())
throw new RuntimeException("Copy has wrong type!");
return (X)clone;
}
}
public class ThingA implements Thing {
public Object clone() { ... }
}
/*code somewhere*/ {
ThingA a1 = new ThingA();
ThingA a2 = Thing.copy(a1);
}
Still, the cloning method is regulated by an exception instead of language restriction, but I think this is far the best solution.
i've stumbled upon a curiosity in the java inheritance, and I wanted you to ask for better ideas on that:
Assume two interfaces A and A1
Interface A1 extends A
Interface A has a method which returns a generic type.
The generic type would be like GenericType<T>.
A basic idea is now to change this generic return type from
GenericType<Object> in Interface A into
GenericType<String> in Interface A1
Well seems to be easy at first (bad things will come later on)
We declare Interface A like
public interface InterfaceA {
public GenericType<? extends Object> getAGenericType();
}
and Interface A1 like
public interface InterfaceA1 extends InterfaceA
{
#Override
public GenericType<String> getAGenericType();
}
As you see we are forced to write GenericType<? extends Object> in Interface A itself to allow overriding it with generic based "subclasses".
(In fact the generic parameter of the generictype is subclassed not the generic type itself)
Now assume the GenericType has its own method looking like:
public interface GenericType<D>
{
public void doSomethingWith( D something );
}
Now trying to instantiate A1 works great.
Rather trying to instantiate A will suck. To see why look at this "use the interface" class:
public class LookAtTheInstance
{
#SuppressWarnings("null")
public static void method()
{
InterfaceA a = null;
InterfaceA1 a1 = null;
GenericType<String> aGenericType = a1.getAGenericType();
GenericType<? extends Object> aGenericType2 = a.getAGenericType();
Object something = null;
aGenericType2.doSomethingWith( something );
}
}
You ask: "And now?"
It does not work on the last lines. In fact the parameter "something" is not even from type "Object" it is from Type "? extends Object". So you cannot pass the declared "Object" type. You can't pass anything at all.
So you end up declaring nice interfaces which, as it turns out, cannot be instantiated right.
Do you have ideas how to model such a use case, where the subclasses will have to override the return type, while the return type is a generics?
Or how would you go around such a model case?
Or am I just missing a simple point in the generic declaration and my example is possible this way?
----------- (1) edit due to answers -----------
A very good basic idea is making the interface A more abstract! I had exactly the same idea first, but... (this has to come)
Assume doing this:
We introduce a new interface AGeneric
public interface InterfaceAGeneric<T>{
public GenericType<T> getAGenericType();
}
Now we will have to extend A and A1 from this new interface:
public interface InterfaceA extends InterfaceAGeneric<Object>{}
public interface InterfaceA1 extends InterfaceAGeneric<String>{}
That works fine, althought it breaks the path of the original inheritance.
If we want A1 still be extendable from A, we have to change A1 to
public interface InterfaceA1 extends InterfaceA, InterfaceAGeneric<String>{}
and there a problem is again. This does not work, since we extend indirectly the same interface with different generic types. This is unfortunately not allowed.
You see the problem?
-
And to point to another circumstance:
If you cast the GenericType<? extends Object> to GenericType<Object> it obviously works.
Example:
public class LookAtTheInstance
{
public static void main( String[] args )
{
InterfaceA a = new InterfaceA()
{
#Override
public GenericType<? extends Object> getAGenericType()
{
return new GenericType<Object>()
{
#Override
public void doSomethingWith( Object something )
{
System.out.println( something );
}
};
}
};
;
#SuppressWarnings("unchecked")
GenericType<Object> aGenericType2 = (GenericType<Object>) a.getAGenericType();
Object something = "test";
aGenericType2.doSomethingWith( something );
}
}
So it seems for me that the resolving of the parameter type of the method
public interface GenericType<D extends Object>
{
public void doSomethingWith( D something );
}
is wrong.
If D is unified with "? extends Object" why the parameter type is not forced to be "Object"?
Wouldnt this make more sence?
A basic idea is now to change this generic return type from GenericType in Interface A into GenericType in Interface A1
This is not possible, because Java Generics are invariant. [1]
As you found out, you cannot have an interface declaring a method that returns GenericType<Object> and in a sub interface override the method to return GenericType<String>: The latter return type is not a subtype of the former. And for good reason!
You tried to
extend indirectly the same interface with different generic types. This is unfortunately not allowed.
There is no way this could possibly work: E.g. what should be the type of E in public E set(int index, E element) in a class that implemented both List<String> and List<Object>? Your subclassed interface would have to produce a similar hybrid: The return value of getAGenericType in the sub interface would have to implement both the GenericType<String> and the GenericType<Object> interface. And as we saw, this is impossible.
The compiler does not know what you are going to do with the type parameter in GenericType (although it theoretically could find out, it doesn't). If you had a variable of type GenericType<String> and assigned a GenericType<Object> to it, you may very well end up putting a Long instance where a String is expected, and get a ClassCastException where you won't expect one.
In the doSomethingWith method of your variable GenericType<? extends Object> aGenericType2 you can pass one thing: null. null is the only object reference that has a subtype of ? extends Object. The lower bound type of ? extends Object is the null type, which cannot be expressed in Java, and only implicitly exists as the type of the null reference.
[1] http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Java
I don't know if this is what you are expecting, but you can declare your interface something like:
public interface Interface <K extends Object> { ... }
While your class might look like:
public class InterfaceImpl implements Interface<String> { ... }
#Override annotation:
When overriding a method, you might
want to use the #Override annotation
that instructs the compiler that you
intend to override a method in the
superclass. If, for some reason, the
compiler detects that the method does
not exist in one of the superclasses,
it will generate an error.
With this annotation you cannot change return type of function.
If you want to override return type, just make interface A more abstract, add generic to this interface:
public interface InterfaceA<T> {
public GenericType<T> getAGenericType();
}
Sample about overriding a generic method in a generic class.
The trouble is that InterfaceA doesn't know what type it's holding. If you get InterfaceA to take a generic argument then you could do this:
public interface InterfaceA<T>
{
public GenericType<T> getAGenericType();
}
public interface InterfaceA1 extends InterfaceA<String>
{
#Override
public GenericType<String> getAGenericType();
}
public class LookAtTheInstance
{
#SuppressWarnings("null")
public static void method()
{
InterfaceA<String> a = null;
InterfaceA1 a1 = null;
GenericType<String> aGenericType = a1.getAGenericType();
GenericType<String> aGenericType2 = a.getAGenericType();
String something = null;
aGenericType2.doSomethingWith( something );
}
}
I'm several years late to the party, but I found this page while searching for a related question and none of the answers really hit on the central issue, which I think is worth clarifying. Let's look at a slightly-more-fleshed-out example:
interface GenericType<D> {
D getAValue();
void doSomethingWith(D value);
}
class StringType implements GenericType<String> {
#Override
public String getAValue() {
return "Hello World";
}
#Override
public void doSomethingWith(final String value) {
System.out.println(value.length());
}
}
interface InterfaceA {
GenericType<? extends Object> getAGenericType();
}
interface InterfaceA1 extends InterfaceA {
#Override
GenericType<String> getAGenericType();
}
class AnActualA1 implements InterfaceA1 {
#Override
public GenericType<String> getAGenericType() {
return new StringType();
}
}
class LookAtTheInstance {
public static void method() {
InterfaceA1 a1 = new AnActualA1();
// 'g1' is a StringType, which implements GenericType<String>; yay!
GenericType<String> g1 = a1.getAGenericType();
// Everything here is fine.
String value = g1.getAValue();
g1.doSomethingWith("Hello World");
// But if we upcast to InterfaceA???
InterfaceA a = (InterfaceA) a1;
// Note: a.getAGenericType() still returns a new StringType instance,
// which is-a GenericType<? extends Object>.
GenricType<? extends Object> g = a.getAGenericType();
// StringType.getAValue() returns a String, which is-an Object; yay!
Object object = g.getAValue();
// StringType.doSomethingWith() method requires a String as the parameter,
// so it is ILLEGAL for us to pass it anything that cannot be cast to a
// String. Java (correctly) prevents you from doing so.
g.doSomethingWith(new Object()); // Compiler error!
}
}
Conceptually, GenericType is NOT a GenericType, since a GenericType can only doSomethingWith() Strings, while a GenericType needs to be able to doSomethingWith() any object. GenericType is a compromise which the compiler allows you to use as a "base class" for any GenericType where D is-an Object, but only allows you to use a reference of that type to call methods that are type-safe for any possible runtime value of '?' (such as getAValue(), whose return value can always be safely cast to an Object since D is-an Object regardless of runtime type).
It's hard to tell what (if anything) the original poster was actually trying to model with this code, and in particular how much of the generic-ness of GenericType was really needed, but perhaps the inheritance should have gone the other way around?
/**
* I can do something with instances of one particular type and one particular
* type only.
*/
interface GenericType<D> {
void doSomethingWith(D value);
}
/**
* I can do something with instances of any type: I am-a GenericType<String>
* because I can totally do something with a String (or any other kind of
* Object).
*/
interface NonGenericType extends GenericType<Object>, GenericType<String> {
#Override
void doSomethingWith(Object value);
}
interface StringHandlerFactory { // nee InterfaceA1
GenericType<String> getAGenericType();
}
/**
* I extend StringHandlerFactory by returning a NonGenericType (which is-a
* GenericType<String>, satisfying the interface contract, but also so much
* more).
*/
interface ObjectHandlerFactory extends StringHandlerFactory { // nee InterfaceA
#Override
NonGenericType getAGenericType();
}
The downside being that there's no good way to express to the java compiler that NonGenericType extends GenericType, even though conceptually it could in this case, since GenericType never uses D as a return value. You have to manually specify each GenericType that you want it to extend. :(
So you end up declaring nice interfaces which, as it turns out, cannot be instantiated right.
I think that the purpose of InterfaceA is not to be instantiated at all, because one of its dependable classes are generic. That's what you meant declaring:
public GenericType<? extends Object> getAGenericType()