perlbot - Bag'o Object Tricks (the BOT) The following collection of tricks and hints is intended to whet curious appetites about such things as the use of instance variables and the mechanics of object and class relationships. The reader is encouraged to consult relevant textbooks for discussion of Object Oriented definitions and methodology. This is not intended as a tutorial for object-oriented programming or as a comprehensive guide to Perl's object oriented features, nor should it be construed as a style guide. If you're looking for tutorials, be sure to read perlboot, perltoot, and perltooc. ここにあるインスタンス変数の使用であるとか、オブジェクトやクラス関係の 機構といったトリックやヒントのコレクションは、好奇心を刺激するようなものです。 読者は、オブジェクト指向の定義や方法論についての議論については 適切な教科書を参照することが求められます。 つまり、これはオブジェクト指向プログラミングのチュートリアルを 指向したものでなく、Perl のオブジェクト指向機能についての 包括的なガイドでもなく、はたまたスタイルガイドとなるべきものでもありません。 The Perl motto still holds: There's more than one way to do it. Perlのモットーはまだ生きています: やり方は一通りじゃない。 1 Do not attempt to verify the type of $self. That'll break if the class is inherited, when the type of $self is valid but its package isn't what you expect. See rule 5. $self の型を確かめることはしないこと。 $self の型が正当であってもそのパッケージがあなたの期待しているものと 異なっているとき、クラスが継承されていればおかしな結果となってしまいます。 規則 5 を参照してください。 2 If an object-oriented (OO) or indirect-object (IO) syntax was used, then the object is probably the correct type and there's no need to become paranoid about it. Perl isn't a paranoid language anyway. If people subvert the OO or IO syntax then they probably know what they're doing and you should let them do it. See rule 1. オブジェクト指向 (OO) あるいは 間接オブジェクト (IO) 構文が使われたならば、 そのオブジェクトはおそらくは正しい型であり、 それについて偏執的になる必要はありません。 どうせ Perl は偏執的言語ではありません。 OO 構文や IO 構文をくつがえす人々がいたなら、そういった人々はおそらく 自分たちが行っていることを知っているでしょうし、 あなたは彼らにそうさせておくべきなのです。 規則 1 を参照してください。 3 Use the two-argument form of bless(). Let a subclass use your constructor. See INHERITING A CONSTRUCTOR. 引数 2 つの bless() を使いましょう。 コンストラクタを使ってサブクラスにしましょう。 INHERITING A CONSTRUCTOR を参照してください。 4 The subclass is allowed to know things about its immediate superclass, the superclass is allowed to know nothing about a subclass. サブクラスは、すぐ上のスーパークラスが何であるかを知ることが許されています。 スーパークラスはサブクラスについての何かを知ることを許されていません。 5 Don't be trigger happy with inheritance. A "using", "containing", or "delegation" relationship (some sort of aggregation, at least) is often more appropriate. See OBJECT RELATIONSHIPS, USING RELATIONSHIP WITH SDBM, and "DELEGATION". やたらと継承を使わないようにしましょう。 実装("using")、包含("containing")、委任("delegation")といった 関係(少なくともある種の集合)は、たいていの場合継承よりも 適切なものとなります。 OBJECT RELATIONSHIPS, USING RELATIONSHIP WITH SDBM, "DELEGATION" を参照してください。 6 The object is the namespace. Make package globals accessible via the object. This will remove the guess work about the symbol's home package. See CLASS CONTEXT AND THE OBJECT. オブジェクトとは名前空間です。 オブジェクトを通して、パッケージを大域的にアクセスできるようにします。 これはシンボルのホームパッケージに関する当て推量を取り除くでしょう。 CLASS CONTEXT AND THE OBJECT を参照してください。 7 IO syntax is certainly less noisy, but it is also prone to ambiguities that can cause difficult-to-find bugs. Allow people to use the sure-thing OO syntax, even if you don't like it. IO 構文はそれほどややこしいものではありません。 しかしその反面、見つけるのが難しいバグを引き起こすあいまいさになる 傾向があります。 あなたが好まないとしても、人々は OO 構文を使うことが許されているのです。 8 Do not use function-call syntax on a method. You're going to be bitten someday. Someone might move that method into a superclass and your code will be broken. On top of that you're feeding the paranoia in rule 2. メソッドを関数呼び出し形式で使わないようにしましょう。 さもなければあなたはいつの日か痛い目にあうこととなるでしょう。 誰かがそのようなメソッドをスーパークラスに移動させればあなたのプログラムは 壊れてしまうのです。 規則 2 の偏執狂になることに繋がりかねません。 9 Don't assume you know the home package of a method. You're making it difficult for someone to override that method. See THINKING OF CODE REUSE. 自分がメソッドのホームパッケージを知っていると仮定しないでください。 それをやってしまうと、他の人がそのメソッドをオーバーライドするのが 難しくなってしまいます。 THINKING OF CODE REUSE を参照してください。 (インスタンス変数) An anonymous array or anonymous hash can be used to hold instance variables. Named parameters are also demonstrated. 無名配列や無名ハッシュはインスタンス変数を保持するのに使うことができます。 名前付きのパラメータと一緒にお見せしましょう。 {'High'} = $params{'High'}; $self->{'Low'} = $params{'Low'}; bless $self, $type; } ]]> [0] = $params{'Left'}; $self->[1] = $params{'Right'}; bless $self, $type; } ]]> new( 'High' => 42, 'Low' => 11 ); print "High=$a->{'High'}\n"; print "Low=$a->{'Low'}\n"; ]]> new( 'Left' => 78, 'Right' => 40 ); print "Left=$b->[0]\n"; print "Right=$b->[1]\n"; ]]> (スカラインスタンス変数) An anonymous scalar can be used when only one instance variable is needed. 無名のスカラは、インスタンス変数が一つだけ必要とされるときのみ 使うことができます。 new( 42 ); print "a=$$a\n"; ]]> (インスタンス変数の継承) This example demonstrates how one might inherit instance variables from a superclass for inclusion in the new class. This requires calling the superclass's constructor and adding one's own instance variables to the new object. 次の例は、どのようにして新しいクラスにスーパークラスからインスタンス変数を 継承するのかということを示すものです。 ここでは、スーパークラスのコンストラクタを呼び出すことと新しい オブジェクトでインスタンス変数を一つ追加するということを行っています。 {'buz'} = 42; bless $self, $type; } ]]> new; $self->{'biz'} = 11; bless $self, $type; } ]]> new; print "buz = ", $a->{'buz'}, "\n"; print "biz = ", $a->{'biz'}, "\n"; ]]> (オブジェクトの関係) The following demonstrates how one might implement "containing" and "using" relationships between objects. 以下の例では、包含("containing")や実装("using")といったオブジェクト間の 関係をどのように実装するかということを説明しています。 {'buz'} = 42; bless $self, $type; } ]]> {'Bar'} = Bar->new; $self->{'biz'} = 11; bless $self, $type; } ]]> new; print "buz = ", $a->{'Bar'}->{'buz'}, "\n"; print "biz = ", $a->{'biz'}, "\n"; ]]> (スーパークラスのメソッドをオーバーライドする) The following example demonstrates how to override a superclass method and then call the overridden method. The SUPER pseudo-class allows the programmer to call an overridden superclass method without actually knowing where that method is defined. 以下の例ではどのようにスーパークラスのメソッドをオーバーライドするのか、 そしてオーバーライドされたメソッドをどのように呼び出すのかを示します。 擬似クラス SUPER はプログラマがスーパークラスのメソッドを そのメソッドがどのクラスに属するかを知らなくても呼べるようにします。 SUPER::goo(); } sub mumble { my $self = shift; $self->SUPER::mumble(); } sub google { my $self = shift; $self->SUPER::google(); } ]]> new; $foo->mumble; $foo->grr; $foo->goo; $foo->google; ]]> Note that SUPER refers to the superclasses of the current package (Foo), not to the superclasses of $self. SUPER はカレントパッケージのスーパークラス(Foo) を参照するのであって、 $self のスーパークラスではないことに注意してください。 (SDBM での実装関係) This example demonstrates an interface for the SDBM class. This creates a "using" relationship between the SDBM class and the new class Mydbm. この例は SDBM クラスに対するインターフェースを示します。 この例では、SDBM クラスと、新しいクラス Mydbm との間の実装("using")関係を 作り出します。 new(@_); bless {'dbm' => $ref}, $type; } sub FETCH { my $self = shift; my $ref = $self->{'dbm'}; $ref->FETCH(@_); } sub STORE { my $self = shift; if (defined $_[0]){ my $ref = $self->{'dbm'}; $ref->STORE(@_); } else { die "Cannot STORE an undefined key in Mydbm\n"; } } ]]> (コードの再利用を考える) One strength of Object-Oriented languages is the ease with which old code can use new code. The following examples will demonstrate first how one can hinder code reuse and then how one can promote code reuse. オブジェクト指向言語の一つの強みとは、古いコードと新しいコードを 混ぜて使うのが簡単だと言うことです。 以下の例では、まず最初にどのようにコードの再利用を妨害するかということを、 続いてどのようにコードの再利用を促進するかということを示します。 This first example illustrates a class which uses a fully-qualified method call to access the "private" method BAZ(). The second example will show that it is impossible to override the BAZ() method. 最初の例では、「プライベート」なメソッド BAZ() にアクセスするために 完全修飾メソッド呼び出しを使っているクラスをお見せします。 二番目の例ではオーバーライドすることのできない BAZ() メソッドを お見せします。 FOO::private::BAZ; } ]]> new; $a->bar; ]]> Now we try to override the BAZ() method. We would like FOO::bar() to call GOOP::BAZ(), but this cannot happen because FOO::bar() explicitly calls FOO::private::BAZ(). 今度はメソッド BAZ() をオーバーライドしてみましょう。 FOO::bar() で GOOP::BAZ() を呼び出したいのですが、これは FOO::bar() が陽に FOO::private::BAZ() を呼び出しているのでできません。 FOO::private::BAZ; } ]]> new; $a->bar; ]]> To create reusable code we must modify class FOO, flattening class FOO::private. The next example shows a reusable class FOO which allows the method GOOP::BAZ() to be used in place of FOO::BAZ(). 再利用可能なコードを作成するには、クラス FOO を修正しなければならず、 クラス FOO:private を平らにします。 次の例では、FOO::BAZ() を使っている場所でメソッド GOOP:BAZ を 置くことのできるクラス FOO をお見せします。 BAZ; } ]]> new; $a->bar; ]]> (クラスのコンテキストとオブジェクト) Use the object to solve package and class context problems. Everything a method needs should be available via the object or should be passed as a parameter to the method. パッケージとクラスコンテキストの問題を解決するためにオブジェクトを 使いましょう。 メソッドが必要とするすべてはオブジェクトを通して使用可能であるべきであり、 メソッドに対するパラメータとして渡されるべきなのです。 A class will sometimes have static or global data to be used by the methods. A subclass may want to override that data and replace it with new data. When this happens the superclass may not know how to find the new copy of the data. あるクラスが、ときとしてメソッドから使うためにスタティックなデータや グローバルなデータを持つことがあるでしょう。 サブクラスでそのようなデータをオーバーライドして、それを新しいデータに 置き換えたいことがあるかもしれません。 このような事態になったとき、スーパークラスは新しいデータのコピーを どうやって見つけるのかを知ることができません。 This problem can be solved by using the object to define the context of the method. Let the method look in the object for a reference to the data. The alternative is to force the method to go hunting for the data ("Is it in my class, or in a subclass? Which subclass?"), and this can be inconvenient and will lead to hackery. It is better just to let the object tell the method where that data is located. この問題は、メソッドのコンテキストを定義するためのオブジェクトを 使うことによって解決できます。 オブジェクト中にあるメソッドにデータのリファレンスを見せましょう。 もう一つの手段はメソッドにデータを探しまわさせる (「自分のクラスにあるの? それともサブクラス? どのサブクラス?」)ことですが、 これは不便ですし、ハッカー的にすぎます。 オブジェクトに、データがどこに位置するかを知らせるメソッドを持つように させるのが良いのです。 'XYZZY' ); ]]> {'fizzle'} = \%fizzle; bless $self, $type; } ]]> {'fizzle'}; ]]> {'fizzle'}; ]]> {'Password'}, "\n"; } ]]> 'Rumple' ); ]]> new; $self->{'fizzle'} = \%fizzle; bless $self, $type; } ]]> new; $b = Foo->new; $a->enter; $b->enter; ]]> (コンストラクタの継承) An inheritable constructor should use the second form of bless() which allows blessing directly into a specified class. Notice in this example that the object will be a BAR not a FOO, even though the constructor is in class FOO. 継承可能なコンストラクタは、特定のクラスに直接 bless することのできる bless() の第二形式を使うべきです。 以下の例において、クラス FOO のコンストラクタを通じて構成された オブジェクトであってもそれは FOO ではなく、BAR として存在するように なることに注意してください。 new; $a->baz; ]]> (委任) Some classes, such as SDBM_File, cannot be effectively subclassed because they create foreign objects. Such a class can be extended with some sort of aggregation technique such as the "using" relationship mentioned earlier or by delegation. SDBM_File のようなクラスは外部オブジェクトを生成するので、効率良く サブクラス化することができません。 そのようなクラスは実装("using")関係のような先に言及したものや、 委任のような集成テクニックを用いることで拡張することができます。 The following example demonstrates delegation using an AUTOLOAD() function to perform message-forwarding. This will allow the Mydbm object to behave exactly like an SDBM_File object. The Mydbm class could now extend the behavior by adding custom FETCH() and STORE() methods, if this is desired. 以下の例では、メッセージフォワーディングを実現するために AUTOLOAD 関数を使っている委任をお見せします。 これは、Mydbm オブジェクトが SDBM_File オブジェクトと全く同じように 振る舞うようにさせるものです。 カスタマイズした FETCH() メソッドや STORE() メソッドを追加することによって、 今や Mydbm クラスを拡張することもできるのです。 new(@_); bless {'delegate' => $ref}; } ]]> {'delegate'}->$AUTOLOAD(@_); } ]]> {'delegate'}->$AUTOLOAD(@_); } ]]> perlboot, perltoot, perltooc. Created: KIMURA Koichi Updated: Kentaro Shirakata <argrath@ub32.org>