Java class & interface naming trouble

Question

In my github repo I have hierarchy of classes and of course serialization/deserialization mechanism is present for them.

I serializing them manually via Externalizable and I want to take all of the code that generates values, needed for instance serialization out of this classes to keep all simple and flexible (or just to take out this mess)

So what I basically want to do is to create SerializationHelpers and DeserializationHelpers classes, where the name of particular class will be NameOfClassSerializationHelper.

Names like this are 29 characters in worst case, but I think that this is too much. Yeah of course it provides better understanding of what's going on and the name is less then 50 chars and user will never see this classes.

Here is scatch of interface hierarchy for those helper classes.

So as you can see I reduced Serialization to Ser and Deserialization to Deser but seems like it hurts readabuility.

For example class that implements TrieSerializationHelper will have name LinkedTrieSerializationHelper.

There is one another trouble: I can't place those serialization/deserialization helpers to another package because they use some package-private class (Node, as you can see from restoreRooot method of WordGraphDeserHelper).

So I'm totally confused how to do better and exactly what I have to do. Thanks in advance.

The `Helper` word just creates noise. Why not `Serializer` and `Deserializer`? — plalx, May 29 '16 at 10:57
they generates values, which has to be serialized and restores root `Node` of `Trie` by those values in case of `DeserializationHelper` — Mike Herasimov, May 29 '16 at 10:59
Why can't that code be generic? What's the output type generated by these helpers? — plalx, May 29 '16 at 11:00
@plalx because there are restrictions on returned type, however I'm not sure that I understand you clearly — Mike Herasimov, May 29 '16 at 11:02
@plalx I mean not even restrictions, for restrictions generics are pretty good — Mike Herasimov, May 29 '16 at 11:02
@plalx in case of `SerializationHelper` I get from it either array of chars or array of chars, array of boolean and 2 arrays of int, when I paste root `Node` to it, in other words all values, which I put to file by `ObjectOutputStream` — Mike Herasimov, May 29 '16 at 11:05
@plalx in case of `DeserializationHelper` I put all those values to it's constructor and after call to it `restoreRoot` method I get the root of previously serializaed Trie or DAWG class — Mike Herasimov, May 29 '16 at 11:06
Possible duplicate of [When is a Java method name too long?](http://stackoverflow.com/questions/2230871/when-is-a-java-method-name-too-long) — Ali Seyedi, May 29 '16 at 11:08
@plalx I can provide a link to one of this classes that is already in my repo and show you code, it will be ok? — Mike Herasimov, May 29 '16 at 11:08
@AliSeyedi thank you good man, lol, I alredy saw this question :D — Mike Herasimov, May 29 '16 at 11:10
Why can't you put `WordGraphDeserHelper` and specific helpers in one package called `helpers`? — Ali Seyedi, May 29 '16 at 11:19
@AliSeyedi look, there are couple of packages where this interfaces will be used, so seems like for interfaces only way is to put them on top package — Mike Herasimov, May 29 '16 at 11:23
@AliSeyedi oh, God, yeah, about interfaces youre totall right — Mike Herasimov, May 29 '16 at 11:24

score 1 · Accepted Answer · answered May 29 '16 at 19:04

You may also want to create something like Externalizer interface with specific implementations (TrieExternalizer) and move all logic there so your main classes (I think, they are Trie and DAWG) won't be overloaded with serialization/deserialization.

Example:

public interface Externalizer<T> {
    void write(T object, ObjectOutput out);
    void read(T object, ObjectInput in);
}

class TrieExternalizer implements Externalizer<Trie> {
    public void write(Trie object, ObjectOutput out) throws IOException {
        out.writeUTF(object.getSomeField());
    }


    public void read(Trie object, ObjectInput in) throws IOException {
        object.setSomeField(in.readUTF());
    }
}

class Trie implements Externalizable {
    private String someField;
    private static final Externalizer<Trie> externalizer = new TrieExternalizer();

    public String getSomeField() {
        return someField;
    }

    public void setSomeField(String someField) {
        this.someField = someField;
    }

    public void writeExternal(ObjectOutput out) throws IOException {
        externalizer.write(this, out);
    }

    public void readExternal(ObjectInput in) throws IOException {
        externalizer.read(this, in);
    }
}

sorry for late response, and yeah, your idea is MUCH better then mine, you putting exactly whole logic of serialization/deserialization to descendants of `Externalizer` interface (by call readressing) and it reduces number of classes in packages — Mike Herasimov, May 31 '16 at 08:22

Java class & interface naming trouble

1 Answers1