Getters and setters are used to help encapsulate your class in case the act of changing a variable has side effects that could mess up the class's inner workings. Or, even if it doesn't, it gives you the option of adding side effects to the change in the future without breaking any other classes.
In the case of a boolean that is intended to be changed by outside classes and has no side-effects from changing the boolean (as in your example above) I wouldn't bother with a getter and setter. I'd just make the boolean public.
But your Color variable is an example where it may make sense to use a setter. For instance, you might right now just want to define a set of colors to choose from, so you would somewhere have a set of static variable colors or an enum of colors to select from, and you would just apply them by using colorSelector.color = COLOR_RED;
. But then down the road you might decide that you want to allow any color imaginable but you don't want to have to instantiate a new color every time it changes and end up triggering the GC. So now you would be stuck. You'd have to change your call to colorSelector.color.setColor(newColor);
in all the other classes that use it, and hope you don't miss any.
If you had started out with a setter, it would look like this:
public void setColor(Color someStaticColor){
this.color = someStaticColor;
}
Then later if you decided you want to allow any incoming color, you could change it to this without having to modify other classes:
public void setColor(Color newColor){
this.color.set(newColor);
}
Now you can freely use any Color object to assign to your ColorSelector, and not worry about your input object changing later (it can be reused instead of reinstantiated).
Admittedly this is a contrived, possibly unrealistic example, but there are cases where this could save you a lot of code refactoring when you make changes.