argra****@users*****
argra****@users*****
2013年 11月 1日 (金) 04:02:15 JST
Index: docs/perl/5.16.1/perlootut.pod diff -u /dev/null docs/perl/5.16.1/perlootut.pod:1.1 --- /dev/null Fri Nov 1 04:02:15 2013 +++ docs/perl/5.16.1/perlootut.pod Fri Nov 1 04:02:15 2013 @@ -0,0 +1,1849 @@ + +=encoding euc-jp + +=for comment +Consistent formatting of this file is achieved with: + perl ./Porting/podtidy pod/perlootut.pod + +=head1 NAME + +=begin original + +perlootut - Object-Oriented Programming in Perl Tutorial + +=end original + +perlootut - Perl でのオブジェクト指向プログラミングのチュートリアル + +=head1 DATE + +=begin original + +This document was created in February, 2011. + +=end original + +この文書は 2011 年 2 月に作成されました。 + +=head1 DESCRIPTION + +=begin original + +This document provides an introduction to object-oriented programming +in Perl. It begins with a brief overview of the concepts behind object +oriented design. Then it introduces several different OO systems from +L<CPAN|http://search.cpan.org> which build on top of what Perl +provides. + +=end original + +This document provides an introduction to object-oriented programming +in Perl. It begins with a brief overview of the concepts behind object +oriented design. Then it introduces several different OO systems from +L<CPAN|http://search.cpan.org> which build on top of what Perl +provides. +(TBT) + +=begin original + +By default, Perl's built-in OO system is very minimal, leaving you to +do most of the work. This minimalism made a lot of sense in 1994, but +in the years since Perl 5.0 we've seen a number of common patterns +emerge in Perl OO. Fortunately, Perl's flexibility has allowed a rich +ecosystem of Perl OO systems to flourish. + +=end original + +By default, Perl's built-in OO system is very minimal, leaving you to +do most of the work. This minimalism made a lot of sense in 1994, but +in the years since Perl 5.0 we've seen a number of common patterns +emerge in Perl OO. Fortunately, Perl's flexibility has allowed a rich +ecosystem of Perl OO systems to flourish. +(TBT) + +=begin original + +If you want to know how Perl OO works under the hood, the L<perlobj> +document explains the nitty gritty details. + +=end original + +If you want to know how Perl OO works under the hood, the L<perlobj> +document explains the nitty gritty details. +(TBT) + +=begin original + +This document assumes that you already understand the basics of Perl +syntax, variable types, operators, and subroutine calls. If you don't +understand these concepts yet, please read L<perlintro> first. You +should also read the L<perlsyn>, L<perlop>, and L<perlsub> documents. + +=end original + +This document assumes that you already understand the basics of Perl +syntax, variable types, operators, and subroutine calls. If you don't +understand these concepts yet, please read L<perlintro> first. You +should also read the L<perlsyn>, L<perlop>, and L<perlsub> documents. +(TBT) + +=head1 OBJECT-ORIENTED FUNDAMENTALS + +(オブジェクト指向の基本) + +=begin original + +Most object systems share a number of common concepts. You've probably +heard terms like "class", "object, "method", and "attribute" before. +Understanding the concepts will make it much easier to read and write +object-oriented code. If you're already familiar with these terms, you +should still skim this section, since it explains each concept in terms +of Perl's OO implementation. + +=end original + +Most object systems share a number of common concepts. You've probably +heard terms like "class", "object, "method", and "attribute" before. +Understanding the concepts will make it much easier to read and write +object-oriented code. If you're already familiar with these terms, you +should still skim this section, since it explains each concept in terms +of Perl's OO implementation. +(TBT) + +=begin original + +Perl's OO system is class-based. Class-based OO is fairly common. It's +used by Java, C++, C#, Python, Ruby, and many other languages. There +are other object orientation paradigms as well. JavaScript is the most +popular language to use another paradigm. JavaScript's OO system is +prototype-based. + +=end original + +Perl's OO system is class-based. Class-based OO is fairly common. It's +used by Java, C++, C#, Python, Ruby, and many other languages. There +are other object orientation paradigms as well. JavaScript is the most +popular language to use another paradigm. JavaScript's OO system is +prototype-based. +(TBT) + +=head2 Object + +(オブジェクト) + +=begin original + +An B<object> is a data structure that bundles together data and +subroutines which operate on that data. An object's data is called +B<attributes>, and its subroutines are called B<methods>. An object can +be thought of as a noun (a person, a web service, a computer). + +=end original + +An B<object> is a data structure that bundles together data and +subroutines which operate on that data. An object's data is called +B<attributes>, and its subroutines are called B<methods>. An object can +be thought of as a noun (a person, a web service, a computer). +(TBT) + +=begin original + +An object represents a single discrete thing. For example, an object +might represent a file. The attributes for a file object might include +its path, content, and last modification time. If we created an object +to represent F</etc/hostname> on a machine named "foo.example.com", +that object's path would be "/etc/hostname", its content would be +"foo\n", and it's last modification time would be 1304974868 seconds +since the beginning of the epoch. + +=end original + +An object represents a single discrete thing. For example, an object +might represent a file. The attributes for a file object might include +its path, content, and last modification time. If we created an object +to represent F</etc/hostname> on a machine named "foo.example.com", +that object's path would be "/etc/hostname", its content would be +"foo\n", and it's last modification time would be 1304974868 seconds +since the beginning of the epoch. +(TBT) + +=begin original + +The methods associated with a file might include C<rename()> and +C<write()>. + +=end original + +The methods associated with a file might include C<rename()> and +C<write()>. +(TBT) + +=begin original + +In Perl most objects are hashes, but the OO systems we recommend keep +you from having to worry about this. In practice, it's best to consider +an object's internal data structure opaque. + +=end original + +In Perl most objects are hashes, but the OO systems we recommend keep +you from having to worry about this. In practice, it's best to consider +an object's internal data structure opaque. +(TBT) + +=head2 Class + +(クラス) + +=begin original + +A B<class> defines the behavior of a category of objects. A class is a +name for a category (like "File"), and a class also defines the +behavior of objects in that category. + +=end original + +A B<class> defines the behavior of a category of objects. A class is a +name for a category (like "File"), and a class also defines the +behavior of objects in that category. +(TBT) + +=begin original + +All objects belong to a specific class. For example, our +F</etc/hostname> object belongs to the C<File> class. When we want to +create a specific object, we start with its class, and B<construct> or +B<instantiate> an object. A specific object is often referred to as an +B<instance> of a class. + +=end original + +All objects belong to a specific class. For example, our +F</etc/hostname> object belongs to the C<File> class. When we want to +create a specific object, we start with its class, and B<construct> or +B<instantiate> an object. A specific object is often referred to as an +B<instance> of a class. +(TBT) + +=begin original + +In Perl, any package can be a class. The difference between a package +which is a class and one which isn't is based on how the package is +used. Here's our "class declaration" for the C<File> class: + +=end original + +In Perl, any package can be a class. The difference between a package +which is a class and one which isn't is based on how the package is +used. Here's our "class declaration" for the C<File> class: +(TBT) + + package File; + +=begin original + +In Perl, there is no special keyword for constructing an object. +However, most OO modules on CPAN use a method named C<new()> to +construct a new object: + +=end original + +In Perl, there is no special keyword for constructing an object. +However, most OO modules on CPAN use a method named C<new()> to +construct a new object: +(TBT) + + my $hostname = File->new( + path => '/etc/hostname', + content => "foo\n", + last_mod_time => 1304974868, + ); + +=begin original + +(Don't worry about that C<< -> >> operator, it will be explained +later.) + +=end original + +(Don't worry about that C<< -> >> operator, it will be explained +later.) +(TBT) + +=head3 Blessing + +(bless) + +=begin original + +As we said earlier, most Perl objects are hashes, but an object can be +an instance of any Perl data type (scalar, array, etc.). Turning a +plain data structure into an object is done by B<blessing> that data +structure using Perl's C<bless> function. + +=end original + +As we said earlier, most Perl objects are hashes, but an object can be +an instance of any Perl data type (scalar, array, etc.). Turning a +plain data structure into an object is done by B<blessing> that data +structure using Perl's C<bless> function. +(TBT) + +=begin original + +While we strongly suggest you don't build your objects from scratch, +you should know the term B<bless>. A B<blessed> data structure (aka "a +referent") is an object. We sometimes say that an object has been +"blessed into a class". + +=end original + +While we strongly suggest you don't build your objects from scratch, +you should know the term B<bless>. A B<blessed> data structure (aka "a +referent") is an object. We sometimes say that an object has been +"blessed into a class". +(TBT) + +=begin original + +Once a referent has been blessed, the C<blessed> function from the +L<Scalar::Util> core module can tell us its class name. This subroutine +returns an object's class when passed an object, and false otherwise. + +=end original + +Once a referent has been blessed, the C<blessed> function from the +L<Scalar::Util> core module can tell us its class name. This subroutine +returns an object's class when passed an object, and false otherwise. +(TBT) + + use Scalar::Util 'blessed'; + + print blessed($hash); # undef + print blessed($hostname); # File + +=head3 Constructor + +(コンストラクタ) + +=begin original + +A B<constructor> creates a new object. In Perl, a class's constructor +is just another method, unlike some other languages, which provide +syntax for constructors. Most Perl classes use C<new> as the name for +their constructor: + +=end original + +A B<constructor> creates a new object. In Perl, a class's constructor +is just another method, unlike some other languages, which provide +syntax for constructors. Most Perl classes use C<new> as the name for +their constructor: +(TBT) + + my $file = File->new(...); + +=head2 Methods + +(メソッド) + +=begin original + +You already learned that a B<method> is a subroutine that operates on +an object. You can think of a method as the things that an object can +I<do>. If an object is a noun, then methods are its verbs (save, print, +open). + +=end original + +You already learned that a B<method> is a subroutine that operates on +an object. You can think of a method as the things that an object can +I<do>. If an object is a noun, then methods are its verbs (save, print, +open). +(TBT) + +=begin original + +In Perl, methods are simply subroutines that live in a class's package. +Methods are always written to receive the object as their first +argument: + +=end original + +In Perl, methods are simply subroutines that live in a class's package. +Methods are always written to receive the object as their first +argument: +(TBT) + + sub print_info { + my $self = shift; + + print "This file is at ", $self->path, "\n"; + } + + $file->print_info; + # The file is at /etc/hostname + +=begin original + +What makes a method special is I<how it's called>. The arrow operator +(C<< -> >>) tells Perl that we are calling a method. + +=end original + +What makes a method special is I<how it's called>. The arrow operator +(C<< -> >>) tells Perl that we are calling a method. +(TBT) + +=begin original + +When we make a method call, Perl arranges for the method's B<invocant> +to be passed as the first argument. B<Invocant> is a fancy name for the +thing on the left side of the arrow. The invocant can either be a class +name or an object. We can also pass additional arguments to the method: + +=end original + +When we make a method call, Perl arranges for the method's B<invocant> +to be passed as the first argument. B<Invocant> is a fancy name for the +thing on the left side of the arrow. The invocant can either be a class +name or an object. We can also pass additional arguments to the method: +(TBT) + + sub print_info { + my $self = shift; + my $prefix = shift // "This file is at "; + + print $prefix, ", ", $self->path, "\n"; + } + + $file->print_info("The file is located at "); + # The file is located at /etc/hostname + +=head2 Attributes + +(属性) + +=begin original + +Each class can define its B<attributes>. When we instantiate an object, +we assign values to those attributes. For example, every C<File> object +has a path. Attributes are sometimes called B<properties>. + +=end original + +Each class can define its B<attributes>. When we instantiate an object, +we assign values to those attributes. For example, every C<File> object +has a path. Attributes are sometimes called B<properties>. +(TBT) + +=begin original + +Perl has no special syntax for attributes. Under the hood, attributes +are often stored as keys in the object's underlying hash, but don't +worry about this. + +=end original + +Perl has no special syntax for attributes. Under the hood, attributes +are often stored as keys in the object's underlying hash, but don't +worry about this. +(TBT) + +=begin original + +We recommend that you only access attributes via B<accessor> methods. +These are methods that can get or set the value of each attribute. We +saw this earlier in the C<print_info()> example, which calls C<< +$self->path >>. + +=end original + +We recommend that you only access attributes via B<accessor> methods. +These are methods that can get or set the value of each attribute. We +saw this earlier in the C<print_info()> example, which calls C<< +$self->path >>. +(TBT) + +=begin original + +You might also see the terms B<getter> and B<setter>. These are two +types of accessors. A getter gets the attribute's value, while a setter +sets it. Another term for a setter is B<mutator> + +=end original + +You might also see the terms B<getter> and B<setter>. These are two +types of accessors. A getter gets the attribute's value, while a setter +sets it. Another term for a setter is B<mutator> +(TBT) + +=begin original + +Attributes are typically defined as read-only or read-write. Read-only +attributes can only be set when the object is first created, while +read-write attributes can be altered at any time. + +=end original + +Attributes are typically defined as read-only or read-write. Read-only +attributes can only be set when the object is first created, while +read-write attributes can be altered at any time. +(TBT) + +=begin original + +The value of an attribute may itself be another object. For example, +instead of returning its last mod time as a number, the C<File> class +could return a L<DateTime> object representing that value. + +=end original + +The value of an attribute may itself be another object. For example, +instead of returning its last mod time as a number, the C<File> class +could return a L<DateTime> object representing that value. +(TBT) + +=begin original + +It's possible to have a class that does not expose any publicly +settable attributes. Not every class has attributes and methods. + +=end original + +It's possible to have a class that does not expose any publicly +settable attributes. Not every class has attributes and methods. +(TBT) + +=head2 Polymorphism + +(多態性) + +=begin original + +B<Polymorphism> is a fancy way of saying that objects from two +different classes share an API. For example, we could have C<File> and +C<WebPage> classes which both have a C<print_content()> method. This +method might produce different output for each class, but they share a +common interface. + +=end original + +B<Polymorphism> is a fancy way of saying that objects from two +different classes share an API. For example, we could have C<File> and +C<WebPage> classes which both have a C<print_content()> method. This +method might produce different output for each class, but they share a +common interface. +(TBT) + +=begin original + +While the two classes may differ in many ways, when it comes to the +C<print_content()> method, they are the same. This means that we can +try to call the C<print_content()> method on an object of either class, +and B<we don't have to know what class the object belongs to!> + +=end original + +While the two classes may differ in many ways, when it comes to the +C<print_content()> method, they are the same. This means that we can +try to call the C<print_content()> method on an object of either class, +and B<we don't have to know what class the object belongs to!> +(TBT) + +=begin original + +Polymorphism is one of the key concepts of object-oriented design. + +=end original + +Polymorphism is one of the key concepts of object-oriented design. +(TBT) + +=head2 Inheritance + +(継承) + +=begin original + +B<Inheritance> lets you create a specialized version of an existing +class. Inheritance lets the new class to reuse the methods and +attributes of another class. + +=end original + +B<Inheritance> lets you create a specialized version of an existing +class. Inheritance lets the new class to reuse the methods and +attributes of another class. +(TBT) + +=begin original + +For example, we could create an C<File::MP3> class which B<inherits> +from C<File>. An C<File::MP3> B<is-a> I<more specific> type of C<File>. +All mp3 files are files, but not all files are mp3 files. + +=end original + +For example, we could create an C<File::MP3> class which B<inherits> +from C<File>. An C<File::MP3> B<is-a> I<more specific> type of C<File>. +All mp3 files are files, but not all files are mp3 files. +(TBT) + +=begin original + +We often refer to inheritance relationships as B<parent-child> or +C<superclass/subclass> relationships. Sometimes we say that the child +has an B<is-a> relationship with its parent class. + +=end original + +We often refer to inheritance relationships as B<parent-child> or +C<superclass/subclass> relationships. Sometimes we say that the child +has an B<is-a> relationship with its parent class. +(TBT) + +=begin original + +C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a +B<subclass> of C<File>. + +=end original + +C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a +B<subclass> of C<File>. +(TBT) + + package File::MP3; + + use parent 'File'; + +=begin original + +The L<parent> module is one of several ways that Perl lets you define +inheritance relationships. + +=end original + +The L<parent> module is one of several ways that Perl lets you define +inheritance relationships. +(TBT) + +=begin original + +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 B<roles> to do everything you can do +with multiple inheritance, but in a cleaner way. + +=end original + +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 B<roles> to do everything you can do +with multiple inheritance, but in a cleaner way. +(TBT) + +=begin original + +Note that there's nothing wrong with defining multiple subclasses of a +given class. This is both common and safe. For example, we might define +C<File::MP3::FixedBitrate> and C<File::MP3::VariableBitrate> classes to +distinguish between different types of mp3 file. + +=end original + +Note that there's nothing wrong with defining multiple subclasses of a +given class. This is both common and safe. For example, we might define +C<File::MP3::FixedBitrate> and C<File::MP3::VariableBitrate> classes to +distinguish between different types of mp3 file. +(TBT) + +=head3 Overriding methods and method resolution + +(メソッドのオーバーライドとメソッド解決) + +=begin original + +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 B<override> a parent's method to provide its own +implementation. For example, if we have an C<File::MP3> object, it has +the C<print_info()> method from C<File>: + +=end original + +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 B<override> a parent's method to provide its own +implementation. For example, if we have an C<File::MP3> object, it has +the C<print_info()> method from C<File>: +(TBT) + + my $cage = File::MP3->new( + path => 'mp3s/My-Body-Is-a-Cage.mp3', + content => $mp3_data, + last_mod_time => 1304974868, + title => 'My Body Is a Cage', + ); + + $cage->print_info; + # The file is at mp3s/My-Body-Is-a-Cage.mp3 + +=begin original + +If we wanted to include the mp3's title in the greeting, we could +override the method: + +=end original + +If we wanted to include the mp3's title in the greeting, we could +override the method: +(TBT) + + package File::MP3; + + use parent 'File'; + + sub print_info { + my $self = shift; + + print "This file is at ", $self->path, "\n"; + print "Its title is ", $self->title, "\n"; + } + + $cage->print_info; + # The file is at mp3s/My-Body-Is-a-Cage.mp3 + # Its title is My Body Is a Cage + +=begin original + +The process of determining what method should be used is called +B<method resolution>. What Perl does is look at the object's class +first (C<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 C<File::MP3>, its only parent is +C<File>. If C<File::MP3> does not define the method, but C<File> does, +then Perl calls the method in C<File>. + +=end original + +The process of determining what method should be used is called +B<method resolution>. What Perl does is look at the object's class +first (C<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 C<File::MP3>, its only parent is +C<File>. If C<File::MP3> does not define the method, but C<File> does, +then Perl calls the method in C<File>. +(TBT) + +=begin original + +If C<File> inherited from C<DataSource>, which inherited from C<Thing>, +then Perl would keep looking "up the chain" if necessary. + +=end original + +If C<File> inherited from C<DataSource>, which inherited from C<Thing>, +then Perl would keep looking "up the chain" if necessary. +(TBT) + +=begin original + +It is possible to explicitly call a parent method from a child: + +=end original + +It is possible to explicitly call a parent method from a child: +(TBT) + + package File::MP3; + + use parent 'File'; + + sub print_info { + my $self = shift; + + $self->SUPER::print_info(); + print "Its title is ", $self->title, "\n"; + } + +=begin original + +The C<SUPER::> bit tells Perl to look for the C<print_info()> in the +C<File::MP3> class's inheritance chain. When it finds the parent class +that implements this method, the method is called. + +=end original + +The C<SUPER::> bit tells Perl to look for the C<print_info()> in the +C<File::MP3> class's inheritance chain. When it finds the parent class +that implements this method, the method is called. +(TBT) + +=begin original + +We mentioned multiple inheritance earlier. The main problem with +multiple inheritance is that it greatly complicates method resolution. +See L<perlobj> for more details. + +=end original + +We mentioned multiple inheritance earlier. The main problem with +multiple inheritance is that it greatly complicates method resolution. +See L<perlobj> for more details. +(TBT) + +=head2 Encapsulation + +(カプセル化) + +=begin original + +B<Encapsulation> is the idea that an object is opaque. When another +developer uses your class, they don't need to know I<how> it is +implemented, they just need to know I<what> it does. + +=end original + +B<Encapsulation> is the idea that an object is opaque. When another +developer uses your class, they don't need to know I<how> it is +implemented, they just need to know I<what> it does. +(TBT) + +=begin original + +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. + +=end original + +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. +(TBT) + +=begin original + +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. + +=end original + +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. +(TBT) + +=begin original + +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. + +=end original + +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. +(TBT) + +=head2 Composition + +(包含) + +=begin original + +In object-oriented code, we often find that one object references +another object. This is called B<composition>, or a B<has-a> +relationship. + +=end original + +In object-oriented code, we often find that one object references +another object. This is called B<composition>, or a B<has-a> +relationship. +(TBT) + +=begin original + +Earlier, we mentioned that the C<File> class's C<last_mod_time> +accessor could return a L<DateTime> object. This is a perfect example +of composition. We could go even further, and make the C<path> and +C<content> accessors return objects as well. The C<File> class would +then be B<composed> of several other objects. + +=end original + +Earlier, we mentioned that the C<File> class's C<last_mod_time> +accessor could return a L<DateTime> object. This is a perfect example +of composition. We could go even further, and make the C<path> and +C<content> accessors return objects as well. The C<File> class would +then be B<composed> of several other objects. +(TBT) + +=head2 Roles + +(ロール) + +=begin original + +B<Roles> are something that a class I<does>, rather than something that +it I<is>. Roles are relatively new to Perl, but have become rather +popular. Roles are B<applied> to classes. Sometimes we say that classes +B<consume> roles. + +=end original + +B<Roles> are something that a class I<does>, rather than something that +it I<is>. Roles are relatively new to Perl, but have become rather +popular. Roles are B<applied> to classes. Sometimes we say that classes +B<consume> roles. +(TBT) + +=begin original + +Roles are an alternative to inheritance for providing polymorphism. +Let's assume we have two classes, C<Radio> and C<Computer>. Both of +these things have on/off switches. We want to model that in our class +definitions. + +=end original + +Roles are an alternative to inheritance for providing polymorphism. +Let's assume we have two classes, C<Radio> and C<Computer>. Both of +these things have on/off switches. We want to model that in our class +definitions. +(TBT) + +=begin original + +We could have both classes inherit from a common parent, like +C<Machine>, but not all machines have on/off switches. We could create +a parent class called C<HasOnOffSwitch>, but that is very artificial. +Radios and computers are not specializations of this parent. This +parent is really a rather ridiculous creation. + +=end original + +We could have both classes inherit from a common parent, like +C<Machine>, but not all machines have on/off switches. We could create +a parent class called C<HasOnOffSwitch>, but that is very artificial. +Radios and computers are not specializations of this parent. This +parent is really a rather ridiculous creation. +(TBT) + +=begin original + +This is where roles come in. It makes a lot of sense to create a +C<HasOnOffSwitch> role and apply it to both classes. This role would +define a known API like providing C<turn_on()> and C<turn_off()> +methods. + +=end original + +This is where roles come in. It makes a lot of sense to create a +C<HasOnOffSwitch> role and apply it to both classes. This role would +define a known API like providing C<turn_on()> and C<turn_off()> +methods. +(TBT) + +=begin original + +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. + +=end original + +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. +(TBT) + +=head2 When to Use OO + +(いつ OO を使うか) + +=begin original + +Object Orientation is not the best solution to every problem. In I<Perl +Best Practices> (copyright 2004, Published by O'Reilly Media, Inc.), +Damian Conway provides a list of criteria to use when deciding if OO is +the right fit for your problem: + +=end original + +Object Orientation is not the best solution to every problem. In I<Perl +Best Practices> (copyright 2004, Published by O'Reilly Media, Inc.), +Damian Conway provides a list of criteria to use when deciding if OO is +the right fit for your problem: +(TBT) + +=over 4 + +=item * + +=begin original + +The system being designed is large, or is likely to become large. + +=end original + +The system being designed is large, or is likely to become large. +(TBT) + +=item * + +=begin original + +The data can be aggregated into obvious structures, especially if +there's a large amount of data in each aggregate. + +=end original + +The data can be aggregated into obvious structures, especially if +there's a large amount of data in each aggregate. +(TBT) + +=item * + +=begin original + +The various types of data aggregate form a natural hierarchy that +facilitates the use of inheritance and polymorphism. + +=end original + +The various types of data aggregate form a natural hierarchy that +facilitates the use of inheritance and polymorphism. +(TBT) + +=item * + +=begin original + +You have a piece of data on which many different operations are +applied. + +=end original + +You have a piece of data on which many different operations are +applied. +(TBT) + +=item * + +=begin original + +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. + +=end original + +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. +(TBT) + +=item * + +=begin original + +It's likely you'll have to add new data types later. + +=end original + +It's likely you'll have to add new data types later. +(TBT) + +=item * + +=begin original + +The typical interactions between pieces of data are best represented by +operators. + +=end original + +The typical interactions between pieces of data are best represented by +operators. +(TBT) + +=item * + +=begin original + +The implementation of individual components of the system is likely to +change over time. + +=end original + +The implementation of individual components of the system is likely to +change over time. +(TBT) + +=item * + +=begin original + +The system design is already object-oriented. + +=end original + +The system design is already object-oriented. +(TBT) + +=item * + +=begin original + +Large numbers of other programmers will be using your code modules. + +=end original + +Large numbers of other programmers will be using your code modules. +(TBT) + +=back + +=head1 PERL OO SYSTEMS + +(Perl の OO システム) + +=begin original + +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. + +=end original + +前述したように、Perl の組み込みの OO システムは非常に最小限ですが、 +一方とても柔軟です。 +年を重ねるにつれて、多くの人々がより多くの機能と利便性を提供するために +Perl の組み込みのシステムの上に構築されたシステムを開発しました。 + +=begin original + +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. + +=end original + +私たちはこれらのシステムの一つを使うことを強く勧めます。 +それらの中の最小限のものでも多くの繰り返される定型文を排除できます。 +Perl でクラスを一から書く本当にいい理由というものはありません。 + +=begin original + +If you are interested in the guts underlying these systems, check out +L<perlobj>. + +=end original + +これらのシステムの基礎となる内部に興味があるなら、 L<perlobj> を +調べてください。 + +=head2 Moose + +=begin original + +L<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". + +=end original + +L<Moose> は自分自身を「Perl 5 のためのポストモダンオブジェクトシステム」と +宣伝しています。 +怖がらなくても大丈夫です; 「ポストモダン」というのはラリーが Perl のことを +「最初のポストモダンコンピュータ言語」と説明したことにちなんでいます。 + +=begin original + +C<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. C<Moose> was created by Stevan +Little, and draws heavily from his work on the Perl 6 OO design. + +=end original + +C<Moose> は完全でモダンな OO システムを提供します。 +その最大の影響元は Common Lisp Object System ですが、Smalltalk およびその他の +いくつかの言語からもアイデアを借りています。 +C<Moose> は Stevan Little によって作成され、彼の Perl 6 OO 設計に関する +作業から多くを引いています。 + +=begin original + +Here is our C<File> class using C<Moose>: + +=end original + +以下は C<Moose> を使った C<File> クラスです: + + package File; + use Moose; + + has path => ( is => 'ro' ); + has content => ( is => 'ro' ); + has last_mod_time => ( is => 'ro' ); + + sub print_info { + my $self = shift; + + print "This file is at ", $self->path, "\n"; + } + +=begin original + +C<Moose> provides a number of features: + +=end original + +C<Moose> は多くの機能を提供します: + +=over 4 + +=item * Declarative sugar + +(構文糖) + +=begin original + +C<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 +I<what> your class is, rather than having to tell Perl I<how> to +implement your class. + +=end original + +C<Moose> はクラスを定義するために、宣言的な「糖」の層を提供します。 +この糖は、クラスがより簡単に、使いやすくなるようにするための単に +エクスポートされた関数の集合です。 +これは Perl が I<どのように> クラスを実装するのかを教えるように +するのではなく、クラスが I<何を> するかを表現するようにします。 + +=begin original + +The C<has()> subroutine declares an attribute, and C<Moose> +automatically creates accessors for these attributes. It also takes +care of creating a C<new()> method for you. This constructor knows +about the attributes you declared, so you can set them when creating a +new C<File>. + +=end original + +C<has()> サブルーチンは属性を定義し、C<Moose> は自動的にそれらの属性のための +アクセサを作成します。 +また、C<new()> メソッドの面倒も見ます。 +このコンストラクタは宣言された属性について知っているので、 +新しい C<File> を作成するときにそれを設定できます。 + +=item * Roles built-in + +(組み込みのロール) + +=begin original + +C<Moose> lets you define roles the same way you define classes: + +=end original + +C<Moose> はクラスを定義するのと同じようにロールを定義できます: + + package HasOnOfSwitch; + use Moose::Role; + + has is_on => ( + is => 'rw', + isa => 'Bool', + ); + + sub turn_on { + my $self = shift; + $self->is_on(1); + } + + sub turn_off { + my $self = shift; + $self->is_on(0); + } + +=item * A miniature type system + +(小型の型システム) + +=begin original + +In the example above, you can see that we passed C<< isa => 'Bool' >> +to C<has()> when creating our C<is_on> attribute. This tells C<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. + +=end original + +前述の例では、C<is_on> 属性を作成するときに C<has()> に +C<< isa => 'Bool' >> を渡します。 +これは C<Moose> に、この属性は真偽値でなければならないということを示します。 +これに不正な値を設定しようとすると、エラーを投げます。 + +=item * Full introspection and manipulation + +(完全なイントロスペクションと操作) + +=begin original + +Perl's built-in introspection features are fairly minimal. C<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?" It also lets you modify your classes +programmatically. + +=end original + +Perl の組み込みのイントロスペクション機能はかなり最低限です。 +C<Moose> はこれらの上に構築され、クラスのための完全なイントロスペクション +層を作成します。 +これにより、「File クラスに実装されているメソッドは何?」といった問い合わせが +できます。 +また、クラスをプログラムで修正できます。 + +=item * Self-hosted and extensible + +(セルフホスティングと拡張性) + +=begin original + +C<Moose> describes itself using its own introspection API. Besides +being a cool trick, this means that you can extend C<Moose> using +C<Moose> itself. + +=end original + +C<Moose> は自分自身を自身のイントロスペクション API を使って記述しています。 +かっこいい技という以外に、これは C<Moose> 自身を使って C<Moose> を +拡張できるということです。 + +=item * Rich ecosystem + +(豊かなエコシステム) + +=begin original + +There is a rich ecosystem of C<Moose> extensions on CPAN under the +L<MooseX|http://search.cpan.org/search?query=MooseX&mode=dist> +namespace. In addition, many modules on CPAN already use C<Moose>, +providing you with lots of examples to learn from. + +=end original + +CPAN の L<MooseX|http://search.cpan.org/search?query=MooseX&mode=dist> +名前空間に、C<Moose> 拡張の豊かなエコシステムがあります。 +さらに、CPAN の多くのモジュールは既に C<Moose> を使っていて、そこから学べる +多くの例を提供しています。 + +=item * Many more features + +(さらに多くの機能) + +=begin original + +C<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 C<Moose> +documentation, starting with +L<Moose::Manual|http://search.cpan.org/perldoc?Moose::Manual>. + +=end original + +C<Moose> はとても強力なツールで、その機能の全てについてここで触れることは +できません。 +さらに学ぶために、C<Moose> の文書を +L<Moose::Manual|http://search.cpan.org/perldoc?Moose::Manual> から +読むことを勧めます。 + +=back + +=begin original + +Of course, C<Moose> isn't perfect. + +=end original + +もちろん、C<Moose> は完璧ではありません。 + +=begin original + +C<Moose> can make your code slower to load. C<Moose> itself is not +small, and it does a I<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. + +=end original + +C<Moose> によってコードの読み込みが遅くなることがあります。 +C<Moose> 自身が小さくなく、またクラスを定義するときに I<大量> の +コードを生成します。 +このコード生成は、実行時コードは可能な限り高速であることを意味しますが、 +このためにモジュールが最初に読み込まれるときにコストを支払うことになります。 + +=begin original + +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. + +=end original + +この読み込み時間は、実行時に毎回読み込みしなければならない +コマンドラインスクリプトや「何の変哲もない」CGIスクリプトのように、 +起動速度が重要な場合には問題になり得ます。 + +=begin original + +Before you panic, know that many people do use C<Moose> for +command-line tools and other startup-sensitive code. We encourage you +to try C<Moose> out first before worrying about startup speed. + +=end original + +うろたえる前に、多くの人々がコマンドラインツールやその他の起動時間が重要な +コードに C<Moose> を使っていることを知ってください。 +起動速度について気にする前にまず C<Moose> を試してみることを勧めます。 + +=begin original + +C<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 C<Moose>. C<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 I<any> dependencies is a problem, then C<Moose> +may not be right for you. + +=end original + +C<Moose> はまた他のモジュールに対していくつかの依存があります。 +それらのほとんどは小さいスタンドアロンのモジュールで、いくつかは +C<Moose> から切り離されたものです。 +C<Moose> 自身と、その依存のいくつかは、コンパイラを必要とします。 +コンパイラのないシステムにインストールする必要があったり、I<どんな> +依存があっても問題がある場合は、C<Moose> は適切ではないかも知れません。 + +=head3 Mouse + +=begin original + +If you try C<Moose> and find that one of these issues is preventing you +from using C<Moose>, we encourage you to consider L<Mouse> next. +C<Mouse> implements a subset of C<Moose>'s functionality in a simpler +package. For all features that it does implement, the end-user API is +I<identical> to C<Moose>, meaning you can switch from C<Mouse> to +C<Moose> quite easily. + +=end original + +C<Moose> を試してみて、これらの理由の一つが C<Moose> を使うのを +妨げているなら、次に L<Mouse> を考慮するのを勧めます。 +C<Mouse> は C<Moose> の昨日のサブセットをより単純なパッケージで +実装しています。 +実装されている全ての機能について、エンドユーザー API は C<Moose> と +I<同一> です; つまり C<Mouse> から C<Moose> にとても簡単に +切り替えられるということです。 + +=begin original + +C<Mouse> does not implement most of C<Moose>'s introspection API, so +it's often faster when loading your modules. Additionally, all of its +I<required> dependencies ship with the Perl core, and it can run +without a compiler. If you do have a compiler, C<Mouse> will use it to +compile some of its code for a speed boost. + +=end original + +C<Mouse> は C<Moose> のイントロスペクション API を実装しておらず、従って +モジュールを読み込むときはしばしばより速いです。 +さらに、I<必要な> 全ての依存は Perl のコアと共に出荷されていて、 +コンパイラなしで動作します。 +コンパイラがあれば、C<Mouse> はコンパイラを高速化のためにコードの一部を +コンパイルするために使います。 + +=begin original + +Finally, it ships with a C<Mouse::Tiny> module that takes most of +C<Mouse>'s features and bundles them up in a single module file. You +can copy this module file into your application's library directory for +easy bundling. + +=end original + +最後に、C<Mouse> のほとんどの機能を持ち、一つのモジュールファイルにまとめた +C<Mouse::Tiny> モジュールも同梱されています。 +簡単に同梱するために、このモジュールファイルをアプリケーションの +ライブラリディレクトリにコピーできます。 + +=begin original + +The C<Moose> authors hope that one day C<Mouse> can be made obsolete by +improving C<Moose> enough, but for now it provides a worthwhile +alternative to C<Moose>. + +=end original + +C<Moose> の作者は、いつの日か C<Moose> が十分改良されることによって +C<Mouse> が古いものになることを望んでいますが、今のところは C<Moose> に対する +価値のある代替を提供します。 + +=head2 Class::Accessor + +=begin original + +L<Class::Accessor> is the polar opposite of C<Moose>. It provides very +few features, nor is it self-hosting. + +=end original + +L<Class::Accessor> は C<Moose> の対極です。 +非常に少ない機能しか提供しませんし、セルフホスティングでもありません。 + +=begin original + +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. + +=end original + +しかし、とても単純で、ピュア Perl で、非コア依存はありません。 +また、対応している機能に対する「Moose 風」 API も提供しています。 + +=begin original + +Even though it doesn't do much, it is still preferable to writing your +own classes from scratch. + +=end original + +多くのことはしませんが、それでもクラスを一から書くよりは望ましいです。 + +=begin original + +Here's our C<File> class with C<Class::Accessor>: + +=end original + +以下に C<Class::Accessor> を使った C<File> クラスを示します: + + package File; + use Class::Accessor 'antlers'; + + has path => ( is => 'ro' ); + has content => ( is => 'ro' ); + has last_mod_time => ( is => 'ro' ); + + sub print_info { + my $self = shift; + + print "This file is at ", $self->path, "\n"; + } + +=begin original + +The C<antlers> import flag tells C<Class::Accessor> that you want to +define your attributes using C<Moose>-like syntax. The only parameter +that you can pass to C<has> is C<is>. We recommend that you use this +Moose-like syntax if you choose C<Class::Accessor> since it means you +will have a smoother upgrade path if you later decide to move to +C<Moose>. + +=end original + +C<antlers> インポートフラグは、属性を C<Moose> 風の文法で定義したいことを +C<Class::Accessor> に伝えます。 +C<has> に渡せる唯一の引数は C<is> です。 +C<Class::Accessor> を選択した場合は、この Moose 風の文法を使うことを勧めます; +なぜなら後に C<Moose> に移行しようと決めたときによりスムーズに +アップグレードできるからです。 + +=begin original + +Like C<Moose>, C<Class::Accessor> generates accessor methods and a +constructor for your class. + +=end original + +C<Moose> と同様、C<Class::Accessor> はアクセサメソッドとコンストラクタを +生成します。 + +=head2 Object::Tiny + +=begin original + +Finally, we have L<Object::Tiny>. This module truly lives up to its +name. It has an incredibly minimal API and absolutely no dependencies +(core or not). Still, we think it's a lot easier to use than writing +your own OO code from scratch. + +=end original + +最後に、L<Object::Tiny> があります。 +このモジュールはまさにその名前通りです。 +これは非常に最小限の API のみを持ち、(コアかどうかに関わらず)全く依存は +ありません。 +それでも、一から独自の OO コードを書くよりも遙かに簡単に使えます。 + +=begin original + +Here's our C<File> class once more: + +=end original + +以下に C<File> クラスをもう一度示します: + + package File; + use Object::Tiny qw( path content last_mod_time ); + + sub print_info { + my $self = shift; + + print "This file is at ", $self->path, "\n"; + } + +=begin original + +That's it! + +=end original + +これだけです! + +=begin original + +With C<Object::Tiny>, all accessors are read-only. It generates a +constructor for you, as well as the accessors you define. + +=end original + +C<Object::Tiny> では、全てのアクセサは読み込み専用です。 +コンストラクタと、定義したアクセサを生成します。 + +=head2 Role::Tiny + +=begin original + +As we mentioned before, roles provide an alternative to inheritance, +but Perl does not have any built-in role support. If you choose to use +Moose, it comes with a full-fledged role implementation. However, if +you use one of our other recommended OO modules, you can still use +roles with L<Role::Tiny> + +=end original + +前述したように、ロールは継承の代替策を提供しますが、Perl には組み込みの +ロール対応はありません。 +Moose を使うことを選んだ場合、完全なロール実装が同梱されています。 +しかし、その他の推奨 OO モジュールを使う場合、L<Role::Tiny> で +ロールを使えます。 + +=begin original + +C<Role::Tiny> provides some of the same features as Moose's role +system, but in a much smaller package. Most notably, it doesn't support +any sort of attribute declaration, so you have to do that by hand. +Still, it's useful, and works well with C<Class::Accessor> and +C<Object::Tiny> + +=end original + +C<Role::Tiny> は Moose のロールシステムと同じような機能を提供しますが、 +パッケージは遙かに小さいです。 +特に、属性宣言には対応していないので、手動で行う必要があります。 +それでも、これは有用で、C<Class::Accessor> および C<Object::Tiny> と +うまく動作します。 + +=head2 OO System Summary + +(OO システムの要約) + +=begin original + +Here's a brief recap of the options we covered: + +=end original + +以下はここで取り上げた選択肢の簡潔なまとめです: + +=over 4 + +=item * L<Moose> + +=begin original + +C<Moose> is the maximal option. It has a lot of features, a big +ecosystem, and a thriving user base. We also covered L<Mouse> briefly. +C<Mouse> is C<Moose> lite, and a reasonable alternative when Moose +doesn't work for your application. + +=end original + +C<Moose> は最大限のオプションです。 +多くの機能、大きなエコシステム、繁栄しているユーザーベースがあります。 +また、L<Mouse> も簡単に取り上げました。 +C<Mouse> は C<Moose> の簡略版で、Moose があなたのアプリケーションで +動作しないときの妥当な代替案です。 + +=item * L<Class::Accessor> + +=begin original + +C<Class::Accessor> does a lot less than C<Moose>, and is a nice +alternative if you find C<Moose> overwhelming. It's been around a long +time and is well battle-tested. It also has a minimal C<Moose> +compatibility mode which makes moving from C<Class::Accessor> to +C<Moose> easy. + +=end original + +C<Class::Accessor> がすることは C<Moose> よりもとても少なく、C<Moose> が +おおげさな時にはよい選択肢です。 +長い間存在し、よくテストされています。 +C<Class::Accessor> から C<Moose> への以降を容易にするための最小限の +C<Moose> 互換モードもあります。 + +=item * L<Object::Tiny> + +=begin original + +C<Object::Tiny> is the absolute minimal option. It has no dependencies, +and almost no syntax to learn. It's a good option for a super minimal +environment and for throwing something together quickly without having +to worry about details. + +=end original + +C<Object::Tiny> は明らかに最小限のオプションです。 +依存はなく、学ぶ必要のある文法もほとんどありません。 +超最小限環境の場合や詳細について心配することなく素早く何かを作るときには +よいオプションです。 + +=item * L<Role::Tiny> + +=begin original + +Use C<Role::Tiny> with C<Class::Accessor> or C<Object::Tiny> if you +find yourself considering multiple inheritance. If you go with +C<Moose>, it comes with its own role implementation. + +=end original + +多重継承について考えているなら C<Class::Accessor> または C<Object::Tiny> と +共に C<Role::Tiny> を使ってください。 +C<Moose> を使っているなら、独自のロール実装が同梱されています。 + +=back + +=head2 Other OO Systems + +(その他の OO システム) + +=begin original + +There are literally dozens of other OO-related modules on CPAN besides +those covered here, and you're likely to run across one or more of them +if you work with other people's code. + +=end original + +ここで扱ったものの他に、CPAN には文字通り数十のその他の OO 関連の +モジュールがあり、他の人のコードを動かすときにはおそらく +それらのいくつかを使っているでしょう。 + +=begin original + +In addition, plenty of code in the wild does all of its OO "by hand", +using just the Perl built-in OO features. If you need to maintain such +code, you should read L<perlobj> to understand exactly how Perl's +built-in OO works. + +=end original + +さらに、世の中の多くのコードは全ての OO を「手動で」、単に Perl 組み込みの +OO 機能を使って行っています。 +もしそのようなコードを保守する必要があるなら、Perl の組み込みの OO が +どのように動作するのかを正確に理解するためにL<perlobj> を読むべきです。 + +=head1 CONCLUSION + +(まとめ) + +=begin original + +As we said before, Perl's minimal OO system has led to a profusion of +OO systems on CPAN. While you can still drop down to the bare metal and +write your classes by hand, there's really no reason to do that with +modern Perl. + +=end original + +既に述べたように、Perl の最小限の OO システムは CPAN での豊富な OO +システムを生み出しました。 +今でもこの地金まで降りていってクラスを手で書くこともできる一方、 +モダン Perl においてそうする理由は本当はありません。 + +=begin original + +For small systems, L<Object::Tiny> and L<Class::Accessor> both provide +minimal object systems that take care of basic boilerplate for you. + +=end original + +小さいシステムなら、L<Object::Tiny> と L<Class::Accessor> の両方は +基本的な定型文の面倒を見る最小限のオブジェクトシステムを提供します。 + +=begin original + +For bigger projects, L<Moose> provides a rich set of features that will +let you focus on implementing your business logic. + +=end original + +より大きいプロジェクトなら、L<Moose> はあなたがビジネスロジックの実装に +集中できるような豊富な機能セットを提供します。 + +=begin original + +We encourage you to play with and evaluate L<Moose>, +L<Class::Accessor>, and L<Object::Tiny> to see which OO system is right +for you. + +=end original + +どの OO システムが適しているかを見るために、L<Moose>, L<Class::Accessor>, +L<Object::Tiny> を試して評価することをお勧めします。 + + +=begin meta + +Translate: SHIRAKATA Kentaro <argra****@ub32*****> (5.16.1-) +Status: in progress + +=end meta + +=cut +
