Instantiation of similar object over a super class deciding the sub class

Question

Hello all
First, sorry if I'm duplicating an already answered question. I didn't searched very deep.
Initial position:
I have 2 Object (A1 and A2) which share the most (about 90%) of their instance variables an the associated methods. The values of the instance variables are retrieved in the real implementation from a stream. Depending of the data of the stream, I have to instantiate either a A1 or A2 object.
A test implementation (using an int in case of the stream):
The super class A:
package aaa;
public class A
  protected int version = -1;
  protected String name = null;
  protected AE ae = null;
  protected A()
  protected A(int v)
    // Pseudo code
    if (v > 7)
      return;
    if (v % 2 == 1)
      this.version = 1;
    else
      this.version = 2;
  public final int getVersion()
    return this.version;
  public final String getName()
    return this.name;
  public final AE getAE()
    return this.ae;
}The first sub class A1:
package aaa;
public final class A1 extends A
  protected A1(int v)
    this.version = v;
    this.name = "A" + v;
    this.ae = new AE(v);
}The second subclass A2:
package aaa;
import java.util.Date;
public final class A2 extends A
  private long time = -1;
  protected A2(int v)
    this.version = v;
    this.name = "A" + v;
    this.time = new Date().getTime();
    this.ae = new AE(v);
  public final long getTime()
    return this.time;
}Another class AE:
package aaa;
public class AE
  protected int type = -1;
  protected AE(int v)
    // Pseudo code
    if (v % 2 == 1)
      this.type = 0;
    else
      this.type = 3;
  public final int getType()
    return this.type;
}To get a specific object, I use this class:
package aaa;
public final class AFactory
  public AFactory()
  public final Object createA(int p)
    A a = new A(p);
    int v = a.getVersion();
    switch (v)
    case 1:
      return new A1(v);
    case 2:
      return new A2(v);
    default:
      return null;
}And at least, a class using this objects:
import aaa.*;
public final class R
  public static void main(String[] args)
    AFactory f = new AFactory();
    Object o = null;
    for (int i = 0; i < 10; i++)
      System.out.println("===== Current Number is " + i + " =====");
      o = f.createA(i);
      if (o instanceof aaa.A)
        A a = (A) o;
        System.out.println("Class   : " + a.getClass().getName());
        System.out.println("Version : " + a.getVersion());
        System.out.println("Name    : " + a.getName());
        System.out.println("AE-Type : " + a.getAE().getType());
      if (o instanceof aaa.A2)
        A2 a = (A2) o;
        System.out.println("Time    : " + a.getTime());
      System.out.println();
Questions:
What would be a better way to encapsulate the logic into their respective objects ? Is there a way to let the super class A itself identify the type of the object and then extend from A to either A1 or A2 ?
Thanks in advance
Andreas

Answer 1

Hello jduprez
First, I would thank you very much for taking the time reviewing my problem.
Just for the record: have you considered regular serialization? If you control the software at both ends of the stream, you could rely on standard serialization mechanism to marshall the objects and unmarshall them automatically.In my case, I can't control the other site of the stream. At the end, the data comes from a FileInputStream and there aren't objects on the other site, only pur binary data.
- It seems you have one such factory class. Then you already have encapsulated the "determine class" logic, you don't need to add such logic in superclass A.I thought from an OO view, that the super class A is responsible of doing that, but that's where the problem starts. So at the end, it's better doing it in the factory class.
- A itself encapsulates the logic to load its own values from the stream.
- A1 and A2 can encapsulate the logic to load their own specific value from a stream (after the superclass' code has loaded the superclass' attributes values).
My advise would be along the lines of:
public class A {
.... // member variables
public void load(InputStream is) {
... // assign values to A's member variables
// from what is read from the stream.
public class A1 extends A {
... // A1-specific member variables
public void load(InputStream is) {
super.load(is);
// now read A1-specific values
public class AFactory {
public A createA(InputStream is) {
A instance;
switch (is.readFirstByte()) {
case A1_ID:
a = new A1();
break;
case A2_ID:
a = new A2();
break;
a.load(is);
}The example above assumes you have control over the layout of the data in the stream (here for a given A instance, the attributes defined in A are read first, then come the subclass-specific attributes.
The outcome is: you don't have to create a new A( ) to later create another instance, of a subclass.I like the idea. In the AFactory, is the "A instance;" read as "A a;" ?
Is there a way to let the super class A itself identify the type of the object and then extend from A to either A1 or A2 ?Note I initially read this question as "can an instance of a class mutate into another class", to which the answer is no (an object has one single, immutable class; it is an instance of this class, and of any superclass and superinterface, but won't change its class at runtime).Yes, I have been thinking about a way for mutating into a subclass to keep the already initialized values from the A class without copying or parsing again. But preventing an instance of an A class will be my way. So, in this aspect, Java didn't changed in the last 10 years... It's a long time ago I've used Java for some real projects.
You can, however, create an instance of another class, that copies the values off a priori A instance. Your example code was one way, another way could be to have a "copy constructor":
public class A {
public A(A model) {
this.att1 = model.att1;
this.att2 = model.att2;
public class A1 {
public A1(A model) {
super(model);
... // do whatever A1-specific business
)Still, I prefer my former solution less disturbing: I find the temporary A instance redundant and awkward.Nice to know. I prefer the first solution too.
Thank you again for the help and advices. My mind is searching sometimes for strange solutions, where the real is so close ;-)
Andreas