Its very simple to define a class. In Perl, a class is corresponds to a Package. To create a class in Perl, we first build a package. A package is a self-contained unit of user-defined variables and subroutines, which can be re-used over and over again. They provide a separate namespace within a Perl program that keeps subroutines and variables from conflicting with those in other packages.
The scope of the package definition extends to the end of the file, or until another package keyword is encountered. To create an instance of a class an object we need an object constructor. This constructor is a method defined within the package.
Most programmers choose to name this object constructor method new, but in Perl one can use any name. One can use any kind of Perl variable as an object in Perl. Most Perl programmers choose either references to arrays or hashes. When creating an object, you need to supply a constructor. This is a subroutine within a package that returns an object reference. The object reference is created by blessing a reference to the package's class.
For example:. Every method of a class passes first argument as class name. So in the above example class name would be "Person". Next rest of the arguments will be rest of the arguments passed to the method. You can use simple hash in your consturctor if you don't want to assign any value to any class variable. For example. Other object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data.
Perl does not have private variables but we can still use the concept of helper functions methods and ask programmers to not mess with our object innards. Lets have a look into complete example: Keep Person package and helper functions into Person. Object-oriented programming sometimes involves inheritance. Inheritance simply means allowing one class called the Child to inherit methods and attributes from another, called the Parent, so you don't have to write the same code again and again.
The parent module is one of several ways that Perl lets you define inheritance relationships. Perl allows multiple inheritance, which means that a class can inherit from multiple parents. While this is possible, we strongly recommend against it. Generally, you can use roles to do everything you can do with multiple inheritance, but in a cleaner way. Note that there's nothing wrong with defining multiple subclasses of a given class. This is both common and safe. Inheritance allows two classes to share code.
By default, every method in the parent class is also available in the child. The child can explicitly override a parent's method to provide its own implementation. The process of determining what method should be used is called method resolution. What Perl does is look at the object's class first File::MP3 in this case. If that class defines the method, then that class's version of the method is called.
If not, Perl looks at each parent class in turn. For File::MP3 , its only parent is File. If File inherited from DataSource , which inherited from Thing , then Perl would keep looking "up the chain" if necessary. When it finds the parent class that implements this method, the method is called. We mentioned multiple inheritance earlier. The main problem with multiple inheritance is that it greatly complicates method resolution.
See perlobj for more details. Encapsulation is the idea that an object is opaque. When another developer uses your class, they don't need to know how it is implemented, they just need to know what it does. Encapsulation is important for several reasons.
First, it allows you to separate the public API from the private implementation. This means you can change that implementation without breaking the API. Second, when classes are well encapsulated, they become easier to subclass. Ideally, a subclass uses the same APIs to access object data that its parent class uses. In reality, subclassing sometimes involves violating encapsulation, but a good API can minimize the need to do this.
We mentioned earlier that most Perl objects are implemented as hashes under the hood. The principle of encapsulation tells us that we should not rely on this. Instead, we should use accessor methods to access the data in that hash. The object systems that we recommend below all automate the generation of accessor methods. If you use one of them, you should never have to access the object as a hash directly.
In object-oriented code, we often find that one object references another object. This is called composition , or a has-a relationship. This is a perfect example of composition. We could go even further, and make the path and content accessors return objects as well.
The File class would then be composed of several other objects. Roles are something that a class does , rather than something that it is. Roles are relatively new to Perl, but have become rather popular.
Roles are applied to classes. Sometimes we say that classes consume roles. Roles are an alternative to inheritance for providing polymorphism. Let's assume we have two classes, Radio and Computer. We want to model that in our class definitions. We could create a parent class called HasOnOffSwitch , but that is very artificial.
Radios and computers are not specializations of this parent. This parent is really a rather ridiculous creation. This is where roles come in. It makes a lot of sense to create a HasOnOffSwitch role and apply it to both classes. Perl does not have any built-in way to express roles. In the past, people just bit the bullet and used multiple inheritance. Nowadays, there are several good choices on CPAN for using roles. Object Orientation is not the best solution to every problem. The data can be aggregated into obvious structures, especially if there's a large amount of data in each aggregate.
The various types of data aggregate form a natural hierarchy that facilitates the use of inheritance and polymorphism. 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. As we mentioned before, Perl's built-in OO system is very minimal, but also quite flexible. Over the years, many people have developed systems which build on top of Perl's built-in system to provide more features and convenience.
We strongly recommend that you use one of these systems. Even the most minimal of them eliminates a lot of repetitive boilerplate. There's really no good reason to write your classes from scratch in Perl.
If you are interested in the guts underlying these systems, check out perlobj. Moose bills itself as a "postmodern object system for Perl 5". Don't be scared, the "postmodern" label is a callback to Larry's description of Perl as "the first postmodern computer language". Moose provides a complete, modern OO system. Its biggest influence is the Common Lisp Object System, but it also borrows ideas from Smalltalk and several other languages.
Moose provides a layer of declarative "sugar" for defining classes. That sugar is just a set of exported functions that make declaring how your class works simpler and more palatable. This lets you describe what your class is, rather than having to tell Perl how to implement your class.
The has subroutine declares an attribute, and Moose automatically creates accessors for these attributes. It also takes care of creating a new method for you. This constructor knows about the attributes you declared, so you can set them when creating a new File. This tells Moose that this attribute must be a boolean value. If we try to set it to an invalid value, our code will throw an error. Perl's built-in introspection features are fairly minimal. Moose builds on top of them and creates a full introspection layer for your classes.
Through object, you can hide its complexity which is known as abstraction or encapsulation in object oriented programming. It means the client of the object does not need to care about the internal logic of the object but still can use the object through its interfaces methods. Inheritance means one class inherits both attributes and methods from another class. Inheritance enables you to reuse and extend existing classes without copy-n-paste the code or re-invent the wheel.
It means a method call can behave differently depending on the type of the object that calls it. We are going to define the Product class in Perl. With rule 1: a class is a package so here is the definition of the Product class in Product. In Perl, we use a subroutine or method named new to construct the object. The subroutine name is not mandatory so you can use any subroutine name you want, but be consistent.
When you create an object, you actually create a reference that knows what class it belongs to.
0コメント