Hmm, well maybe I'm just in violent agreement with the "partial initialization" camp here. I'm just more partial to less initialization. :)

I use a simple constructor, inherited by every package. It accepts random name-value pairs as arguments, stores them internally, and returns a blessed object. Nothing more. Usually "id" and reftype are all my objects need up front. I don't use anything like a UNIVERSAL::new(), because that implies too many assumptions about third party code operating in my ecosystem. My constructor does get inherited by all of my classes though, to deliver a consistent construction behavior and common method call syntax throughout my frameworks.

I don't presume in my constructor to know how the objects will be used in their lifetime. The only valid assumption in my use model is that construction has been requested. When a method gets called that requires initialization, then apparently a use model requiring initialization is being used, so initialization gets done then.

I've worked with abstracting SCM systems quite a bit like ClearCase and Perforce. In many cases, an object representing a file or version may not need to be initialized with the attributes from the database in order to be able to request the SCM system do something interesting or useful with that file. Self-identification is sufficient. Other custom integration operations in user space will want more inforamtion from the database in order to complete their task, and will trigger initialization.

One issue I used to have with having a half/half approach was inconsistency in maintenance. When developers saw initialization happening in the constructor, it was easy to just dump more stuff in there, slowing everything down. When there is "no" constructor available for initialization, and every method becomes responsible for whatever initialization it needs to operate properly, it's easier to maintain a consistent level of performance imo. Never doing more work than required at any point during execution.

It's absolutely preferable not to even construct objects that won't be used, but its hard to call methods on things that don't exist. Sufficiently abstracted frameworks cannot always make assumptions about use models.

--Dave

In reply to Re^4: Perl Object Initilization by armstd
in thread Perl Object Initilization by PyrexKidd

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.