以前自分が書いた記事Scalaのtraitはmixinか？を元に、トレイトに関する補足記事を書こうとして「そうだ、どうせならば元論文の記述とも照らしあわせたほうがよいな」と「Traits: A Mechanism for Fine-grained Reuse」を読んだ。そこで気づいたのだけども、この件に関して意見が咬み合わないことがあるのは、そもそも「クラス」の定義に食い違いがあるせいではないか？ 「Traits: A Mechanism for Fine-grained Reuse」での定義ではクラスとは「空クラスnil」もしくは「属性の集合と、メソッドの集合と、親クラス」と定義されている*1 で、トレイトとは「メソッドの集合」と定義されている*2 これがどういうことかというと、トレイトなどから作られたクラスは「自分を構成するのにどういうトレイトが使われたか」という情報を持たないってこと
Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str
概要 [/2014-03-22] trait with [/2011-01-08] 初期化順 [2011-01-08] super[] [/2011-09-13] ソース分割の例 [/2011-08-26] 概要 Javaはクラスの多重継承は出来ないが、複数のインターフェース（interface）を1つのクラスに実装（implements）することが出来るようになっている。 そのクラスを呼び出す（使う）側からすれば、そのインターフェース経由でメソッドが呼べるということなので、分かり易くて便利だ。 しかしそのクラスを作る（用意する）側からすると、インターフェースで宣言されている全てのメソッドの中身をコーディングしなければならないので、面倒。 （インターフェースでは、メソッドの宣言は出来ても、その中身（本体）を記述することが出来ない為（JDK1.7以前）） 例えどのクラスでも同じようなコーディ
Traits は、inline関数や Cのマクロに似ています。 Traits を クラスに use した際に、継承や委譲と違い、メソッドの持ち主を指し示すのではなく、メソッドそのものをクラスに展開してしまいます。これは通常のコール/リターンする関数と、 inline関数や Cのマクロ の間柄によく似ています。 これを「フラッティング」と呼ぶのですが、たいていは実効効率 の問題で用いられる inline関数と違い、Traits の場合「フラッティング」は可読性の為だと言います。 Even though a class may have been constructed by composing small traits in a complex hierarchy, there is no need to require that it be viewed in the same way.
この記事はPHP5.4 Advent Calendar 2011の23日分です。 trait自体はすでに10日目の@tpyamamotoさんによるTRAITでデザインパターン再考でも取り上げられていますが、目玉機能なのでもう一回ネタにしちゃいます＞＜ おさらい：traitとは 相変わらず公式マニュアルが充実しまくっているのでそちらを見た方がいいのですが、抜粋するとこんな感じ。 PHP5.4の目玉機能 多重継承を安全に行えるよう導入された概念 traitはプロパティ・メソッドを持てる traitは定数を持てない trait自体はインスタンス化できない classを継承してtraitを作ることはできない interfaceを実装してtraitを作ることはできない traitを継承してtraitを作ることが可能 classは複数のtraitを継承して実装を再利用できる traitはclassでは
<< 2010/06/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(1) argument delegation 16 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(2) nested def as local function 17 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(3) module operations 18 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(4) keyword arguments 19 20 21 22 23 24 1. 上海 2. 買い物 3. 大容量USBメモリ 25 26 27 28 29 30 >> _ [Ruby] Ruby2.0の新機能(かもしれないもの)(3) module operations 注
PHP5.4にはトレイトという文法が導入されて、多重継承の便利さが享受できるようになるそうです。 いろいろ試してみることにしました。 トレイトといえば代表選手はScalaですね。Scalaでいうトレイトは、インターフェースの定義とメソッドの実装を同時にやってくれる便利な概念でした。単一継承のOOP言語では「〜は〜の一種」という制約が強すぎて、「ペンギンは鳥の飛行メソッドによって飛行できてしまう」という問題があります。でもちゃんと「ペンギンは飛べないが泳げる鳥」を綺麗に解決する必要はあって、その解答として、トレイトのあるScalaではこんな解が導けます。 abstract class Animal abstract class Bird extends Animal { def hasBeak = true // 鳥にはかならずクチバシがある def hasWings = true // 翼
<< 2010/06/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(1) argument delegation 16 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(2) nested def as local function 17 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(3) module operations 18 1. [Ruby] Ruby2.0の新機能(かもしれないもの)(4) keyword arguments 19 20 21 22 23 24 1. 上海 2. 買い物 3. 大容量USBメモリ 25 26 27 28 29 30 >> _ [Ruby] Ruby2.0の新機能(かもしれないもの)(3) module operations 注
Moose::RoleはJavaのInterfaceと似たような物だと思ってたんですが、大きな誤解でした。 モダンPerlの世界へようこそを読んで、Moose::RoleはTraits: Composable Units of Behaviorの概念の実装らしいことがわかったので、この論文を読んでみました。*1。非常に面白い内容でした。P.12 の a) と b) を見るだけでも、この概念の面白さが伝わるんじゃないかと。要は、指定した振る舞い(requires)から新しい振る舞い(provides)を作るものが、Traitsってことです。(ただし、ここで言う振る舞いにはアクセサを含みます。) 誤解していたこと Moose::RoleをTraitsとして見なすとすれば、JavaのInterfaceの性質である以下の2点は誤解です*2。 Moose::Roleは、単なるインタフェース(API)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
