Traits: Composable Units of Behaviour のイントロ部分を訳してみました

トレイト・Traits、よくわかりません。・・なんとかくもやもやしてしまっていて、上手く咀嚼できていないのです。なので、理解のとっかかりとして Traits の 元論文 のイントロダクション部分を翻訳してみました。

ていうか、訳に自信がないので誰かに突っ込んでもらおうかな、というスケベ心なのですョ。


* * *

1 Introduction

1 イントロダクション

Although single inheritance is widely accepted as the sine qua non of object-orientation, programmers have long realized that single inheritance is not expressive enough to factor out common features (i.e., instance variables and methods) shared by classes in a complex hierarchy. As a consequence, language designers have proposed various forms of multiple inheritance [7, 23, 29, 35, 41], as well as other mechanisms such as mixins [3, 10, 18, 27, 32], that allow classes to be composed incrementally from sets of features.

単一継承(single inheritance) は オブジェクト指向の必須条件として広く 受け入れられてきましたが、プログラマーは長い間、単一継承が 複合階層にあるクラス間でシェアされるような共通の機能(feature, すなわち インスタンス変数とメソッド)を表現出来ないので、これらを実現できませんでした。結果として、言語デザイナー達は、機能のセットからクラスを段階的に構成することができるように、多重継承(multiple inheritance) の変種[7, 23, 29, 35, 41]や、代替となる ミックスイン(mixin) のような他のメカニズム[3 ,10, 18, 27, 32]を提案することとなりました。

Despite the passage of nearly twenty years, neither multiple inheritance nor mixins have achieved wide acceptance [44]. Summarizing Alan Snyder’s contribution to the inheritance panel discussion at OOPSLA ’87, Steve Cook wrote:

“Multiple inheritance is good, but there is no good way to do it.” [11]

The trend seems to be away from multiple inheritance; the designers of recent languages such as Java and C# decided that the complexities introduced by multiple inheritance far outweighed its utility. It is widely accepted that multiple inheritance creates some serious implementation problems [14, 43]; we believe that it also introduces serious conceptual problems. Our study of these problems has led us to the present design for traits.

20年近く立ったにもかかわらず、多重継承もミックスインも広く受け入れられたとは言えません[44]。Alan Snyder の書いた OOPSLA '87 での 「継承」パネルディスカッション の要約によると、Steve Cook は

 「多重継承自体は良いんだけど、それを上手くやる方法はないんだよなぁ」 [11]

と言ったそうな。

トレンドは多重継承から離れたかのように見えます。JavaC# のような最近の言語のデザイナー達は多重継承によりもたらされる複雑さは、その有用性を上回ると判断しました。多重継承はは幾つかの深刻な実装上の問題を持ち込むことが広く認識されています[14, 43]。そして 我々はまた、多重継承は深刻な概念上の問題をも持ち込むと確信しています。この問題に対する研究の成果が トレイト(trait) です。

Although multiple inheritance makes it possible to reuse any desired set of classes, a class is frequently not the most appropriate element to reuse. This is because classes play two competing roles. A class has a primary role as a generator of instances: it must therefore be complete. But as a unit of reuse, a class should be small. These properties often conflict. Furthermore, the role of classes as instance generators requires that each class have a unique place in the class hierarchy, whereas units of reuse should be applicable at arbitrary places.

多重継承は 複数のクラスに対するリユースを可能にしましたが、クラスはしばし再利用に最も適した要素ではなかったりします。なぜならクラスには二つの競合する役割(role)があるからです。クラスの主たる役割はインスタンスの生成器です。それゆえクラスはそれだけで完全なものでなければなりません。でも、再利用の単位という役割においてはクラスは小さくあるべきです。これら二つの性質はしばしば競合します。さらに、クラスのインスタンス生成器としての役割において、各々のクラスはクラス階層内で特定の一カ所を占める必要がありますが、一方 再利用の単位としては、クラス階層中の任意の位置に適用出来なくてはなりません。

Moon’s Flavors [32] were an early attempt to address this problem: Flavors are small, not necessarily complete, and they can be “mixed in” at arbitrary places in the class hierarchy. More sophisticated notions of mixins were subsequently developed by Bracha and Cook [10], Mens and van Limberghen [27], Flatt, Krishnamurthi and Felleisen [18], and Ancona, Lagorio and Zucca [3]. These approaches all permit the programmer to create components that are designed for reuse, rather than for instantiation. However, as we shall show, they can have a negative influence on understandability.

Moon のフレーバー(Flavor)[32]は、この問題を解決するための初期の試みでした。フレーバーは小さくて、完結している必要もなく、そして クラス階層上の任意の位置に「ミックスイン」できます。ミックスインのより洗練された概念は、その後 Bracha と Coock [10]、Mens と van Limberghen [27]、Flatt、Krishnamurth と Fellesen [18]、そして Ancona、Legorio と Zucca[3] により 開発されました。これらのアプローチは、プログラマーインスタンス生成の為ではなくく、リユースのために コンポーネントをつくることを許可しました。しかし、我々が明らかにするように、これらはわかりやすさについて、悪い影響を与える可能性があります。

Mixins use the ordinary single inheritance operator to extend various base classes with the same set of features. However, although this inheritance operator is well-suited for deriving new classes from existing ones, it is not appropriate for composing reusable building blocks. Specifically, inheritance requires that mixins be composed linearly; this severely restricts one’s ability to specify the “glue code” that is necessary to adapt the mixins so that they fit together.

ミックスイン(Mixin)は、様々な基底クラスに対し 同じ機能(fuature)セットで拡張するのに、通常の単一継承オペレータ を使用します。しかし、この継承オペレータは既存のクラスから新しいクラスを派生させるのには適していますが、再利用可能なビルディングブロックを構成するには適していません。具体的には、 継承はミックスインにそれが直線的に構成されることを要求しますが、その深刻な制限ゆえに、複数のミックスインをフィットするように適用する場合「グルーコード」が必須となります。

In our proposal, lightweight entities called traits serve as the primitive units of code reuse. The design of traits started with the observation that the conflict between reuse and understandability is more apparent than real. In general, we believe that understanding a program is easier if it is possible to view the program in multiple forms. 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. It should be possible to view the class either as a flat collection of methods or as a composite entity built from traits. The flattened view promotes understanding; the composite view promotes reuse. There is no conflict so long as both of these views can coexist, which requires that composition be used only as a structuring tool and have no effect on the meaning of the class.

我々の提案する軽量エンティティ「トレイト」は、コード再利用のプリミティブなユニットとして働きます。トレイトの設計は、再利用と理解性の現実よりも明らかな競合の観察から始まりました(訳注:???..orz)。トレイトの設計は、再利用性と解りやすさの競合は、現実のものではなく見かけ上のものであるという観察結果から始まりました。一般に、プログラムは複数の姿(form)で見ることができたほうが解りやすいです。にもかかわらず、クラスは複雑な階層内での小さな特性(trait)の複合体として構築されることはあったかもしれませんが、けれどそのような姿で見たいという要求は満たされていませんでした。クラスは、「フラットなメソッドのコレクション 」あるいは 「トレイトで形作られた複合エンティティ」のように見なすことができます。クラスを「フラット」にみなす視点は理解を促進しますし、「複合物」とみなす視点は 再利用を促進します。長い間これら2つの視点が競合せず共存可能だったのは、それは「複合物」視点が単に構成ツールにのみ利用されていて、クラスの意味には何の影響も与えなかったからです。*1あるクラスが小さなトレイトの複雑な階層として構成されていたとしても、クラスを見る際にもそのような形式で見る必要はありません。クラスは「メソッドのフラットなコレクション」としても「トレイトで形作られた複合エンティティ」としても見られようになっているべきです。両方の視点が共存できる限り(再利用性と解りやすさの)競合はありません。そのためには構成(composition)が構造化のツールとしてのみ使われていて、クラスの意味に影響を与えない必要があります。

Traits satisfy this requirement. They provide structure, modularity and reusability within classes, but they can be ignored when one considers the relationships between one classeand another. Traits provide an excellent balance between reusability and understandability, while enabling better conceptual modeling. Moreover, because traits are concerned solely with the reuse of behaviour and not with the reuse of state, they avoid the implementation difficulties that characterize multiple inheritance and mixins. Traits have the following properties.

トレイトはこの要求を満します。トレイトは、クラス世界に 構造とモジューラリティ、リユーサビリティをもたらしますが、それを クラスとクラスの間の関係とみなさないことが出来ます。トレイトは再利用と分かりやすさのエクセレントなバランスを提供し、よりよい概念的なモデリングを可能にします。トレイトは構造・モジューラリティ・再利用性をクラス内において提供しますが、クラス間の関係を見る際には無視できます。トレイトは再利用と分かりやすさのエクセレントなバランスを提供しながらも、よりよい概念的なモデリングを可能にします。さらにトレイトは、振る舞いの再利用にのみ関係し 状態の再利用には関係しないため、多重継承やミックスインに特徴的な実装の困難さを回避します。

トレイトの特徴は以下のとおりです。

  • A trait provides a set of methods that implement behaviour.
  • A trait requires a set of methods that serve as parameters for the provided behaviour.
  • Traits do not specify any state variables, and the methods provided by traits never access state variables directly.
  • Classes and traits can be composed from other traits, but the composition order is irrelevant. Conflicting methods must be explicitly resolved.
  • Trait composition does not affect the semantics of a class: the meaning of the class is the same as it would be if all of the methods obtained from the trait(s) were defined directly in the class.
  • Similarly, trait composition does not affect the semantics of a trait: a composite trait is equivalent to a flattened trait containing the same methods.
  • トレイトは振る舞いを実装した メソッドのセットを提供します
  • トレイトは振る舞い提供する為のパラメータとなるメソッド・セットを必要とします
  • トレイトは状態変数を定義しません。またトレイトにより提供されるメソッドは直接変数にアクセスしません
  • クラスとトレイトは 他のトレイト達を複合することができます。しかし、複合の順序は適用しません。メソッドのコンフリクトは 明示的に解決されなければなりません。
  • トレイト複合は クラスのセマンティクスに影響を与えません。トレイトからメソッドを取得した場合も、直接クラスに定義した場合もクラスの意味は全く同じです
  • 同様にトレイト複合体は トレイトのセマンティクスにも影響しません。複合トレイトはフラットにメソッドが含まれるトレイトと全く同等です

A class can be constructed by inheriting from a superclass, and adding a set of traits, the necessary state variables and the required methods. These methods represent glue that specifies how the traits are connected together and how conflicts are resolved. This approach allows a class to be decomposed into sets of coherent features .i.e., traits. and factors out the glue code that connects the features together. Because the semantics of a method is independent of whether it is defined in a trait or in a class that uses the trait, it is always possible to flatten a composite trait structure at any level.

クラスはスーパークラスからの継承と、トレイトセットの追加、それに 必要な状態変数と、「必要なメソッド」で構築されます。「必要なメソッド」とはグルー(=具体的にトレイト達を相方と接続する方法や競合を解決する方)のことです。このアプローチでは、すっきりとしていて解りやすい機能の塊(coherent features)、ようするにトレイトでクラスを分解することが出来ます。また機能同士を接続するグルーコードを 取り除かれます。なぜならメソッドのセマンティクスは、トレイトを使用するトレイトまたはクラスの定義から独立しているからです。いつでももどのレベルの複合トレイト構造でもフラットにすることが可能です。メソッドのセマンティクスはメソッドがクラス内で定義たものなのかトレイト内で定義されたものなのかに依りませんので、複合トレイトの構造をどのレベルでも平坦化できます。

The contributions of this paper are the identification of the problems associated with multiple inheritance and mixins, and the introduction of traits as a composition model that solves these problems. We proceed as follows: in section 2 we describe the problems of multiple inheritance and mixins, and in section 3 we introduce traits and illustrate their use on some small examples. In section 4 we discuss the most important design decisions and evaluate traits against the problems we identified in section 2. In section 5 we present our implementation of traits. In section 6 we summarize the results of a realistic application of traits: a refactoring of the Smalltalk-80 collection hierarchy. We discuss related work in section 7. We conclude the paper and indicate future work in section 8.

本論文は、多重継承とミックスインに付きものの問題の識別と、これらの問題を解決する構成モデルとしてのトレイトの導入に貢献します。本論文の構成を以下に述べます:第2節では多重継承とミックスインの問題を解説し、第3節でトレイトとの紹介と小さなエグザンプルを使った利用方の説明を行います。第4節では最も重要なデザイン上の決定を議論し、第2節で特定した問題にいかに対処するかに着目してトレイトを評価します。第5節では私たちのトレイトの実装を示します。第6節では Smalltalk-80 の collection 階層のリファクタリングを通じて、実用的なアプリケーションにおけるトレイトの結果についてまとめます。第7節は 関連作業について議論します。第8節で この論文の結論と今後の課題について述べる予定です。


* * *


以上。なんだかわかるような、わからないような。英語は本当に苦手で、かなり適当に訳しています。・・・なんだか酷いことになっている気がします。

追記

気のせいではなく、とても酷いことになっていました..orz るとさん、ありがとうございます。

*1:訳注:よくわかりませんが、Smalltalk の メソッドカテゴリ(プロトコル)のことを言ってます?