On the plus side:
  1. the ctor establishes an invariant for the object, that it has open filehandles for its other methods to work with
  2. as pointed out elsewhere, the dtor (DESTROY) will undo the work of the ctor, releasing the resources
  3. the resource usage scope tracks that of the object, which fits the 'Resource Acquisition Is Initialisation' (RAII) admittedly more of a C++ thing but also easy to understand.
On the minus side:
  1. You're consuming a resource (3 open filehandles). This is 'small' (~1024, configurable) and finite on some platforms (most Unices, not Windows). This might not matter, depending on how many of these objects you have, their lifetimes etc.
  2. You've added state to the object. This doesn't really matter if the filehandles are only closed by the dtor, but if a method can close them then the object now has 'open' and 'closed' states, with some methods only being valid in some states ('open'). This can lead to maintenance issues, since you've added an (implicit) ordering to the object methods.
If there is a single, required ordering to the methods of the object (e.g. instantiate, call 'print_data', call 'close', destroy) then one thing to consider is making that ordering explicit - with a good old fashioned procedure (or class method). To avoid an over-long sub, you can leave the functionality broken out into methods, but make them 'private' (in perl, this is traditionally done with a leading underscore on the name and not documenting them as part of the object's interface). I guess the file handles could then live as lexically-scoped vars of that procedure.

From what you say, its possible that the object has been created to break up a long subroutine, pushing some of the sub locals into object member vars. If so, bear in mind that the original solution had the sequencing of operations and that is lost (except at the calling site) by this refactoring. Since the ordering is part of the object's knowledge, it should live within it (as a class method) and not at the call site.

Lastly, it can be worth thinking of the member vars as 'has-a'. If the object *has* filehandles, then make them member vars (e.g. a logging class). If it just interacts with them (e.g. opens file so object can be serialised) then perhaps that resource is better owned by something else and passed in as a parameter.

In reply to Re: FileHandle objects as data members of another object by jbert
in thread FileHandle objects as data members of another object by jkeenan1

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.