Has anybody read this book about OOP using java?
i downloaded a free pdf book called Object Oriented Programming using Java by Simon Kendal
wondered if anybody has read it,knows about it...is it any good?
or can somebody suggest a good book on java oop
i am enjoying the book (only read 10 pages) but it has a lot of typos...this worries me
let me know
you can visit here for such reviews.
their are plenty of posts regarding reviews of different books.hope it will help you in chosing
one you are quering for.
regards
praveen
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
its a must read book for java programmer.
For the thread part read "java concurrency in practice by brian goetz and several other authors".
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
The book make some assumptions, for example it says that OO depends on encapsulation and abstraction (p13) without saying what those terms mean. I don't think the explanations on p16 are sufficient for beginners. I think the book is all right, but it demands a bit of knowledge of the field already.
I don't know whether book son that website are edited by the publisher or not, becaus that book could have been greatly improved by some critical editing.
In discussing polymorphism, Kendal doesn't seem to use of the @Override annotation, which I would have expected from the publication date.
It is not a bad book, but it could be a lot better.
Campbell Ritchie wrote:On p63 Kendal seems to think that protected means only accessible in subclasses.
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.
From what I understand, the only reason to make a member protected is one of these:
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.
I agree that it is good practice to use the @Override annotation in order to avoid mistakes but polymorphism works without the @Override annotation.
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 would not quite agree about abuse of protected. The Java in a nutshell quote you showed puts it much better. “Not abuse their privileged level of access.” That is a really good way to put it. You can also use package‑private access and agree that your team are going to use access to package‑private fields responsibly; that is a valid alternative to making all fields private if you can be sure that only a few people will ever have such access.
But I would expect somebody writing such a book to know what protected means; Kendal doesn't mention access in the same package at all.
It's missing a word, presumably either "run" or "execute".
Definitely an issue with proof reading, even if it's not too surprising. It is a freebie after all.
