in reply to Is it a bad idea to subclass XML::LibXML ?

Is there a reason you want to subclass vice apply a decorator when you use it? Generally speaking, it is not easy to inject your object into a framework that expects its own objects. Depending on how you are using your object, you may want to use composition over inheritance. Composition is defined as one object that uses another to extend or adapt it's interface (slightly simplified).

#code doesn't work
foreach my $node (@{$nodes}){
	my $ele = new Foo($node);
	# use ele as a wrapper for $node
}
#end code that doesn't work
In this example Foo is used to extend or adapt the functionality and interface of $node, but doesn't confuse the framework by adding additional subclasses. If you are trying to add additional behavior to $node you want to use something called the Decorator pattern. If you are just trying to simplify the interface or change it to meet you expectation you want to use something called the Adaptor pattern. Both of these patterns use composition. Using Composition over inheritance will generally simplify your design.

Scott Walters has put together a great Perl patterns resource called http://perldesignpatterns.com/?/ and has created a great explanation of what patterns (a highly recommended read) are. The decorator pattern is discussed here and the adaptor pattern is discussed here. Based on your question I think one of these may help.

Cheers,

John

  • Comment on Re: Is it a bad idea to subclass XML::LibXML ?

Replies are listed 'Best First'.
Re: Re: Is it a bad idea to subclass XML::LibXML ?
by nenbrian (Acolyte) on May 09, 2004 at 05:45 UTC

    Thanks for your reply, John.

    Yes, I thought about implementing my objects as wrappers around XML::LibXML::Element objects. However, the problem is that I need to be able to link my objects into a hierarchical structure, and then export that structure into an XML document that reflects the structure of this hierarchy. And, of course, to re-import the XML document by parsing it with the XML::LibXML::Parser, which would build a DOM tree. I would then bless the DOM objects into my classes, magically re-creating the hierarchy of my application's data... (can you see how beautiful it is?) The simplest way to accomplish this is to have my objects be the DOM objects themselves, and use the DOM tree's structure to represent my application's structure.

    To wrap the DOM objects would be to require that I link the wrapper objects together to represent my application's structure, and then to link their underlying DOM objects in parallel. This would be a lot of duplication, as well as complexity in keeping the two sets of links consistent. Unfortunately, I might be stuck using a solution like this. It's either that, or revert to using XML::DOM (for which my subclassing scheme worked, but which is sub-optimal for other reasons).

    Thanks again,
    -brian

[reply]
      I posted a new module called IOC::Lite last week that contains a class that may be useful to you. It's called IOC::Lite::Adaptor. This class's job is to pretend to be another object while providing the means to add methods to it at runtime. It will be greatly enhanced in my next release (due out this weekend), but the current one may help you now (at least in concept).

      Cheers,

      John

[reply]

        Hello John,

        If I understand correctly, that might suit my purpose. Does it just AUTOLOAD its methods, and then dispatch the method calls that you don't implement in your subclasses to the contained object?

        What I have done in the mean time is to store the subclass name in the XML::LibXML::Element objects as an attribute, and then use that to bless the references returned by my lookup routine (which is just a wrapper around findnodes() that does the bless()ings). Unfortunately this is a little bit inefficient when findnodes() returns a large nodelist, but it works, and it seems to perform reasonably well for my application. I think that your solution is cleaner, and will most likely perform better. I'll take a look at it.

        Thanks,
        -brian

[reply]

In Section Seekers of Perl Wisdom