This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Ok so Java is my first OO language (and to be honest the first language I have actually spent significant intimate time with), so I am still confused about the different basics items(things, objects, whatever) in it. I looked up object on Wikipedia (no teacher, i am not referencing wikipedia) and here is the first line: In the programming paradigm of object-oriented programming, an object is an individual unit of run-time data storage that is used as the basic building block of programs. To me, that sounds like a class. Does someone have a clear way to understand objects vs classes? And maybe just for kicks, methods and instance variables too seeing as Head First Java seems to feel I should (and probably with good reason) have a good grasp of these by now.
The way I think of it, a class is sort of a template for an object. The analogy breaks down since 'static' members belong to the class as a whole (one time only) rather than living in each of the objects. For some strange reason I think of objects as bulky, and classes as sleek and thin.
Right. Reading what I wrote convinced me that I have just made things worse [ July 18, 2007: Message edited by: Katrina Owen ]
Joined: Jun 27, 2007
Haha, well thanks a lot for the response! I will reread it in the morning when my mind is fresh and not completely Java-overloaded and see if it makes more sense. I sort of get it... maybe if I keep going I will get more examples. I tend to learn best with actual examples.
If you search around, you will probably find hundreds of different analogies about classes and objects and the like. The instructor in my first Java course used an analogy of a car to drive the concept home to a bunch of glassy eyed freshmen who had no idea what he was talking about. But that analogy has stuck with me.
If you think of a Car in a general sense, i.e. without thinking about any specific make or model of Car, you can make some general statements. I'll take this opportunity to make three such statements:
A car needs fuel to run. A car has an accelerator (gas pedal) that will cause the car to move faster if its pressed. A car has a brake that will cause the car to move slower and eventually stop if depressed.
We can formalize these ideas in Java by creating a class that captures these essential features.
This construct can be read as saying, we are describing a class of objects called Car, every real object in this class will be able to do these basic things. This is a very high-level abstraction of a car that omits many details, but thats fine for now.
Now when we thing of a particular instance of a Car, or a Car object, we already have some frame of reference for it. If someone hands us a Car object, no matter where it came from, we can assume that somewhere it has a port for us to add fuel, and an accelerator for us to make it go faster, and a brake for it to stop.
However individual Car objects also have their own state. For instance right now *my* Car object has about a quarter tank of gas. It has an accelerator, but if you press it it may hesitate for a second or two before slowly (imperceptibly perhaps) beginning to speed up. The brakes will definitely cause it to stop, and as a side-effect you might be treated to a high-pitched squeal, and a fair bit a smoke for the effort.
So you can have a class of objects -> Car
And an object that belongs to that class that carries its own state -> my crappy car with a quarter tank of gas, bad accelerator, and squeaky brakes.
Does that help out at all?
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
A class is like blueprints An object is like a house
blueprints describe how to build a house
If I want that house BUT I want two extra rooms added on then we take the original blueprints, draw the new rooms in their positions. We have now extended blueprints "House" and created blueprints for "House2".
If I want to take an original class and add two more ints, I edit the original, add the two new ints, and save it as a new class.
I can use either set of blueprints to build a house,
I can use either class to instantiate an object
If you want to use the US Mail services you may want to implement a Mailbox. The type of box is prescribed by the US Postal Service but they are not going to tell you how to walk from your house to the mailbox to get your mail or drop off your outgoing mail, you have to do that part on your own. But the box is defined and the set of services is defined (they will drop off your mail, and pick up your mail to take with them) but it does not tell you how to do those things, you have to implement those activities yourself. This is sort of like "implementing an interface". The mailbox does not really change the house, per se, it simply adds an interface to the US Mail.
I hope you get a laugh out of this...... but it isnt that far from the concept....
SCJP - 86% - June 11, 2009
Joined: Jun 27, 2007
Wow, this forum is beyond helpful. Thanks all! I am starting to grasp it a little better. I like the class -> blueprint, object -> actual instance of blueprint idea. I guess now thinking about it, the words "class" and "object" sort of make a little more sense. An object is a specific object for a general class. Thanks again!