File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Welcome Kathy Sierra and Bert Bates to our Book Promotion of the Week Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Welcome Kathy Sierra and Bert Bates to our Book Promotion of the Week" Watch "Welcome Kathy Sierra and Bert Bates to our Book Promotion of the Week" New topic
Author

Welcome Kathy Sierra and Bert Bates to our Book Promotion of the Week

Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
Kathy and Bert are co-authors of Head First Java, which is our book promotion for this week.
Let's give them all a big Welcome!!


"JavaRanch, where the deer and the Certified play" - David O'Meara
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hello Kathy and Bert,
Welcome.
Thanks for taking the time to join and help us along.
Rajesh
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Hey Cindy and JavaRanchers -
It's great to be in this forum, we're usually pretty tied down in the SCJP and SCBCD forums!
If you want to find out more about 'Head First Java' you might also want to go to:
http://www.oreilly.com/catalog/hfjava/
where you can see a couple of samples from the book. They're fairly big because the book is VERY graphically oriented, but these samples will give you a good idea about what this very unique Java book is like.
The target audience for 'Head First Java' is anybody new to Java, or Java programmers who want to become more fluent in OO. The book starts off pretty simply, but it ramps up quickly, and by the end of the book you'll be doing projects with Swing, threads, Sockets, RMI and Java Web Start, just to name a few.
All that is pretty pedestrian. The real heart of the book is that we threw away all the rules about book writing when we wrote this baby! It's truly like nothing you've ever seen in a technical book.
We were not happy with writing just another Java book. This book is 'brain-friendly'; the entire book is not geared towards 'covering the material', but instead towards ' what do brains need, to learn complex topics quickly and well'.
Check it out at oreilly.com!
-Bert
p.s. Shoot us some questions!
[ June 03, 2003: Message edited by: Bert Bates ]

Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hello Kathy and Bert,
I haven't read your book (yet) as I'm still looking at what books would help me understand Java better.
I'm new to Java and still trying to get to grips with it. What level of programmers is your book aimed at and how would it help to improving a persons Java skills.
I have a good understanding of OO and have worked with an OO language. However, I'm completely at sea with Java. I've read a few articles but I'm still a novice. Would your book teach me the basics and fundamentals and get me up to speed with Java. This may seem a silly question - but how long would it take for someone to understand Java after reading your book.
Thanks in advance and all the best with your book.
Rajesh.
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Rajesh -
It sounds like you are definitely the kind of reader we had in mind for this book. If we're right (and only time will tell), this book should be one of the fastest ways you can get up to speed in Java.
The book is very 'interactive', there are various types of exercises and puzzles sprinkled liberally throughout the book. We put them in to give your brain lots of different kinds of opportunities to process the Java content. We believe that if you do all the exercises, (and however many puzzles you can handle ), you'll really 'get' the concepts.
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hello
It's me again.
I was checking out your snowboard example in the sample excerpts.
<quote>
Snowboard s = new Snowboard() ;
Object o = s ;
</quote>
Using the remote control analogy - you say that 's' has more buttons than 'o'. Why is this?
If 's' is a snowboard and 'o' is an object that points to 's' then shouldn't they both point to the same reference. I assume that Snowboard is a subclass of Object or is that an incorrect assumption.
Why does 's' have more buttons than 'o' if they both are referencing the same object.
Thanks,
Rajesh
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Rajesh -

<quote>
Snowboard s = new Snowboard() ;
Object o = s ;
</quote>
Using the remote control analogy - you say that 's' has more buttons than 'o'. Why is this?
If 's' is a snowboard and 'o' is an object that points to 's' then shouldn't they both point to the same reference. I assume that Snowboard is a subclass of Object or is that an incorrect assumption.
Why does 's' have more buttons than 'o' if they both are referencing the same object.

Let's start by getting our terminology really precise:
In this example there is only one object, it is of type 'Snowboard'. There are two reference variables that refer to this single 'Snowboard' object. (Watch out, it's *polymorphism" coming right at ya'.)
All reference variables have a specific 'type', in this case 'o' is of type Object, and 's' is of type Snowboard. When you declare a reference variable you give it its type. From that moment on, even though polymorphism allows you to use that reference variable to refer to objects that are a subclass of the reference variable's type, (like 'o' is really referring to a Snowboard object), that reference variable knows *ONLY* about the methods (remote control buttons), in its own type.
Since subclasses are GUARANTEED to support all of the methods of their superclasses you know that, in this case, class Snowboard will have all of class Object's methods.
So in this case 'o' is of type Object, but it's referring to an object of type Snowboard. Using 'o' you can call any of the methods that Snowboard inherited from Object, but when 'o' was created, it was designed to be for objects of type Object. It was only given access to (buttons for), Object methods, not Snowboard methods.
Why is this cool?
You could create a collection or an array of all different classes of objects, Snowboards, Dogs, Airplanes, Buttons, etc, with references of type Object referring to them all. Then you could iterate or loop thru your collection and ask each object to display it's important info. (for instance by calling the 'toString' method).
When you loop thru calling toString, you'll get every different type of Object's toString method called. If a particular class hasn't overridden class Object's toString method, then class Object's toString will be used for that object. If that object's class HAS overridden the toString method, then the overridden toString method will be used for that object... it's all automatic!
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hello Again
Thanks for your explanation - It really helps and I like you use of examples to everyday objects. If you use this kind of simple style in your book then I would really love to get a copy of your book.
OK - I think I understand. The heirarchy is that Snowboard inherits from Object so by the rules of inheritance it inherits all of the parent(super) classes methods and attributes. Am I correct.
Also what distinguishes overriding methods - in other words - Suppose in the super class you have a method MethodA with parameters Parm1 and in the sub class you have a method MethodA but with parameters Parm1 and Parm2. Are these regarded as two totally different methods. I assume it does since the signatures are different. Also I believe that for a method to override the superclass method the name and signature must be the same - Am I correct in this assumption.
Rajesh
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9053
    
  12
I think that's one of the cool things about this book -- it uses everyday stuff to illustrate the principles of Java.


JavaBeginnersFaq
"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Rajesh -
You're right on all counts. The overriding method MUST have the same signature (i.e., arguments and return type). However it can have a LESS restrictive access modifier.
After writing Head First Java, it's hard to answer a question without using a picture , I'm glad the explanation was clear.
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hello Again,
Thanks again for your reply - I did not know about the less restrictive access modifier.
Another question :
I've read that Java does not utilize pass-by-reference but only uses pass-by-value. Isn't an expensive way of doing things. The reason is that in a distributed environment if you are calling a method that is on another machine/location and you need to pass an object as a parameter - then it means that you must pass the complete object - which could slow network traffic and thus affect performance. Passing by reference would be a cheaper solution. Why does Java not use pass-by-reference or am I missing something.
Rajesh
Matt Cao
Ranch Hand

Joined: Apr 03, 2003
Posts: 715
Hi Bert,
Is the book out to the retail stores yet? I only saw the draft at your personal web site. I like it a lot because I have couple hardware technicians that I would like to convert them into programmers whom used to read PCB blueprints so I think by introduce them to your book would cut short there learning curve time drastically.
Thanks,
MCao
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Matt -
The book is in some stores at this point. (We've seen it here in Colorado.) Let us know how your plan works, it seems from the little bit that you said that your friends could be good candidates.
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by R Mera Naam:
Hello Again,
I've read that Java does not utilize pass-by-reference but only uses pass-by-value. Isn't an expensive way of doing things. The reason is that in a distributed environment if you are calling a method that is on another machine/location and you need to pass an object as a parameter - then it means that you must pass the complete object - which could slow network traffic and thus affect performance. Passing by reference would be a cheaper solution. Why does Java not use pass-by-reference or am I missing something.
Rajesh

Ahhhh... the whole pass-by thing
Here's the deal (I pushed Bert out of the way so I could answer this one. )
Within a single JVM, we *say* that Java is pass-by-value because we are saying that Java is "pass by the value of the variable". In other words, the bit pattern in the variable.
Which also means, "PASS-BY-COPY"
A copy of whatever bits are sitting in that variable when you pass it as an argument or return type.
Since Java variable values are either primitives or references to objects, the *thing* passed is always whatever bits were in that particular variable, while the object a reference variable is referring to is still sitting happily on the heap.
OK, so no problem there. We're passing a COPY of the reference. In a single JVM, we *never* pass the actual object, and we also never pass the caller's *original* reference. In other words, once you are handed a reference, say, as a parameter, you can't use that parameter within your own method to change the caller's reference.
If the object is a Television, and the reference is the remote control, when someone passes you a reference:

The doStuff() method is getting a new COPY of the remote control. So there is still just a single television, but now there are TWO remote controls. Either remote control can be used to change the one and only television object, but the key point is:

You can't use your copy of the reference to change the *caller's* reference. In other words, if I am the doStuff() method, I can use MY remote control, tv, to change channels on the same television that the caller is watching. But... I can never change the caller's REMOTE CONTROL. I can change his TV, since he gave me my own copy of the remote, but I can never change HIS remote. In other words, I cannot re-program his remote to some other television, or set it to null (which would be like deprogramming the remote so it didn't control anything at all).
OK, that wasn't actually your question but I just got carried away.
But now that we have that as the background, with distributed programming, things *are* different in Java. Because now Java *does* pass the actual object. It must, and in fact that is absolutely (in my opinion) THE coolest thing that Java can do. It lets you move live objects from one JVM to another... over a network... wherever you want. Those objects can then start executing in that new heap, and then you can send them back again.
This is definitely not a beginner question, you know that, but since this *is* the topic of the last chapter in the Head First Java book, I figured I could get away with answering it here on a high level.
An object is both state (the instance variables) and behavior (the methods defined in the class... i.e. things the object can DO).
When you pass a reference to an object through a remote method call, the value of the reference variable would have no meaning, since that value is a bit-pattern specific to that particular memory space running within one particular JVM. So Java passes the whole object. Serialized. Flattened. Deflated. Freeze-dried.
But what is in a serialized object? Just the state. So you are passing only the saved valued of the instance variables (not statics) that have not been marked with the 'transient' modifier (you can use 'transient' to control how much of your state is actually saved and passed).
Then when the object gets to the other end of the method call (or return value), the object is 'deserialized' / reconstituted / inflated / water-is-added and the object is brought back to life. Well, an identical COPY of the object anyway... we *say* that the object has moved, but really a *copy* of the object has moved.
So yes there is a cost, but it is a small one, and it is the only way it could ever work to move objects. If you wanted to do something more like RPC, you could do it with no-argument remote method calls, or make your own protocol using Sockets. But where's the fun in that?
With Java's Remote Method Invocation (used by Jini and J2EE/EJB), you pass the object because you *need* to get a whole object, not just it's data, so that it can start running on the other machine.
There would be a potentially much LARGER cost if each saved object carried its own class with it. So the class file does NOT travel, just the state.
Hmmmm... but then what happens if the object gets to the other side and the class file doesn't exist there?
Well, it seems like it MUST be there, right? Otherwise, how would you be making that call in the first place:
remoteObject.setTelevision(t);
Doesn't this mean there is a method on the other side that says:

public void setTelevision(Television tv) { }
Maybe not! The method on the other side, of course, might be using polymorphism (you knew we'd get back to that eventually ), so the method on the remote side might be written as:
public void setTelevision(Appliance a) { }
And assuming that Television extends Appliance, a Television would fit perfectly well in that 'a' parameter.
So that means that the caller could send in a Television from a class (including a subclass of Television) that the remote method doesn't even know anything about! And there's a big problem -- you send your object over the network, as a little serialized thing with no methods, but how do you use it on the other side?
That's where Java has something VERY cool -- "dynamic class downloading". OK, that is definitely NOT for this forum, but in a nutshell -- there is a way in Java to 'stamp' an object with a URL so that when the object is deserialized / brought back to life on the other end of the method call, the receiving JVM can look at the object and say, "Oh, I don't have this class... but look! There's a URL and I can just do a little HTTP GET and fetch the class and we're in business".
Ok, that's a condensed version of what makes Java so cool. So yes there *is* an expense, in sending state, but there is no other way to send a live object unless you jump down to your own low-level protocols. But the expense is kept to a minimum, because the class file does not travel with the class, and the receiving JVM can get the class on an as-needed basis.
(sorry for how ridiculously LONG this message is, but you happened to hit on just about my favorite thing. the last chapter in the Head First Java book has you make a "universal service browser" using RMI, where you send little services over the network and then they build themselves on the end-users machine. So you don't ship a big giant GUI, you instead send a little tiny object with almost NO state, but it has a method that can build a whole GUI *after* it reaches the new destination (i.e. the new JVM 'home').
Cheers,
Kathy
(now watch, it'll turn out that this wasn't even your question )
Francis Siu
Ranch Hand

Joined: Jan 04, 2003
Posts: 867
Hi Kathy and Bert,
I have the question that waht is the method signature?
I have read some books answer following
The name of the method and
The parameter list of the method
But without the return type
Does the method signature including the return type?
Does the book contain both of your signature as well if I win the book?
Because I can not go to the book shop which both of you will be there.
thanks for your attention
And one more thing
For moderators
Do I need to post it as a new topic in order to have opportunity to win the book.

[ June 04, 2003: Message edited by: siu chung man ]

Francis Siu
SCJP, MCDBA
juliane gross
Ranch Hand

Joined: May 30, 2002
Posts: 161
Hi Kathy and Bert,
I am very curious to get my hands (and brain ) on your book.
This is not only because I study Java but also because I am very interested in learning strategies. As a child in school I got the impression that technical things are nothing for me and I am too stupid to learn mathematics or physics or even logical thinking.
I studied music then, and only by accident turned to do computer things (first doing student jobs in my vacations) where I detected the big mistake: not I was too stupid but in school they provided a wrong way of learning for me.
Two years ago I visited a school "for women only" to study internet programming technics. From there I know that I learn easily enough and with lots of spirits and fun if the teacher's way matches my needs.
Short after this I found out about Java Ranch cattle drive and I love doing my assignments there! The helping network is incredible, and this was (and still is) a very important experience for me, too!
Today I know much better what ways & technics are good for me if I want to learn something; as a child you are usually so helpless and at the mery of the grownups regarding those things.
I think your new book is a very interesting and probably important way to help people detect their true abilities in learning.
I am looking forward to a lot of discussion by people sharing their experiences while using your book!
What about an extra forum, something like "discussing (java) learning (and teaching) strategies"?

Juliane
Amy Phillips
Ranch Hand

Joined: Apr 02, 2003
Posts: 280
Hi Kathy, Hi Bert,
Can't wait to get hold of the book its looks great. I agree with Juliane on this one and am hoping your book really will make the stuff stay in my head this time
Just one question though, I have seen from the reviews on Amazon that this book will help you with the certification exam but I take it that this means as well as using your study guide book am I right?
Could you also get O'reilly to hurry up and get this book published in the UK - Amazon have the publish date as 30th June
I am planning to get the head first one first and go from there - I will let you know

Amy
[ June 04, 2003: Message edited by: Amy Phillips ]
James Bunbury
Greenhorn

Joined: Mar 17, 2003
Posts: 3
Kathy and Bert are co-authors of Head First Java, which is our book promotion for this week.
Hello! As I am brand new to the Java World (Heck, I am new to the programming world), I am always on the look out for books that help me understand what I am reading. I look forward to exploring your hyperlink and your book!
Jim~
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

Hi Bert and Kathy, and welcome! I feel a bit odd welcoming you, when I'm quite new here myself. Nevertheless, it's great to see your participation in this forum, and I deeply appreciate your clear and thorough explanations.
As one (of many, I'm sure) who has learned Java as a first language entirely through self-study, good reference material has been the most essential resource. I am looking *so* forward to your book to help solidify some of the concepts that have been more challenging to me; e.g. Threads.
Judging by your easy-to-read and in-depth discussions on this forum, I'm sure this book will be an invaluable addition to my expanding Java library! Thanks!
John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
thanks for the good work!
now i feel i am nathan hale, because I regret that I only have to pass the exam once to get my scjp.
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Originally posted by Steve Morrow:
I am looking *so* forward to your book to help solidify some of the concepts that have been more challenging to me; e.g. Threads.

Hi Steve I was luckly enough to read the draft chapters as Kathy & Bert turned them out, and I can tell you one thing for sure, that is exactly what Head First Java will do for quite a few people, it will solidify OO & Java concepts.
Tom Gardner
Greenhorn

Joined: Jun 04, 2003
Posts: 1
Hi,
I've been in an out of s/w development over the past few years, and I'm leaning back in. I've looked at the excerpts from your book and am excited to read it. (Much more so than the two or three existing Java 'how to' books in the bookcase.)
It's now on my 'wish list,' but before I pull the trigger, I was hoping you'd just send me a copy out of the goodness of your heart. (Blatant enough? - I can do better if need be.)
Thanks!
Tom
Jay Myers
Greenhorn

Joined: Jun 04, 2003
Posts: 4
hello kathy and bert,
i am currently finishing up the last couple of chapters in your Java 2 Sun Certified Programmer & Developer book (McGraw Hill, (c)2002 for all those interested in a really good cert. book [shameless plug]).
i have been reading a bit about the upcoming java 1.5. in brief terms, what type of changes will we see going from 1.4.x to 1.5?
thanks,
Jay M.
Ryan Edward
Greenhorn

Joined: May 22, 2003
Posts: 1
welcome kathy and bert!...i'm a noobie in Java trying to do some self-study in learning the language...i look forward to reading your book to assist me in my endeavor...one thing that i look forward to is your detailed descriptions on concepts and techniques -- not just words to do the explanations...i'm how would you say -- a visual kinda guy!...welcome!
Donald R. Cossitt
buckaroo
Ranch Hand

Joined: Jan 31, 2003
Posts: 401
Will post for books

Bert said:
...They're fairly big because the book is VERY graphically oriented...

I am especially looking forward to the book if in fact it has the 'visual' approach. I can understand the text if you draw pictures . I have heard it said about computer manuals, and true, "they are understood if you know": too much jargon and assumption on the part of authors.
Looking forward to a purchase if not successful at winning a signed promotion copy.
I do have one question about Brad the programmer: he can code while listening to Bela Fleck play banjo at Telluride? I don't think that can be done. Maybe between songs, but not during
[ June 04, 2003: Message edited by: Donald R. Cossitt ]

doco
Jon Knight
Greenhorn

Joined: Jul 10, 2002
Posts: 1
I saw where Dr. Dan Russell said it's got a "real sense of humor". Looking forward to it ...
Tom Rodrigues
Greenhorn

Joined: Jun 04, 2003
Posts: 2
I am totally psyched that you guys have produced this book. I learn so much faster when someone shows me how to do something rather than just telling me how. I've chased after Java for quite some time now, reading this book and that, trying to grasp the concepts. To be honest, it's been pretty difficult for me. I've worked with several scripting languages and that has definitely help me to grasp a lot of the concepts. I don't know what it is about Java, but it just keeps pulling me back in. I've got to learn it!
I'd eventually like to work towards getting my Sun certification and spend lots of time exploring Swing in particular. Seems like a fun part of Java to focus on.
Thanks again!
Jem Edwards
Greenhorn

Joined: Mar 28, 2003
Posts: 22
I recently took a University Internet course entitled "Intro to Java Programming". It was a disaster! First of all, the book we used by Walter Savitch is not very beginner friendly and second, I really miss the interaction of a teacher writing code on a board and having the class break it down and/or discuss it. This board was invaluable to me while I was working on projects for the class!
I have to take the second level of this course and I intend to take it in a classroom environment but first I have to try and reteach myself the Intro class again. Besides re-reading the Savitch textbook, I'm hoping that your book will break down Java easier for me so I can continue to the next level.
Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
Originally posted by Jem Edwards:
...not very beginner friendly and second, I really miss the interaction of a teacher writing code on a board and having the class break it down and/or discuss it.

Hey Jem, I hear you.
*commercial interuption*
I found happiness right here at Javaranch's Cattle Drive. Have you heard of it? You write assignments, send them in to a nitpicker, get back comments, then send in another attempt until it's given the stamp of approval. Lots of help and moral support from the other Cattle Drivers via the the cattle drive forum, a *very* friendly bunch.
Check it out!
*back to our regular programming*
There's no teacher writing code on the board, in fact there's no code allowed in the forum. That's where you pick up skills in cryptic expression, it's quite a challenge.

Pauline
[ June 04, 2003: Message edited by: Pauline McNamara ]
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Wow !
What fun! I'll try to answer some of these questions and I'll bet my bottom dollar that Kathy will want to add her two cents .
Head First Java is really two big topics colliding. (We hope it's a good collision ). The first topic is of course Java, which we all love. The second is learning theory. We put everything we knew about BOTH topics into this book.
- We would be thrilled if people were to discuss their learning experiences using this book. We're already on to the next book (EJB cert.), and more books are planned. We see this Head First series as an evolutionary process. Two chapters into the new book and we think it's better than the last. For us the books are meant to be interactive as much as possible, and it's true of the book writing process. We like to enlist lots of tech editors, and we really, really like feedback, so bring it on!
- Head First Java isn't really a cert. book - it's more like a pre-cert book. Its goal is to get you really solid with the key Java concepts. It is definitely NOT a reference book. We purposefully left out a lot of details that are important for the SCJP cert, but aren't really key to understanding concepts. (For instance I don't think we talk about the 'switch' statement at all.) One of our guiding principals is that 80% of what you'll ever do in Java (or anything else), you'll do using the key 20% of the language. We looked at everything with our 80/20 glasses on, and really try not to bog you down with unnecessary details.
- It is WAY visual - if you like pictures, don't worry!
- One of our favorite quotes is when people describe technical literature as:
'clear only if already known'
we try to avoid that pitfall
- finally, we can't listen to live Bela and code at the same time (although you will find us at Telluride). We can however listen to Bela CDs while we're coding!
As I said earlier, count on Kathy chiming in any second now!
-Bert
Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
Originally posted by Jay M.:
hello kathy and bert,
i am currently finishing up the last couple of chapters in your Java 2 Sun Certified Programmer & Developer book (McGraw Hill, (c)2002 for all those interested in a really good cert. book [shameless plug]).
i have been reading a bit about the upcoming java 1.5. in brief terms, what type of changes will we see going from 1.4.x to 1.5?
thanks,
Jay M.

Welcome to JavaRanch Jay.
Your display name doesn't quite fit the famous JavaRanch naming policy. Could you please take a minute to change your display name and spell out the rest of your last name? (It's all about maintaining our professional image - don't let the one-eyed moose fool you!).
Thanks and hope you'll be visiting the ranch often,
Pauline
ps Here's some *real* motivation: no free books for naming policy violators.
[ June 04, 2003: Message edited by: Pauline McNamara ]
Francis Siu
Ranch Hand

Joined: Jan 04, 2003
Posts: 867
Hi Kathy and Bert again
doco said
Looking forward to a purchase if not successful at winning a signed promotion copy
Does the book signed? I mean the book is real signed not the copy of the signed.
Commend of the book
The book is attractive,innovative and creative.
I just see a few pages of the book
thanks
Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
Head First Java is really two big topics colliding. (We hope it's a good collision ). The first topic is of course Java, which we all love. The second is learning theory. We put everything we knew about BOTH topics into this book.

Have you considered pulling out the learning theory and doing a "Brain First Learning" book?
For something that is so fascinating, so much of the stuff written about didactical/pedagogical theory is just soooo dry.

Pauline
[ June 04, 2003: Message edited by: Pauline McNamara ]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
I mean the book is real signed not the copy of the signed.
Ok, siu, do you want Bert's and Kathy's signature or their descriptor.


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Francis Siu
Ranch Hand

Joined: Jan 04, 2003
Posts: 867
do you want Bert's and Kathy's signature or their descriptor
Of course ,I want both of it
Greedy thomas
Ranch Hand

Joined: May 15, 2003
Posts: 37
Hi Kathy and Bert,
Is there some easy way (apart from reading your book, I assume) to understand the use of public and private methods, static vs non static methods and variables, final method and classes. What they mean and in what context and when should you decide to use which.
Thanks,
Rajesh
sunitha reghu
Ranch Hand

Joined: Dec 12, 2002
Posts: 937
According to oreiily's description of the book
Is Head First Java right for you? That depends. Head First Java assumes you're a programmer or at least have experience with scripting languages. It assumes that you're smart, that you're creative and open to new ideas, and that you know you're just not the type of person who wants to learn the traditional way
Does it mean only smart should read this book.
My que is actually is this book really good for beginners.
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Wow! This is what I get for sleeping in this morning; a really fun pile of posts here today.
Before I answer this next one, I just want to say that Bert and I can completely relate to the frustrations of trying to learn from books that make too many assumptions about what you already know. Or they don't include any pictures. Although I must say that *now*, having done both the Head First book and our certification book, I understand why so few books have pictures -- when we did the certification book, we were forced (as just about any technical book author IS) to use their templates, and the process of getting diagrams and illustrations in is VERY difficult and error-prone. And you do not always get to specify even *where* the pictures will actually go.
In contrast, with the Head First book, O'Reilly let us build each page by hand, so we made pictures in much the same way that I would sketch on a white board (or a napkin, over a few drinks... doesn't *everyone* discuss polymorphism at the pub? ) In other words, we drew or pasted pictures, directly into the actual page that you see. O'Reilly let us -- encouraged us -- to build the book exactly the way it needed to be built for *learners*. But most authors are forced into building a book for the benefit of the publisher's process.
Originally posted by R Mera Naam:
Is there some easy way (apart from reading your book, I assume) to understand...

No. Without our book, there is only the slow, painful, torturous way.
I'll try to give a little summary
1) public vs. private
'public' is for the things you want to expose to everyone else's code. If you are making re-usable classes (which of course, good OO programmer that you are, you are doing), the 'public' methods are the reason you created the class in the first place: so that others can take advantage of the functionality you built into your class. In other words, the things your objects can DO.
'private' is for what your class needs to use internally, but that you don't want others to access.
The simplest -- and most important example -- is to use public and private to implement good 'encapsulation'. This is where you protect your *data* (i.e. your instance variables) and force everyone else to go through methods to access the data.
Easy way to do this:
* Mark your instance variables PRIVATE
* Create PUBLIC getters and setters
Why? What happens if you have the Cat class, for your animal simulation program, and it looks like this:

This is an example of a well-encapsulated class, because you have protected the data (the size instance variable) through methods.
Now, if you look at the way it is NOW, it looks like you have saved *nothing* and instead just added more overhead to getting and setting the Cat size.
But look at what this lets you do:
public void setSize(int s) {
// validate the size -- in other words, make sure
// the size is appropriate
if (s >= 0) {
// size is acceptable
size = s;
} else {
// NO! Can't have a zero-sized Cat!
// don't do it
}
}
If you allow someone to change the size without going through your method, they could do something awful -- like make a zero-sized cat. Or worse... a NEGATIVE-sized cat. (Something I *wish* would happen to my cat).
Most importantly, marking your variables private and forcing everyone to go through methods gives you another HUGE benefit of OO -- The ability to CHANGE YOUR MIND later. Flexibility, extensibility, maintainability are all made possible or greatly improved by using encapsulation.
Because look at what would happen if you didn't do this... you make a Cat class, and you let everyone step all over the data:
public class Cat {
public int size;
// other stuff
}
Now everyone else writes their code to directly access the size.
After a few weeks, you realize this is a problem (it didn't occur to you that anyone would accidentally or on purpose try to make a zero-sized cat...)
So you decide to fix it by marking the data private and adding public getters and setters so that you can validate the data.
And now look what you have done -- broken everyone else's code! Anyone who was using your class must change their code! And nobody wants to do that.
The bottom line is that if you protect your data, by marking instance variables private and providing more accessible (i.e. public) methods to access the data, you have the flexibility to go back and change and improve your methods, without hurting anyone else's code.
But there is a lot more to public and private, and of course there are the other modifiers as well.
You might want to mark METHODS as private, because they are methods that *your* own methods can call, from within your class, but you do not want anyone else to be able to call. For example;

Here we use a public constructor, but inside the public constructor we call our own *private* method. We don't want anyone else to access the 'assignNewID' method because it does critical things, including access a database. So private methods are for functionality that our own class needs, but that would be dangerous for anyone else to access. It is security to mark it private.
You can go a LONG way without having to use the other two access levels 'default' (what you get when you do not specify private, public, or protected) and 'protected' -- which most developers almost NEVER use.)
==================
2) Static vs. non-static methods
This one is easy: Java is an OO language. OO is good, for a million reasons, so you should assume that almost everything you make will NOT be static. If you make your methods static, you are hurting your ability -- permanently -- to have those methods be specific to a particular object. So the best rule is to assume NOTHING is going to be static. And then only if you see a very strong need, should you mark something static.
Non-static methods, remember, can use the instance variables of the object that was used to invoke the method.
public void bark() {
if (dogSize > 5) {
doBigBark();
} else {
doSmallBark();
}
}
In this code, the method must use an instance variable - the value of 'dogSize', in order to perform the appropriate bark.
If the method were static, it could not use any individual dog's value, and would have to bark the same way for every dog.
It is a lot like the argument for why you should use public getters and setters -- you can change your mind later without breaking anyone else's code! If you make a method static, you cannot later decide that maybe it *should* be an instance method.
But if you make everything an instance method, you can change your mind later.
So why ever use static for a method?
Because sometimes -- but RARELY -- you have a 'utitlity' method where there is NO question that it will always run exactly the same way. This is how java.lang.Math package works. A method that takes a number and returns the absolute value, for example, will NEVER change for different instances of the Math class.
But this is a special case. Do NOT make the mistake of thinking that static methods give you a performance benefit. Well, they actually *do* give you a tiny performance gain over non-static methods, but it is almost NEVER worth it for what you lose in flexibility, extensibility. If you make something static, you have made a permanent decision. If you make something an instance method instead, you are leaving yourself the freedom.
Static variables are a little different. Use 'static' when you have a variable that MUST be shared by all instances of a certain class. If you want to count the number of Cats being created, then you want ONE variable that does not get reset for each new Cat (as an instance variable would), but instead be the same for EVERY Cat.
public class Cat {
private static int catCount;
public Cat() {
catCount = catCount + 1;
}
}
OK, that's the short version of using static.
======================
FINAL:

final means slightly different things, depending on what it is marking:
1) FINAL CLASS
-- means the class cannot be extended / subclassed
Why use it? Don't use it very often! Again, you have hurt your extensibility (killed it, actually) if you make a final class. But sometimes, for security, you need to, because you must guarantee that a class always works the same way -- the way you wrote it. That's how the String class in Java works, for example.
2) FINAL VARIABLE
-- means that once the variable is given a value, you can never reassign the variable. In other words, if the size is set to 5, it can never be changed to 6 or 10 or 4,000.
CONFUSION: if the value of the variable is a reference to an object, a final variable does NOT mean that the object itself is final. If you have a final 'remote control', it means that you cannot ever "reprogram" that remote control to a different object. In other words, the programming of the remote control is what cannot be changed. But you can still USE the remote control to change the object itself (change channels, colors, sound, etc.)
final Dog d = new Dog();
// now I cannot ever do this:
d = new Dog(); // NO
d = null; // NO
d.setName("Neo"); // FINE
3) FINAL METHOD
-- means the method must not ever be overridden by a subclass. So, if a class if marked final, it means that all of it's methods are automatically final. But you might have a class that you DO want to subclass, but which has one or more methods which you do not want overridden. In this case, mark the method final but leave the class NOT-final.
Why make a method final? Again, for security. When you absolutely must guarantee that no subclass can sneak in and make their own version of the method (which, because of polymorphism will run whether you planned on it or not), then mark the method final.
CAUTION: use 'final' with a lot of caution for methods and classes! It can really hurt your OO. But when it is needed, use it. A 'final' variable has such a different purpose, that it usually does not hurt your OO to use it.
last thing...
PUBLIC STATIC FINAL VARIABLE
-- this is how you do a 'constant' in Java.
The value of Math.pi is a constant.
If you have something that must never change, and is always the same for any object of any class, then make it a public static final variable.
======================
Warning: I have really simplified things here; there are -- as always -- lots of exceptions to these rules, but they are enough to get you started on a good OO path.
Cheers,
Kathy
(whew! that was NOT a tidy little question )
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by sunitha raghu:
According to oreiily's description of the book ...
Does it mean only smart should read this book.
My que is actually is this book really good for beginners.

YES! It is absolutely good for beginners. By 'smart' then do not mean 'smart about Java'. They just mean that you have a brain that works
This book is for beginners, but not 'for dummies'. This is an important distinction, because we want to make sure that people know that just because they have trouble learning something does NOT mean they are a 'dummy'!
As others have pointed out, trouble learning a technical topic is usually because the book / class is not using good learning theory, and NOT because the learner is slow or stupid.
So we assume that you are a smart (if you're even on javaranch, we already know you are ) who is capable of learning, at least in the right conditions.
If you feel like a 'dummy', it is because a book has failed to do its job. This is the same thing that designers have been facing for years. Remember how everybody had a VCR with a 'flashing 12:00" ? Most people thought they were too stupid to figure out how to program their VCR. But it was because the designers did a TERRIBLE job of making the interface for programming a VCR. It was never your fault. There is an outstanding book about this, which is also a wonderful book for anyone who will be doing user interface work in software, called:
"The Design of Everyday Things" by Donald Norman. I used to teach interface and game design at UCLA, and this was required reading.
I would say that this book was designed completely with the beginner in mind, but every advanced Java programmer who has reviewed it has said that they still learned something or understood something in a way hadn't before reading the book.
Who is this book NOT for?
According to the book's intro...
The book is NOT for you if:
* You are hot-shot C++ programmer who just needs a reference book
* You have absolutely NO programming experience, other than JUST HTML tags. If you have done any scripting at all (javascript, ActionScript, etc.), and you are willing to stay focused and do all the exercises, you can probably do very well, even though the book is intended for those with at least *some* traditional programming.

* You would not be caught dead mixing stripes with plaid
* You would rather listed to a dry, boring lecture than a stimulating dinner party conversation.

cheers,
-Kathy
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
A long time ago (maybe in the 1920s or 1930s?), an organization wanted to publish a clear, lucid explanation of Einstein's advanced theories, suitable for everyone to read, not just physicists. They held a competition, and received many entries (they created a mechanism whereby the authors of the entries were anonymous to the judges).
By far and away, the best entry, the winning entry, was submitted by, you guessed it, Albert Einstein himself.
Now, we're no rocket scientists, or physicists, or Albert Einsteins, but we believe that if you're trying to learn something, really trying, and you're not 'getting it'... it's not your fault, it's the teacher's fault.
So that's our goal, we'll see how well we do, but we're interested in making complex topics accessible.
Let us know!
-Bert
p,s, This isn't hubris, we're always picking up some new technical book and wishing it was easier to read. Life is short, when we want to learn a topic we want to learn it without a lot of pain. We'd rather not have to wade thru dry, boring tomes, struggling to 'make it stick'. I want to read a book called 'Head First Banjo Playing' or maybe 'Head First Cabin building.'
[ June 04, 2003: Message edited by: Bert Bates ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Welcome Kathy Sierra and Bert Bates to our Book Promotion of the Week