0

Let's say I have a social media website. On this website, users can upload several pieces of information about themselves, including their phone number. To implement this, I have a class called PhoneNumber that represents the users phone number. But phone numbers are optional. I have this PhoneNumber class which is supposed to guarantee access to a users phone number, but it can't. How do I handle this?

My current approach is to, whenever there's a problem, assign a value to an error variable inside PhoneNumber that represents the problem in question (this could be an exception, a string, or an error code, it's irrelevant for this question). I also added a method to PhoneNumber called isPhoneNumberAvailable() that should be called before any of the accessors are used. If one of the accessors is called and the user hasn't added their phone number, I throw an IllegalStateException. But this doesn't seem like a good solution. I'm not sure why, I'm too new at this to explain it, but it seems like this could cause me some problems down the road.

Note that this question is language agnostic, the existence of an IllegalStateException in Java is purely coincidental.

EDIT: The solution is improving the model. I have guaranteed access to something I can't guarantee access to, which is bad design. My other problem was with the use of an error variable in class scope but that's beyond the scope of this question. See my follow up question here.

Improve this question
8
  • Having 'Hobbies' class (plural) was a bad idea to start with in the first place. Instead have Hobby (singular) class, and any user of it should use a list of Hobby objects. This will make your model much better. Commented Jun 17, 2014 at 5:44
  • If you edit the question, then where is the problem? we can just use an empty list of Hobby to indicate there is no Hobby. Am I missing something (?!?!) Commented Jun 17, 2014 at 5:46
  • Yes... It was a badly made question. Give me a minute to edit it. Commented Jun 17, 2014 at 5:47
  • Done, does that make more sense? Commented Jun 17, 2014 at 5:51
  • Sorry :) Still no sense for me. If it is optional then say you have a User class, in this user class, you have a list of PhoneNumber objects. Because PhoneNumber is optional, the list might be empty. Where is any problem? What I think you want here is not really about option, but about what if the info in PhoneNumber was not valid. But I have to ask you for sure. Commented Jun 17, 2014 at 6:00

2 Answers 2

Reset to default
1

I would just have the PhoneNumber property on the User object set to null. That way you can test if PhoneNumber == null, then the user can't call the phone number, so your UI doesn't even need to show the option (or show that there's no phone number).

Once phone number is provided, initialize an instance of the PhoneNumber class with the user's phone number and assign it the PhoneNumber property on the User object. The user's phone number can be validated the first time it is provided, and then it would be guaranteed to exist and be called. If the validation fails on the first attempt, it throws an exception during instantiation, and thus the PhoneNumber object is never created.

If at a later stage, you decided to have multiple phone numbers, either you can add more properties to the User (i.e. User.HomePhone, User.MobilePhone), or have a list of PhoneNumbers that is instantiated to empty list. As phone numbers are added, a new PhoneNumber object is instantiated and added to the list. Both these approaches will also guarantee that you never have a PhoneNumber unless it holds a valid number.

In fact, I have done something similar for a PhoneNumber class for multi-factor authentication and this approach worked fine for me.

Improve this answer
1
  • @Mat: Thanks for the catch. I meant to say "not instantiated (and set to null)", but even that is redundant. I just changed it to "set to null". I also edited other places to fix this confusion. (This is what happens when you're typing late at night and sleepy...) Commented Jun 17, 2014 at 20:07
0

I think what you're asking is where to handle possible errors, right? Among others you have the ways you described:

  1. The client asks if phone numbers are available. This has the benefit of a clean and exception-free API. But what happens if the client never asked before accessing the numbers?

  2. Your getter (within your PhobeNumber) throws an exception of nothing is available. The advantage here is that clients don't need two remember two API calls.

Both are valid ways to handle this and which you choose depends highly on your application and what you think should happen if no phone numbers are available. I, personally, prefer exceptions as you can't forget them but that is even a matter of style.

Is that what you were looking for?

Improve this answer
1
  • Thank you for your answer, in responding to it I clarified my own ideas and I may have discovered the answer and another question. Is storing error variables bad practice? Because it doesn't seem right. Nevermind. I'll make a new question (if one doesn't already exist) Commented Jun 17, 2014 at 6:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.