[Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Hi,

[kal]

I am very lucky to see that the copying stuff has just started.
It's one of those functionalities I need most these days.
I had a peak view at the TopicMapCopier class. And from there
some questions arose.

As long as I understand the copying problem it depends on
the origins (or factories/owners) of the objects and the type
of copying (shallow/deep).

involved objects/params are:

- sourceObject
- destObject (created from sourceObjects factory or a different one)
- shallow/deep copy switch

which in my thoughts would lead to a basic method

copy(srcObj, destObj, deep)

in case of class Topic:

copy(Topic srcTopic, Topic destTopic, boolean deep)

This method could be a static method of class topic.
Or like an example in Collections class collected
in a utility class (see Collections.copy(List,List)).

Having such static methods it is easy to create other
needed functionalities e.g. clone().

assuming factory is the factory of the topicmap containing
srcTopic a clone() method would be like that:

public Object clone()
{
    Topic dest = factory.createTopic();
    return copy(this, dest, false);
}

Additionally we don't need all time to create a util class
to duplicate an object.

If we have the copying functionality in the object itself
the utility class could cope with comfortability. In the
present TopicMapCopier the factory is always the same.
So we could store one specific factory in the TopicMapCopier
and create copies of Objects automagically.

This would lead from

    public Topic copy(Topic t)
    { ... }

    to

    public Topic copy(Topic t, boolean  deep)
    {
       Topic ret = m_dest.getFactory().createTopic....;
       return Topic.copy(t, ret, deep);
    }

or something similar.

I would also prefer not to use two different method names
like copy() and deepCopy(). If there are requirements to
have automated decision of shallow/deep this comes into place.
The kind of copy is done via a switch. A switch mostly forms
itself as an ifElse statements.
While the method names are chosen at compile time the programmer
using the API has to write an ifElse statement to decide which
copy should be made. With a switch in the method this functionality
moves into the API and appears more comfortable.
Additional there is the possibility to define a default behaviour
having a method without the switch parameter.

what do you think?

NoB