0

I'm implementing a library for a network protocol that involves sending data at a constant rate of 50Hz. The actual transmission of data will be done on a separate thread. As part of the library, there will be a class that represents all the data that needs to be sent, and the library will take care of serializing it and transmitting it.

My issue is that I'm not sure how to design this data class. The options I was thinking of were:

  • Single mutable object. The sending thread will lock the object, serialize it, then unlock it so the client can modify it again. I think this is probably the worst option.
  • Mutable object, that is cloned by the library when passed as an argument. This way the calling method can modify the existing object while not interfering with the send thread.
  • Immutable object, so a new one will have to be created each time by the calling method, and repopulated with the data.

I was not sure about going the cloning route since a new object will have to be created and populated 50 times per second.

For the cloning options, I was also wondering what the best way to clone an object like this would be. Should I take advantage of Object.clone(), which I have heard mixed things about, or implement a custom copy method/constructor? If I make something custom, what would be the most robust way of implementing it? Basically, I'll have to write in the code to copy every field of the source object one by one, and I was hoping there would be some easier way of doing it.

AniDev
  • 1,569
  • 1
  • 18
  • 21
  • It depends on how big these objects are, but a normal PC can create millions of objects per second. So creating 50 objects per second is unlikely to become a performance problem. – Jesper Feb 25 '15 at 07:44
  • My intention was to possibly use this library on a smartphone as well as on a PC. Would cloning 50 times/sec be a problem on modern smartphones? – AniDev Feb 26 '15 at 17:35

2 Answers2

0

I'd go with a mutable object and cloning. Without cloning you have potential data corruption, and making your class immutable adds complexity which is probably unwarranted.

Yes, your class should implement Cloneable and override Object.clone(). If any of your instance variable types are mutable, you should clone them too. For example:

class Data implements Cloneable {
    private int i; // int type is immutable
    private String s; // String type is immutable
    private List<String> l; // List type is mutable

    @Override
    public Data clone() {
        try {
            Data clone = (Data) super.clone();
            clone.l = new ArrayList<String>(l); // copy the mutable list
            return clone;
        } catch (CloneNotSupportedException e) {
            throw new RuntimeException(e); // impossible
        }
    }

    // other class members
}
gknicker
  • 5,509
  • 2
  • 25
  • 41
  • So for the clone method, will I have to write code for copying each field, or will super.clone() do a shallow copy of all the fields automatically? From your example code it looks like it does, and then manually copy where shallow copy isn't enough. – AniDev Feb 26 '15 at 17:29
0

I would go with the mutable object cloned as it maintains your original object. With this solution you can clone your object to send it and modify the original object for the next sending task.

The cloning mecanism should not be a performance problem as cloning 50 objects per second should not be a problem for any modern system (although I don't know what system are you working on).

Community
  • 1
  • 1
antonio
  • 18,044
  • 4
  • 45
  • 61
  • Thanks for that link about cloning methods, it will come in very useful. I guess the easiest thing for me will probably be clone each field line by line instead of bringing in a library. – AniDev Feb 26 '15 at 17:33