kasia in a nutshell

I don't know. I've been bitten a few times with external components that required subclassing but used private members. This created enormous customisation problems.

I think the problem is more that protected members are not considered part of the clas interface. A protected member is very definitely a part of the public API of a class and should be documented and designed as such. They should be treated in the same was as public API methods. That's the way I do it with my own components.

If all developers read and follow documentation the world would be a much happier place.. such as it is, it's best to enforce the behaviour if something is required and protected variables don't provide the easiest way of doing that.

now, see, this is where being out of the field is frustrating for me. i used to have an example where protected is actually useful, but i can't remember it. i'd check notes but god knows if i'll have the time.

i also think this example is in C++, not Java and the rules for protected may differ.

i'll let you know if i can find it.

Correct me if I'm wrong, but without protected fields, you can't do something like this:

class Foo {
    protected Logger logger = Logger.getLogger(this.getClass());
    public Foo() {
        logger.debug("in constructor");
    }
}
class Bar extends Foo {
    public doBaz() {
        logger.debug("in baz");
    }
}

*That's* what I find protected fields useful for. But otherwise, I agree, fields should not be accessable outside of their enclosing classes.