java abstraction inheritance query

[Roozbeh Pirooz]

Hi everyone! I'm new to this forum and I hope I can benefit from its collective knowledge and wisdom regarding java!!
I have done some java on and off for some time and I have started looking into both the language and OO concepts in a little more details. I thought the best way to do this is by putting my knowledge into practice by doing some java quizzes and tests. So I was wondering if I can get some assistance (as long as I am pointed out towards the right direction I'll be very happy .

I have the following class hierarchy: AbstractClass, ConcreteClassOne, ConcreteClassTwo, ConcreteClassThree. ConcreteClassOne extends the abstract class and the other two classes extends ConcreteClassOne. At the moment I am focusing on the first two classes and I have detected the following errors and my solutions are commented out

public abstract class AbstractClass {
	private String id;

	protected AbstractClass(String anId) {
		if (anId == null) {
			throw new NullPointerException("null id not allowed");
		}

		id = anId;
	}

	public String getId() {
		return id;
	}

        // this.id=id; or change param id to anId so id=anId;
	public void setId( String id) {
		id = id;
	}

        // add other==this condition also needs to override the hashCode() method 
	public boolean equals(Object other) {
		return other != null && other.getClass().equals(getClass())
				&& id.equals(((AbstractClass) other).id);
	}

	
	
	
	public String toString() {
		return "AbstractClass(" + id + ")";
	}
}

Now my main issue is in the ConcreteClassOne. Is it even possible to pass an abstract class object as a constructor's parameter since abstract classes cannot be instantiated?
If it's possible then how would you instantiate it? Or how can a useful ConcreteClassOne object be created without passing null for AbstractClass parameter in the constructor.

public class ConcreteClassOne extends AbstractClass
{
  private final AbstractClass parent;

  public ConcreteClassOne( String anId, AbstractClass aParent )
  {
    super( anId );

    parent = aParent;
  }

  public AbstractClass getParent()
  {
    return parent;
  }

  public String toString()
  {
    return "ConcreteClassOne{" + getId() + ", parent=" + parent + '}';
  }
}

[Jeff Verdegan]

Roozbeh Pirooz wrote:Is it even possible to pass an abstract class object as a constructor's parameter since abstract classes cannot be instantiated?

There's nothing special about passing anything as a parameter to a constructor. You might as well be asking, "Can we ever use an abstract class object at all, since they can't be instantiated?"

The answer is, "yes and no." No, because, as you correctly surmise, we can't instantiate an abstract class. But yes, because we can instantiate a concrete subclass. And remember, a if we have C2 extends C1, then every C2 IS-A C1, so a C2 can be provided wherever a C1 is expected.

Also keep in mind that we never pass or assign objects, only refrences. So if a constructor (or method) takes a parameter, whether that parameter is an interface or an abstract class or a concrete class, it's a reference that's getting passed, and that reference will point to an instance of a concrete class that is a subtype of whatever type the parameter is declared as (or possibly that type itself, in the case of a concrete class parameter).

The real question is, why are you passing Parent to a Child's constructor? Why do you watn CC1 to have an AC member variable? If you're just trying out different things to see how stuff works, that's fine, but to do that for real you'd want a solid design justification for it.

For example, if you had abstract class Mammal and concrete classes Dromedary and Dolphin, why would every Dromedary have to have a reference to another Dromedary or Dolphin?

[Roozbeh Pirooz]

Thanks for the reply Jeff. I think your point about why Parent is passed to a Child's constructor here was what I am being confused about and of course the fact that in this case Parent is abstract doesn’t make a difference.

Just to clarify again, I haven't written these classes it's a java quiz/puzzle and I am trying to fix the bugs and make sense of it. I understand that constructors/methods can have different kind of parameters (e.g. abstract, interface or primitive and so on) but what I meant was why it’s being done in the context of the current class hierarchy (AC, CC1, CC2 and CC3) and I asked myself the same question( Parent to Child?).

I have included the CC2, I think what’s being attempted here is to establish which Child is related to Which Parent and also other possible Children in the same family in order to determine the size of the whole family and child’s ancestors. However again AC is used in CC2 constructor as well as addChild()/removeChild() methods which I think is not a sensible design as it risks allowing the following scenarios to occur:

Instances of CC1 get added to CC2 as both Parent and Children
Instances of CC2 get added to CC2 as both Parent and Children
Instances of CC3 get added to CC2 as both Parent and Children

Does this make any sense or am I just confusing myself? Frankly I can’t think of a good reason for doing so in any design scenario.

import java.util.Set;
import java.util.HashSet;
import java.util.Iterator;

public class ConcreteClassTwo extends ConcreteClassOne
{
  private final Set children;

  public ConcreteClassTwo( String anId,  AbstractClass aParent )
  {
    super( anId, aParent );

    children = new HashSet();
  }

  public int getCount()
  {
    return children.size();
  }

  public void addChild( AbstractClass aChild )
  {
    children.add( aChild );
  }

  public void removeChild( AbstractClass aChild )
  {
    children.remove( aChild );
  }

  public Iterator getChildren()
  {
    return children.iterator();
  }

  // incorrect recursive method resulting in indefinite loop  
  public int getFamilySize()
  {
    int count = children.size();

    for ( Iterator iter = getChildren(); iter.hasNext(); )
    {
      count += ( (ConcreteClassTwo) iter.next() ).getFamilySize();
    }

    return count;
  }

  public int getAncestorCount()
  {
    int count = 0;
    AbstractClass ancestor = getParent();

    while ( ancestor != null )
    {
      count++;
      if ( ancestor instanceof ConcreteClassOne )
      {
        ancestor = ( (ConcreteClassOne) ancestor ).getParent();
      }
      else
      {
        ancestor = null;
      }
    }

    return count;
  }

}

[Winston Gutkowski]

Roozbeh Pirooz wrote:Just to clarify again, I haven't written these classes it's a java quiz/puzzle and I am trying to fix the bugs and make sense of it. I understand that constructors/methods can have different kind of parameters (e.g. abstract, interface or primitive and so on) but what I meant was why it’s being done in the context of the current class hierarchy (AC, CC1, CC2 and CC3) and I asked myself the same question( Parent to Child?).

Well, one possibility is that it's a "copy constructor" (Google it) - ie, a constructor used to create a new instance of a class that is equal() to, but NOT the same as, another.

As to the other stuff: One suggestion might be to draw some diagrams. What does this hierarchy look like? Sometimes seeing something helps you to work out if it's wrong in a way that code or words can't.

Winston

[Roozbeh Pirooz]

Winston Gutkowski wrote:
As to the other stuff: One suggestion might be to draw some diagrams. What does this hierarchy look like? Sometimes seeing something helps you to work out if it's wrong in a way that code or words can't.

Winston

Thanks Winston! I'll look into copy constructor. Regarding using a diagram, I completely agree. So I have done that, and to me it doesn't make sense to use Parent in a Child constructor/methods here as I think it creates the Parent/Child paradox which I highlighted in my previous post.

[Jeff Verdegan]

Winston Gutkowski wrote:
Well, one possibility is that it's a "copy constructor"

That's what I thought too at first, but the object maintains a reference to the passed parameter as a member variable, which is not typical of copy constructors.

[Jeff Verdegan]

Roozbeh Pirooz wrote:I think what’s being attempted here is to establish which Child is related to Which Parent and also other possible Children in the same family

It's possible that it's something like that--like it's some kind of a singly-linked list or something.

Keep in mind though that "parent" and "child" in terms of a class hierarchy is not at all the same as "parent" and "child" in a biological sense, nor in the sense of nodes in a data structure. People tend to try to take the "parent and child" and "inheritance" analogy too literally, when it really bears very little similarity to the biological case, and then get confused when things don't match what they expected.

[Roozbeh Pirooz]

Jeff Verdegan wrote:
Keep in mind though that "parent" and "child" in terms of a class hierarchy is not at all the same as "parent" and "child" in a biological sense, nor in the sense of nodes in a data structure. People tend to try to take the "parent and child" and "inheritance" analogy too literally, when it really bears very little similarity to the biological case, and then get confused when things don't match what they expected.

Thanks again Jeff. I always try not to fall into that trap. But I am still struggling to understand why Parent to Child has been used in both constructor/methods here. It's more confusing to see it's been used in the constructor as I can't think of a way to instantiate CC1 without passing null for the parent argument in its constructor and I don't see the point why that would be useful. Of course once CC1 is instantiated (even if it is with a null parent) it can be used to instantiate CC2 but again I don't see the benefit.

Any hint regarding design decision which may justify a case like this?

[Jeff Verdegan]

Roozbeh Pirooz wrote:
Thanks again Jeff. I always try not to fall into that trap. But I am still struggling to understand why Parent to Child has been used in both constructor/methods here.

For that you'd have to ask the original author of the classes. However, since these aren't "real" classes and they don't really do anything useful anyway, my guess is that it's just to demonstrate whatever point he's trying to teach--passing parameters to constructors, or something about abstraction or inheritance. It's hard to say without more context, but it looks like the author of these classes may have just chosen a rotten way of making his point.

Any hint regarding design decision which may justify a case like this?

The only one I can think of (not that I'm wasting much time thinking particularly hard about it) is a singly-linked list, if generics don't exist. But even then it would be a bad design, because it doesn't separate the data structure from the type it contains. So on further reflection, no, I cannot think of any good reason for this particular structure.