You might find Damian Conway's ten rules for when to use OO of interest.

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.

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.

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.

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.

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 OO^TM 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!

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.