On the ‘Interfaces’ trail on the Oracle website, we are presented with the following scenario:
Imagine a futuristic society where computer-controlled robotic cars
transport passengers through city streets without a human operator.
Automobile manufacturers write software (Java, of course) that
operates the automobile—stop, start, accelerate, turn left, and so
forth. Another industrial group, electronic guidance instrument
manufacturers, make computer systems that receive GPS (Global
Positioning System) position data and wireless transmission of traffic
conditions and use that information to drive the car.The auto manufacturers must publish an industry-standard interface
that spells out in detail what methods can be invoked to make the car
move (any car, from any manufacturer). The guidance manufacturers can
then write software that invokes the methods described in the
interface to command the car. Neither industrial group needs to know
how the other group’s software is implemented. In fact, each group
considers its software highly proprietary and reserves the right to
modify it at any time, as long as it continues to adhere to the
published interface. (http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html)
So we create an interface like this:
public interface OperateCar {
// constant declarations, if any
// method signatures
// An enum with values RIGHT, LEFT
int turn(Direction direction,
double radius,
double startSpeed,
double endSpeed);
int changeLanes(Direction direction,
double startSpeed,
double endSpeed);
int signalTurn(Direction direction,
boolean signalOn);
int getRadarFront(double distanceToCar,
double speedOfCar);
int getRadarRear(double distanceToCar,
double speedOfCar);
......
// more method signatures
}
and implement it as:
public class OperateBMW760i implements OperateCar {
// the OperateCar method signatures, with implementation --
// for example:
int signalTurn(Direction direction, boolean signalOn) {
// code to turn BMW's LEFT turn indicator lights on
// code to turn BMW's LEFT turn indicator lights off
// code to turn BMW's RIGHT turn indicator lights on
// code to turn BMW's RIGHT turn indicator lights off
}
// other members, as needed -- for example, helper classes not
// visible to clients of the interface
}
So far so good. Now suppose that, in addition, each car manufacturer is required to create a prototype car, and suppose that, for some reason, we wish to keep track of these prototype cars. One solution is to add a new method to the OperateCar interface:
public OperateCar getPrototype();
Then each implementing class could implement this method by returning its prototype car. But there’s a problem with this: the prototype car has nothing to do with any instantiation of the implementing class; instead, it belongs to the class itself. In other words, if we didn’t have the interface, we’d automatically declare this method as static. But we can’t do that here, because Java interfaces don’t allow static methods.
What are the problems associated with not declaring a class-method static? Is it OK in this case just to leave out the static keyword so that the code compiles? Or are the drawbacks so great that it’s better to look for another solution?
public OperateCar getPrototype(); is essentially a Factory Method. Your question essentially boils down to this: if I have a Factory Method, but I’m not allows to put it into my interface, then how can I make it static?
The answer of course, is that you can’t. But you don’t need that capability anyway.
I would expect a static factory method to be part of… a factory. I would expect that factory method to return an instance of your interface.
In other words, you don’t need the static method in your interface. Once the object gets created, a static method in the interface would become useless anyway, unless you intend to spawn new objects from the existing object.
the prototype car has nothing to do with any instantiation of the implementing class; instead, it belongs to the class itself. In other words, if we didn’t have the interface, we’d automatically declare this method as static.
Is it possible that one “car” class might inherit the same prototype as another?
Could the 760i share a common prototype with, say, the 760? If so, the implementation of getPrototype() would come from the superclass and so couldn’t be static.
And anyway, if your aim is to “keep track” of prototypes, surely there could be be any number of them for a given, road-worthy, production model?
Your interface doesn’t (and shouldn’t) care how the method is implemented in any particular class – just so long as it is implemented.
1
If I understand you correctly, a car manufacturer is the only source of cars (including the prototype). It’s only the interface that must be public. And that interface should provide a way to access the prototype (for whatever reason) but no-one outside the manufacturing process will ever be building the prototype. Using these assumptions…
The interface should indeed have a method getPrototype() of some sorts. It’s only a matter of how the prototype got inserted into the actual car implementation. That (actual) inserted prototype may easily be static.
class MyCarManufactory() {
OperateCar buildNewCar(OperateCar prototype) {
// build your car here
}
}
While your car may look like:
public class OperateBMW760i implements OperateCar {
private static OperateCar prototype;
OperateCar getPrototype() {
return prototype;
}
int signalTurn(Direction direction, boolean signalOn) {
// code to turn BMW's LEFT turn indicator lights on
// code to turn BMW's LEFT turn indicator lights off
// code to turn BMW's RIGHT turn indicator lights on
// code to turn BMW's RIGHT turn indicator lights off
}
// other members, as needed -- for example, helper classes not
// visible to clients of the interface
}
There is no harm using an instance method to access a static field. In fact, the information about your prototype actually being static is not of anyone’s concern.