to use class or not to use class

I have a question about whether I should use a class for this problem or not. Here is my scenario:

I am going to be receiving data packets every second containing 2 sets of data. dataA and dataB. Once I get the data, I need to timestamp that data. I need to perform calculations on the data and keep the answers. I am thinking about using a class for each data packet that comes to me. And have that class a member for timestamp and all the other stuff I need.

Is this a good idea? Is there a better way?

I am new to java, I come from c++, do I need to deconstruct these classes after I am finished using them or does开发者_StackOverflow java do that for me? Once I am done with the object, how do I get rid of it?

Thanks in advance!

---

Certainly seems valid to me. You're getting primitive data, and wrapping it in a class that contains it and metadata information about it. In Java, you HAVE to have a class to store code, and since you want to encapsulate all this stuff I say it's a good design decision.

As for having to destroy the class yourself, usually no. The Java VM has a garbage collector that searches for and destroys unreferenced objects. It usually does so pretty efficiently in the case of "managed" objects (objects that live totally within the program's memory "sandbox").

---

Well, In Java it's pretty much all classes.

Yes, it sounds appropiate to model your package data and all the operations on it as a class.

And no, you don't have to deconstruct objects manually, when nothing references them anymore*, they are collected by the garbage collector (eventually).

*The actual rules are a bit more complicated than that, any object that isn't reachable from an active thread is considered as eligible for garbage collection. This means that you don't have to worry about circular references between your objects.

---

Create your own class. That's the Java way.

Unless the class is a private inner class, you should define it with private fields and getter / setter methods to access and update them. Or if you don't need to update the fields, only setter methods. (This may sound a bit heavy-weight from a C/C++ perspective, but getters and setters tend to pay off in the long term, and the JIT compiler typically inlines the calls anyway.)

You shouldn't worry about memory management. The Java garbage collector will automatically get rid of any instances that become inaccessible. In most situations, it is best to just let the GC handle the problem.

---

There are alternatives (though not good ones, IMO):

• Use a generic map type such as HashMap or Properties to represent the objects as name value pairs. This is a bad choice from lots of standpoints: performance is poor, you don't have a definite API (for your "objects"), and your code is more fragile.

• Use an array or list type. This is even worse, because you don't even have "names" for the fields.

• Don't reify the data packets at all, but pass the bits around separately. Ughh ...

---

You can use immutable class. IMHO it is the better way to model remote data. Ince you finished with them, if you dereference them, the garbage collector will free the memory for you.

Have a good job.