Because entries[entries.length - 1] is null you see NullPointerException.
Why are you copying the array every time you try to add a contact? you should use a List.
Why should a ContactBook care about scanners and reading input? It should only care about adding/removing/updating/retrieving contacts.
Matthean Brown wrote:The scanner being past is part of the requirement.
Paweł Baczyński wrote:Why should a ContactBook care about scanners and reading input? It should only care about adding/removing/updating/retrieving contacts.
What Paweł was trying to make clear with his remark is not that you should not use Scanner, he was trying to point out an important principle of object oriented programming: separation of concerns.
A class (or on a smaller level, a method) should only have one responsibility. For example, the only thing an address book class should do is keep track of a list of addresses. It should not deal with other things that don't directly have to do with that, such as reading input from the keyboard. That should be in a separate class, that only deals with that specific task.
Why is this: Because it makes the structure of a program much better and much easier to understand. Imagine that you have a big program with lots of classes, and each of the classes does a whole list of different, unrelated things. It would be really hard to understand which class is responsible for which part of the functionality of the program, and it would therefore be very hard to maintain that program.
If your teacher or course designed class ContactBook in such a way... then you should take it as an example of how not to design a class.
Matthean Brown wrote:Oh, I know. It was the reason why it took so long to figure out what I was suppose to be doing as it felt needless the way it was hinted at. If I knew how to store scanner data across multiple lines within the scanner itself, it would be more straightforward.
I doubt that. Apart from the fact that they duplicate a lot of code, your add() and update() methods in ContactBook look perfectly reasonable to me.
I would qualify Jesper's post with one addition though: A class should know how to create an instance of itself in whatever way necessary, so I have no particular problem with a constructor like:or indeed - and possibly even better - a static factory:although not everybody will agree with me about this.
What we do agree on is that the business of getting input from a Scanner does NOT belong in a Contact class; so if you do write a method like the one above, don't include stuff like s.nextInt() in it. You might find the UserInput page worth reading for some pointers on how to write generic user input methods (or indeed, a utility class).
I would also add one tip: Whenever you write a class, write one constructor that takes ALL the private fields it defines as parameters - ie, in your case:and make this the ONLY constructor you write to begin with. You may need to add other ones later, but don't do it until you know you need do.
I don't see someone mentioned that, but you should choose your variables a bit more carefully.
When you do have a method:
What does "p", "phone" represents? phone number? maybe phone model? If you still want to leave such a variable names, then method name should be more descriptive (better both). If such a questions comes to the mind when someone from outside looking at your code, it is a good indicator, that chosen variable names are not descriptive enough.
The same as method:
"a", "address" - home address, office address, company address, pick up point address?
It is rather important in order to have less questions when look at your code.