0

Ok, so this question is mostly just related to: is there a better way to do this?

I have a phonebook application, and you can add users to it, delete them, and such, with each person being assigned a distinct ID#. A Person class stores lastIDused as a static class variable. The phonebook class has a vector of Persons.

My workaround thought is this: create a new non-static variable for the Person class, and upon serializing/saving, for the 1st element in the vector only, store the static variable's data into this new variable. Then, when de-serializing, re-set the static variable using the 1st Person's such-variable.

Going back to my original question: is there a better/more-formal/proper way to do this?

squirrelsareduck
  • 874
  • 1
  • 10
  • 15

2 Answers2

3

A better solution (IMO) would be to make lastIdUsed an instance field of the PhoneBook class. It sounds like you are already serializing an instance of that class ...

FWIW - making lastIdUsed an instance field of Person is just bad object modelling. The field is almost never going to be useful and almost never going to have a valid value. It will only have a valid value in the case of the first serialized Person in a PhoneBook.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Since it's in a Vector where the value is the first element it can probably be inferred too. Might not need it at all. just my two cents – Greg Giacovelli Jan 06 '14 at 03:29
  • I wonder if this assertion is true: class (static) variables can be replaced by instance (non-static) variables in the super-class, useful when serialization is needed – squirrelsareduck Jan 06 '14 at 03:46
  • No it is not. (Besides, I *hope* that PhoneBook is not a superclass of Person ... 'cos that would be broken modelling.) – Stephen C Jan 06 '14 at 04:10
  • @GregGiacovelli - What "it" are you referring to? The last id used cannot be "inferred" from the `Person` objects ... unless you make it an instance field of EVERY `Person`. That's what the OP originally proposed. If the field is not there (and not correct) then you can't infer the last ID used. All you can infer is the last ID that is *still in use* ... and that's a different thing entirely! – Stephen C Jan 06 '14 at 04:15
  • The "it" is the last ID. "It" can be inferred. Like if you didn't have it at all, the `Person` class is defined as already having a unique ID as per the question. So if the order is defined by a list then the "end" of the vector is your last used ID. It's overall bad modelling so I am just remove it from the Person class entirely and just rely on it's data. If you need to know how to assign new ids (a prerequisite to the object), that sort of logic inherently belongs outside the object being constructed. This is why the vector is ordered the way it since it's sort of inherent to the problem – Greg Giacovelli Jan 06 '14 at 16:20
  • @GregGiacovelli - May be don't understand the distinction between "the last id issued" and the "last id still in use". Or maybe you are assuming that `Person` objects cannot be removed from the `Vector` and discarded. If `Person` objects can be removed from the `PhoneBook` (as you would expect in an application like this), then it is *mathematically impossible* to infer the last (or largest) id issued from the set of ids still in use. – Stephen C Jan 06 '14 at 16:26
  • Sorry didn't mean to go into theory. I wasn't stating you were wrong. Notice the word "might" in the original. No one clearly understands the question. We know the ids have to be unique. It could just be a UUID and then it doesn't matter ;) This is a problem with just how to store a model that you don't know the details of. I was just offering a hint that maybe the model didn't totally fit which is why the serialization problem occurred. Like if it is an ordered id, then some atomic counter stored outside the instances persisted separately. Similar to an auto gen key in a RDBMS. – Greg Giacovelli Jan 06 '14 at 16:49
0

First, I would avoid this kind of thing entirely. Static variables aren't serializable for a reason, namely by deserializing something you would invalidate the state of other objects. For example, if your lastUsedId is at 10 and you deserialize an object where it was at 5, it could lead to creating duplicates (6-10).

However, if you are still going to do this, check out the Externalizable interface. It lets you control the serialization and deserialization of an object. Here[1] is a good discussion on it. In the past I've used Externalizable to more tightly control the format of the object being serialized in order to save space. If you really want to, you could serialize a static variable and set it when you deserialize. You could even only set it if it is higher than the value currently in memory. Again, like other commenters I would advise against this approach entirely, but it doesn't hurt to learn this stuff, eh?

[1] What is the difference between Serializable and Externalizable in Java?

Community
  • 1
  • 1
Todd
  • 30,472
  • 11
  • 81
  • 89