That's why you shouldn't use methods calls on "private methods"--to avoid that intersection with any subclass.

That choice doesn't always make sense.

It is common for a class to use appropriately placed method calls as convenient "hooks" to let subclasses override behaviour. In fact this is a decent design strategy, and I've been known to recommend it.

But these methods are not public. That is, they are not meant to be part of the public API that the class and its subclasses present to the user. Rather it is part of the private API between the class and its subclasses. So they are private (at least to some extent). But they really have to be done as method calls, because the entire point of the method is to be overridden appropriately in subclasses.

What now? Well one choice is to decide to never add such hooks once the module has been written. In fact this is exactly what the open-closed principle tells you to do. However if you maintain an evolving system over time and adhere to that strictly, then you'll find that this encourages developing a maze of classes that is a maintainance problem of its own.

Another strategy is to say that you'll sometimes accept the up front risk and go ahead anyways. (Making design tradeoffs is, after all, the job of the programmer.) This makes particular sense if you have a closed code-base and are willing to grep it to make sure that you won't create a conflict. But even if you don't, it is sometimes still an acceptable cost. Particularly if you have a stated convention that all such methods will start with a particular substring.

In any case it takes coordination between the maintainer of the class and subclass to make this work and continue to work. If you don't feel comfortable with that, then you shouldn't be subclassing.


In reply to Re^7: Private Methods Meditation by tilly
in thread Private Methods Meditation by theAcolyte

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.