Sometimes, a class that you define represents an abstract concept and, as such, should not be instantiated. Take, for example, food in the real world. Have you ever seen an instance of food? No. What you see instead are instances of carrot, apple, and (our favorite) chocolate. Food represents the abstract concept of things that we all can eat. It doesn't make sense for an instance of food to exist.
Static is kind of difficult to explain. You don't instantiate static methods, you just use them. It basically means that there is only one copy of the code. I'm sure someone else can explain it better than that
I don't have a good explanation for concrete code, other than that abstract classes don't have it.
[ June 18, 2004: Message edited by: Darin Niard ]
An abstract method consists of just the method header. It's a kind of placeholder for a concrete method with the same signature defined in a subclass of the class containing the abstract method. Any class containing or inheriting an abstract method must itself be defined as abstract.
An abstract class can be extended but not directly instantiated.
A static method can be called without instantiating its class. It's usually a utility method related to the purposes of the class.
There is never more than one shared copy of the byte code in a method, but there can be multiple sets of a method's local variables. One set is creatd each time the method is called and destroyed each time the method returns. The distinction for a static method is that it cannot reference the instance variables or instance methods of its class using 'this' or 'super'.
There are a lot more things to learn about these concepts, so please read up!
It represent a general idea of a thing that is a fruit. Since you can't eat a general idea, we have to refine the general idea to something specific or concrete, so we create two new classes, Apple and Banana:
The important concept here is that since an Apple and a Banana are both "peelable"(since they inherit the peel() method), but exactly how you peel them is different, you must give each of the classes a concrete implementation of the abstract peel method. In other words, you take the generality of peeling a fruit and tell each class how to do it in a way that is appropriate for the type of fruit, be it an apple or a banana.
Does that make sense?
As for static, a static variable or method belongs to the class itself, not specific instances of the class. The point to see here is the distinction between a class and an instance of that class, usually called and object. A class is a blueprint for creating objects, but sometimes it makes a lot of sense to associate a variable or a method with the blueprint of the object instead of the object itself. The big advantage of this is that you do no need to create a specific instance of a class to access a static variable or method. If you know the class, you can access the static parts just by the class name, i.e. It would be a hassle, and inefficient, to always have to create an instance of a System object to be able to print to the console, so Sun gave the System class a static output stream called "out" that you access by calling:
without having to construct a System object in each class that needs it.
[ June 18, 2004: Message edited by: Eric Fletcher ]
Any class containing or inheriting an abstract method must itself be defined as abstract.
How come Eric Fletcher's peel method didn't declear as abstract?
To Eric Fletcher's post, Abstract acts really much like an interface. What are the differencs of them?
Thank you all again
I hope that helps. Also, as far as your comparison to Interfaces, I agree, Interfaces and Abstract classes are similiar, but only in the fact that they contain placeholder methods that must be implemented. However, a class can implement as many interfaces as it wants, it can only inherit a single class (abstract or otherwise). Abstract classes can also contain non-abstract methods, and even static methods and variables. Which means you can have methods in an abstract class that are usable, even without an implementing subclass. I can't think of any from the standard JDK right now, but I'm sure there's an example somewhere.