Rust における継承と合成

# 0. はじめに

Rust を学び始めてから「継承より合成 (Composition over Inheritance [^1]  [^2])」という言葉に出会い、OOP において継承が提供する機能を、合成という別の設計方法によって実現できることを知った。私は C++ の比較的古い文法から OOP に入門したので、脳内が継承で凝り固まっていたが、C++ のような言語でも合成の精神でプログラム設計していけることに気づいた [^3]。Rust では継承が言語機能として実装されていないので、合成の書き方が自然になる。

この記事では、同じ境遇の方を想定して、Rust においてクラス継承に代わる手段の例を説明する。次のような方の参考になるかもしれない。

+ Rust で継承に代わる手段を知りたい。
+ トレイトを使ってインターフェースを実現したが、同じメソッドをコピペして各構造体に実装しなければならないのが嫌だ。
+ 構造体が特定のフィールドを持つことをアテにしたメソッドを作りたいが、コンパイルエラーになる。あるいは、``.get_hoge()`` ``.as_hoge()`` 等のメソッドを都度実装しなければならないのが嫌だ。
+ 継承元の構造体をフィールドに持つ継承先の構造体を作った際に、同名のメソッドを再び実装しなければならないのが嫌だ。
+ コードの抽象化には成功しているが、他の設計方法がないか探している。

先に、継承と合成の考え方の比較図を載せておく。上記のような悩みが発生した場合は、このように設計方針を変えると上手くいくかもしれないという話を以下で具体的な例題・コードと共に述べる。

![inheritance_vs_composition_game.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2988127/3fe52617-f8a2-5dee-0a84-89928a59c947.png)

なお、この記事は Rust の基本文法の解説ではなく、文法をどう活用してプログラム設計するかの模索である。文法に関しては、公式によって Rust ツアーというサイトで一通り解説されており、有用である。

https://tourofrust.com/TOC_ja.html

また、入門書としては、原旅人『コンセプトから理解する Rust』(技術評論社, 2022) を薦める。この記事では、この本の 5 章も参考にしている。

https://gihyo.jp/book/2022/978-4-297-12562-2

この記事は、Rust においていかなる場合も継承より合成の方が有用であると主張しているわけではない。性質の違いを認識し、問題に応じて使い分けるのが良いと思う。使用している外部クレートの性質によっても書き方は変わるだろう。そもそも、私はそのような主張ができるほど Rust におけるプログラム経験が無い。この記事は、別解の提案と比較として読んで頂きたい。

節 1 で、インターフェイスを実装するために継承を使いたい状況を、具体的な例題を通じて考える。節 2 では、C++ におけるアップキャストに代わる手段を説明する。節 3 では、機能を追加した構造体を新たに作りたい場合を考える。その後、節 4 で継承と合成の違いについて、抽象的にまとめる。

[^1]: Rust における継承より合成が説明されている記事: https://medium.com/comsystoreply/28-days-of-rust-part-2-composition-over-inheritance-cab1b106534a

[^2]: 継承より合成のウィキペディア: https://en.wikipedia.org/wiki/Composition_over_inheritance

[^3]: 特に、C++20 では、Rust のトレイト境界に相当する「コンセプト」という機能が搭載されたので、以下に述べるような設計は C++ でもできるようになっているのだと思う。私はまだ使ったことがない。: https://cpprefjp.github.io/lang/cpp20/concepts.html

# 1. インターフェイスの実装

異なる型のインスタンスに対して同じ機能を持つ (しかし実行内容は異なるかもしれない) 同名のメソッドを実装したい場合に継承が用いられる。もっと言うと、そういったメソッドの実装を各々の型に対して強制したい場合である。例えば、次の問題を考える。

あるお店では、商品 ``Product`` を売っていて、それらの商品はフルーツ ``Fruit`` と駄菓子 ``Snack`` というカテゴリに大別される。各商品は名前 ``name`` と値段 ``price`` を持つ。フルーツはそれに加え、色 ``color`` という特徴を持つ。対して、駄菓子は味 ``taste`` という特徴を持つ。

商品を体現するインスタンスに対して、次の 3 つのメソッドを**共通の呼び出し方法になるように**定義したい。

+ ``how_much()``: その商品の税込み価格を返す。税率は定数 ``TAX_RATE`` で表現する。
+ ``what_this()``: その商品の特徴を返す。例えばリンゴの場合、``red fruits``、チョコの場合、``sweet snacks`` を返したい。
+ ``print_description()``: その商品の特徴と価格を文章にして、標準出力に出力する。

## 1-1. 継承による設計 (C++)

このとき、継承を積極的に用いた設計は次のようになると思う。C++ のコードで示す。

```C++: C++
#include <string>
#include<iostream>
using namespace std;

// 税率を設定
const float TAX_RATE = 1.1;

// 商品を体現する継承用の抽象クラス
class Product {
    string name;
    int price;
public:
    // コンストラクタ
    explicit Product(string name, int price)
    : name(name), price(price) {}
    // 各メソッドの定義 or 継承先クラスでの実装の要求: ここでインターフェイスを実現
    int how_much() const {return (int)(price * TAX_RATE);}
    virtual string what_this() const = 0; // 継承用の純粋仮想関数
    void print_description() const {
	    cout << "The " << name << " is one of the " << what_this() << "." << endl;
	    cout << "The price is " << how_much() << " yen." << endl;
    }
};

// フルーツを体現するクラス: Product を継承
class Fruit: public Product {
    string color;
public:
    // コンストラクタ
    explicit Fruit(string name, int price, string color)
    : Product(name, price), color(color) {}
    // Product の純粋仮想関数をオーバーライド
    string what_this() const override {return color + " fruits";}
};

// 駄菓子を体現するクラス: Product を継承
class Snack: public Product {
    string taste;
public:
    // コンストラクタ
    explicit Snack(string name, int price, string taste)
    : Product(name, price), taste(taste) {}
    // Product の純粋仮想関数をオーバーライド
    string what_this() const override {return taste + " snacks";}
};

int main() {
    Fruit apple("apple", 100, "red");
    apple.print_description();

    Snack chocolate("chocolate", 20, "sweet");
    chocolate.print_description()

    return 0;
}
```

```: 実行結果
The apple is one of the red fruits.
The price is 110 yen.
The chocolate is one of the sweet snacks.
The price is 22 yen.
```

継承専用の抽象クラス ``Product`` を作り、クラス ``Fruit`` と ``Snack`` はそれを継承している。フルーツの商品については ``Fruit``、駄菓子の商品については ``Snack`` をインスタンス化することで、それぞれ適切なパラメータを持たせられる。このとき、インターフェイスの実装に関して注目すべきは次の点だと思う。

+ 基底クラス ``Product`` にメンバ変数 ``name`` と ``price`` を持たせることで、カテゴリ に依らず全ての商品インスタンスがこれらのパラメータを持つことが保証される。
+ 基底クラス ``Product`` にメソッド ``how_much()`` と ``what_this()``、``print_description()`` を持たせることによって、全ての商品インスタンスがこれらのメソッドを持つことが保証される。

また、各々のメソッドに関する次の性質も確認しておく。

+ メソッド ``how_much()`` の定義は、そのインスタンスがメンバ変数 ``price`` を持つことを前提にしている。
+ メソッド ``what_this()`` の定義は、継承先の子クラスの持つメンバ変数を前提にしているので、基底クラスでは定義できない。これと上述したインターフェイスの実装を両立するために、基底クラスで純粋仮想関数を用いて宣言している。
+ メソッド ``print_description()`` の定義は、そのインスタンスがメソッド ``how_much()`` と ``what_this()`` を持つことを前提にしている。

## 1-2. 継承のような設計: 抽象クラスをトレイトで代用

Rust においてクラスにいちばん近い型は、メソッドが実装された構造体である。上述の C++ コードと同じ全体設計で Rust を書くならば、次のような発想になるかもしれない。構造体には言語機能としての継承はないので、代わりにトレイトを用いて表現してみる。

Rust のトレイトは、構造体の持つメソッドを規定することができるが、抽象クラスとは違い、構造体の持つフィールドを規定することはできない[^4]。このため、フィールドの抽象化は諦めて、``Product`` トレイトによってメソッドに関するインターフェースを実装する方法が考えられる。

この方法をとる場合、次のように、トレイトのデフォルト実装で、フィールドにアクセスできないことが障壁になる。

[^4]: 今は構造体を考えているが、Rust ではその他の型にもメソッドやトレイトを実装できる。

```Rust: Rust
struct Fruit {
    name: String,
    price: u32,
    color: String,
}

trait Product {
    fn how_much(&self) -> u32 {
        self.price        
    }
}

impl Product for Fruit {}
```

```: エラー内容
error[E0609]: no field `price` on type `&Self`
 --> src/main.rs:9:14
  |
7 | trait Product {
  | ------------- type parameter 'Self' declared here
8 |     fn how_much(&self) -> u32 {
9 |         self.price        
  |              ^^^^^

For more information about this error, try `rustc --explain E0609`.
```

トレイトのデフォルト実装の時点では、実装先の構造体が ``self.price`` を持つことが保証されないので、コンパイラに怒られる。このため、次のように各構造体に対してメソッドを都度実装していくのがひとつの手である。

```Rust: Rust
const TAX_RATE: f32 = 1.1;

// メインプログラムでインスタンス化する構造体たちを定義
struct Fruit {
    name: String,
    price: u32,
    color: String,
}
// コンストラクタ
impl Fruit {
    fn new(name: &str, price: u32, color: &str) -> Self {
        Self {
            name: name.to_string(),
            price: price,
            color: color.to_string(),
        }
    }
}

struct Snack {
    name: String,
    price: u32,
    taste: String,
}
// コンストラクタ
impl Snack {
    fn new(name: &str, price: u32, taste: &str) -> Self {
        Self {
            name: name.to_string(),
            price: price,
            taste: taste.to_string(),
        }
    }
}

// 商品としてのふるまいを規定するトレイト
trait Product {
    fn how_much(&self) -> u32;
    fn what_this(&self) -> String;
    fn print_description(&self);
}

// 各構造体へ実装
impl Product for Fruit {
    fn how_much(&self) -> u32 {
        (self.price as f32 * TAX_RATE) as u32
    }
    fn what_this(&self) -> String {
        self.color.clone() + " fruits"
    }
    fn print_description(&self) {
        println!("The {} is one of the {}.\nThe price is {} yen.",
            &self.name, self.what_this(), self.how_much());
    }
}
impl Product for Snack {
    fn how_much(&self) -> u32 {
        (self.price as f32 * TAX_RATE) as u32
    }
    fn what_this(&self) -> String {
        self.taste.clone() + " snacks"
    }
    fn print_description(&self) {
        println!("The {} is one of the {}.\nThe price is {} yen.",
            &self.name, self.what_this(), self.how_much());
    }
}

fn main() {
    let apple = Fruit::new("apple", 100, "red");
    apple.print_description();

    let chocolate = Snack::new("chocolate", 20, "sweet");
    chocolate.print_description();
}
```

この方法のメリットは、各々の構造体に対してメソッドの定義を一箇所にまとめられる点だろう。しかし、今の文脈では ``how_much()`` や ``print_description()`` の定義を何度もコピペしなければならないデメリットの方が大きいので、改良案を次節で述べる。

## 1-3. 継承のような設計 <改>: ゲッターメソッド

前節の設計では、トレイトによって構造体のフィールドの規定ができないことから、フィールドの存在を前提にしたメソッドをデフォルト実装できなかった。そのため、共通の定義を持つメソッドも個別にコピペして実装しなければならなくなった。

これに対する処方には、ゲッターメソッドを用いるものがある。``Product`` が共通して持つべきフィールドの値を取得するメソッドをトレイトによって要求することで、間接的にそのフィールドの所持を要求する。

```Rust: Rust
const TAX_RATE: f32 = 1.1;

// メインプログラムでインスタンス化する構造体たちを定義
struct Fruit {
    name: String,
    price: u32,
    color: String,
}
// コンストラクタ
impl Fruit {
    fn new(name: &str, price: u32, color: &str) -> Self {
        Self {
            name: name.to_string(),
            price: price,
            color: color.to_string(),
        }
    }
}

struct Snack {
    name: String,
    price: u32,
    taste: String,
}
// コンストラクタ
impl Snack {
    fn new(name: &str, price: u32, taste: &str) -> Self {
        Self {
            name: name.to_string(),
            price: price,
            taste: taste.to_string(),
        }
    }
}

// 商品としてのふるまいを規定するトレイト
trait Product {
    // 共通のフィールドに対しゲッターメソッドを実装要求
    fn get_name(&self) -> String;
    fn get_price(&self) -> u32;
    // 共通のメソッドはデフォルトで定義
    fn how_much(&self) -> u32 {
        (self.get_price() as f32 * TAX_RATE) as u32
    }
    fn what_this(&self) -> String;
    fn print_description(&self) {
        println!("The {} is one of the {}.\nThe price is {} yen.",
            &self.get_name(), self.what_this(), self.how_much());
    }
}

// 各構造体へ実装
impl Product for Fruit {
    fn get_name(&self) -> String {self.name.clone()}
    fn get_price(&self) -> u32 {self.price}
    fn what_this(&self) -> String {
        self.color.clone() + " fruits"
    }
}
impl Product for Snack {
    fn get_name(&self) -> String {self.name.clone()}
    fn get_price(&self) -> u32 {self.price}
    fn what_this(&self) -> String {
        self.taste.clone() + " snacks"
    }
}

fn main() {
    let apple = Fruit::new("apple", 100, "red");
    apple.print_description();

    let chocolate = Snack::new("chocolate", 20, "sweet");
    chocolate.print_description();
}
```

ゲッターメソッド自身は各構造体に対して用意しなければならないが、それらを定義してしまえば、``Product`` に共通するメソッドの定義が一度だけで済むようになった。

この方針では、C++ の継承機能をトレイトで代用しているが、プログラムの全体設計は節 1-1 と同じである。同じトレイトを実装することによって、``Fruit`` と ``Snack`` のふるまいを共通化している。

## 1-4. 合成による設計: 機能ごとに構造体を用意

継承の考え方では、メインプログラムでインスタンス化するのは ``Fruit`` や ``Snack`` のような具体カテゴリを表す型だった。それらに共通する性質をインターフェース ``Product`` にまとめ、実装することによって、それらの所持を保証した。

対して、合成の考え方では次のように考えるのが自然だと思う。インスタンス化するのは商品全体を表す親構造体 ``Product`` である。商品をその機能 (構成要素) ごとに分解し、各機能に対し構造型を用意する。各機能に関するメソッドは、各々の子構造体に実装する。子構造体の抽象化にトレイトを用いる。最後にそれらの子構造体を親構造体に持たせる。子構造体の組み合わせを変えることで、親構造体のバリエーションを作り、共通した子構造体 (あるいは共通したトレイトを持った子構造体) を持たせることで、親構造体のふるまいを共通化する。

具体的には、``Product`` が値札 ``Tag`` と内容 ``Content`` を持つと考える。``name``, ``price`` を持つのは ``Tag`` であり、特徴 (``color`` や ``taste``) を持つのは ``Content`` である。メソッド ``how_much()`` は ``Tag`` に対するメソッドなので、``Tag`` 構造体に実装する。他のメソッドについても同様に、その機能を体現する構造体に紐づけていく。

``Content`` に関しては、それぞれの具体カテゴリ ``Fruit``, ``Snack`` が持つべきフィールドが異なるので、共通した型を作ることができない。この場合は、``Content`` に共通するふるまいをトレイトによって規定する。そして、ジェネリクスとトレイト境界を駆使し、親構造体にこれらの子構造体を持たせる。

```Rust: Rust
const TAX_RATE: f32 = 1.1;

// メインプログラムでインスタンス化する構造体
// 商品 (Product) は値札 (Tag) と内容 (Content) を持つ
// Content トレイトを持つ任意の型を content フィールドに持てる
struct Product<T: Content> {
    tag: Tag,
    content: T,
}

// Tag には name と price が書かれている
struct Tag {
    name: String,
    price: u32,
}
impl Tag {
    // コンストラクタ
    fn new(name: &str, price: u32) -> Self {
        Tag {name: name.to_string(), price}
    }
    // Tag に対するメソッドは Tag に紐づける
    fn how_much(&self) -> u32 {
        (self.price as f32 * TAX_RATE) as u32
    }
}

// Content に対して what_this() メソッドを要求
trait Content {
    fn what_this(&self) -> String;
}

// Content の具体バリエーション
struct Fruit {color: String}
impl Fruit {
    // コンストラクタ
    fn new(color: &str) -> Self {
        Fruit {color: color.to_string()}
    }
}
impl Content for Fruit {
    fn what_this(&self) -> String {
        self.color.clone() + " fruits"
    }
}

struct Snack {taste: String}
impl Snack {
    // コンストラクタ
    fn new(taste: &str) -> Self {
        Snack {taste: taste.to_string()}
    }
}
impl Content for Snack {
    fn what_this(&self) -> String {
        self.taste.clone() + " snacks"
    }
}

// print_description() は Product に対して実装
impl<T: Content> Product<T> {
    fn print_description(&self) {
        println!("The {} is one of the {}.\nThe price is {} yen.",
            &self.tag.name, 
            self.content.what_this(), 
            self.tag.how_much());
    }
}

// Product のコンストラクタ
impl Product<Fruit> {
    fn new(name: &str, price: u32, color: &str) -> Self {
        Self {
            tag: Tag::new(name, price),
            content: Fruit::new(color),
        }
    }
}
impl Product<Snack> {
    fn new(name: &str, price: u32, taste: &str) -> Self {
        Self {
            tag: Tag::new(name, price),
            content: Snack::new(taste),
        }
    }
}

fn main() {
    let apple = Product::<Fruit>::new("apple", 200, "red");
    apple.print_description();

    let chocolate = Product::<Snack>::new("chocolate", 20, "sweet");
    chocolate.print_description();
}
```

メソッド ``print_description()`` は ``Tag`` と ``Content`` 両方のメソッドをアテにしているので、親構造体 ``Product`` に紐づけた。この際に、``Content`` トレイトで ``what_this()`` メソッドを要求していることと、``Product`` の定義時にトレイト境界 ``T: Content`` を引いていることが重要である。これにより、``Product`` のフィールド ``content`` の具体型が定まらなくても、それが ``what_this()`` を持つことは保証されるので、``print_description()`` の定義に使える。

また、``Content`` 用の子構造体を作ることも大切である。仮に、次のようにして定義された ``Fruit`` 構造体をメインプログラムでインスタンス化する方針を取った場合、``print_description()`` の定義を一度にすることが難しくなるだろう。

```Rust: Rust
struct Fruit {
    tag: Tag,
    color: String,
}
```

# 2. ポリモーフィズムの実現

共通のふるまいをする複数の型を、その具体的な型に囚われずに一般的に扱うことをポリモーフィズムという[^5]。

[^5]: ポリモーフィズムのウィキペディア: https://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%95%E3%82%A3%E3%82%BA%E3%83%A0

## 2-1. アップキャストとオーバーライド → トレイト境界

(他の言語は知らないが) C++ では、アップキャストを用いてポリモーフィズムを実現するために、継承を用いることもある。Rust で同じ機能を実現するには、ジェネリクスとトレイト境界を用いることになる。

例えば、節 1-1 で述べた C++ のコードに次の関数を追加し、メインプログラムを実行する。

```C++: C++
void print_character(const Product& product) {
    cout << product.what_this() << endl;
}

int main() {
    Fruit apple("apple", 100, "red");
    Snack chocolate("chocolate", 20, "sweet");

    print_character(apple);
    print_character(chocolate);

    return 0;
}
```

```: 実行結果
red fruits
sweet snacks
```

これは、継承先クラスの参照を基底クラスの参照にキャストできることを用いた設計である。``print_character()`` では基底クラスの参照を仮引数で受け取っているので、基底クラスで宣言されているメソッドは使える。メインプログラムの実引数では、継承先のクラスの参照を渡している。そのため、``what_this()`` メソッドについては、継承先でオーバーライドされたものが呼び出される。このようにして、同じ ``print_character()`` 関数で複数の型を引数に取ることができる。

節 1-3 の継承のような設計において同じ関数を実装するには、ジェネリクスとトレイト境界、あるいはそれの簡略記法である ``impl`` 構文を用いる。

```Rust: Rust
// Product トレイトを持つ任意の型の参照を引数に取る
fn print_character(product: &impl Product) {
    println!("{}", product.what_this()); // Product トレイトのメソッドは使える
}

fn main() {
    let apple = Fruit::new("apple", 100, "red");
    let chocolate = Snack::new("chocolate", 20, "sweet");

    print_character(&apple);
    print_character(&chocolate);
}
```

節 1-4 の合成による設計ならば、メインプログラムでインスタンス化する型は全て同じ ``Product`` なので、引数を ``Product`` 型に取ればよい。ただし、``content`` 内の ``what_this()`` を用いるには、トレイト境界を引く必要がある。

```Rust: Rust
fn print_character<T: Content>(product: &Product<T>) {
    println!("{}", product.content.what_this());
}

fn main() {
    let apple = Product::<Fruit>::new("apple", 200, "red");
    let chocolate = Product::<Snack>::new("chocolate", 20, "sweet");

    print_character(&apple);
    print_character(&chocolate);
}
```

あるいは、次のように ``content`` を引数に取ることで、関数に渡す情報を最小限にした方が分かりやすくなるかもしれない。

```Rust: Rust
// Content トレイトを持つ任意の型の参照を引数に取る
fn print_character(content: &impl Content) {
    println!("{}", content.what_this());
}

fn main() {
    let apple = Product::<Fruit>::new("apple", 200, "red");
    let chocolate = Product::<Snack>::new("chocolate", 20, "sweet");

    print_character(&apple.content);
    print_character(&chocolate.content);
}
```

## 2-2. 動的ディスパッチ

上の例では、メインプログラムでインスタンス化した時点で、``apple`` の型はフルーツに決まり、``chocolate`` の型は駄菓子に決まる。``print_character()`` はフルーツ型とチョコレート型に対して用いられることがあらかじめ分かっているので、Rust ではコンパイル時にこの 2 つの型に対する ``print_character()`` が生成 (複製) される。つまり、実行時には、自分で 2 つの型に対する ``print_character()`` を定義したのと同じコードの状態になっている。これがジェネリクスの役割であり、静的ディスパッチなどと呼ばれる。

一方で、商品インスタンスを要素に取るベクタを宣言したい場合を考える。ベクタの各要素は、それぞれフルーツかもしれないし、駄菓子かもしれない。ジェネリクスとトレイト境界では、``Vec<Fruit>`` や ``Vec<Snack>`` のような、一貫して同じ型を要素に持つベクタしか作れないので、両者が入り混じったベクタを生成できない。こういう問題は動的ディスパッチと呼ばれたりする[^6]。

[^6]: C++ のアップキャストとオーバーライドを使った方法は、動的ディスパッチである。一般には、静的に行った方が実行パフォーマンスが良いので、静的な問題には静的に対応したい。C++ ではそのような場合、テンプレート機能が用いられる。

動的ポリモーフィズムを実現するには、``enum`` 型を用いる方法とトレイトオブジェクトを用いる方法がある。詳細は、例えば次の記事を参考にして欲しい。

https://zenn.dev/j5ik2o/articles/045737392958a3

https://sharply.hatenablog.com/entry/2020/04/19/001236

## 2-3. ``Deref`` を使って継承を真似する (要注意)

``std::ops::Deref`` トレイトを実装することで、まるで参照外しのようにして、「派生」構造体がフィールドとして持つ「基底」構造体のメソッドやフィールド (の参照) にアクセスできるようになる[^7]。これにより、C++ のアップキャストに似た設計を実装できる。しかし、Rust の文法的におかしい挙動をすることになるので、使用には注意を要する。

[^7]: 参考: https://github.com/rust-unofficial/patterns/blob/main/anti_patterns/deref.md

```Rust: Rust
use std::ops::Deref;

// 基底クラスの代用
#[derive(Debug)]
struct Base {field: u32}

impl Base {
    fn print_hello(&self) {
        println!("Hello")
    }
}

// 派生クラスの代用
#[derive(Debug)]
struct Derived {
    base: Base,
}

impl Deref for Derived {
    type Target = Base;
    fn deref(&self) -> &Base {
        &self.base
    }
}

fn main() {
    let derived = Derived {base: Base {field: 10}};
    derived.print_hello();
    println!("{}", derived.field);
    println!("{:?}", derived);
    println!("{:?}", *derived);
}
```

```: 実行結果
Hello
10
Derived { base: Base { field: 10 } }
Base { field: 10 }
```

# 3. 機能の追加

継承を使う最も直接的な場面は、ある型が持つフィールドやメソッドを引き継ぎ、かつ新たな機能を持った別の型を定義する場合だと思う。もっと言うと、古い型と新しい型の共通項については同じふるまいをさせたい場合である。節 1 で考えた問題と同じ店における別の問題を考える。なお、以下では簡素化のため、コンストラクタやメインプログラムを省き、重要な部分のみを切り抜いたコードを提示する。

通常の商品 ``Product`` に加え、同種の商品を袋詰めした商品 ``PackedProduct`` も売ることになった。これに伴い、プログラムに対して新たな要求が発生した。

+ **要求 1**: ``PackedProduct`` は ``Product`` の持つ変数に加え、個数 (内容量) ``number`` という変数を持つ。
+ **要求 2**: ``PackedProduct`` は ``Product`` の持つメソッドに加え、``unit_price()`` というメソッドを持つ。これは、袋詰めされた商品 1 個あたりの値段を返す。
+ **要求 3**: ``print_description()`` メソッドについては、``PackedProduct`` 用の定義を加えたい。
+ **要求 4**: ``Product`` と ``PackedProduct`` が共通して持つメソッドについては、注目するインスタンスが ``Packed`` かどうかを気にすることなく、同じ書き方で呼び出せるようにしたい。

## 3-1. 継承による設計 (C++)

継承を積極的に用いるならば、``Product`` を継承して機能を追加した ``PackedProduct`` クラスを作る発想になると思う。節 1-1 でのコードに次の変更を加える。``Product`` を継承した ``Fruit`` クラスとは別に、``PackedProduct`` を継承した ``PackedFruit`` クラスを作り、メインプログラムでインスタンス化する。``print_description()`` メソッドについては、``Product`` での定義に ``virtual`` 指定子を付け、``PackedProduct`` でオーバーライドすればよい。

```C++: C++
// 袋詰め商品を体現する抽象クラス
class PackedProduct: public Product {
protected:
    int number;
public:
    int unit_price() const {return price / number;}
    void print_description() const override {
        cout << "This is a packed product. The number of contents is " << number << "." << endl;
	    cout << "The " << name << " is one of the " << what_this() << "." << endl;
	    cout << "The price is " << how_much() << " yen." << endl;
    }
};
// 袋詰めされたフルーツ
class PackedFruit: public PackedProduct {
    string color;
public:
    string what_this() const override {return color + " fruits";}
};
```

この方法のメリットは、機能の追加が直接的に実装されていて分かりやすい点である。上述した**要求 4** については、言語の機能として自動的に保証される。

しかし、注目しているクラスがどんな変数やメソッドを持つのかが分かりにくい。また、``what_this()`` については、``Fruit`` と ``PackedFruit`` に対し、同じ定義を二度書かなければならなくなっている。この定義を共通化するには多重継承を用いる手があるが、すると、全体の設計は合成によるものに近づくことになる。

## 3-2. 継承のような設計: トレイトの継承

節 1-3 の方針を採用するならば、トレイトの継承を用いることになる。``Product`` トレイトを継承した新たなトレイト ``Packed`` を作る。これにより、``Packed`` を実装した構造体は必ず ``Product`` も実装しなければならないので、``Product`` で宣言されたメソッドも用いた定義を行える。``PackedFruit`` 構造体を新たに作り、``Product`` と ``Packed`` を実装する。

トレイトの継承では、メソッドのオーバーライドはできない。言い換えると、ある構造体に 2 つのトレイトを実装する際に、それらのトレイトが同じ名前のメソッドを持っているとコンパイルエラーになる。しかしながら、トレイトにデフォルト実装されたメソッドを、構造体への実装 (``impl for`` 構文) 時にオーバーライドすることはできる。この場合、オーバーライドしなかった構造体にのみ、デフォルト実装での定義が適用される。この機能を用いて ``print_description()`` の更新を行う。

```Rust: Rust
trait Packed: Product {
    fn get_number(&self) -> u32;
    fn unit_price(&self) -> u32 {
        self.get_price() / self.get_number()
    }
}
struct PackedFruit {
    name: String,
    price: u32,
    number: u32,
    color: String,
}
impl Product for PackedFruit {
    fn get_name(&self) -> String {self.name.clone()}
    fn get_price(&self) -> u32 {self.price}
    fn what_this(&self) -> String {
        self.color.clone() + " fruits"
    }
    fn print_description(&self) {
        println!("This is a packed product. The number of contents is {}.\nThe {} is one of the {}.\nThe price is {} yen.",
            self.unit_price(),
            self.get_name(),
            self.what_this(),
            self.how_much()
        );
    }
}
impl Packed for PackedFruit {
    fn get_number(&self) -> u32 {self.number}
}
```

``PackedFruit`` に ``Product`` トレイトを実装し忘れるとコンパイルエラーになる。故に、``Fruit`` と同じトレイトを実装しなければならないので、**要求 4** は保証される。

``Product`` に関連したフィールドについては、新たな構造体を追加するたびに、全て書き直さないといけない。フィールド数が多くなるとややこしくなるかもしれない。また、フィールドを増やすたびに、関連する全ての構造体に対してゲッターメソッドを追加しなければならない。前節と全体設計は同じなので、``what_this()`` の定義ダブり問題も健在である。

## 3-3. 委譲による設計: 構造体の入れ子

合成の設計は委譲による依存関係の構築を基礎にしている。構造体 (クラス) A の機能を構造体 B にも持たせたい場合に、B にフィールドとして A を持たせてしまうのが委譲である。この節では、委譲を用いることで、節 3-1 と同じ全体設計の実現を試みる。しかし、この節の方針は今回の問題に対する良い解ではないかもしれない。

```Rust: Rust
const TAX_RATE: f32 = 1.1;

struct Product {
    name: String,
    price: u32,
}
impl Product {
    fn how_much(&self) -> u32 {
        (self.price as f32 * TAX_RATE) as u32
    }
}

// Product の機能を委譲
struct PackedProduct {
    product: Product,
    number: u32,
}
impl PackedProduct {
    // how_much() を再定義（転送）
    fn how_much(&self) -> u32 {self.how_much()}
    fn unit_price(&self) -> u32 {
        self.product.price / self.number
    }
}

// Product または PackedProduct の機能を
// それぞれの構造体に委譲
struct Fruit {
    product: Product,
    color: String,
}

struct PackedFruit {
    product: PackedProduct,
    color: String,
}
```

このコードでは、メインプログラムでインスタンス化する構造体の機能の一部を、入れ子のようにして委譲している。今回の問題では、``Fruit`` と ``PackedFruit`` をインスタンス化 (``obj``) した際に、共通して ``obj.product.how_much()`` という形式でメソッドを呼び出したい。このため、``Product`` で定義した ``how_much()`` を ``PackedProduct`` のメソッドとして呼び出すために、再定義が必要になっている。

上では示さなかったが、``what_this()`` や ``print_description()`` については、``Fruit`` と ``PackedFruit`` が共通して持つトレイトを定義して要求し、各々の構造体へ個別に定義することになるだろう。この定義の共通化をしようとすると、プログラム構造がややこしくなってくる。次の記事では、トレイトの継承と ``.as_hoge()`` メソッドを用いた実現方法が説明されている。

https://qiita.com/muumu/items/a0d111d129d20240d182

## 3-4. 合成による設計: 機能ごとに構造体を用意

節 1-4 の合成による方針を採用する場合、次のように考える。まず、節 2-1 で考えたような関数において、全商品を抽象的に扱いたいので、インスタンス化する構造体として ``Product<T>`` に加えて ``PackedProduct<T>`` を新たに作るようなことはしたくない。よって、``Product<T>`` の持つフィールドを変更することによって、機能を追加する。

具体的には ``Fruit`` の機能に ``Packed`` の機能を加えた ``PackedFruit`` 構造体を作り、``content`` フィールドとして持たせることもできるだろう。しかし、``content`` フィールドは既に、商品カテゴリ (``Fruit`` or ``Snack``) の数 N だけバリエーションを持つので、更に ``Packed`` と ``UnPacked`` の軸を増やすと、N × 2 の構造体を用意しなければならない。また、今回追加するメソッド ``unit_price()`` は ``Tag`` の情報を必要とする。これらを踏まえると、``tag`` フィールド用の構造体として、``Tag`` とは別の構造体を用意するのがより良い策に思われる。``Tag`` 構造体に ``Packed`` の機能を追加した構造体 ``TagForPacked`` を作る際には、節 3-2 のトレイト継承を用いた方法と、節 3-3 の委譲を用いた方法がある。

この節では、合成の考え方に固執し、``Product<T>`` に新たなフィールドを加える方針を取る。いちばん簡単な方法は、袋詰めされていない商品を、１個だけ袋詰めされている商品と同一視し、全ての商品インスタンスが ``number`` を持つようにするものである。この一般化が許されるのであれば、この方法が最善だろう。しかし、それではこの節の文脈を逸脱してしまう。

袋詰めされていない商品 (``number`` を持たない商品) と袋詰めされた商品 (``number`` を持つ商品) を区別するためには、``Product<T>`` に持たせる ``number`` をオプショナルにしたいが、Rust にはオプショナルフィールドを持たせられない。代わりに、``Option<u32>`` 型を ``number`` フィールドに持たせることになる。こうすれば、``number`` を持たないことは、``None`` によって表現される。この方針を取った場合、``unit_price()`` メソッドは全ての ``Product<T>`` に実装される。よって、``unit_price()`` の定義内で ``number`` フィールドが ``Some()`` か ``None`` かによる場合分けが必要になるだろう。袋詰めされていない商品に対して ``unit_price()`` メソッドを呼び出した場合に、実行時ではなくコンパイル時エラーを出したいのならば、そのような ``Product<T>`` にはメソッドを実装すべきではない。

そのような場合、ジェネリクスを用いるのが良いと思う。節 1-4 のコードに次の変更を加える。

```Rust: Rust
// 新たに bag フィールドを追加
// bag フィールドには、Bag (袋) トレイトを持つ任意の型が入りうる
struct Product<T: Content, U: Bag> {
    tag: Tag,
    content: T,
    bag: U,
}

// bag フィールド用に Packed と UnPacked の 2 つの型を用意
// Packed 構造体は number (袋詰めされた個数) を持つ
struct Packed {number: u32}
struct UnPacked;
trait Bag {}
impl Bag for Packed {}
impl Bag for UnPacked {}

// Packed Product にのみ unit_price() を実装
impl<T: Content> Product<T, Packed> {
    fn unit_price(&self) -> u32 {
        self.tag.price / self.bag.number
    }
}

// print_description() の定義は UnPacked の場合と Packed の場合の 2 通り
impl<T: Content> Product<T, UnPacked> {
    fn print_description(&self) {
        println!("The {} is one of the {}.\nThe price is {} yen.",
            &self.tag.name, 
            self.content.what_this(), 
            self.tag.how_much());
    }
}
impl<T: Content> Product<T, Packed> {
    fn print_description(&self) {
        println!("This is a packed product. The number of contents is {}.\nThe {} is one of the {}.\nThe price is {} yen.",
            &self.bag.number,
            &self.tag.name, 
            self.content.what_this(), 
            self.tag.how_much());
    }
}
```

メインプログラムで、例えば袋詰めされたフルーツのインスタンスを生成したい場合は、``Product<Fruit, Packed>`` をインスタンス化すれば良い。この方針の場合、親構造体が共通の型をフィールドに持つことと、メソッド実装の際のジェネリクスによって、**要求 4** が保証される。

この方法のメリットは、定義文のダブりが無く、ボイラープレート[^8]が最小限に抑えられていることである。また、インスタンス化する構造体がどのような機能を持っているのかが比較的見渡しやすいように感じる。

[^8]: 言語の仕様上仕方なく発生してしまう定型コードのこと: https://ja.wikipedia.org/wiki/%E3%83%9C%E3%82%A4%E3%83%A9%E3%83%BC%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89

# 4. 継承と委譲と合成

継承 (inheritance) と対比される言葉には、合成 (composition) の他に、委譲 (delegation) がある。ここで述べる委譲は、本来は転送 (forwarding) と呼ぶべきものであるようだ[^9]。しかし、今では多くの場合誤用されるようなので、この記事でも委譲と書いてしまう。

[^9]: 委譲と転送の違いについて: https://qiita.com/jesus_isao/items/4b6b7846ccf5eb46b1bc

継承と委譲を比較した際は、具体的な実装方法の違いに注目している。``Base`` 構造体の持った機能に新たな機能を加えた構造体 ``Derived`` を作りたいときに、言語機能としての継承とは、``Base`` のフィールドとメソッドを ``Derived`` にも強制的に持たせる機能である。この継承を用いる代わりに、``Derived`` に ``Base`` のインスタンスを持たせ、メソッドを再定義することで、同じプログラム設計を実現しようとするのが委譲 (転送) である。

OOP 言語における継承と委譲の比較については、例えば次の記事に書かれている。

https://ikenox.info/blog/inheritance-and-delegation-and-interface/

まとめると、``Base`` と ``Derived`` がプログラムにおいて同じ役割を果たす型であるならば継承、両者の役割が異なるならば委譲を用いた方が良いようだ。Rust では、継承が言語機能として存在しないので、委譲の有効範囲がもう少し広がる。これまで述べてきたように、Rust では次の 2 つの方法がある。

+ **Rust 式継承**: トレイト継承機能を用いる。フィールドを継承したい場合は、ゲッターメソッドを用いて間接的に行う。
+ **委譲**: 素直に委譲 (転送) を行う。

Rust 式継承ではゲッターメソッド、委譲ではメソッドの再定義 (転送) がボイラープレート[^8]になる。

委譲において、ボイラープレートを抑えるには、プログラム全体の設計を見直し、構造体間の依存関係を変更する必要がある。具体的には、なるべく役割が異なる型間でのみ委譲を行うようにする。役割が同じ型間での委譲を避けるために、役割をさらに細かく分割する。各々の機能を備えた型を、最後にまとめて 1 つの構造体に委譲することで、インスタンスに要求される全ての機能を備えた型を作る。これが合成の基本方針である。継承と合成を比較した場合、プログラムの設計方針に注目している。

![inheritance_vs_composition.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2988127/9d3cf421-68f4-e8a5-f5c6-529740a06d7a.png)