Design choice: subclassing or "supplementing"

Discussion in 'Perl Misc' started by J Krugman, Apr 9, 2004.

  1. J Krugman

    J Krugman Guest

    I have this class from CPAN (let's call it, creatively enough, Foo)
    that suits me fine in almost every respect, except for one workhorse
    method (say, bar) that I think could be significantly enhanced.
    One possibility would be to create a subclass MyFoo of Foo just
    for the purpose of overriding bar. Alternatively, I could have a
    file FooSupplement.pm, in which I do something like

    use strict;
    use warnings;
    package Foo;
    {
    no warnings 'redefine';
    sub bar {
    # raise the bar to perfection
    }
    }
    1;

    Then, instead of using some subclass MyFoo, I use good ol' Foo
    followed by "use FooSupplement".

    I *suppose* (please correct me if I'm wrong) that this is yet
    another one of those choices that boils down to personal preference,
    but I'd love to take a very informal poll on what programmers here
    would typically prefer to do in such a situation.

    TIA,

    jill

    --
    To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
    J Krugman, Apr 9, 2004
    #1
    1. Advertising

  2. J Krugman <> wrote:

    > I have this class from CPAN (let's call it, creatively enough,
    > Foo) that suits me fine in almost every respect, except for one
    > workhorse method (say, bar) that I think could be significantly
    > enhanced. One possibility would be to create a subclass MyFoo of
    > Foo just for the purpose of overriding bar. Alternatively, I
    > could have a file FooSupplement.pm, in which I do something like

    [redefining a method instead of subclassing and overriding it]

    I'm no OOP guru, in fact I'm a downright novice at OOP, so keep that
    in mind.

    Subclassing and overriding the method seems to me the better way.

    If you simply redefine the method, then someone reading your code
    might look at the docs for Foo.pm and then wonder why bar() is not
    functioning as documented. Yes, they should have looked at the docs
    for FooSupplement as well, but why look there for a method for a Foo
    object?

    If you subclass, then your "main" program says 'use MyFoo;' and the
    maintenance programmer knows to look at MyFoo.pm instead of Foo.pm.
    Once there, it's obvious you're subclassing because the first thing
    there is

    package MyFoo;
    use base 'Foo';

    And, of course, you've documented everything in pod and perhaps in
    comments as well.

    --
    David Wall
    David K. Wall, Apr 9, 2004
    #2
    1. Advertising

  3. J Krugman

    Anno Siegel Guest

    J Krugman <> wrote in comp.lang.perl.misc:
    >
    >
    >
    >
    > I have this class from CPAN (let's call it, creatively enough, Foo)
    > that suits me fine in almost every respect, except for one workhorse
    > method (say, bar) that I think could be significantly enhanced.
    > One possibility would be to create a subclass MyFoo of Foo just
    > for the purpose of overriding bar.


    Overriding base class methods is more than just replacement. If
    the base class uses the overridden method internally, it will call
    the *overriding* method on objects from your (inheriting) class.
    This is what allows old code to call new code in OO, and it is at the
    heart of inheritance.

    > Alternatively, I could have a
    > file FooSupplement.pm, in which I do something like
    >
    > use strict;
    > use warnings;
    > package Foo;
    > {
    > no warnings 'redefine';
    > sub bar {
    > # raise the bar to perfection
    > }
    > }
    > 1;
    >
    > Then, instead of using some subclass MyFoo, I use good ol' Foo
    > followed by "use FooSupplement".


    Boo!

    That's called "intrusion into Foo's living-room", and in languages less
    forgiving than Perl you can get shot for that. Perl allows it, but
    it's only for emergencies, not for regular programming.

    > I *suppose* (please correct me if I'm wrong) that this is yet
    > another one of those choices that boils down to personal preference,
    > but I'd love to take a very informal poll on what programmers here
    > would typically prefer to do in such a situation.


    I don't think it is a matter of much choice. If you can do what you
    need to do via inheritance, go that way. You need very good reasons
    to change into someone else's name space, and you'd limit the access
    to the absolute minimum. I don't think you have such a situation.

    Anno
    Anno Siegel, Apr 9, 2004
    #3
  4. J Krugman

    J Krugman Guest

    In <c575e7$q5$-Berlin.DE> -berlin.de (Anno Siegel) writes:

    >J Krugman <> wrote in comp.lang.perl.misc:
    >>
    >>
    >>
    >>
    >> I have this class from CPAN (let's call it, creatively enough, Foo)
    >> that suits me fine in almost every respect, except for one workhorse
    >> method (say, bar) that I think could be significantly enhanced.
    >> One possibility would be to create a subclass MyFoo of Foo just
    >> for the purpose of overriding bar.


    >Overriding base class methods is more than just replacement. If
    >the base class uses the overridden method internally, it will call
    >the *overriding* method on objects from your (inheriting) class.
    >This is what allows old code to call new code in OO, and it is at the
    >heart of inheritance.


    >> Alternatively, I could have a
    >> file FooSupplement.pm, in which I do something like
    >>
    >> use strict;
    >> use warnings;
    >> package Foo;
    >> {
    >> no warnings 'redefine';
    >> sub bar {
    >> # raise the bar to perfection
    >> }
    >> }
    >> 1;
    >>
    >> Then, instead of using some subclass MyFoo, I use good ol' Foo
    >> followed by "use FooSupplement".


    >Boo!


    >That's called "intrusion into Foo's living-room", and in languages less
    >forgiving than Perl you can get shot for that. Perl allows it, but
    >it's only for emergencies, not for regular programming.


    >> I *suppose* (please correct me if I'm wrong) that this is yet
    >> another one of those choices that boils down to personal preference,
    >> but I'd love to take a very informal poll on what programmers here
    >> would typically prefer to do in such a situation.


    >I don't think it is a matter of much choice. If you can do what you
    >need to do via inheritance, go that way. You need very good reasons
    >to change into someone else's name space, and you'd limit the access
    >to the absolute minimum. I don't think you have such a situation.


    Many, many thanks. I was definitely heading in a bad direction
    there.

    jill

    --
    To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
    J Krugman, Apr 10, 2004
    #4
  5. Abigail <> wrote:

    > David K. Wall () wrote on MMMDCCCLXXIV September
    > MCMXCIII in <URL:news:Xns94C6993E413Edkwwashere@216.168.3.30>:
    > () J Krugman <> wrote:
    > ()
    > () > I have this class from CPAN (let's call it, creatively enough,
    > () > Foo) that suits me fine in almost every respect, except for one
    > () > workhorse method (say, bar) that I think could be significantly
    > () > enhanced. One possibility would be to create a subclass MyFoo of
    > () > Foo just for the purpose of overriding bar. Alternatively, I
    > () > could have a file FooSupplement.pm, in which I do something like
    > () [redefining a method instead of subclassing and overriding it]
    > ()
    > () I'm no OOP guru, in fact I'm a downright novice at OOP, so keep that
    > () in mind.
    > ()
    > () Subclassing and overriding the method seems to me the better way.
    > ()
    > () If you simply redefine the method, then someone reading your code
    > () might look at the docs for Foo.pm and then wonder why bar() is not
    > () functioning as documented. Yes, they should have looked at the docs
    > () for FooSupplement as well, but why look there for a method for a Foo
    > () object?
    >
    > I don't buy that argument. Why would someone reading your code and
    > wanting to look up the documentation for 'bar()' in Foo.pm?


    I was thinking of bar() as a method for an object of class Foo. Given that
    assumption (which I carelessly didn't state explicitly), Foo.pm should be
    the obvious place to look for its definition, right?

    > The code
    > contains a call to a function 'bar()', which turns out not to be
    > defined in the file. The code also uses two classes.


    Two? Foo and what else? Unless I'm mistaken, FooSupplement.pm doesn't
    create a new class, it just redefines one of the Foo methods, namely bar().

    > I'd say any programmer that just ignores 50% of the inherited modules,
    > and only searches the documentation for the other half deserves what
    > he gets.


    I agree completely.

    > () If you subclass, then your "main" program says 'use MyFoo;' and the
    > () maintenance programmer knows to look at MyFoo.pm instead of Foo.pm.
    >
    > But in the given example, the code says "use FooSupplement". So, why
    > *wouldn't* the maintainance programmer look there (which he doesn't
    > according to you)?


    No reason at all. A competent maintenance programmer *would* look at
    FooSupplement. I just don't think it's the *obvious* place to look for a
    method for a Foo object. Why do something in a non-obvious way when there's
    an obvious way -- subclassing and overriding -- to achieve a similar
    effect? That's all I meant, though I'll readily admit I could have stated
    it more clearly.

    Apologies for the long delay in getting back to this thread.

    --
    David Wall
    David K. Wall, Apr 19, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mickey Segal
    Replies:
    0
    Views:
    869
    Mickey Segal
    Feb 2, 2004
  2. Rhino
    Replies:
    11
    Views:
    631
    Rhino
    Feb 23, 2005
  3. Replies:
    5
    Views:
    390
    John C. Bollinger
    Jun 6, 2005
  4. deancoo
    Replies:
    5
    Views:
    405
    Ioannis Vranos
    Feb 17, 2005
  5. miles.jg
    Replies:
    16
    Views:
    868
    Alf P. Steinbach
    Nov 14, 2007
Loading...

Share This Page