When to use OO in your projects

[ Perl tips index ]
[ Subscribe to Perl tips ]

This week we'll look at when you might use objects in your projects. This is based on Dr Damian Conway's rules with commentary by Perl Training Australia.

"Ten rules for when to use OO"

Use OO...

1. When your design is large, or is likely to become large.

2. When data is aggregated into obvious structures, especially if there's a lot of data in each aggregate.

A person's name is often not a good candidate for an object. A string of any length is still only a single piece of information. If however, you wish to associate other information with the name, such as age, address, phone number (enough data for example that you'd think to use a hash), then you have a good case for an object.

        my %person1 = (
                        name => "Julien Gileson",
                        age => 42,
                        address => "42 Halloway St"

3. When types of data form a natural hierarchy that lets us use inheritance.

Inheritance allows us to have a common set of operations shared by all similar objects, while still allowing specific operations for each specialied type. For example you may have a base class of queues which implements pushing and popping of objects and returning the number of elements in the queue.

At the same time you may derive one or more specialised types of queues from this base class which re-implement their own push function or which provide extra abilities as well.

4. When operations on data varies on data type.

Many similar types of data have similar operations. For example music stored on CD is a different kind of data than music stored on disk in mpeg or ogg vorbis format. However, although the code to achieve it would be different, both can be played. An OO model allows code similar to the following:

        foreach my $song ($cd_track, $mpeg, $ogg) {

5. When it's likely you'll have to add data types later.

Consider the above example. If our specification says that we want something which will handle mpeg files and music from CDs, we could code a solution to handle these two exact cases. However, as specifications tend to change over time it may become likely that we'll need to handle ogg vorbis files and other formats too.

If this is likely then a carefully designed OO model can allow us to add these in later without significant changes all over our original application.

6. When interactions between data is best shown by operators.

Perl's object model allows operators to be overloaded so that things work the way you'd like them to. For example

                $queue += $event;

is traditionally only meaningful if $queue and $event are numbers. However, with overloading, we can tell Perl that addition, when applied to a Queue object should call the push function.

Thus instead of writing:


we could write:

                $queue += $event;

or, potentially, if we wish to join a number of queues:

                $new_queue = $queue1 + $queue2;

7. When implementation of components is likely to change, especially in the same program.

Object oriented programming assists in data encapsulation. A class should be treated as a black box by the code which uses it. Defining clear interfaces allows the internals of the class to be changed as many times as necessary without affecting the rest of the project.

Thus if your class implements access to some data in a file, then the data's format could change from being in plain-text, to a flat-file database, to a full relational database without the rest of the application needing to change.

8. When the system design is already object-oriented.

9. When huge numbers of clients use your code

In addition to encapsulation, object oriented code encourages modularisation. By breaking your project up into separate modules it becomes easier to maintain. It also makes patching your customer's code cleaner too.

Furthermore, object oriented design can allow you to provide different classes to fulfil differing customer needs. Thus an Australian customer may recieve the Payroll::AU class while a European customer may receive Payroll::Eu.

10. When you have a piece of data on which many different operations are applied.

Consider a piece of data representing sound. This sound can be mixed, adjusted, run backwards, have echo effects added and many other kinds of operations. By wrapping it in a Perl object we can associate these operations with this kind of data. Afterall it doesn't make a lot of sense to apply echo effects to an image, for example, or to someone's age.

11. When the kinds of operations have standard names (check, process, etc).

The traditional way of handling identical names for operations on unrelated data is to use the data type in the subroutine name. For example.

                sub process_person { ... }

                sub process_payment { ... }

                sub process_music { ... }

Objects side-step this issue by associating the operation with the data allowing all of the subroutines to have the same name, but be in different name spaces. So:

                Person::process, Payment::process, Music::process.

This is the end of our small Object Oriented Perl thread. Next week we'll be covering good programming techniques in Perl.

[ Perl tips index ]
[ Subscribe to Perl tips ]

This Perl tip and associated text is copyright Perl Training Australia. You may freely distribute this text so long as it is distributed in full with this Copyright noticed attached.

If you have any questions please don't hesitate to contact us:

Email: contact@perltraining.com.au
Phone: 03 9354 6001 (Australia)
International: +61 3 9354 6001

Valid XHTML 1.0 Valid CSS