2017-06-05

Java Abstract Classes

Using Abstract Classes
Java lets you declare that a method or an entire class is abstract, which
means that the method has no body. An abstract method is just a prototype
for a method: a return type, a name, a list of parameters, and (optionally) a
throws clause.
To create an abstract method, you specify the modifier abstract and
replace the method body with a semicolon:
public abstract int hit(int batSpeed);
Here, the method named hit is declared as an abstract method that returns
an int value and accepts an int parameter.
A class that contains at least one abstract method is called an abstract class,
and must be declared with the abstract modifier on the class declaration.
For example:
public abstract class Ball
{
public abstract int hit(int batSpeed);
}
If you omit the abstract modifier from the class declaration, the Java
compiler coughs up an error message to remind you that the class must be
declared abstract.

An abstract class can’t be instantiated. Thus, given the preceding declaration,
the following line doesn’t compile:
Ball b = new Ball(); // error: Ball is abstract
You can create a subclass from an abstract class like this:
public class BaseBall extends Ball
{
public int hit(int batSpeed)
{
// code that implements the hit method goes here
}
}
When you subclass an abstract class, the subclass must provide an implementation for each abstract method in the abstract class. In other words, it must override each abstract method with a non-abstract method. (If it doesn’t, the subclass is also abstract, so it too cannot be instantiated.)
Abstract classes are useful when you want to create a generic type that is  used as the superclass for two or more subclasses, but the superclass itself doesn’t represent an actual object. For example, if all employees are either salaried or hourly, creating an abstract Employee class makes sense, and then use it as the base class for the SalariedEmployee and HourlyEmployee subclasses.
Here are a few additional points to ponder concerning abstract classes:
✦ Not all the methods in an abstract class have to be abstract. A class can
provide an implementation for some of its methods but not others. In
fact, you can declare a class that doesn’t have any abstract methods as
abstract. In that case, the class can’t be instantiated.
✦ A private method can’t be abstract. That only makes sense, because a
subclass can’t override a private method, and abstract methods must be
overridden.
✦ Although you can’t create an instance of an abstract class, you can declare a variable using an abstract class as its type. Then, use the variable to refer to an instance of any of the subclasses of the abstract class.

✦ A class can’t specify both abstract and final. That would cause one
of those logical paradoxes that result in the complete annihilation of the
entire universe. Well, hopefully the effect would be localized. But the
point is that because an abstract class can only be used if you subclass
it, and a final class can’t be subclassed, letting you specify both
abstract and final for the same class doesn’t make sense.
✦ Abstract classes are used extensively in the Java API. Many of the abstract classes have names that begin with Abstract, such as AbstractBorder, AbstractCollection, and AbstractMap. But most of the abstract classes don’t. For example, the InputStream class (used by System.in) is abstract.

The Abstract Factory Pattern

One common use for abstract classes is to provide a way to obtain an instance of one of several subclasses when you don’t know which subclass you need in advance. To do this, you can create an Abstract Factory class that has one or more methods that return subclasses of the abstract class.
For example, suppose you want to create a Ball object, but you want to let the user choose whether to create a SoftBall or a BaseBall. To use the Abstract Factory pattern, you create a class (I call it BallFactory) that has a method named getBallInstance. This method accepts a String parameter that’s set to “BaseBall” if you want a BaseBall object or “SoftBall” if you want a SoftBall object.
Here’s the factory class:
class BallFactory
{
public static Ball getBallInstance(String t)
{
if (s.equalsIgnoreCase(“BaseBall”))
return new BaseBall();
if (s.equalsIgnoreCase(“SoftBall”))
return new SoftBall();
return null;
}
}
Then, assuming the String variable userChoice has been set according to the user’s choice, you can create the selected type of ball object like this:
Ball b = BallFactory.getBallInstance(userChoice);
In an actual application, using an enum variable is better rather than a String variable to indicate the type of object to be returned.

No comments:

Post a Comment