Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I still feel a bit silly from my last question, which turned out to be a typo. But, as I get into this, my first real attempt at solving a problem by making a perl OO package, it is obvious this isn't a single module, but rather a whole family of interconnected modules. If I had time to burn, I suppose a person should try to do a single package first, but I really do need to get this complicated system working.

Finding documentation which talks about the philosophy of doing things is what I really need. It would be nice to sit down and write POD first, and then make the module fit the documentation. But I am learning as I go along about where I have to move from further complicating a single module into making multiple modules, and it looks like I need at least one class that is abstract.

One thing I picked up from here, is Class::Autouse. I think that will actually make it easier for others to make use of this thing after I get it done. So far, I don't see any way to do this by "factories", it looks like a whole lot of manual coding at this point.

But, pointers on philosophical documentation and classes which might be useful, or classes to avoid because they are obsolete/not-supported would be wonderful. Thanks.

Replies are listed 'Best First'.
Re: Multiple packages for first time
by pc88mxer (Vicar) on Feb 24, 2008 at 01:32 UTC
    Considering mapping out your classes using Class-Responsibility-Collaboration cards (wikipedia link.) It's a technique used to help you determine what classes you need and how they will interact with each other. Even if you have an existing class structure, the questions you'll answer by going through the CRC process is valuable information that should be explained in your documentation. The way classes interact with each other is one piece of information that is not usually explained well by documentation but is immensely useful in understanding how or why or when to use a class.

    If you have a complicated class structure and you want to simplify or generalize it, tell us more about it, and perhaps we can offer some suggestions.

[reply]
Re: Multiple packages for first time
by tilly (Archbishop) on Feb 24, 2008 at 06:46 UTC
    You are seriously hoping that a vague question will turn up some resource that tells you how to do object-oriented design? Entire books have been written on that!

    http://www.c2.com/cgi/wiki?WelcomeVisitors is a wiki where a lot of useful information may be found. http://www.c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign might be a good starting place for you.

    My personal advice is to figure out the simplest possible design that might work. Then think about how to make it simpler. Particularly since you're inexperienced, do not try to make it too abstract.

    Your attitude should be that no matter what you do, you're bound to get something wrong. So try to make it as easy as possible to refactor and fix your design when you realize your inevitable mistakes.

    Good luck.

[reply]
      I would much rather do FORTRAN that OOP, but I have dabbled in OOP in the past. Nothing as big as this though. As it is a 4.5 hour drive to a good library or bookstore, finding documentation on the web would be nicer. I do have lots of books, none seem to work well enough.

      I have solved many statistical questions by considering the philosophy behind the statistics. I was hoping a similar approach here might work for maximizing the chance of getting something workable. Having to rewrite parts later isn't something I will try to avoid.

      Thanks for the links.

[reply]

        "I would much rather do FORTRAN that OOP"

        I wouldn't want to do a CGI application in FORTRAN however! I think you are making the OO part out to harder than it is. In perl you can make your objects as complicated or as simple as you're task demands. At the simple level you are just placing your data and it's access methods in a separate Package. You don't have to make the methods private if you don't want to. The Package can be in the same file or a separate one. You don't even have to export your methods (doing so makes them easier to call). You don't have to use inheritance and should you need inheritance you can choose your inheritance method.

        If there is a "philosophy" behind perl OO it's "There is more than one way to do it." I can't take credit for that particular insight. I just heard it somewhere, once. ;->

        There exists templates for making perl classes. I'm not familiar with them but a search of CPAN and this site should turn up some. My own tendency would be to learn to do it "longhand" first before evaluating packaged solutions. YMMV

      • Step one is to localize your data.
      • Step two is to create access methods (subroutines) for your data.
      • Step three is to move the data and methods into a separate file. Bless the references and call Exporter on your methods. Done!

        s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
[reply]

Back to Seekers of Perl Wisdom