I certainly wouldn't say inheritance was evil, but it's not always the best solution.

In the context of Net::LDAP, it might be helpful to consider the various reasons people might subclass or encapsulate LDAP connections, and how those might work together.

For example, let's say that people have created several subclasses of Net::LDAP:
- one like yours, which adds some convenient high-level methods;
- one that better caches results to avoid repeated requests to the LDAP host; and
- one that proxies the LDAP requests over SOAP to a mod_perl server behind a firewall, where the LDAP server is located.

Ideally, I'd like to be able to get an object that has the Express interface, the Caching functionality, and the SOAPProxy implementation, but if they're all just simple subclasses of Net::LDAP, it's awkward to assemble such a beast. (Cf. "diamond pattern".) Perhaps you could accomplish it using mixin classes, but still, ick.

If each of those packages is implemented as a "decorator" or "proxy," using delegation, then things suddenly become simpler:

my $ldap_handle = Net::LDAP::Express->new( 
  debug => 0,
  target => Net::LDAP::Caching->new( 
    duration => 30,
    target => Net::LDAP::SOAPProxy->new( 
      soap_url => '...'
    )
  )
);
[download]

This kind of mix-and-match composition of functionality provides a combinatorial explosion of possibilities, rather than the incremental addition of a subclass.