The following collection of tricks and hints is intended to whet curious appetites about such things as the use of instance variables and the mechanics of object and class relationships. The reader is encouraged to consult relevant textbooks for discussion of Object Oriented definitions and methodology. This is not intended as a tutorial for object-oriented programming or as a comprehensive guide to Perl's object oriented features, nor should it be construed as a style guide.
Do not attempt to verify the type of $self. That'll break if the class is inherited, when the type of $self is valid but its package isn't what you expect. See rule 5.
If an object-oriented ( OO ) or indirect-object ( IO ) syntax was used, then the object is probably the correct type and there's no need to become paranoid about it. Perl isn't a paranoid language anyway. If people subvert the OO or IO syntax then they probably know what they're doing and you should let them do it. See rule 1.
Use the two-argument form of bless(). Let a subclass use your constructor. See `` INHERITING A CONSTRUCTOR ''.
The subclass is allowed to know things about its immediate superclass, the superclass is allowed to know nothing about a subclass.
Don't be trigger happy with inheritance. A ``using, ``containing, or ``delegation relationship (some sort of aggregation, at least) is often more appropriate. See `` OBJECT RELATIONSHIPS , `` USING RELATIONSHIP WITH SDBM , and `` DELEGATION .
The object is the namespace. Make package globals accessible via the object. This will remove the guess work about the symbol's home package. See `` CLASS CONTEXT AND THE OBJECT ''.
IO syntax is certainly less noisy, but it is also prone to ambiguities that can cause difficult-to-find bugs. Allow people to use the sure-thing OO syntax, even if you don't like it.
Do not use function-call syntax on a method. You're going to be bitten someday. Someone might move that method into a superclass and your code will be broken. On top of that you're feeding the paranoia in rule 2.
An anonymous array or anonymous hash can be used to hold instance variables. Named parameters are also demonstrated.
An anonymous scalar can be used when only one instance variable is needed.
This example demonstrates how one might inherit instance variables from a superclass for inclusion in the new class. This requires calling the superclass's constructor and adding one's own instance variables to the new object.
The following demonstrates how one might implement ``containing and ``using relationships between objects.
The following example demonstrates how to override a superclass method and then call the overridden method. The SUPER pseudo-class allows the programmer to call an overridden superclass method without actually knowing where that method is defined.
This example demonstrates an interface for the SDBM class. This creates a ``using'' relationship between the SDBM class and the new class Mydbm.
One strength of Object-Oriented languages is the ease with which old code can use new code. The following examples will demonstrate first how one can hinder code reuse and then how one can promote code reuse.
This first example illustrates a class which uses a fully-qualified method call to access the ``private method BAZ (). The second example will show that it is impossible to override the BAZ ()'' method.
Now we try to override the BAZ () method. We would like FOO::bar() to call GOOP::BAZ (), but this cannot happen because FOO::bar() explicitly calls FOO::private::BAZ().
To create reusable code we must modify class FOO , flattening class FOO::private. The next example shows a reusable class FOO which allows the method GOOP::BAZ () to be used in place of FOO::BAZ ().
Use the object to solve package and class context problems. Everything a method needs should be available via the object or should be passed as a parameter to the method.
A class will sometimes have static or global data to be used by the methods. A subclass may want to override that data and replace it with new data. When this happens the superclass may not know how to find the new copy of the data.
This problem can be solved by using the object to define the context of the method. Let the method look in the object for a reference to the data. The alternative is to force the method to go hunting for the data (``Is it in my class, or in a subclass? Which subclass?''), and this can be inconvenient and will lead to hackery. It is better just to let the object tell the method where that data is located.
An inheritable constructor should use the second form of bless() which allows blessing directly into a specified class. Notice in this example that the object will be a BAR not a FOO , even though the constructor is in class FOO .
Some classes, such as SDBM_File, cannot be effectively subclassed because they create foreign objects. Such a class can be extended with some sort of aggregation technique such as the ``using'' relationship mentioned earlier or by delegation.
The following example demonstrates delegation using an AUTOLOAD () function to perform message-forwarding. This will allow the Mydbm object to behave exactly like an SDBM_File object. The Mydbm class could now extend the behavior by adding custom FETCH () and STORE () methods, if this is desired.