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 ]
A concrete class or method is simply one that is not abstract.
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!
An abstraction is a generalization, something that describes a thing or a related group of things theoretically. To stay with the food analogy, consider the concept of a fruit. As Darin's example stated, you don't eat a fruit, per se, you eat a type of fruit, such as an apple or banana. So what defines a fruit in theoretical terms? Well, you can peel a fruit before you eat it, so let's go with that. So you have the following abstract class called Fruit:
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.
HTH, E [ June 18, 2004: Message edited by: Eric Fletcher ]
My theory of evolution is that Darwin was adopted. - Steven Wright
Joined: Jun 12, 2004
from Mike Gershman:
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?
You only have to declare the placeholder method as abstract, the implementing method is declared normally. An example:
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.