Я перебираю этот список в другой точке игры и хочу получить доступ к альфа-версии Цвета.Моя проблема в том, что, поскольку они все заключены в суперкласс, я не могу просто сказать, что colorObj.alpha
Если у всех ваших реальных цветов есть альфа, то поместите это в класс Color.Он должен содержать атрибуты и поведение, общие для всех цветов.
Примечание: один из тентов объектно-ориентированного программирования - enscapsulation .Открытые члены данных предоставляют внутреннее представление вашего класса.Обычно вы скрываете это представление за методами accessor , такими как:
class Color {
private int alpha;
public int getAlpha() { return alpha; }
}
Теперь никто не знает ваше представление;никто не может изменить альфа на значение, которое не имеет смысла для цвета, вы можете сделать его доступным только для чтения или только для записи, вы даже можете изменить его на вычисленное значение, и ни один из клиентов, которые его используют, не затронут.
Фактически, «лучшая практика» в ООП сводит это к крайности и программирует для интерфейсов, а не классов.Вы должны определить интерфейс для цветов, который не имеет элементов данных и фактически не может быть создан.Он представляет контракт, которому подчиняются Цвета, и ничего более.Например:
interface Color {
int getR();
int getG();
int getB();
int getA();
}
class Red implements Color {
...
Конечно, это излишне для чего-то вроде цвета.Я знаю, что это надуманный пример, но у цветов нет другого поведения , просто разные значения , поэтому вместо классов Red, Orange и т. Д. У вас будут экземпляры Colorкласс, который представляет каждый.
Точно так же я не смог бы получить доступ к любым методам в классе Orange.
True.Но идея состоит в том, что коду, который имеет дело с цветами, не нужно знать , какие они на самом деле цвета.Это сила полиморфизма.Если для есть требуется некоторая обработка в специальном случае, вы можете «понижать» цвет до определенного подтипа, но необходимость в этом часто является признаком небрежного дизайна.