in reply to evolving an OO design

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)

Replies are listed 'Best First'.
Re(2): evolving an OO design
by mstone (Deacon) on Nov 22, 2002 at 21:43 UTC

    My apologies for waiting so long before posting a reply.. I just did a couple of 22-hour days back to back (as a stagehand, not as a coder).

    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.

    I tend to side with Knuth with regard to the top-down/bottom-up debate: both ideas are useful, but the best software design tends to happen from the middle out. Check out Literate Programming (D.E. Knuth; CSLI Publications; ISBN: 0937073814) for a wonderful treatment of the subject.

    Both the top-down and bottom-up methods give programmers ways to sweep bad decisions under the rug. Top-down design shares the same basic weakness as testing, in that you can only design (or test) for the problems you know about. Checking your top-down design won't tell you about missing assumptions, or assumptions that contradict each other in subtle ways. Bottom-up design, OTOH, tends to fall prey to circular logic. Every piece of code ends up needing to be the client for some chunk of information, but nobody wants to take responsibility for it.

    You need bottom-up information to make sure your top-down design is both complete and self-consistent, and you need top-down design to keep your bottom-up pieces from wrapping themselves up into a snakepit of mutual dependencies.

    In your case, this is forgiveable if it is purely a learning exercise to teach yourself about OO.

    Minor misunderstanding: I'm not doing this to learn about OOPerl.. I've been doing that for years. I'm doing it to learn about compilers and parsers, specifically in terms of applying my own OO preferences to the job of building a compiler. I have read Parse::RecDescent, and I think it's a wonderful piece of code. I'm just exploring my own ideas about how to partition responsibilities.

    Finally, consider gaining an understanding of design patterns.

    *grin*

    I'm already a Patterns junkie. My copy of GoF is well-worn, as are Fowler's Analysis Patterns and Pattern Languages of Program Design vols 1-4. I also have architect Christopher Alexander's 7-book series on urban design, of which A Pattern Language is volume 3.

    The 'error state' that I introduced in pass 10 is actually an application of the Null Object Pattern, for instance.

[reply]
Re: Re: evolving an OO design
by Schemer (Scribe) on Dec 04, 2002 at 04:10 UTC
    .. 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.

    Just for your information there are types of grammar a recursive descent parser (like Parse::RecDescent) can't parse. Among other conditions (which I don't remember quite clearly) a left-recursive grammar can't be parsed by recdescent. A LR(n) parser would be more useful to write a grammar for a full language.

    The strenght of Parse::RecDescent is in its ease of use to parse simple grammars, which is most of the time enough for general needs.

    And from what I think I've understood from what I've read (parse that!), Perl 6 will be even more powerful on parsing grammars than Parse::RecDescent, which may make it a really good tool for prototyping small languages.
[reply]

In Section Meditations