We notice a third symptom when using the mathematics functions
from
the standard library. Before continuing, we should
point out that numbers in Java are not normally represented
as objects. The constant 2.0 is an instance of the type float,
which is one of several built-in non-object types.
These are the only possible non-object types:
users are not allowed to create their own.
To parallel these, Java provides a range of built-in object types. (The naming conventions are such that the non-object types start with a lower-case letter; all object types with an upper-case letter.) It is easy to convert from non-objects to objects:
float x = 1.2; Float X = new Float( x );Here, the first variable is a number of the built-in type
float,
and the second is an object of the built-in type Float. The
right-hand-side of the second assignment calls the constructor method
for type Float, passing it a number as argument and returning the
corresponding object.
Knowing how easy it is to convert numbers to objects, we might
expect that Java would implement sin, cos, and other
mathematical functions as methods of class Float, enabling one to write, for
example:
Float result = X.sin();This would be consistent with the way we defined negation on complex numbers. However, here Java's attachment to the strict OOP view breaks down, and we must instead write
float result = Math.sin( x );
The reason is that Math is a class defined in a
library. Its definition includes two so-called static methods:
class Math
{
static public real sin( float r ) { ... }
static public real cos( float r ) { ... }
}
Static methods are ones whose class doesn't have to be instantiated
before it can be called. So in Math.sin(x), Math is the
name of the class, not an instance of it. Java's designers, as well as
other OOP programmers, frequently use them in this way.