3 ms·

Default virtual is quite the whopper, for example. Interesting. Could you elaborate on why you find that so? By way of illustration regarding why I ask: I've

Default virtual is quite the whopper, for example. Interesting. Could you elaborate on why you find that so? By way of illustration regarding why I ask: I've been writing Java code for 20+ years now, and I can't remember a single time that the "default virtual" behavior wasn't what I wanted. And I wrote C++ before moving to Java so I'm familiar with the approach of requiring one to mark methods as virtual explicitly. I've just always found that the Java approach makes sense. What am I missing?

ncmncm 6y ago
Not thinking about the design of the language is a necessary adaptation for Java coders; the cognitive dissonance would be debilitating. The reasoning goes stepwise. 1. In a good design, a class interface represents an abstraction. The public interface provides access at the level of the abstraction, obscuring details of implementation. 2. If it is a good abstraction, by definition it maps the public view to an internal model that differs from the public view. 3. Inheritors provide different implementations of the abstraction by defining their own versions of inherited virtual-function signatures, operating on the internal, abstracted model. 4. Because these virtual functions operate on the implementation, they should not be exposed to the client. Exposing them would violate the abstraction, exposing the internal model. 5. The public members of the base class translate abstract operations to operations on the internal model, and call virtual functions that provide variable concrete operations on it. 6. Therefore, it is wrong for the public members of the base class to be virtual: their interface is the public view of the abstraction. It is their job to map that view to the internal model, and to call the virtual functions that implement the model. 7. Similarly, it is wrong for the virtual functions to be public, because they implement the internal model. Making them public would expose it. All that said, since Java offers only one organizing mechanism, the class, it necessarily gets used for everything, and not just for well-designed abstractions. It is not wrong to treat language features as a pot of mechanisms, and use them in ways that do not match their designed intent. Coding Java, there is no choice about it; classes are all you have, so you use them for everything, and the well-designed abstraction may be a rarity among all the other uses, and might not exist at all in many programs. But Java's limited feature set is out of scope for discussion of the designed purpose of virtual functions. Used according to the Object Oriented model, public virtual functions are an oxymoron. But as mechanism, they are as usable as any other, if they work.

ncmncm 6y ago

Not thinking about the design of the language is a necessary adaptation for Java coders; the cognitive dissonance would be debilitating. The reasoning goes stepwise. 1. In a good design, a class interface represents an abstraction. The public interface provides access at the level of the abstraction, obscuring details of implementation. 2. If it is a good abstraction, by definition it maps the public view to an internal model that differs from the public view. 3. Inheritors provide different implementations of the abstraction by defining their own versions of inherited virtual-function signatures, operating on the internal, abstracted model. 4. Because these virtual functions operate on the implementation, they should not be exposed to the client. Exposing them would violate the abstraction, exposing the internal model. 5. The public members of the base class translate abstract operations to operations on the internal model, and call virtual functions that provide variable concrete operations on it. 6. Therefore, it is wrong for the public members of the base class to be virtual: their interface is the public view of the abstraction. It is their job to map that view to the internal model, and to call the virtual functions that implement the model. 7. Similarly, it is wrong for the virtual functions to be public, because they implement the internal model. Making them public would expose it. All that said, since Java offers only one organizing mechanism, the class, it necessarily gets used for everything, and not just for well-designed abstractions. It is not wrong to treat language features as a pot of mechanisms, and use them in ways that do not match their designed intent. Coding Java, there is no choice about it; classes are all you have, so you use them for everything, and the well-designed abstraction may be a rarity among all the other uses, and might not exist at all in many programs. But Java's limited feature set is out of scope for discussion of the designed purpose of virtual functions. Used according to the Object Oriented model, public virtual functions are an oxymoron. But as mechanism, they are as usable as any other, if they work.