SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Because the cast is only effective in the right half of line 16. It doesn't change the declared type, so it reverts to Base n line 17.Nan Jordan wrote:. . . Why casting b2 in a separate statement doesn't work . . .
VM
Campbell Ritchie wrote:Welcome to the Ranch
![]()
Doubtless you already know you should make all fields private, but the real problem is to do with polymorphism. Polymorphism apples to instance methods full stop Not static methods, not fields of any kind. So line 17 gives you the subclass' version.
Fields are not polymorphic; whichever field you get depends on the declared type of the variable, which, by the way, makes it a very bad idea to have fields with the same name in superclass and subclass. Never mind whether you cast or not, the declared type of b2 is Base, and Base doesn't have that field in the first place. So the compiler can't find the field from the Base class, and cannot therefore allow the code to run.
Try this instead:-
Another problem I can see: if the T or W are mutable reference types, it will be possible to change the state of a Pair object without that object “knowing” about it.Stephan van Hulst wrote:Several things wrong with that. . . .
Stephan van Hulst wrote:Several things wrong with that. First of all, a Pair class is degenerate in that it conveys no semantic meaning and should be avoided in preference for a data structure that is appropriate for the specific problem domain. That's why Java doesn't include a Pair class in the first place.
Now, it's fine to create classes that exposes their fields to other classes in the same package, but making fields public is always a big no no because you give up the ability to change the internal representation of the class without breaking backwards compatibility of your public API.
So while fields don't necessarily have to be private, they should definitely never be coderanch.
Gerard Gauthier wrote:This endorses a strict OPP view which is falling out of favor in the mainstream.
Yes you do expose the internals of the data but you have to expose something in an object for it to be accessible.
The idea that its OK to expose some methods of an object while forbidding others is flawed.
The designer of the class has to consider its usage before committing to a public interface.
What makes you think a strict OO view is falling out of favour?Gerard Gauthier wrote:. . . This endorses a strict OPP view which is falling out of favor in the mainstream.
Yes, that is correct. You keep the implementation details well hidden but the methods can expose a “result” obtained by using the implementation. That also allows you to change the implementation, such changes being “transparent” to other code.. . . objects which have visible methods.
No, that is a correct design principle. In fact you can start making every method private and give each a less restrictive access modifier as required.The idea that its OK to expose some methods of an object while forbidding others is flawed. . . . .
Campbell Ritchie wrote:
What makes you think a strict OO view is falling out of favour?Gerard Gauthier wrote:. . . This endorses a strict OPP view which is falling out of favor in the mainstream.
Yes, that is correct. You keep the implementation details well hidden but the methods can expose a “result” obtained by using the implementation. That also allows you to change the implementation, such changes being “transparent” to other code.. . . objects which have visible methods.
No, that is a correct design principle. In fact you can start making every method private and give each a less restrictive access modifier as required.The idea that its OK to expose some methods of an object while forbidding others is flawed. . . . .
Stephan van Hulst wrote:Object Oriented Programming and Functional Programming are not mutually exclusive. I also fail to see what higher order functions have to do with not exposing fields.
Quite a lot. For a start it fixes that part of the implementation for ever. If a more efficient way to execute the program is found, it may be impossible to implement that without “breaking” client code. It makes refactoring and code maintenance more difficult.The 101.010101.... assumes that only 99% of the honey comprises sugar and water and 1% consists of something else, which gives the honey its flavour and colour. You now have an immutable object, until you watn to change it to this sort of thing:-That sort of change is now precluded, though it would have been easy with private fields throughout. I think all fields should be private, but, as Stephan says, the developers of a particular package may decide a different policy, that inside their package all fields may have package‑private access (officially called default access).Gerard Gauthier wrote:. . . what harm can occur if a field is visible but immutable? . . . .