Instantiating Objects within Abstract Class or Concrete Class?

I have an abstract class with several member classes in it in addition to the abstract methods

Code:

---

public abstract class AbstractClass{
  protected ClassA classA;
  protected ClassB classB;
  ...
  public abstract void method1( ArgClass arg, ... );
  public abstract void method2( ArgClass arg, ... );
  ...
  public AbstractClass() {
      class A = new ClassA();  // not sure whether I should instantiate these members here
      class B = new ClassB();  // or if I should instantiate them in a derived (concrete) class.
  }
}

public class ConcreteClass extends AbstractClass{
  public ConcreteClass() {
      class A = new ClassA();  // not sure whether I should instantiate these members here
      class B = new ClassB();  // or if I should instantiate them in a superclass (abstract)
  }
  public void method1( argument )
  {
    ... method2 definition
  }
  public void method1( argument )
  {
    ... method2 definition
  }
}

---

Can anyone help me with this seemingly simple issue.

Thanks,

EVAC

if you only use the objects in the abstract class than I would instantiate them there. If you need the concrete class to instantiate them but you want to use them in the abstract class also then do this...

Code:

---

public abstract class AbstractClass{
  ...
  public abstract void method1( ArgClass arg, ... );
  public abstract void method2( ArgClass arg, ... );
  public abstract ClassA getClassA();
  public abstract ClassB getClassB():
  ...
  public void someNonAbstractMethod(){
    getClassA().doWork();
    ...
    getClassB().doWork();
    ...
}

public class ConcreteClass extends AbstractClass{
  ClassA ca;
  ClassB cb;
  public ConcreteClass(){
    ca = new ClassA();
    cb = new ClassB();
}
  public ClassA getClassA(){
    return ca;
  }
  public ClassB getClassB(){
    return cb;
  }
  public void method1( argument )
  {
    ... method2 definition
  }
  public void method1( argument )
  {
    ... method2 definition
  }
}

---

It really all depends on where you need to use the classes. If the Abstract class uses them then either use the method above or instantiate them in the abstract class. If you declare them in the abstract class you should not instantiate them in the concrete class!!

Thanks Joe,

I'm going to have to take a hard look at your response. I think when you say "use them [the instantiated objects] in the abstract class" you mean I have instantiated a concrete class object and assigned it to a reference of the abstract class. I'll get back to you later if I have more question.

Thanks a Million,

EVAC

Sorry, my response was really confusing. lol

But mainly it was that, if you declare an object in a abstract class you should not instantiate them in the concrete class (sub class).

Remember an abstract class with "only" abstract methods is pretty much an ugly interface... :) Usually an abstract class will provide some base functionality and leave part of it up to the derived class. Look at the Template design pattern to see what I mean.

http://www.fluffycat.com/java-design-patterns/Template/

Hey... that's a really good website. It explains very (extremely) well the different design patterns by using practical examples. Are there any more similar websites? Oh, never mind, I just ran across the Portland Pattern Repository link on the page. That'll keep me busy. But that is a good point in that eventhough we have an abstract class it should provide some implementation (which can be overidden) instead of having nothing but abstract functions. Many Java textbooks give this impression when they explain the basic functionality of abstract classes.

EVAC

The real benefit of using abstract classes is that the extended classes can implement the abstract methods in their own way and make them accessible through a pointer to the abstract class. This is also the case for interfaces, but then you will not be able to supply any superclass methods.

Consider the case when you have an animation that uses several classes for rendering (squares, polynoms, lines, images...), and all these class instances are to be rendered on a JPanel extension. The code for handling this would be very messy if this panel should have an arraylist of Objects, doing instanceof tesing for each object during its paintComponent -processing.

A suitable abstract class could then be:

Code:

---

public abstract class VisibleObject {
  protected Point currentPos=null;

  public abstract void draw(Graphics g);

  public VisibleObject (Point currentPos) {
    this.currentPos=currentPos;
  }
}

---

By making all the visible classes descendants of the abstract VisibleObject
the panel extension could then have an arrayList of VisibleObject and process it like:

Code:

---

ArrayList voList=new ArrayList();
.
.
public void addVisibleObject(VisibleObject vo) {
  voList.add(vo);
  repaint();
}
public void paintComponent(Graphics g) {
  for (int i=0; i<voList.size(); i++) {
    ((VisibleObject)voList.get(i)).draw(g);
  }
}

---

Like I said, this can be achieved using an interface too, but I bet a dime that, in this scenario, the need for superclass methods will appear quickly...

I think this sums up my original question in a more compact and comprehendable form. When using abstract classes with protected members so that those members are accessible in the subclass, should one instantiate those members in the Constructer of the abstract (base) class or the Constructor of the concrete (derived) class. It seems that if you do it in both, that it really shouldn't matter, only that it will instantiate the members twice or more depending on how many superclass Constructors are called.

EVAC

You should not instantiate the protected superclass members in the subclasses unless there is a good reason to do the extra work (doing something that the superclass already handles for you).
However, I beleive that in a deep the class hierchy, if you end up overwriting the value of a protected member defined at some low class level repeatedly up through the descendants' constructors, then you should reconsider the analysis and design for that member (and probably for some of the classes too).

With this approach you are sure that the instantiation happends only once:

Code:

---

// An abstract class with a member like:

Polygon outline=null;

// and an abstract method defined like:

public abstract Polygon getOutline();

// and a default constructor like:

public AbstrClass () {
  this.outLine=getOutline();
}

---