我们应该使用什么原始或什么类型来表示java中的电话号码？

Question

what type could contain a number like 2023209999 in java? do you think that using a string type to represent a telephone number is a good idea?

Answer 1

Using a string is a very good idea. Remember that the point of OOP is that different types of data have different usage patterns. So let's look at a phone number patterns.

• Do we add phone numbers or perform other arithmetic on them?
• Do we split it based on length, match against parts of it, replace parts of it?

The answer to the first question is no. So we don't manipulate them like numbers. The answer to the second question is yes, so we manipulate them like strings.

Now, many here are advocating making phones a class by itself. There is merit in this regard, but I'm addressing the more pressing concern of how do you store the phone number, which is something you need to do no matter if a phone is a class or not. A phone class which stored its data as a number would not be a good fit.

Answer 2

我会写一个PhoneNumber类，它使用String作为底层存储，并添加验证/漂亮的格式化功能。

Answer 3

I'd say a String at the least, but personally, I'd make a PhoneNumber object. It's the sort of thing that affords itself to extra methods such as:

 boolean isValid();

 PhoneNumberUtils.getCountry(PhoneNumber number);
 PhoneNumberUtils.getState(PhoneNumber number);

...or whatever. One thing I'd be thinking out for is just letting people put in phone numbers and getting the system to learn the rest. I despise entering data that could be determined by the system. This is just my preference.

On a simpler level, just encapsulating the String in an PhoneNumber object gives your brain a handle ... in a week or so when your brain wonders "Where should this phone number method go?", you may find yourself with a quick answer.

Answer 4

it's rather late, but I may add my 2 cents ....

I am in telecom and have made best experience to store phone numbers in structures (or objects) with character members of variable length, ie

struct TelephoneNumber (
    InternationalPrefix VARCHAR;
    AreaCode VARCHAR;
    Subscriber VARCHAR;
    Extension VARCHAR;)

I never store access digits (the zero's, double zeros, pluses etc.), they don't belong to to the telephone number per se but are part of what I may call "dialing rules"

struct DialingRule (
    International VARCHAR;
    National VARCHAR;
    Local VARCHAR;)

typical values for DialingRule are "00", "0", NULL for a direct line, and "000", "00", "0" for a PBX requiring a "0 to get the line"

to "display" a number you can freely format the objects, insert hyphens, brackets or whatever you fancy

to create a dialable sequence I determine the type (international, national or local) by comparing the corresponding elements of the FROM and TO number and add the respective string from the dialing rule set as a prefix.

This all may sound like an overkill, but for international applications with strong requirements on data integrity and with strong links to hardware I didn't come up with any better. It removes ambiguities and the need for hardcoding lenghts etc. when you want to manipulate numbers. It's also easy to prefill parts of the structure from country / city lookup tables containing ISO country codes, IATA city codes and their corresponding prefixes.

Good luck MikeD

Answer 5

I think that a dedicated PhoneNumber class is the way to go about it. Phone number are not just strings. First and foremost, phone numbers obey to rules, such as: they only contain digits, in the US they can contain either 7 or 10 digits. You'd need a constructor to make sure that your phone numbers are correct.

Second, a class will make it easy for you to steamline the differences between various formats. For instance, 555-4834 and 5554834 are different strings but are the same phone number.

Finally, you'd probably want methods such as: getAreaCode() or getLocalNumber() Calling such a method is much more concise and much less error prone than manipulating a String directly:

String phoneNumber pn = ....;
String localNumber = pn.length() == 7 ? pn : pn.substring(4) : 

Answer 6

In Germany area codes start with a 0 so a integer representation would lose that information.

Still I wouldn't recommend just using a String.
Instead use a Phonenumber class (or interface and implementations). This approach has some advantages.
If at some point you find that a String is insufficient you just have to change the Phonenumber class not every class that uses Phonenumbers.
Additionally it would allow you to seperate area code and number internally.

Answer 7

If you need to record leading 0 or + for international then you should use a String. If you ain't worried about these you can just use a long. eg

long phoneNumber = 2023209999L; // the L is for a long constant.

Answer 8

It would honestly come down to what you plan to do with it. If you just want to store it to reprint it a string or maybe even a long would be fine, assuming we are dealing with US numbers.

If you want to do something more sophisticated making a Class with containing several strings, one for each component.

Basically just not enough info here to make a real decision.

Answer 9

Using a String Type allows you to break apart the phone number without any voodoo or casting.

For instance, if you change the format of how you accept phone numbers, you'll have to do extra work to get the phone number contatenated if it is a long instead of a string .

Answer 10

Another thing to consider: an int would be too small. the maximum value an int can hold is 2,147,483,647. as far as primitives are concerned, long is your best bet.

Answer 11

It depends on what you're doing. Let's say you want to be able to represent international numbers, local numbers, branch exchange numbers, etc. In this case, a String is a bad choice. It doesn't have any meta-information. You probably want a class to represent a phone number.

As far as what you use to represent the phone number in this class, you could use a BigInteger (to allow you to have international numbers), or more simply, you could store each portion of a phone number as a long.