One question, what's the value of the methods in the parent like find_fur_texture, vs. simply calling the method from the child directly?
Think in terms of a client/server architecture: a class (or an object instantiated from that class) is a server, and code which calls its (class or object) methods is a client. A server’s interface should publicly expose only the services it offers. In this case, find_fur_texture is a service (class method) offered by package Monk; the fact that it happens to be implemented inside that class by calling a class method in package Monk::Data is the sort of implementation detail that should remain private to the Monk class.
Put another way: the client code’s access to the services it requires should be kept as simple as possible. Thus, it should use Monk; but it should not have to use Monk::Data.
As Anonymous Monk and kcott have pointed out, there is no need (in the code shown) for package Monk::Data to use parent 'Monk'; — as kcott says, that looks like an OO design flaw. But I agree with kcott in seeing no problem with package Monk useing Monk::Data — that’s simply a part of Monk’s implementation.1
Also, one of the things that concerned me when reading the warnings about inheritance was the idea of calling the methods by name (ala, Monks::Data::get_texture) as opposed to something more abstract.
I don’t see a problem here. As stated above, clients of the Monk class shouldn’t need to know about the Monk::Data class at all; but clients of Monk::Data have to know the names of its methods, otherwise how can they call them?
In regards to the last bit, one example would be a 2d hash with a bunch of compiled regular expressions that I'm using to parse the data that the module deals with.
This doesn’t sound like a large data structure, only a collection of individual regexen. However, if you do have a data structure large enough to make the costs of copying prohibitive,2 that probably indicates that the data structure should itself be encapsulated into its own class. Then Monk::Data can hold and return an instance of that class3 without breaking encapsulation.
1Yes, this creates a transitive dependency, but that’s really only an issue in compiled languages (see, e.g., the so-called Pimpl idiom in C++). In an interpreted language like Perl, the dependencies to be avoided are those which force client code to be rewritten when the server’s implementation code is changed.
2Beware premature optimisation. Always test your code and profile carefully before expending effort on optimising something that may well be fine as it is.
3In Perl, objects (class instances) are actually blessed references, so passing an object requires little overheard: only a pointer is copied under the hood.
Hope that helps,
| Athanasius <°(((>< contra mundum | Iustus alius egestas vitae, eros Piratica, |
In reply to Re^3: OO manner of accessing static variables in a subclass?
by Athanasius
in thread OO manner of accessing static variables in a subclass?
by HipDeep
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |