Re: When are packages the right design choice?
by adrianh (Chancellor) on Jun 03, 2004 at 19:02 UTC
|
| [reply] |
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.
| [reply] |
|
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
| [reply] |
|
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
| [reply] |
|
|
|
|
| [reply] |
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.
| [reply] |
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
| [reply] |
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
| [reply] |
|
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.
| [reply] |
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. | [reply] |