mstone++, you have given us all an excellent insight into your thought processes.

I recall my own introduction to OO, which was through Perl. I also remember several years of ignoring OO, as I did not see the point of it. Then I tried applying objects and classes to a problem, piecemeal, and arriving at a solution I was pleased with at the time, but I would probably recoil in horror at if I were to see the code now.

I do not wish to be too scathing on your approach, merely to shed some light on accepted wisdoms. Firstly, your approach is bottom up. Most successful Object Oriented Design starts with defining the problem, working out the entities and relationships, deciding on which classes to use, then designing the code.

The second piece of accepted wisdom is to look at what is out there already.

For those of you who've gotten this far and are mentally composing a reply along the lines of: "Why reinvent the wheel? Just use [insert CPAN module here...]," my answer is:

Because I chose to.

In your case, this is forgiveable if it is purely a learning exercise to teach yourself about OO. However, you can learn a tremendous amount from the modules that others have already written. Although you may reject many of the modules as being unsuitable for your particular problem, knowledge of their existence could prove useful on a future occasion.

The namespace DFA:: (Discrete Finite-state Automaton) contains some modules which do very similar stuff, and Parse::RecDescent provides a tool to build complete grammars, and according to TheDamian, most of the capabilities of this module are going into the Perl 6 language.

regarding OO, there are a large number of modules in the Class:: namespace. This is a case of TAMWTDI (there are many ways to do it).

Finally, consider gaining an understanding of design patterns. I am not advocating following the Gang of Four book1 religiously - this is Perl after all, and you are allowed niceties like variable argument lists and AUTOLOAD. But, an appreciation of design patterns will help you get the right level of abstraction and decoupling to solve problems without tears, and give you a library of ways of thinking about problems. There are also other more accessable books on design patterns, and I would recommend getting one of these first, before attempting the GoF.

1Design Patterns : Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. (Addison Wesley, ISBN ISBN 0201633612)

In reply to Re: evolving an OO design by rinceWind
in thread evolving an OO design by mstone

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.