Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

When are packages the right design choice?

by fuzzyping (Chaplain)
on Jun 03, 2004 at 18:55 UTC ( [id://360359]=perlmeditation: print w/replies, xml ) Need Help??

I often find myself coding in OOP using the interfaces provided by CPAN authors. I also make a conscience effort to modularize code for easy reuse within the same script, often creating object-like structures for sake of "compartmentability". However, I've yet to create my own OO packages for large projects, either out of concern that I'll really screw something up, or an ignorance of the best way to break everything into classes.

What guidelines do other monks use to determine the right project for OO design methods? Is it a concscience design decision from the get-go, or is it a "fork in the road" that just happens when the time is right?

-fp
  • Comment on When are packages the right design choice?

Replies are listed 'Best First'.
Re: When are packages the right design choice?
by adrianh (Chancellor) on Jun 03, 2004 at 19:02 UTC
Re: When are packages the right design choice?
by hardburn (Abbot) on Jun 03, 2004 at 21:11 UTC

    My biggest gripe with most OO tutorials/books/whatever is that the example is usually something trivial that fits into an OO model neatly, such as types of animals or geometric shapes. In the real world, you're likely to encounter data that is not so clear.

    For instance, if a person can be a member of a committee, and there can be one president per committee, should the president be considered a type of member with special status, or should the president be completely seperated from the member class? I don't think there is a right answer to that, at least not with the data provided. There may even be a completely different solution I haven't thought of. Even after getting more details, the "right" answer may not be clear.

    I suggest "Object Oriented Analysis and Design" by Grady Booch. It's one of the few OO books I've seen that gives you examples that are small enough to be understood, but large enough to reflect the way a real program could be structured.

    ----
    send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

      My biggest gripe with most OO tutorials/books/whatever is that the example is usually something trivial that fits into an OO model neatly, such as types of animals or geometric shapes. In the real world, you're likely to encounter data that is not so clear.

      I agree. I worked hard to avoid using "a square ISA rectangle" type examples in my book. My primary OO example class is a logger called BOA::Logger for the fictitious Big Ol' Application. Instead of talking about inheritence as a way to express "natural" relationships, I tried to present it the way it's really used - as an extension mechanism to enhance an existing class. I also tried to give equal time to composition, an alternative to inheritence which often results in simpler code with equal or greater flexibility.

      -sam

        I worked hard to avoid using "a square ISA rectangle" type examples in my book.

        And that while that's a great example to explain why MI is so useful. A square is both a rectangle and a rhombus, but a rectangle that isn't a square isn't a rhombus, and a rhombus that doesn't have square corners isn't a rectangle. And both a rhombus and a rectangle are parallelograms.

        Abigail

      I suggest "Object Oriented Analysis and Design" by Grady Booch. It's one of the few OO books I've seen that gives you examples that are small enough to be understood, but large enough to reflect the way a real program could be structured.

      I'd recommend Meyer's "Object-oriented Software Construction" for similar reasons.

Re: When are packages the right design choice?
by duff (Parson) on Jun 03, 2004 at 21:55 UTC

    There's a dichotomy between your title and your text. Packages do not imply OOP. Packages are the right design choice when you have many subroutines that are related in some way; you group them by putting them in a package.

    As far as when to use OOP, Damian's got that one pretty much covered.

Re: When are packages the right design choice?
by dragonchild (Archbishop) on Jun 04, 2004 at 01:47 UTC
    Let's just put it this way - if your application is more than 200-300 lines, you should have a really good reason not break out into packages.

    Now, packages don't necessarily mean OO. They could be Exporter packages that simply contain a bunch of (related) subroutines and data structures. They could be full-fledged OO hierarchies. That's up to you. But, the package breakout isn't Perl or OO specific. It's good programming specific.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

Re: When are packages the right design choice?
by toma (Vicar) on Jun 04, 2004 at 04:31 UTC
    I run into a similar question. I use a hash to store variables used by a group of subroutines, and pass around a pointer to the hash instead of using argument lists. I create modules, so that the subroutines using this pointer are in a module.

    My training (from Conway) tells me that this is object-oriented code. The question I run into is, "When should I bless a hash pointer to make Real Perl OOTM code?"

    My answer is, "As soon as the API that I want to create benefits from it."

    It's all about the interface. I imagine that my subroutine calls look good, and are nicely documented with POD. The synopsis section of the POD is a working program that easily solves a real problem. The calls are easy-to-read and self-documenting.

    The bless statement makes it possible to create a better API under some circumstances. If I'm not going to make a good API, I don't bother with the trappings of OO.

    If I can imagine a good API, then it is worthwhile to fulfill my vision and implement it with the tools that are available. When I write this code, I often need a bless statement.

    Without the vision of a good API, the rules of thumb for "when to use OO" do not inspire me enough to bless my objects. I save my blessings for objects that I want to be proud of!

    It should work perfectly the first time! - toma

      pass around a pointer to the hash instead of using argument lists

      Err, you mean a reference to a hash. Perl doesn't have pointers.

      "When should I bless a hash pointer to make Real Perl OOTM code?"

      IMHO, you should just bless the sucker and be done with it. In the simple case, the worst that can happen is that you move the first argument to the left side of the sub's name (and it'll be a little slower, but that probably won't matter). But if you don't bless, you will have a much harder time getting inheirtance and polymorphism to work.

      There are many "trivial OO" systems, but they often break down under anything more than a trivial class heirachracy.

      ----
      send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Re: When are packages the right design choice?
by fireartist (Chaplain) on Jun 04, 2004 at 09:01 UTC
    I particularly agree with toma's comments above about the API. Once you know how to 'do' Perl OO, the hard part is designing the API.
    My advice is to learn the basics of Perl OO, firstly from the docs perlboot, perltoot, perltooc, perlbot. I also found this book by TheDamian very good.

    Then I suggest you try out using the techniques in a few small projects. I know this goes against normal guidelines of when to use OO, but I think it's important to be able to experiment and not have to worry about making mistakes.
    I think spending time designing the API before coding is vital, as there's nothing worse that working on a large project and having to make changes throughout when you realise the API is flawed.
    Once you've go the API down, then you should be able to make changes to the object structure without having to change everything that uses it. It rewarding when you can do that and you know it's because you've got a good design.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://360359]
Approved by kvale
Front-paged by hsmyers
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-04-24 02:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found