On Wed, 9 May 2007, Peter Karman wrote:
My experience tells me that lots of subclassing is a bad smell. Delegation
is often simpler and less fraught with possibility for name conflicts.
What do you mean by delegation?
Delegation is "has-a" relationships, as opposed to "is-a".
Here's a practical Catalyst example of both subclassing and delegation in
action together.
In the big Catalyst project I'm working on now, I wanted to have some
custom accessors in my response object. These are things which are
specific to my app, like breadcrumbs.
I have a very minimal Response subclass that simply adds some accessors:
package VegGuide::Response;
use base 'Catalyst::Response';
__PACKAGE__->mk_accessors( 'alternate_links', 'breadcrumbs', 'keywords' );
That's the subclassing piece. The delegation is that rather than implement
the functionality of breadcrumbs in the response object, the breadcrumbs
accessor simply returns a VegGuide::Breadcrumbs object.
On a side note, Catalyst plugins as a rule seem to jam _way_ too many
methods into the things they extend (the session plugin is truly
egregious). Some day I'd like to write a version of the session plugin
that adds one method to the core Catalyst object, session(), and all the
rest of the methods would be available via the object returned from
session().
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
