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. For example, we can have a class Employee which inherits from Person. This is referred to as an "isa" relationship because an employee is a person. Perl has a special variable, ISA, to help with this. ISA governs method inheritance. So to create a new Employee class that will inherit methods and attributes from our Person class, we simply code: Keep this code into Employee.
Now Employee Class has all the methods and attributes inherited from Person class and you can use it as follows: Use main. The child class Employee inherits all the methods from parent class Person. But if you would like to override those methods in your child class then you can do it by givig your implementation.
You can add your additional functions in child class. It can done as follows: modify Employee. Perl offers a feature which you would not find any many other programming languages: a default subroutine.
This function is very useful for error handling purpose. If you have programmed using objects before, then you will be aware of the need to create a. Perl does this automatically for you as soon as the object goes out of scope. In case you want to implement your destructore which should take care of closing files or doing some extra processing then you need to define a special method called DESTROY.
This method will be called on the object just before Perl frees the memory allocated to it. In all other respects, the DESTROY method is just like any other, and you can do anything you like with the object in order to close it properly. Here is another nice example which will help you to understand Object Oriented Concepts of Perl. 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. This lets you ask questions like "what methods does the File class implement? Moose describes itself using its own introspection API.
Besides being a cool trick, this means that you can extend Moose using Moose itself. In addition, many modules on CPAN already use Moose , providing you with lots of examples to learn from. Moose is a very powerful tool, and we can't cover all of its features here.
We encourage you to learn more by reading the Moose documentation, starting with Moose::Manual. Moose can make your code slower to load. Moose itself is not small, and it does a lot of code generation when you define your class. This code generation means that your runtime code is as fast as it can be, but you pay for this when your modules are first loaded.
This load time hit can be a problem when startup speed is important, such as with a command-line script or a "plain vanilla" CGI script that must be loaded each time it is executed. Before you panic, know that many people do use Moose for command-line tools and other startup-sensitive code. We encourage you to try Moose out first before worrying about startup speed. Moose also has several dependencies on other modules. Most of these are small stand-alone modules, a number of which have been spun off from Moose.
Moose itself, and some of its dependencies, require a compiler. If you need to install your software on a system without a compiler, or if having any dependencies is a problem, then Moose may not be right for you. If you try Moose and find that one of these issues is preventing you from using Moose , we encourage you to consider Moo next. Moo implements a subset of Moose 's functionality in a simpler package. For most features that it does implement, the end-user API is identical to Moose , meaning you can switch from Moo to Moose quite easily.
Moo does not implement most of Moose 's introspection API, so it's often faster when loading your modules. Additionally, none of its dependencies require XS, so it can be installed on machines without a compiler.
One of Moo 's most compelling features is its interoperability with Moose. When someone tries to use Moose 's introspection API on a Moo class or role, it is transparently inflated into a Moose class or role. This makes it easier to incorporate Moo -using code into a Moose code base and vice versa. For example, a Moose class can subclass a Moo class using extends or consume a Moo role using with. The Moose authors hope that one day Moo can be made obsolete by improving Moose enough, but for now it provides a worthwhile alternative to Moose.
Class::Accessor is the polar opposite of Moose. It provides very few features, nor is it self-hosting. It is, however, very simple, pure Perl, and it has no non-core dependencies. It also provides a "Moose-like" API on demand for the features it supports. Even though it doesn't do much, it is still preferable to writing your own classes from scratch.
The antlers import flag tells Class::Accessor that you want to define your attributes using Moose -like syntax. The only parameter that you can pass to has is is. We recommend that you use this Moose-like syntax if you choose Class::Accessor since it means you will have a smoother upgrade path if you later decide to move to Moose.
Like Moose , Class::Accessor generates accessor methods and a constructor for your class. Finally, we have Class::Tiny. Perl provides a bless function, which is used to return a reference which ultimately becomes an object. It is very simple to define a class in Perl. A class is corresponding to a Perl Package in its simplest form.
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.
Perl Packages provide a separate namespace within a Perl program which keeps subroutines and variables independent 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 you can use any name.
You can use any kind of Perl variable as an object in Perl. Most Perl programmers choose either references to arrays or hashes. Let's create our constructor for our Person class using a Perl hash reference. When creating an object, you need to supply a constructor, which 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.
You can use simple hash in your consturctor if you don't want to assign any value to any class variable. Other object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and they provide accessor methods to modify object data. Perl does not have private variables but we can still use the concept of helper methods to manipulate object data.
Now lets have a look into complete example: Keep Person package and helper functions into Person. Object-oriented programming has very good and useful concept called inheritance. Inheritance simply means that properties and methods of a parent class will be available to the child classes.
0コメント