Previous Page
Next Page

15.2. Criteria

Choose object orientation using appropriate criteria.

When deciding whether to use object orientation, look for features of the problemor of the proposed solutionthat suggest that OO might be a good fit. For example, object orientation might be the right approach in any of the following situations:


The system being designed is large, or is likely to become large

Object orientation helps in large systems, because it breaks them down into smaller decoupled systems (called "classes"), which are generally still simple enough to fit in a single brainunlike the large system as a whole.


The data can be aggregated into obvious structures, especially if there's a large amount of data in each aggregate

Object orientation is about classifying data into coherent chunks (called "objects") and then specifying how those chunks can interact and change over time. If there are natural clusterings in the data to be handled by your system, then the natural place for those clusterings is probably inside an object. And the larger the amount of data in each chunk, the more likely it is that you're going to need to think of those chunks at some higher, more abstract level. It's also more likely that you'll need to control access to that data more tightly to ensure it remains consistent.


The various types of data aggregate form a natural hierarchy that facilitates the use of inheritance and polymorphism

Object orientation provides a way to capture, express, and take advantage of the abstract relationships between chunks of data in your code. If one kind of data is a special form of another kind of data (a restriction, or elaboration, or some other variation), then organizing that data into class hierarchies can minimize the amount of nearly identical code that has to be written.


You have a piece of data on which many different operations are applied

You're going to be calling many different subroutines on the same data. But Perl subroutines don't type-check their arguments in any way, so it's very easy to send the wrong type of data to the wrong subroutine. If that happens, Perl's otherwise helpful implicit behaviours[*] can conspire to mask the mistake, making it vastly harder to detect and correct. In contrast, if the data is an object, then only those subroutines that are methods of the appropriate class can ever be called on that data.

[*] Such as the automatic interconversion of strings and numbers, and the autovivification of non-existent hash and array elements.


You need to perform the same general operations on related types of data, but with slight variations depending on the specific type of data the operations are applied to

For example, if every piece of equipment needs to have check( ), register( ), deploy( ), and activate( ) applied to it, but the process of checking, registration, deployment, and activation differs for each type of equipment, then you have the textbook conditions for using polymorphic method calls.


It's likely you'll have to add new data types later

New data types will usually be related in some way to existing data types. If those existing data types are in class hierarchies, you'll be able to use inheritance to create the new type with minimal extra effort, and little or no duplication of code. Better still, the new data type will then be usable in existing code, without the need to modify that code in any way.


The typical interactions between pieces of data are best represented by operators

Perl operators can be overloaded only when at least one of their operands is an object.


The implementation of individual components of the system is likely to change over time

Proper encapsulation of objects can ensure that any code that uses those objects is isolated from the details of how the objects' data is stored and manipulated. This means that no source code outside your control will ever rely on those details, so you're free to change how the object is implemented whenever necessary, without having to rewrite huge amounts of client code.


The system design is already object-oriented

If the designers have designed a huge, complex, awkward nail, then the big, familiar, comfortable hammer of OO will almost certainly be the best tool for the job.


Large numbers of other programmers will be using your code modules

Object-oriented modules tend to have interfaces that are more clearly defined, which often makes them easier to understand and use correctly. Unlike procedural APIs that export subroutines into the caller's symbol table, classes never pollute client namespaces, and therefore are much less likely to clash with other modules. And the need to use object constructors and accessors can often improve the integrity of data as well, because it's easy to embed vetting procedures into the initialization or access methods.

    Previous Page
    Next Page