aspose file tools*
The moose likes Beginning Java and the fly likes Head First Java Guessing Game Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Head First Java Guessing Game " Watch "Head First Java Guessing Game " New topic
Author

Head First Java Guessing Game

Mike Hudek
Greenhorn

Joined: Dec 31, 2005
Posts: 17
Hello again!

I have successfully typed in, compiled and run the guessing game.

However, looking at the code there are a few things I am unsure about . I know that the authors say that not everything should be clear at this stage in the book, but, following my own learning style, I think I'm seeing connections and clarification here would confirm that I'm constructing the ideas correctly!

Here's the code for the three classes: GameLauncher.class, Player.class and GuessGame.class:








Note 1: As I see it here, an instance of the class GuessGame has been created, and it has been given the variable name 'game'.

Note 2: But here, instances of Player called p1, p2 and p3 are simply declared, without yet having been explicitly defined. This only comes at Note 3:

Note 3: Here three instances of the class Player are created and assigned the names p1, p2 and p3.

I replaced the code in the first few lines of the GuessGame code to the following, and re-compiled it, and everything still seemed to work satisfactorily, so I am not sure why the extra code lines included in the Head First Java text were deemed necessary.



I even don't understand why, under the text book version, there is NOT a compile error, as it would seem to me that the statements



are being included before new instances have been created.

Rather confused!

I hope my explanation of an apparent contradiction in my eyes of how instances are declared/defined/created is clear to you!

Mike
[ January 15, 2006: Message edited by: Mike Hudek ]

Mike
Stuart Goss
Ranch Hand

Joined: Mar 21, 2001
Posts: 169
Hi Mike, the first examples in the book are probably only to get to know a bit of the Java syntax and use the compiler and interpreter/jvm. The example you are trying out here seems to be pretty procedural like and not very OOP relevant. For that reason it could be confusing at this time.

I'm trying to help you out here. But you must have a bit of patience with me

Originally posted by Mike Hudek:
Note 1: As I see it here, an instance of the class GuessGame has been created, and it has been given the variable name 'game'.

Yep, a GuessGame variable (which can hold a reference to a GuessGame) is created and then an Object containing the real GuessGame is created (a reference to this object is then assigned to the variable).

Note 2: But here, instances of Player called Playerp1, Playerp2 and Playerp3 are simply declared, without yet having been explicitly defined. This only comes at Note 3:

Yep, we have some variables here, that can hold references to objects. No need to give them a reference to an object, let them point to NULL (no where, i.e. somewhere where it can't hurt anybody). Let them just exist, "they've just come out of factory and haven't been programmed yet".

Note 3: Here three instances of the class Player are created and assigned the names p1, p2 and p3.

Yep, we have now created some real-time objects and want to remember where we put them. Luckily we have variables for this (p1, p2, etc.), so we can assign the handles/references/addresses (whatever) of the new objects to these variables.

I replaced the code in the first few lines of the GuessGame code to the following, and re-compiled it, and everything still seemed to work satisfactorily, so I am not sure why the extra code lines included in the Head First Java text were deemed necessary.


Now you're working really messy. You're right out of OOP. This is procedural programming, which you are doing. You're not thinking "objects".
p1, p2, and p3 are THINGS that the class owns. If you want to DO something with those things (like create objects to put in them), then you need to DO that in a METHOD (if you want to use OOP).

I even don't understand why, under the text book version, there is NOT a compile error, as it would seem to me that the statements



are being included before new instances have been created.

As mentioned: the class owns variables that can point to Players (these are THINGS = member data). When these Players need to be filled with references to objects (somebody needs to do this = the class lets a method do this (method = member function) ).

A class is an "idea" of an object. Try to imagine a horse in your head. What you are imagining is the beginning of a class. You know a horse has 4 legs, a head, and a tail. It can trot, sleep, eat, and make a sound.
But if you wanted to "make" or "find" a horse you would have to leave your head/imagination (even house) and look for a horse somewhere. Once you've found one, you would have something "real" to fill the horse variable "leg", "head" and "tail" with. Going out to look would be one of your class methods. "leg" would be a class member data.

OK, I hope this was helpful
Mike Hudek
Greenhorn

Joined: Dec 31, 2005
Posts: 17
Hi Stuart!

Thanks for your time and patience to get me thinking OOP! I'm sure I'll struggle with the concepts (and the paradigm shift from my procedural roots) ... but I can clearly see the benefits of the OO approach - and am devoting all my attentions at the moment to wrenching myself into this way of thinking.

OK, so, according to what you have said, it would have been perfectly legit to have written in the code for the GameLauncher class the following:



In this way, the variable game would be set aside without it referring to anything just yet, and its presentation would be similar to the code in the Player class.



was creating an object - an instance of the class 'Player'. Later on in the code we have



and later on



where methods are being applied to the object p1. While it's all fairly rudimentary, I know, I did feel kind of happy that the structure was more according to OOP principles than procedural programming.

Page 39 of Head First Java completed. Another 600 pages or so to go... (Actually I am really enjoying the book! )

Regards for now,
[ January 15, 2006: Message edited by: Mike Hudek ]
Stuart Goss
Ranch Hand

Joined: Mar 21, 2001
Posts: 169
Originally posted by Mike Hudek:
OK, so, according to what you have said, it would have been perfectly legit to have written in the code for the GameLauncher class the following:



Not entirely, here you have given the class "GameLauncher" a member data named "game" ("game" can contain a GuessGame).
1. does GameLauncher realy HAVE-A game (I don't think so. It just starts one.)
2. in the main() method you don't need to say that "game" is a GuessGame. Your class knows that now. The member data variabel "game" belongs to it now. But (as you just read above) doing the above doesn't make much sense as the HAS-A relationship is missing.

Later on in the code we have



and later on



where methods are being applied to the object p1.


Those aren't methods. You are saying "take p1, and give me the number (a member data)". This is also not good, as als writen in the book. You should "always" use encapsulation (Set and Get methods). I think that comes up about NOW in the book

It was a head-ache for me switching from Fortran77 to Java back then. I flunked it about 3 times, and now I'm trying it again

I think I'm in chapter 9 of the HF Java book.
Mike Hudek
Greenhorn

Joined: Dec 31, 2005
Posts: 17
Hi again Stuart,

My programming past hasn't been as lofty as yours... just a bit of BASIC programming on first a Sinclair ZX81, and then old BBC Acorn Machines - and now the programmable Texas Instruments TI-83s and TI-84s I use with students - so I have a lot of 'bad habits' ingrained into me from decades past I gotta get out of!

I'll certainly get back once this encapsulation thing is covered and let you know how I'm coping with it.

As a Mathematics teacher, I am well aware of the difficulties of presenting conceptual frameworks - I liken it to being someone helping in the creation a massive tapestry ... but you don't know what the overall picture is. You have to start somewhere, and then you might hop somewhere else, and then a third point, but it is only with persistance and resolve that things start linking together and you begin seeing the overall picture - the real essence of what it is all about.

All the best for now!
[ January 15, 2006: Message edited by: Mike Hudek ]
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Mike Hudek:


You have to be a little careful with code like this. Here you have declared two variables named game! One is a member variable that is available in any non-static method of the GameLauncher class. The other is a local variable that is only available in the main() class. Eventually you will need to learn about variable scope in order to understand how variables like this interact. I won't get into any detail yet since you are just starting, but I thought I'd point this out so you can be careful about it in the future.

Layne


Java API Documentation
The Java Tutorial
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
I'd like to point out that the original version still does not follow OOP paradigms very well. If this is all there is to the class, then I think your modifications are good.

In the original version, the variables p1, p2, and p3 are all called member variables. This means that they are available to any method within the class. I don't know how much you have learned about methods yet, so I won't go into much detail. In case you are interested, this compiles because member variables are given a default value. In the case of object references that we see here, the default value is "null". This basically means that the references do not point to any objects at all. Later in the startGame() method, the objects are created.

There are several other concepts I could go into here, but I think I'll end up just confusing you more. I hope you have a fun time learning about Java. Please come back with some more questions.

Layne
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Head First Java Guessing Game