Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Campbell Ritchie wrote:On p63 Kendal seems to think that protected means only accessible in subclasses.
Java in a Nutshell, 5th Edition, Chapter 3. Object-Oriented Programming in Java wrote:We have defined the Circle class within a package named shapes. Since "r" is protected, any other classes in the shapes package have direct access to that field and can set it however they like. The assumption here is that all classes within the shapes package were written by the same author or a closely cooperating group of authors and that the classes all trust each other not to abuse their privileged level of access to each other's implementation details.
Campbell Ritchie wrote:In discussing polymorphism, Kendal doesn't seem to use of the @Override annotation, which I would have expected from the publication date.
Remember the thread is about the book, not principally about best practice in programming. In a textbook however, you would expect the author to highlight best practice. When defining overriding, I would expect to see something like this:-Daniel Cox wrote:. . .
I agree that a protected member is accessible outside subtypes but from what I understand, this is an abuse of the protected access modifier.
. . .Java in a Nutshell, 5th Edition, Chapter 3. Object-Oriented Programming in Java wrote:We have defined the Circle class within a package named shapes. Since "r" is protected, any other classes in the shapes package have direct access to that field and can set it however they like. The assumption here is that all classes within the shapes package were written by the same author or a closely cooperating group of authors and that the classes all trust each other not to abuse their privileged level of access to each other's implementation details.
Even Horstmann and Cornell don't write @Override when they describe the WindowAdapter class in Core JavaII (9th edition) volI page 399, even though @Override was described earlier on page 233.The book I didn't write wrote:Always use the @Override annotation when you think you are overriding a method. It will prevent problems like writing
public String tostring()
and not understanding why the method doesn't seem to work.
I didn't notice Kendal saying anything like that, but I may have missed it.Horstmann and Cornell, page 233 wrote:You can protect yourself against this type of error by tagging methods that are intended to override superclass methods with @Override . . .
I hardly noticed any typos. Please list some.jon ninpoja wrote:. . . it has a lot of typos...this worries me . . .
Don't get me started about those stupid light bulbs. |