Java Tip 27: Typesafe constants in C++ and Java

This article offers an alternative to using

enum

s or

const int

s
to help eliminate range checking and runtime errors -- first looking at C++ and then exploring an implementation of the same using Java. The summary above shows one of the problems associated with using these constructs. Another problem is the additional range
checking that is required to validate the parameter (see below).

Probably the best known and most widely used approach in C++ is through the use of enum.

class Car

{
public:

enum{FORD,VW,SAAB,MAX_CAR};
};
void car_wash(int car)

{

//requires range checking on Cars

if(car>=0 && car<MAX_CAR)

{

//ok

}

}
void main(void)

{

car_wash(Car::FORD);

}

The main problem with the approach above is that any

int

value or object with a conversion to

int

(that is, a class with

operator
int()

) can be passed to

car_wash()

. For example, there is nothing stopping someone from using

car_wash()

like this:

car_wash(100);

--
or someone who knows that

Car::FORD

is zero from being lazy and calling

car_wash(0)

. This leaves the implementor of

car_wash()

with
the responsibility of range-checking the parameter.

The next example takes advantage of the C++ compiler's type checking, but it is still open to abuse through the use of a cast.

class Car

{
public:

enum Type{FORD,VW,SAAB};
};
void car_wash(Car::Type c)

{

//do something with c

}
void main(void)

{
Car::Type car=Car::FORD;

car_wash(car);  //OK car_wash is expecting a Car::Type parameter

car_wash(1); // error, no conversion from int Car::Type

}

Even though

Car::Type

is an

enum

and therefore ultimately is an

int

, the compiler
stops clients of

car_wash()

from passing an

int

as a parameter. However, although this approach is an improvement on the previous example,
it is still open to abuse by undermining the compiler's type checking through the use of a cast. For example, the compiler can not prevent someone from casting an

int

to a Car::Type.

void main(void)

{
Car::Type car=(Car::Type)100;

car_wash(car);

}

Now this leaves us back at square one. Again a cautious implementor of car_wash() will feel obliged to do some form of range checking.

NOTE: The

class

keyword can be replaced by

namespace

in these C++ examples if your compiler supports it and the

enum

s
could also be replaced by

const int

. But the problem we are trying to eliminate remains the same: the need for range checking and the potential for runtime errors.

Below I offer an alternative to the above methods that gives both type safety and "constness."

class Car

{
private:
//private ctor to stop instantiation of client Car objects

Car() {}

public:

static const Car FORD;

static const Car VW;

static const Car SAAB;
int operator==(const Car &car) const

{

return &car==this;

}
};
//static initialization
const Car Car::FORD;

const Car Car::VW;

const Car Car::SAAB;
void car_wash(const Car &car)

{
if(Car::FORD==car)

{

cout << "The Car being washed is a FORD" << endl;

}

else if(Car::VW==car)

{

cout << " The Car being washed is a VW" << endl;

}

//

}
void main(void)

{

car_wash(Car::VW);

}

Notice the use of the private ctor (constructor) this stops the instantiation of client

Car

objects. Because clients of class

Car

can not
instantiate their own objects, the need to perform any range checking in

car_wash()

is eliminated.

One last area of improvement would be to remove the nasty

if, else if

clauses from

car_wash()

. The presence of these clauses is a common
problem with enumerated types or constants. Although client code becomes more readable through the use of constant objects, the class methods that receive these objects as parameters can become giant switch statements or a series of

if,
else if

clauses.

In a future tip I will explore various techniques that can be used to eliminate these problems.

In the meantime I will leave it as an exercise for the reader to come up with an alternative design for

car_wash()

that removes the

if, else if

clauses.

Finally, for those of you who have been patient enough to wade through C++ desperate to get your hands on some Java (and who can blame you!), here is the Java implementation of the

Car

class. The
AWT (abstract windowing toolkit) uses a similar approach in some classes.

public final class Car

{

private Car() {}

public static final Car FORD=new Car();

public static final Car VW=new Car();

public static final Car SAAB=new Car();

}

Notice that in this case, as in many others, the Java implementation is more elegant than the C++ implementation. Also note the use of "final" in the class declaration. The "final" keyword declares that a class can not be subclassed.

At this point some of you may be thinking that the declaration of class

Car

as final may be too restrictive and that the class should be non-final with a protected ctor to allow subclasses
to add new cars. Although not an award-winning design, the Java code below illustrates how the subclassing of class

Car

can reintroduce the problems we have been trying to eliminate.

import java.util.Vector;
public class Car

{

protected Car() {}

public static final Car FORD=new Car();

public static final Car VW=new Car();

public static final Car SAAB=new Car();

}
public class FrenchCar extends Car

{

public static final Car CITROEN=new Car();

protected FrenchCar()

{

}

}
public class CarWash

{

public void Start(Car car)

{

//

}

}
public class SuperCarWash extends CarWash

{

public void Start(Car car)

{

if(FrenchCar.CITROEN==car)

{

//do some specialized washing

//could still call super.Start(car)

//to finish off

}

else

super.Start(car);

}

}
public class SuperCarWashOwner

{

private SuperCarWash superCarWash= new SuperCarWash();

private Vector carsToWash        = new Vector();
public void AddCar(Car c)

{

carsToWash.addElement(c);

}

public void WashCars()

{

//iterate cars an call superCarWash.Start

}

}
public class Test

{

private SuperCarWashOwner scwOwner = new SuperCarWashOwner();
public void TestMethod()

{

scwOwner.AddCar(Car.VW);

//add more cars

scwOwner.WashCars();

}

}

The first thing to note in the code above is that the potential exists for clients of

CarWash

to pass a

FrenchCar

to

CarWash.Start()

.
To improve matters,

CarWash.Start()

could throw an exception if a

FrenchCar

object is passed in, but all this leads us back to where we
started -- trying to design typesafe constants!

It is left as an exercise for the reader to explore this last technique and balance the advantages with the tradeoffs.

About the author

Philip Bishop is technical director and a consultant at Eveque Systems Ltd. in the UK. Eveque specializes in designing and implementing distributed object systems using Java, CORBA, C++, ODBMS, and so on. He can be reached at
phil@eveque.demon.co.uk.