Question

This is a very simple question, and I apologize for being so noobish :/

I’m new(ish) to Java. I’ve got a game on the Market that works quite well, but the code is all rubbish. Basically, I wrote it like I was writing JavaScript. I’m trying to learn more about Object Oriented Programming. So, in my new game I’ve been creating Objects that extend from a custom class. For example (this isn’t actually what I’m doing):

public class Color{
    public final int STROKE_WIDTH = 3;

    public Color(){}
}

public class Orange extends Color{
    public int alpha = 30;

    public Orange(){
        super();
    }
}

Now, say in my game’s main thread I instantiate many Colors (Orange, Red, Purple) and I store them in an ArrayList<Color>. I iterate through this list at another point in the game, and I want to access the Color‘s alpha. My problem is, since they’re all wrapped into the superclass, I can’t just say colorObj.alpha, but I do have access to colorObj.STROKE_WIDTH. Similarly, I wouldn’t be able to access any methods in the Orange class.

There must be a way to do this, I’m just new. I don’t expect anyone to sit here and type out an explanation.. I wouldn’t want to waste your time. But if someone could just paste a link to some beginner’s tutorial or something that would help me out with this, I’d appreciate it!

Answer 1

I iterate through this list at another point in the game, and I want to access the Color’s alpha. My problem is, since they’re all wrapped into the superclass, I can’t just say colorObj.alpha

If all your actual colors have alpha, then put that in the Color class. It should contain the attributes and behaviors that are common to all colors.

Side note: one of the tentants of object oriented programming is enscapsulation. Public data members expose the internal representation of your class. Typically you hide that representation behind accessor methods, such as:

class Color {
   private int alpha;
   public int getAlpha() { return alpha; }
}

Now nobody knows your representation; nobody can change alpha to a value that doesn’t make sense for a Color, you could make it read-only or write-only, you could even change it to a computed value and none of the clients who use it are affected.

In fact, a “best practice” in OOP is taking this to extreme and programming to interfaces, not classes. You would define an interface for Colors which has no data members and in fact cannot be instantiated. It represents the contract that Colors will obey and nothing more. For instance:

interface Color {
   int getR();
   int getG();
   int getB();
   int getA();
}

class Red implements Color {
   ...

Of course, this is overkill for something like a Color. I know it’s a contrived example, but Colors don’t have different behavior, just different values, so rather than having class Red, Orange, etc. you would have instances of a Color class which represent each.

Similarly, I wouldn’t be able to access any methods in the Orange class.

True. But the idea is that the code which is dealing with Colors doesn’t need to know what actual colors they are. That’s the power of polymorphism. If there is some special-case processing required, you can “down cast” a Color to a specific subtype, but the need to do that is often a symptom of sloppy design.