A Collection of an Abstract Class (or something like that…)

Question

The Scenario

I\'m making a program in Java that involves cars.

NOTE: I\'ve simplified this scenario (to the best of my ability) to make

Answer 1

You have to say it someplace - there's no getting around that. If you have many more kinds of Cars, you'll have to specify those attributes somewhere.

I don't see where subclassing helps you much, unless you can identify families of cars that are similar (e.g. sports cars, mini-vans, etc.).

One way to centralize all those attributes in one place is to instantiate Car using a factory method (it has a nice symmetry with manufacturing of physical cars, too).

Make the Car constructor private; have an enumeration of CarType that is the key into a Map of attributes for each type; pass in the CarType and get back a Car, fully initialized.

public class Car {

   private static final Map<CarType, Map<String, Object>> DEFAULT_ATTRIBUTES;

   private Map<String, Object> attributes; 

   static {
      DEFAULT_ATTRIBUTES = new HashMap<CarType, Map<String, Object>>();
      // Insert values here
   }

   private Car(Map<String, Object> initializers) {  
      this.attributes = new HashMap<String, Object>(initializers);
   }

   public static Car create(CarType type) {
      return new Car(DEFAULT_ATTRIBUTES.get(type));
   }
}

Answer 2

I'm looking for a solution that allows a single Cars class to contain every Car object. I don't want different collections (like Corvettes, Clunkers). I'm also looking for a solution that allows the creation of Car objects based on the attributes of an individual car kind... as previously mentioned, creating a new Car of kind Corvette would result in a speed of 0.9. There should be no other way to specify a car's speed.

Oh boy oh boy there are so many ways to deal with this that we could go on all day! I will do a brain dump, and hopefully it will not be too much for you to deal with.

---

solution 1: use Strategy.

A strategy is basically a way to separate heavy substitutable logic from another class. In this case, every car needs to be created differently. A strategy is PERFECT for this.

Sorry if I mix in some C# by accident... been a long time since I javaed.

public interface CarCreationStrategy{
   void BuildCar(Car theCar);
}

public class CorvetteStrategy implements CarCreationStrategy{
   public void BuildCar(Car theCar){
      theCar.Type = "Corvette";
      theCar.Speed = 0.9;
      theCar.Comments = "Speedster!";
   }
}

public class ToyotaStrategy implements CarCreationStrategy{
   public void BuildCar(Car theCar){
      theCar.Type = "Toyota";
      theCar.Speed = "0.5";
      theCar.Comments = "Never dies, even if you drop it from the top of a building";
   }
}

Now, you can pass a strategy in with your car constructor.

public class Car{
   // Variables ...

   public Car(CarCreationStrategy strategy, int year){
      strategy.BuildCar(this); // Implements your properties here.
      this.year = year;
   }
}

So, what you get now is so awesome!

List<Car> cars = new List<Car>();
cars.Add(new Car(new CorvetteStrategy(),1999));
cars.Add(new Car(new ToyotaStrategy(),2011);

And this will do exactly what you want.

However, you get a coupling between the strategy and the Car.

---

solution 2: use Factory.

Factory is an okay solution for this as well, and is probably easier. What you do is have a CarFactory, with multiple factory methods for creating each type of car.

public class CarFactory{
   public static Car BuildCorvette(int year){
      Car car = new Car(year);
      car.Type = "Corvette;
      car.Speed = 0.9";
      return car;
   }

   public static Car BuildToyota(int year){
      Car car = new Car(year);
      car.Type = "Toyota;
      car.Speed = 0.5";
      return car;
   }
}

Usage:

List<Car> cars = new List<Car>();
cars.Add(CarFactory.BuildCorvette(1999));
cars.Add(CarFactory.BuildToyota(2011));

So the good thing about this is you don't have to worry about instantiating Car now. its all handled by CarFactory, decoupling your "instantiation logic" from your code. However, you still need to know which car you want to build and call that method accordingly, which is still a small coupling.

---

solution 3: strategy factory!

So, if we wanted to get rid of that last bit of couplings, lets combine the two together!

public class CarFactory{
   public static Car BuildCar(CarCreationStrategy strategy, int year){
      Car car = new Car(year);
      strategy.BuildCar(car);
      return car;
   }
}

List<Car> cars = new List<Car>();
cars.Add(CarFactory.BuildCar(new CorvetteStrategy(),1999));
cars.Add(CarFactory.BuildCar(new ToyotaStrategy(),2011);

Now you have a Strategy for building cars, a Factory that builds them for you, and a Car with no extra couplings from your original. Wonderful, isn't it?

If you have worked with Swing, you will notice that this is how they handle a few things like the Layouts (GridBagLayout, GridLayout are all strategies). There's also a BorderFactory as well.

---

Improvement

Abstract Strategy

public interface CarCreationStrategy{
   void BuildCar(Car theCar);
}

public class AbstractStrategy:CarCreationStrategy{
   public string Type;
   public double Speed;
   public string Comments;

   public void BuildCar(Car theCar){
       theCar.Type = this.Type;
       theCar.Speed = this.Speed;
       theCar.Comments = this.Comments;
   }
}

public class CorvetteStrategy extends AbstractStrategy{
   public CorvetteStrategy(){
      this.Type = "Corvette";
      this.Speed = 0.9;
      this.Comments = "Speedster!";
   }
}

public class ToyotaStrategy extends AbstractStrategy{
   public ToyotaStrategy{
      this.Type = "Toyota";
      this.Speed = "0.5";
      this.Comments = "Never dies, even if you drop it from the top of a building";
   }
}

Using this gives you the flexibility to create AbstractStrategies on the fly (say, pulling car properties from a data store).

Answer 3

I could work with sub classes, that is, have an abstract Car class that's extended by Corvette and Clunker, but then I have the problem of using a Cars object (because I can't make a collection of something that can't be instantiated).

It depends on how you use and how you create your Car object, but anyway, creating your object should always been easy, I'd imaging using a factory will do.

You will need to extend your Car object to have fields you wanted in general, and in concrete class, you can assign them individually, so instead of

Car car = new Car(1998, Corvette);

you do

Car car = new Corvette(1998);

and in your Corvette class:

public Corvette(int year)
{
    speed = 0.9;
}

But keep in mind always make sure Car is a Corvette, and Corvette is a Car.

Answer 4

I used the method described in Daryl Teo's answer, but I modified it a little bit to include an enum (since there are a finite number of individual cars). Because his answer was so instrumental to the development of my final solution, I selected it as the best answer.

The CarCreationStrategy interface:

public interface CarCreationStrategy {
    public void buildCar(Car car);
}

enum CarTypes implements CarCreationStrategy{
    CORVETTE() {
        @Override
        public String toString() {
            return "Corvette";
        }

        public void buildCar(Car car) {
            car.setSpeed (0.9);
        }
    },
    CLUNKER() {
        @Override
        public String toString() {
            return "A piece of junk!";
        }

        public void buildCar(Car car) {
            car.setSpeed (0.1);
        }
    }
}

The Cars class:

public class Cars {
    private List<Car> cars = new List<Car>;

    public void createCar() {
        // There would be logic here to determine what kind
        // We'll make a Corvette just to demonstrate
        Car car = new Car(1998, CarTypes.CORVETTE);
        cars.add(car);
    }
}

The Car class:

public class Car {
    private int year;
    private double speed;

    public Car(int year, CarType type) {
        this.year = year;
        type.buildCar(this);  // Sets the speed based on CarType
    }

    public void setSpeed(double speed) {
        this.speed = speed;
    }
}