| 1 | =head1 NAME
|
|---|
| 2 |
|
|---|
| 3 | perlbot - Bag'o Object Tricks (the BOT)
|
|---|
| 4 |
|
|---|
| 5 | =head1 DESCRIPTION
|
|---|
| 6 |
|
|---|
| 7 | The following collection of tricks and hints is intended to whet curious
|
|---|
| 8 | appetites about such things as the use of instance variables and the
|
|---|
| 9 | mechanics of object and class relationships. The reader is encouraged to
|
|---|
| 10 | consult relevant textbooks for discussion of Object Oriented definitions and
|
|---|
| 11 | methodology. This is not intended as a tutorial for object-oriented
|
|---|
| 12 | programming or as a comprehensive guide to Perl's object oriented features,
|
|---|
| 13 | nor should it be construed as a style guide. If you're looking for tutorials,
|
|---|
| 14 | be sure to read L<perlboot>, L<perltoot>, and L<perltooc>.
|
|---|
| 15 |
|
|---|
| 16 | The Perl motto still holds: There's more than one way to do it.
|
|---|
| 17 |
|
|---|
| 18 | =head1 OO SCALING TIPS
|
|---|
| 19 |
|
|---|
| 20 | =over 5
|
|---|
| 21 |
|
|---|
| 22 | =item 1
|
|---|
| 23 |
|
|---|
| 24 | Do not attempt to verify the type of $self. That'll break if the class is
|
|---|
| 25 | inherited, when the type of $self is valid but its package isn't what you
|
|---|
| 26 | expect. See rule 5.
|
|---|
| 27 |
|
|---|
| 28 | =item 2
|
|---|
| 29 |
|
|---|
| 30 | If an object-oriented (OO) or indirect-object (IO) syntax was used, then the
|
|---|
| 31 | object is probably the correct type and there's no need to become paranoid
|
|---|
| 32 | about it. Perl isn't a paranoid language anyway. If people subvert the OO
|
|---|
| 33 | or IO syntax then they probably know what they're doing and you should let
|
|---|
| 34 | them do it. See rule 1.
|
|---|
| 35 |
|
|---|
| 36 | =item 3
|
|---|
| 37 |
|
|---|
| 38 | Use the two-argument form of bless(). Let a subclass use your constructor.
|
|---|
| 39 | See L<INHERITING A CONSTRUCTOR>.
|
|---|
| 40 |
|
|---|
| 41 | =item 4
|
|---|
| 42 |
|
|---|
| 43 | The subclass is allowed to know things about its immediate superclass, the
|
|---|
| 44 | superclass is allowed to know nothing about a subclass.
|
|---|
| 45 |
|
|---|
| 46 | =item 5
|
|---|
| 47 |
|
|---|
| 48 | Don't be trigger happy with inheritance. A "using", "containing", or
|
|---|
| 49 | "delegation" relationship (some sort of aggregation, at least) is often more
|
|---|
| 50 | appropriate. See L<OBJECT RELATIONSHIPS>, L<USING RELATIONSHIP WITH SDBM>,
|
|---|
| 51 | and L<"DELEGATION">.
|
|---|
| 52 |
|
|---|
| 53 | =item 6
|
|---|
| 54 |
|
|---|
| 55 | The object is the namespace. Make package globals accessible via the
|
|---|
| 56 | object. This will remove the guess work about the symbol's home package.
|
|---|
| 57 | See L<CLASS CONTEXT AND THE OBJECT>.
|
|---|
| 58 |
|
|---|
| 59 | =item 7
|
|---|
| 60 |
|
|---|
| 61 | IO syntax is certainly less noisy, but it is also prone to ambiguities that
|
|---|
| 62 | can cause difficult-to-find bugs. Allow people to use the sure-thing OO
|
|---|
| 63 | syntax, even if you don't like it.
|
|---|
| 64 |
|
|---|
| 65 | =item 8
|
|---|
| 66 |
|
|---|
| 67 | Do not use function-call syntax on a method. You're going to be bitten
|
|---|
| 68 | someday. Someone might move that method into a superclass and your code
|
|---|
| 69 | will be broken. On top of that you're feeding the paranoia in rule 2.
|
|---|
| 70 |
|
|---|
| 71 | =item 9
|
|---|
| 72 |
|
|---|
| 73 | Don't assume you know the home package of a method. You're making it
|
|---|
| 74 | difficult for someone to override that method. See L<THINKING OF CODE REUSE>.
|
|---|
| 75 |
|
|---|
|
|---|
