G'day HipDeep,
Welcome to the Monastery. [At least, as a poster: you appear to have been visiting for some time.]
One of the first things I noticed was that Monks loads Monks::Data and vice versa. While Perl handles this cyclic dependency by only loading modules once, it does highlight a fundamental flaw in your OO design. I'd allow Monks to know about, and load, Monks::Data. On the other hand, Monks::Data does not need to know about Monks; it could, in fact, be used by any number of classes. Using a name that doesn't suggest a subclass of Monks would probably be a good move.
I see no valid use for Exporter in the code you've shown: you export nothing. If, at some stage, you do need to export something, I'd recommend first reading the documentation carefully, especially the "Good Practices" section, and consider "Exporting Without Inheriting from Exporter" (and not modifying @ISA).
With respect to $VERSION, I see no reason for either the BEGIN block or sub version { ... }. I'd also suggest you look at use and version for better $VERSION values.
For constant data, you have a variety of options, which include:
If, at some later stage, you use Moose (or similar), consider MooseX::ClassAttribute.
"I've also seen quite a few references to the concept that you should never access data structures directly, that you should always use a method."
Obviously, without seeing these references, I'm guessing here: I suspect this probably refers to using a method (such as $self->get_attr) rather than direct access (like $self->{attr}).
[In the code below, I initially got a bit confused between furry and fluffy, so I've changed everything to furry. Choose whatever you want but consider carefully whether names might introduce problems such as this.]
Here's my suggestion for Monks::Data which, as I said, could be used by any number of classes. It's very basic and only intended to get the general idea across.
package Monks::Data; use strict; use warnings; our $VERSION = '20160808.00'; sub get_furries { [qw{Rabbits Minks Cats}] } sub get_texture_for { +{qw{Rabbits soft Minks supersoft Cats coarse}} +} 1;
Here's Monks. Like Monks::Data, this is intentionally simplistic.
package Monks; use strict; use warnings; our $VERSION = '0.01'; use Monks::Data; sub new { my ($class, @args) = @_; bless { @args } => $class; } sub is_furry { my ($self, $furry) = @_; grep { /$furry/ } @{Monks::Data::->get_furries}; } sub find_fur_texture { my ($self, $fur) = @_; Monks::Data::->get_texture_for->{$fur}; } 1;
For an explanation of the '::' following class names (e.g. in Monks::Data::->get_furries), see "perlobj: Invoking Class Methods".
Also note that the object reference ($self) is not used in my examples, but could be.
Here's a script, similar to yours, to use these modules:
#!/usr/bin/env perl -l use strict; use warnings; use Monks; my $obj = Monks::->new; for (qw{Cats Alligators Rabbits}) { print $_, ': furry? ', $obj->is_furry($_) ? 'Yes' : 'No'; } print 'Fur texture for Cats: ', $obj->find_fur_texture('Cats');
Output:
Cats: furry? Yes Alligators: furry? No Rabbits: furry? Yes Fur texture for Cats: coarse
— Ken
In reply to Re: OO manner of accessing static variables in a subclass?
by kcott
in thread OO manner of accessing static variables in a subclass?
by HipDeep
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |