Home/ Questions/Q 8705515
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T03:22:47+00:00

Say I have a class A class A { Z source; } Now, the

  • 0

Say I have a class A

class A
{
   Z source;
}

Now, the context tells me that ‘Z’ can be an instance of different classes (say, B and C) which doesn’t share any common class in their inheritance tree.

I guess the naive approach is to make ‘Z’ an Interface class, and make classes B and C implement it.

But something still doesn’t convince me because every time an instance of class A is used, I need to know the type of ‘source’. So all finishes in multiple ‘ifs’ making ‘is instanceof’ which doesn’t sound quite nice. Maybe in the future some other class implements Z, and having hardcoded ‘ifs’ of this type definitely could break something.

The escence of the problem is that I cannot resolve the issue by adding functions to Z, because the work done in each instance type of Z is different.

I hope someone can give me and advice, maybe about some useful design pattern.

Thanks

Edit: The work ‘someone’ does in some place when get some instance of A is totally different depending of the class behind the interface Z. That’s the problem, the entity that does the ‘important job’ is not Z, is someone else that wants to know who is Z.

Edit2: Maybe a concrete example would help:

class Picture
{
  Artist a;
}

interface Artist
{
}

class Human : Artist { }

class Robot : Artist {}

Now somewhere I have an instance of Picture,

Picture p = getPicture();
// Now is the moment that depending if the type of `p.a` different jobs are done
// it doesn't matter any data or logic inside Human or Robot
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The point of using an interface is to hide these different implementations; A should just know the intent or high-level purpose of the method(s).

    The work done by each implementation of Z may be different, but the method signature used to invoke that work can be the same. Class A can just call method Z.foo(), and depending on whether the implementation of Z is B or C, different code will be executed.

    The only time you need to know the real implementation type is when you need to carry out completely unrelated processing on the two different types, and they don’t share an interface. But in that case, why are they being processed by the same class A? Now, there are cases where this may make sense, such as when B and C are classes generated from XML Schemas, and you can’t modify them – but generally it indicates that the design can be improved.

    Updated now that you’ve added the Picture example. I think this confirms my point – although the implementation of getPicture() is different, the purpose and the return type are the same. In both cases, the Artist returns a Picture.

    If the caller wants to treat Robot-created and Human-created pictures in the same way, then they use the Artist interface. They do not need to distinguish between Human or Robot, because they just want a picture! The details of how the picture is created belong in the subclass, and the caller should not see these details. If the caller cares about precisely how a picture is created, then the caller should paint it, not the Robot or Human, and the design would be quite different.

    If your subclasses are performing totally unrelated tasks (and this is not what your Artist example shows!) then you might use a very vague interface such as the standard Java Runnable; in this case, the caller really has no idea what the run() method will do – it just knows how to run things that are Runnable.

    Links

    The following questions/articles suggest some alternatives to instanceof:

    And the following articles also gives example code, using an example that seems similar to yours:

    and the following articles discuss the tradeoffs of instanceof versus other approaches such as the Visitor pattern and Acyclic Visitor:

    • 0