Thanks a lot for your thoughts

In fact I followed your last suggestion in a first version of the classes (My::XML and My::JSON inherited from My::Base). But I found that doing it in that way you emphasize how the data is stored (XML or JSON in this case). But in both cases you should be able to end up with the same object regardless how the information to build it was stored. I mean, it should be natural to get an object of class My instead of My::XML or My::JSON.

I don't know if this has any sense.

What you are doing is basically a factory design pattern where the factory (in your case the My:: package) usually is not part of the hierarchie of the classes it creates.

I mean, it should be natural to get an object of class My instead of My::XML or My::JSON.

I am not sure if I understand your question, but clients of your factory would usually not bother weather they have a XML or a JSON instance but work through the interface that the base-class (My::Base) provides.

Maybe you want then My->from_xml and/or My->from_json? Why is it important that My objects are XML or JSON objects? It seems to me that they should maybe be able to display or store themselves as XML or JSON, which I would put into a separate plugin or serialization class.