Problems Using an Array of Objects

Question

I have taken some time off from java and have aparently forgot something. I have a program which has one parent class "Car" with three child classes"Sedan", "Sport", "Suv" and one interface. The "Car" class contains three accessor and mutator methods, and the child classes also have three accessor and mutator methods. In my main I create an array Car[] carArray = new Car[6]; and instantiate. I can call the methods of the parent class but am unable to call the methods of the child classes. I need a little help to get me in the right direction to get these cobwebs out of my skull. Here is a sample of what I'm doing:
//from my main method
Car[] carArray = new Car[3];
carArray[0] = new Sport("Chev", "Camaro", 1995, 4500.67, 120000);
carArray[1] = new Sedan("Ford", "Taurus", 1997, 3689.55, 40000);
carArray[2] = new Suv("Honda", "Pilot", 2003, 6955.99, 67000);
for(int i = 1; i < carArray.length(); i++)
    carArray.getYear(); //getYear() is from the parent "Car" class and works just fine.
carArray[i].getValue(); //getValue() also from the parent "Car" class and works just fine.
carArray[i].getMiles(); //getMiles() from parent "Car" class and works.
carArray[i].getMake(); //getMake() is part of the child class and gives me an error: "cannot find symbol. symbol: variable getMake()
carArray[i].getModel(); //getModel() is also a part of the child classes and also cannot find symbol.
{code}
I have imported my package with my parent and child classes correctly and have tried putting them all in the same folder, so I think I have a failure in logic. Can someone help me straighten this out in my head? :) Much thanks

Answer 1

"Is it A or B"?
"Yes"
Meaning "either one."
The parent class doesn't have to be abstract as far as Java is concerned, but it seems to me you'd want it to be abstract. Will you ever be creating just a plain old Car (as opposed to a Sedan or Suv)?
You just said "doesn't work," without providing any details about what you tried or what the exact problems was, so it's impossible to offer any specific, concrete advice. Here's an example that shows one way things might fit together.
   * inteface, to define the type, with 3 methods: add(), iterator(), and contains()
  public interface List {
    boolean add(Object obj);
    Iterator iterator();
    boolean contains(Object obj);
   * abstract base class, to implement methods that don't depend on specific implementations
   * (just contains() in this case
  public abstract class AbstractList implements List {
    public boolean contains(Object obj) {
      for (Iterator iter = iterator(); iter.hasNext ();) {
        if (iter.next ().equals (obj)) {
          return true;
      return false;
   * concrete subclass
   * provides concrete methods that depend on the specific implementation
  public class ArrayList extends AbstractList {
    private Object[] elements = new Object[256];
    int size = 0;
    public boolean add(Object obj) {
      if (size == elements.length) {
        // create a larger array and copy over existing elements
      elements[size++] = obj;
      return true;
     * anonymous inner class that implements Iterator
    public Iterator iterator() {
      return new Iterator() {
        private int nextIndex = 0;
        public boolean hasNext () {
          return nextIndex < size;
        public Object next () {
          return elements[nextIndex++];
  }A few things to note:
0. The above are based on the classes of the same names in java.util, but are stripped down for simplicity. If something doesn't look right (like missing methods on List and Iterator) it was done to keep the example clean and simple.
1. We could skip either the interface or the abstract class or both, or the abstract base class could be concrete. Java doesn't care. We do what makes sense for our design.
2. Here we define an interface because we want to define a pure type with no implementation. Anybody anywhere can implement a List however they want, and as long as it meets the contract of our interface, it can be used by any code expecting a List.
3. We define the base class AbstractList because there are methods that have a reasonable default implementation that can be reused by subclasses. In this case, contains() doesn't do anything that depends on the specific implementation, so it can be defined in the base class. All the subclasses can use that implementation of contains(). Of course, any subclass is still free to override contains() to provide its own implementation if it wants.
4. An implementation of List can extend the base class, AbstractList, but it doesn't have to. It could just implement List and provide its own implementation of contains().
5. The base class is abstract because some methods don't have a default implementation that can be reused. Both add() and iterator() depend on the specifics of the implementation. They both need direct access to the internal backing store. If we had another concrete implementation, LinkedList, its backing store would be a privately defined class of Node that contains the elements and pointers to previous and next. There would be no array, and add() and iterator() would be written very differently. There's no way we could have written add() and iterator() in a way that would have worked for both backing stores.
6. All methods in an interface are public and abstract, even if you don't declare them that way.
7. A class that implements an interface or extends an abstract class must provide implementations for all the abstract methods in both, or else must be itself declared abstract.
8. When a class extends another class, it also implicitly implements all the interfaces that the parent class does.
9. A class with one or more abstract methods must be declared abstract, but any class can be declared abstract, even if it has no abstract methods.
Edited by: jverd on Mar 27, 2010 9:12 AM