Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Kal A. <ka...@te...>]

OK, I'll try again without hitting Emacs control keys in a non-emacs 
environment ;-)

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>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.

These are all good points. I think you have convinced me that static copy 
methods would be a Good Thing. My reason for making the TopicMapCopier a 
separate object is that it uses only the standard interfaces and so is not 
implementation-specific. If we make static copy methods, then perhaps we 
should create abstract base classes in the org.tm4j.topicmap package which 
implement those methods.

As I typed that I began to think that there are some other pieces of pretty 
complex logic which might also be better off moved into an abstract base 
class to allow reuse in other backend implementations.


>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.

Actually, perhaps it would be better to get rid of TopicMapCopier 
completely and to make the factory to be used for creating copied objects 
into a property of the TopicMap (or TopicMapUtils) interface, with a 
default value set to the factory used to create the topic map in the first 
place. That way, the static copy() functions can use a runtime-configured 
factory (enabling me to copy from an Ozone database into an in-memory 
implementation for local modification, for example).

>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?

I was in two minds about that when I wrote the TopicMapCopier class...I'm 
not now sure why I chose to use two different names. I think it was because 
I felt that copy() and deepCopy() were getting overloaded enough...but if 
we have them in the interfaces, then that problem goes away and a boolean 
flag is appropriate.

So in summary:

1) implement copy() in each object interface - note, this includes 
interfaces such as TopicMapObject
2) Put the implementations in abstract base classes and change the memory 
and ozone implementations to extend the base classes.
2) Add a getCopyFactory() method to TopicMap which defaults to the factory 
used for the TopicMap
3) Add a setCopyFactory() method to TopicMap which enables the user to 
provide a new Factory to use for copying
4) copy() supports deep and shallow copies according to the value of a 
boolean flag passed in to the copy() method.


>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>