A good general guideline is that superclasses shouldn't know about how many and which subclasses they have, so they can't know what data structures their subclasses contain. (What they can do is define abstract methods that must be overridden, more on that below.) That means your package Monks; should probably not use Monks::Data; and should not know about @Monks::Data::Fluffy and %Monks::Data::Textures.

A second general guideline is that if you want to make the data interchangeable, don't use direct access to fields, encapsulate the data in method calls. To that end, either move the methods sub check_fluffy and sub find_fur_texture into package Monks::Data;, or wrap the fields into accessor methods like sub get_fluffy and sub get_textures, then the methods Monks::check_fluffy and Monks::find_fur_texture can call those methods to get the data.

Next, two suggestions for loosening the coupling between package Monks; and package Monks::Data;. Option A, don't use subclassing, instead make the data object Monks::Data a field on the class Monks - again encapsulated in a getter/setter method. Then that object could be passed to the constructor: my $object = Monks->new( data => Monks::Data->new );. That way, Monks doesn't need to care about the details of the data class, it simply needs to know that the data class has two methods e.g. get_fluffy and get_textures.

Option B, if you really want to use super/subclasses (whether that's the best design choice in this case is debatable, depending on what the rest of your class structure looks like), have package Monks; define abstract methods within itself that must be overridden in the subclasses. So for example, in your package Monks; add sub is_fluffy { croak "abstract method must be overridden" }, and in package Monks::Data; add sub is_fluffy { my $self = shift; my $who = shift; return 1 if grep { /\Q$who/ } qw/Rabbits Minks Cats/; return; }. Then, the calling script needs to do my $object = Monks::Data->new; instead of Monks->new. Now, the interesting thing about this approach is that other methods in Monks can still call the abstract methods in Monks - for example, in Monks, you can do sub check_fluffy { my $self = shift; return $self->is_fluffy(shift) ? "Yes" : "No"; }.

The above concepts apply to any OO design, so if that's what you're practicing, then using Moose or Moo just saves you some typing. Also, BTW, objects don't usually use Exporter.

In reply to Re: OO manner of accessing static variables in a subclass? by Anonymous Monk
in thread OO manner of accessing static variables in a subclass? by HipDeep

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.