To the user of a class, the most important piece of information is the interface describing how to use the class. Usually this interface can easily be summarized in a few examples provided by the author of the class. The details of how the class is implemented may change; as long as the interface remains the same, your code needn't change even when the internals of the class you're using change. This provides good modularization, protecting your system from the ripple effects of changes in individual components, thus making your code as a whole more robust and reliable. This is one of the main benefits of OO design.
With OO design, you know that:
A class is a package.
An object is a reference to a data structure in the class, that is marked (or "blessed") with the class name.
A method is a subroutine in the class.
Several other concepts and their associated terminology are also important in object-oriented programming. For instance, inheritance enables one class to use the definitions from another class, while adding to or changing the definitions.
At this point you may be wondering: if an object is really just a data structure (usually a reference to a hash), and if a method is really just a subroutine, then why all this new terminology? The answer is that the framework imposed upon these data structures and subroutines, in which each data structure has a defined set of subroutines that alone can access the data structure, is indeed a new level of abstraction?a new set of constraints influencing the programming structure.
These constraints have proved to be so frequently useful that the new terminology of class, object, and method does say something new about the data structures and subroutines involved. Also, there are some new features such as bless and the arrow notation that cause subroutines to behave a little differently, as has been mentioned already, and will be explained in detail. But surprisingly few such additions are needed to transition from a knowledge of Perl's declarative style to Perl's OO style.
When you program using a defined class with its methods and objects, you can gain access to the class data only with the class methods provided by the class designer. The restriction of access to a class's data to the methods alone is called encapsulation. From the standpoint of the programmer using the class, exactly how the methods and objects are implemented isn't necessarily a concern. As a programmer using the class, you can regard the class as a black box; you don't have to look inside to see how it is implemented. Usually, it's only the programer writing the code who needs to worry about that.
One final point: in the field of OO programming, different authors define terms in different ways and present differing sets of essential concepts. Be warned that considerable diversity exists in the literature and among the languages that deal with object-orientation. The excellent book Object Oriented Perl (see Section 3.14) includes a table that matches basic concepts with some of the alternate terminologies for those concepts.
In OO Perl programming, most objects are implemented as hashes and are accessed with blessed references to the hashes.
Each individual component of data in an object?for example, the name of a gene?is called an attribute and is assigned a value. The attribute/value nature of the component of an object is well suited to be represented as a key/value pair in a hash data structure.
It is quite possible, and sometimes desirable, to use other data structures such as scalars or arrays as the basis for objects. However, most situations are well handled by the hash data structure. Its benefits include having a name (key) for the data (value), allowing arguments to be specified in any order, and very fast lookup speed.
In this book, all objects are based on the hash data structure.