Review a simple PHP OOP model I wanted to write the best implementation I could think of the following really, super simple and stupid OOP model in php.



class Number {
    private $number = false;

    function __construct($n) {
        if(is_int($n)) {
            $this-&gt;number = $n;
        }
    }

    public function get() {
        return $this-&gt;number;
    }
}

class Numbers {
    public static function multiply(Number $a, Number $b) {
        return ($a-&gt;get() * $b-&gt;get());
    }
}

////
// Example
////
$first = new Number(45);
$second = new Number(80);

echo Numbers::multiply($first, $second);


Anything you guys would change? I was thinking of having Numbers extend Number, but really, the type of operations (functions) Numbers does do not need to extend the Number class. Is there a better object oriented pattern for this model?
Here's a few things that caught my eye:


I'm assuming this is just a sketch of an unfinished class, or perhaps a learning excersize? As it stands, your class is unnecessary, and I would advise against using it. Since it just wraps a built in int, built in ints might as well be used. Various functionalities could indeed make it a useful class though (for example, arbitrary precision capabilities).
If the constructor's argument can't be used, throw an exception. Objects should never exist in an incomplete or meaningless state. What does a false number mean? What does multiply($n1, $n2) mean if one of the numbers is false? Just throw an exception instead.
I wouldn't bother having Numbers exist. Just have the operations be members of Number. Static methods tend to be regretted down the line. It's always better to have a non-static that could be static than to have a static that you later realize shouldn't be static. Also, having the method be internal to Number would be nice as it would allow you access to Number's internals without having to expose them to the world.
multiply should return a Number, not an int. Why bother abstracting into an object if you're not going to stick with it?
Name your argument to the constructor something meaningful. Rather than $n name it $value (or something along those lines).
Consider expanding your number to handle more than ints. Using the BC Math or GMP extensions, you could write a class that handles arbitrary precision numbers very easily.

I would probably go with BCM just because it's more commonly available. It's statically linked on Windows and thus always enabled, whereas GMP is bundled in the binary archives, but not enabled by default. I'm not sure what the situation is on linux.
Since BCM works with ASCII encoded base 10 numeric strings and GMP works with handles, GMP is probably more memory efficient. No idea about general performance though since I'm not very familiar with GMP or BCM's internals or features.
I belive GMP is limited to integers whereas BC Math is not. That could be good or bad depending on the needs/expectations.

You missed the public in front of your constructor.
Depending on what you end up doing with the class, I probably wouldn't expose the internal representation. For example, if you ended up using GMP and wanted to switch to BMP, you couldn't if you had previously exposed the internals. Rather than expose them directly, I would implement methods like toString, toInt, toFloat, toBinary, etc. Those methods woud then either do the conversion if possible, or, if precision would be lost (like trying to convert a value to large for an int to an int), an exception would be thrown (or you could return false depending on how you expected to use the methods and if you consider a failure to convert a truly exceptional situation).
As it is right now, Number is a misnomer. 5 and 5.0 are both numbers, but your class only supports 5. I might rename it to Integer or something similar.