What safe way to check if an object is numerical?

Asked

Viewed 882 times

6

I am implementing some generic functions in a module of my system, and I want to treat in a certain situation if the record is numerical (I do calculations).

Then searching some way to do without having to compare with each numerical type separately (Ex: Integer, Double, Float, etc.), I saw that Number is a base type of all the others (as far as I researched and understood), so this being true, it would be enough to compare the instance of the object to the base type Number, thus:

// sendo 'value' um Object
if(value instanceof Number){
    // é uma instância de um valor numérico
} else {
    // NÃO é uma instância de um valor numérico
}

I did some tests, to confirm that this is correct and in my test everything seems to be correct, as you can follow here at Ideone.

Questions

  • This shape will cover all possible types of numerical objects?
  • This way is correct?
  • This is the best way to do this check?
java oop
  • 4

    Yes, yes and yes. Only the primitive type was left out char and its corresponding class wrapper Character.

  • 2

    The guy char keeps an integer number in the range from 0 to 65535. Whether it is considered a number for you or not, will depend on your application.

  • @Piovezan, this one char is like a int 16-bit? For the int is 32 bits and the long 64 bits, right?

  • @Piovezan, I was checking the other class common among them that the Character also implements, which would be Comparable (class Character implements Serializable, Comparable<Character>), but is String also implements, so the best way to treat the Character together the check is making a instanceof extra, something like that: (value instanceof Number || value instanceof Character)?

  • Yes, it would be a 16-bit int unsigned. And yes, the best way would be as you suggest.

1 answer

5


Yeah, this way is right to check if the guy is a Number.

There may be other wrinkles that can help in some specific cases, but basically this is the best way.

But note that it will not cover all numerical types. And in fact, in a way, this is not possible at all. Obviously this only checks whether the type implements the Number, nothing else. If someone creates a numeric type that does not implement this type, it will not be considered.

Of course you will see that it is a mistake of design of the numerical type in question. There you need to see whether this is acceptable or not. I think it’s, to me, wrong-implemented types shouldn’t be considered at all. And it may not be a mistake, it may be that you have a good reason to do it this way.

Anyway, when we inherit from classes or implement interfaces, we’re saying something relevant to the code. If there is an external condition that groups certain types and this cannot be determined in code, it does not make much sense to use them in code. And I don’t even know if it should exist, even in documentation.

For example, the type Complex Apache does not do this.

  • 1

    The important thing in my view is that the test to be implemented Number covers cases where the compiler does Boxing of the primitive type for types that could be used in arithmetic operations with normal Java operators (+, -, etc.), as in OP tests. Be alone Boolean outsider.

  • Yes, I agree, but to tell you the truth I don’t even consider Boolean, nor Character numeric types. They should never be used as if they were.

  • 1

    I agree, but unaware of the intention of the OP should be considered the possibility of someone inadvertently using Character or char in an arithmetic operation, which Java accepts.

  • @Piovezan, now reading the comments, another question arose, the char or Character should not be used for numerical values? I never used it in my application! But when you initially quoted the char I checked into the documentation and I thought he was for purposes similar to C#short, which is a "16-bit signed integer", but from what I understand in his comments he has no such purpose? What would be his purpose?

  • Let me get this straight. Character/char represents a character or symbol (letter, digit, special symbol, etc.) but this representation is no more than a numeric code in an encoding table (in the case of Java internally the char is stored as UTF-16, but there are other tables, such as UTF-8, ASCII, ISO-8859-1, etc.), so what it stores is this numerical value (code). Why does Java allow arithmetic operations with it? Perhaps to facilitate the manipulation of characters or to maintain compatibility with other numerical types since in the background it is a number tbm.

  • @Piovezan, but in this case, char or Character, Although "basically it is a number tbm", it should not be used as a certain number? So thinking like @bigown quoted: "but to tell you the truth I don’t even consider Boolean, nor Character numeric types. They should never be used as if they were". It would make no sense in my checking them as numerical (although at bottom they are). So the correct would be just: value instanceof Number as the original example of the question. Right?

  • 2

    Right, but you didn’t specify in the question which classes of objects will be tested, just mentioned that the objects will be used in calculations, so I recommended the checking of Character/char by way of doubt. And so I said in one of the first comments: "whether should be considered numbers or not, will depend on your application".

  • 1

    @Fernando is right. Piovezan gave additional information to help you since you came to use a char in his example. Although a Boolean can be represented by a number, the semantics is not a number, don’t consider it as a.

Show 3 more comments

Browser other questions tagged java oop

You are not signed in. Login or sign up in order to post.