I find repeatedly that simple code written in a procedural style becomes too limiting for me and, as a result, I often switch to objects. However, a very important concern of objects is that they should be responsible for the things they're responsible for and the calling code should not. As a result, I noticed something rather curious about your code (seems like a great start, but you're still thinking procedurally :):

my $paper = Paper->new($cnf_file);

for my $issue ($paper->issues){
  while (my $article = $issue->article){ # an iterator
    $paper->process($article);
  }
}

$paper->post_process;
[download]

Your paper is processing articles, which are fetched from issues, which in turn are fetched from the paper, which processes the articles, which are fetched from ...

See something circular there? :) Why not have the paper manage this responsibility since it knows everything in needs to know?

my $paper = Paper->new($cnf_file);

# and in your Paper package:

sub new {
    my ( $class, $cnf_file ) = @_;
    my $self = # construct your object
    $self->_initiaze;
}

sub _initialize {
    for my $issue ($self->_issues){
        while (my $article = $issue->_article){
            $self->_process($article);
        }
    }
    $self->_post_process;
}
[download]

That pushes the responsibility of processing the issues into the Paper class. Also note that I've made most of your methods private (starting with leading underscores). You should not make them public unless you must have access to them outside of this class, though I suspect you'll want to do this with your issues and articles.

The benefit of this approach is that the logic of processing the paper is encapsulated in your paper class and if you need to rewrite it, you can try to keep the same API rather than hunt through your code and find every place which is mistakenly controlling this logic. Just tell the paper what to do and let it do it :) You also might want to read The AuthenticationFairy for more background on this.

At this point, the question is whether or not you would need to intervene in any of those steps (i.e., do you need to filter out issues or something?). If you don't, the above code is fine. Otherwise, thinking about how to do that without exposing the process is important, particularly since exposing that logic can leave the object in an inconsistent state and this should never happen.

---

---

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! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

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:
	&		&
	<		&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.