Why extends is evil：extendsはなぜ邪悪か - 具象基底クラスをインターフェイスに変えることでコードを改善する

## 翻訳にあたり

この記事はアレン・ホルブ(Allen Holub)[^1]さんの[Why extends is evil](https://www.infoworld.com/article/2073649/why-extends-is-evil.html)の翻訳です。古い記事ですが日本語訳が存在しないため翻訳いたしました。アレンさんにはTwitterメッセージ越しに快諾いただきました。

[^1]: 日本語圏における情報が少なかったため、[氏が講師を務めるアメリカO'reilly社の講座](http://shop.oreilly.com/product/0636920043942.do)で発音を確認したところ、「u」がほとんど発音されておらず(聴感上は「Holb」)、それに倣った。早口なせいか書き起こしが「Alan Holt(日本語字幕も当然アランホルト)」になっていたのはご愛敬。

Javaに総称型が導入される前の記事ですが、この記事の要点は現在でも通用する内容で、いい意味での古典だと思います。C#など、Java同様にインターフェイス(もしくはプロトコル、トレイト)を持つ言語にも応用できる知見です。なお、訳者は主にC#を使っていますが、以前Javaの経験も若干ながらあり、コードを読むのは苦手ではありません。

高校が語学系だったため英語には自信がありますが、翻訳記事の投稿は初めてのため、脚注に言葉選びの経緯を記載したり、重要なキーワードや意訳・翻訳ニュアンスに迷った言葉は英語を併記しています。訳注は少々本文とずれる部分がありますが、理解を深めると思われる情報を載せました。

## 序文

`extends` キーワードは邪悪だ。オウム真理教[^2]レベルではないが、できる限り避けるべきである。GoF本ではページ数を割いて実装の継承(`extends`)をインタフェイスの継承(`implements`)に置き換える方法を議論している。

[^2]: 原文ではCharles Manson. こういうちょっとした(Penn and Tellerをナポレオンズと言い換えるような)ローカライズは必要だと訳者は思うのだが、余計なお世話だろうか。原文からしてブラックジョークなわけだし…

いいプログラマは大半のコードを具象基底クラス[^3]ではなくインタフェイスで書く。この記事ではなぜ設計者がそのような奇習をするのか、またインターフェイスを使ったプログラミングの基本について数点述べる。

[^3]: キーワード：concrete base class

## インタフェイス対クラス

あるとき参加したJavaのユーザーグループ会議で、ゲストスピーカーとしてJavaの発明者ジェイムズ・ゴスリングが登壇した。記憶に残るのはQ&Aセッションで、誰かが「Javaを作り直すのなら何を変えたいですか？」と質問したときのことだ。その質問に彼は「クラスを取り除きたい」と答えた。笑いが引いた後、彼は問題がクラスそのものにあるのではなく、実装の継承(`extends`の関係)にあるのだと続けた。ゴスリングさんのおっしゃる通り[^4]、インタフェイスの継承の方が好ましい。できるなら実装の継承を避けるべきだ[^5] [^6]。

[^4]: 訳注：これは訳者の勝手な追加。もしかしたら「インタフェイスの継承の方が…」というのも実際ゴスリングさんがQ&Aで答えた内容なのかもしれない。そこまで原文からは読み取れなかったので、この内容が筆者の伝えたいことであることを鑑み、意味合いを補完する形での追記をさせていただいた。

[^5]: 訳注：インターフェイスの継承のみを許した言語にRustが挙げられる。実装は`impl`、トレイト(実装は持たないため実質インターフェイス)は`trait`と区別され、`impl`を拡張することはできない。

[^6]: 訳注：逆に実装の継承しか認めないのがC++である。この辺りはC言語のヘッダ形式(関数の型や引数の宣言部。インターフェイスと役割が重複すると言える)を受け継いだのが原因か。登場するメソッドを全て純粋仮想関数にすればインターフェイスっぽいことはできなくない(いわゆる抽象基底クラス)が、それは単なる中身のないクラスであり、メモリのオーバーヘッドが発生する。どう考えてもC++の設計思想に反している(が背に腹は代えられず濫用されているようだ)。脚注4のRustとは好対照である。

### 柔軟性の喪失

なぜ実装の継承をすべきではないか？　最初の問題として、明示的に具象クラスの名前を使うのは特定の実装に捉われてしまうことになり、将来的にゼロから[^7]書き換えるのがやたら難しくなることが挙げられる。

[^7]: 原文：down-the-line. 「将来的に」「徹底的に」と2つの意味があるが、文脈から両方の意味で取れるため併記した。

現代的なアジャイル開発手法の核となるのは並列設計[^8]と開発という2つのコンセプトだ。プログラムの詳細を決める前からプログラミングを始める。この技術は既存の叡智―すなわち設計はプログラミング前に完了する―に反するが、様々な成功を収めたプロジェクトが今までのやり方よりも、ハイクオリティなコードをより迅速に(そしてコスパ良く)作れることを証明している。並列開発のカギを握るのは柔軟性への理解だ。新しく出てきた必要条件を既存のコードにできるだけ楽に取り入れられるようにコードを書かなければならない。

[^8]: キーワード：parallel design. これといった和訳は無いし、Googleにも情報が見つからなかったが、言葉通りの意味でとらえて問題ないと思われる。

必要**かもしれない**機能よりも、変更を許容するやり方で**絶対**必要になる機能を実装する。このような柔軟性が無ければ、並行開発は不可能だ。

インターフェイスでプログラミングするのは柔軟な構造の肝だ。それを確認するために、もしインターフェイスを使わなかった場合どうなるかを見てみよう。以下のコードを考える。

```java
f()
{
    LinkedList list = new LinkedList();
    //...
    g( list );
}
g( LinkedList list )
{
    list.add( ... );
    g2( list )
}
```

高速なデータ検索が必要になったと仮定しよう。すると`LinkedList`は力不足なので、`HashSet`に変える必要がある。現状のコードでは、`f()`だけでなく`g()` (`LinkedList`を引数に取るため)及び`g()`のリストを受け取る部分ももれなく修正する必要があるため、変更は局所的ではない。

そこでコードを以下の様に変えてみよう。

```java
f()
{
    Collection list = new LinkedList();
    //...
    g( list );
}
g( Collection list )
{
    list.add( ... );
    g2( list )
}
```

これで、`LinkedList()`を`HashSet()`にすれば、結合リストをハッシュテーブルに簡単に変えることができる。以上だ。他の変更は不要である。

次に、以下のコードを比較しよう。

```java
f()
{
    Collection c = new HashSet();
    //...
    g( c );
}
g( Collection c )
{
    for( Iterator i = c.iterator(); i.hasNext() ;)
        do_something_with( i.next() );
}
```

```java
f2()
{
    Collection c = new HashSet();
    //...
    g2( c.iterator() );
}
g2( Iterator i )
{
    while( i.hasNext() ;)
        do_something_with( i.next() );
}
```

`g2()`メソッドはコレクションの派生物だけではなく、`Map`から取得できるキーと値のリストも横断できるようになった。実際、コレクションを横断するのではなく、データを生成するイテレータを書くこともできる。テストの土台やプログラムのファイルから情報を仕入れるイテレーターすら書くことができる、非常に柔軟なコードになった。

### 結合

実装の継承にまつわるさらに重大な問題は結合[^9]だ―つまり、プログラムのある部分と別の部分が望まざる依存関係になることだ。グローバル変数は強い結合がトラブルを起こす古典的な例だ。例えば、グローバル変数の型を変えた場合、その変数を使う(すなわち変数に**結合**している)関数が影響を受けうるので、コードを検証し、変更し、再テストしなければならない。さらに、その変数を使うすべての関数は変数を通してつながっている。ということは、ある関数が変なタイミングで変数の値を変更するのなら、不適切に他の関数の振る舞いに影響しているかもしれない。マルチスレッドプログラムではこの問題はことさらおぞましい。

[^9]: キーワード：coupling

設計者として、結合関係を最小限にとどめるよう努めるべきだ。あるクラスのオブジェクトからのメソッド読み出しはゆるい結合であるので、結合は完全に排除できない。つまり、結合の無いプログラムを書くことはできない。それでも、オブジェクト指向の原理(その中で最も大事なのは、オブジェクトの実装はそれを使うオブジェクトから完全に秘匿されるということだ)を頑なに守ることにより、結合をかなり抑えることができる。例えば、オブジェクトのインスタンス変数(定数でないメンバーフィールド)は常に`private`にすべきだ。**例外は一切認めない**(時には`protected`メソッドを効果的に使えることもあるが、`protected`インスタンス変数は禁忌だ)。同様の理由でアクセサーも使ってはいけない―フィールドを無駄に複雑な方法で公開しているに過ぎないからだ(基本型ではなくオブジェクトを丸ごと返すアクセス関数は、戻り値のオブジェクトのクラスが設計における大事な抽象化であるなら有用なのだが)。

何も教条主義という訳ではない。自分が関わった仕事の中でオブジェクト指向のアプローチの厳密性とコード開発の迅速性、コードメンテナンスの簡便性の間に明らかな相関性があったからだ。実装の隠蔽のようなオブジェクト指向の原理を破った時は例外なく、コードを書き直さなければならなかった。大抵の場合、コードがデバッグ不可能だからだ。筆者はプログラムを書き換える時間が惜しいので、ルールを守ることにしている。問題なのは完全に実用的であることだ。純粋であろうとするために純粋さを追及することに興味はない。

### 基底クラスの脆弱性問題

さて、結合の考え方を継承に適用してみよう。実装の継承システムは`extends`を使い、派生クラスは基底クラスと強固な結合を持つが、この親密なつながりは望ましくない。設計者はこの振る舞いを「基底クラスの脆弱性問題」[^10]と呼ぶ。基底クラスの修正はさも安全そうだが、この新しい振る舞いが派生クラスに継承された場合、派生クラスで誤動作が起こってしまいかねないため、基底クラスは脆弱と考えられる。基底クラスのメソッドだけを調べるだけでは、その変更が安全かどうかは分からないので、すべての派生クラスを見(て、テストし)なければならない。さらに言えば、新しい動作でコードが壊れる可能性があるので、基底・派生両方のクラスのオブジェクトをすべてチェックしなければならない。基底クラスをちょっと変えただけで全プログラムが動作不能に陥ることだってある。

[^10]: キーワード：Fragile base class problem. [英語版Wikipediaに記事がある](https://en.wikipedia.org/wiki/Fragile_base_class)ほど有名な問題だが和訳が無いため直訳した。流行れ。

脆弱な基底クラスと、基底クラスの結合問題をまとめて見てみよう。以下のクラスはJavaの`ArrayList`クラスをスタックのように振る舞わせるものだ[^11]。

[^11]: 訳注：ご存知かもしれないが、`Stack`[クラス](https://docs.oracle.com/javase/jp/17/docs/api/java.base/java/util/Stack.html)自体はjava.utilモジュールに存在する。ここでは学習のために独自のモジュールで実装したと考えてほしい。

```java
class Stack extends ArrayList
{
    private int stack_pointer = 0;
    public void push( Object article )
    {
        add( stack_pointer++, article );
    }
    public Object pop()
    {
        return remove( --stack_pointer );
    }
    public void push_many( Object[] articles )
    {
        for( int i = 0; i < articles.length; ++i )
            push( articles[i] );
    }
}
```

こんな簡単なクラスでさえ問題がある。ユーザが継承を誤用[^12]して`ArrayList`の`clear()`メソッドでスタックを空にしてしまった時を考えよう。

[^12]: 原文：leverages。「使う」程度の言葉であるが、やってはいけないことなのでこう訳した。

```java
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();
```

このコードは普通にコンパイルされるが、基底クラスはスタックポインタのことを知らないので、`Stack`オブジェクトは不定状態になる。次に`push()`を読みだした際は`stack_pointer`の今の値である2番目に新しいアイテムを入れるため、スタックには3つのアイテムがあることになる―底の2つはゴミなのだが(Javaの`Stack`クラスはまさにこの問題があるので使わないこと)。

望ましくないメソッド継承問題を解決するには配列の状態を変えるすべての`ArrayList`のメソッドをオーバーライドして、スタックポインタを正しく操作するようにしたり、例外を投げたり(`removeRange()`メソッドとか)することだ。

この手法には2つのデメリットがある、まず、すべてをオーバーライドするなら、基底クラスはもはやクラスでなくインターフェイスであるということだ。メソッドを継承しない限り、実装を継承することに意味は無い。2つ目に、より重要なことだが、スタックで`ArrayList`のメソッドを全て継承したくないはずだ。例えば、面倒な`removeRange()`は不要だ。使えないメソッドを実装する合理的な方法は例外を投げることだ。呼ばれないわけだから。この手法は事実上コンパイル時のエラーを実行時にたらいまわししている。もしメソッドがあって例外を投げるなら、プログラムが実際に走るまで関数が呼ばれるかどうかは分からない。

基底クラス問題に対するベターな案として、データ構造を継承するのではなくカプセル化する方法がある。新しい`Stack`の改善版は以下のとおりである。

```java
class Stack
{
    private int stack_pointer = 0;
    private ArrayList the_data = new ArrayList();
    public void push( Object article )
    {
        the_data.add( stack_pointer++, article );
    }
    public Object pop()
    {
        return the_data.remove( --stack_pointer );
    }
    public void push_many( Object[] articles )
    {
        for( int i = 0; i < o.length; ++i )
            push( articles[i] );
    }
}
```

パッと見は良さげだが、ここで基底クラスの脆弱性問題を考えてみよう。ある期間の最大スタックサイズを管理できる`Stack`の派生を作りたいとする。実装は例えばこんな感じである。

```java
class Monitorable_stack extends Stack
{
    private int high_water_mark = 0;
    private int current_size;
    public void push( Object article )
    {
        if( ++current_size > high_water_mark )
            high_water_mark = current_size;
        super.push(article);
    }
    
    public Object pop()
    {
        --current_size;
        return super.pop();
    }
    public int maximum_size_so_far()
    {
        return high_water_mark;
    }
}
```

とりあえずはこの新しいクラスは機能する。しかし`push_many()`が`push()`を呼び出すということを悪用[^13]していることがのちに響いてくる。とはいえ、それが悪いことだとは思いづらい。コードが単純化しているし、`Monitorable_stack`が`Stack`経由で参照されていても`push()`の派生版を使えるから、最大スタック数(`high_water_mark`)は正しく更新されるしね。

[^13]: 原文：exploits. 搾取するという意味で知られるが、プログラミング関連では「バグ」「不正動作」という意味でも使われる。

やがてある日のこと、プロファイラを走らせた誰かさんが`Stack`がたくさん使われているにもかかわらず遅いことに気づいた。`ArrayList`を使わないように`Stack`を書き換えることでパフォーマンスが上がる。ということで、大慌てで[^14]作ったバージョンがこちらだ。

[^14]: 原文：lean and mean

```java
class Stack
{
    private int stack_pointer = -1;
    private Object[] stack = new Object[1000];
    public void push( Object article )
    {
        assert stack_pointer < stack.length;
        stack[ ++stack_pointer ] = article;
    }
    public Object pop()
    {
        assert stack_pointer >= 0;
        return stack[ stack_pointer-- ];
    }
    public void push_many( Object[] articles )
    {
        assert (stack_pointer + articles.length) < stack.length;
        System.arraycopy(articles, 0, stack, stack_pointer+1,
                                             articles.length);
        stack_pointer += articles.length;
    }
}
```

`push_many()`が`push()`を何回も読みださなくなったことに注目してほしい―ブロック転送に変わっている。`Stack`の新しいバージョンは前のものよりもきびきびと動く。だが残念ながら、`push_many()`から派生版の`push()`が呼ばれないので、`high_water_mark`が更新されない。そのため`push_many()`を読みだした際に使用量が正しく測れなくなってしまい、`Monitorable_stack`派生クラスは機能しなくなってしまった。`Stack`は脆弱な基底クラスだ。ただ注意深くなるだけではこのような問題は実質排除できないことがお分かりいただけたと思う。

しかし、このように悪さを働く機能の継承が無いインターフェイスの継承を使えばこんな問題は発生しない。`Stack`がインターフェイスで、`Simple_stack`と`Monitorable_stack`に実装が分かれていたならば、コードはさらに堅牢だ。

例0.1に、インターフェイスを使用した解法を載せる。この解法は実装の継承版と同じ柔軟性がある。どのスタック実装を操作しているのにかかわらず`Stack`の抽象性に則ってコードを書くことができる。2つの実装はすべてのパブリックなインターフェイスを実装しているので、間違えることは難しい。派生ではなくカプセル化を使ったことで、基底クラスのコードを1回だけ書くのと同等の利点がある。カプセル化されたクラスの些細なアクセサメソッドを使ってデフォルト実装にアクセスしなければならないのが欠点だ(例えば、例のコード上では、`Monitorable_Stack.push(...)`はSimple_stackの相当のメソッドを読みださなければならない)。プログラマーはこう言ったワンライナーを書くことを嫌がるが、明らかなバグの温床を取り除けるなら安いものだ。

### 例0.1：インターフェイスで基底クラスの脆弱性を排除したバージョン

``` java
import java.util.*;

interface Stack
{
    void push( Object o );
    Object pop();
    void push_many( Object[] source );
}

class Simple_stack implements Stack
{
    private int stack_pointer = -1;
    private Object[] stack = new Object[1000];

    public void push( Object o )
    {
        assert stack_pointer < stack.length;

        stack[ ++stack_pointer ] = o;
    }

    public Object pop()
    {
        assert stack_pointer >= 0;

        return stack[ stack_pointer-- ];
    }

    public void push_many( Object[] source )
    {
        assert (stack_pointer + source.length) < stack.length;

        System.arraycopy(source,0,stack,stack_pointer+1,source.length);
        stack_pointer += source.length;
    }
}

class Monitorable_Stack implements Stack
{
    private int high_water_mark = 0;
    private int current_size;
    Simple_stack stack = new Simple_stack();

    public void push( Object o )
    {
        if( ++current_size > high_water_mark )
            high_water_mark = current_size;
        stack.push(o);
    }

    public Object pop()
    {
        --current_size;
        return stack.pop();
    }

    public void push_many( Object[] source )
    {
        if( current_size + source.length > high_water_mark )
            high_water_mark = current_size + source.length;

        stack.push_many( source );
    }

    public int maximum_size()
    {
        return high_water_mark;
    }
}
```

(訳注：さらなる柔軟性を求めるのであれば、`stack`の初期化をデフォルトで与えるのではなく、依存性の注入の考え方を用いて、`Stack`インターフェイスを引数に持つ`Monitorable_Stack`コンストラクタを定義すると良い。これがDecorator Patternである。デザインパターンを取り扱った書籍からの抜粋なので、以降のページで取り扱う内容だったのかもしれない。)

## フレームワーク

フレームワークベースプログラミングについて語らなければ、基底クラスの脆弱性問題の議論は不完全だろう。クラスライブラリをこしらえるのにMicrosoft Foundation Class (MFC)などのフレームワークは良く使われる。MFC自体はありがたいことに[^15]消えつつあるのだが、MFCの構造はあまたのマイクロソフト商品[^16]に入り込んでいる。プログラマが自分たちのやり方が最高だと思っているためだ。

[^15]: 原文：blessedly

[^16]: 原文：Microsoft shops. ここでいう「shops」は「店」のことではなく「工房(つまりMS社内)」と取るのが妥当だろう。ここでは文脈に合うように意訳した。

フレームワークベースシステムは必要なことをすべてやるわけではなく、派生クラスで欠如した機能を補う半分出来合いのクラス[^17]から始まる。Javaにおける分かりやすい例は`Component`の`paint()`だ。これは実際のところ仮初めのものにすぎず、派生クラスで実際の処理を実装しなければならない。

[^17]: 訳注：抽象クラスのこと。なぜ著者が「abstract class」という一般的な呼び方を避けたのかは不明だが、本文中の「抽象性」と意味合いが違っているし、抽象クラスはこの記事の論旨から言えば新規に設計するのは避けるべきことなので、婉曲的な呼び方をしているのかもしれない。

このようなものは何の問題もなく[^18]避けられるが、全体のクラスフレームワークが派生ベースのカスタマイズに頼るのは極端にもろく[^19]、基底クラスの段階で脆弱が過ぎる。MFCをプログラミングしたとき、マイクロソフトが新バージョンをリリースするたびにすべてのアプリケーションを書き換えなければならなかったし、コードはコンパイルされても、基底クラスのメソッドが変わったために動かないことがままあった。

[^18]: 原文：in moderation. [「適度に」「ほどほどに」という意味](https://ejje.weblio.jp/content/in+moderation)だが日本語としてはしっくりこないので、ニュアンスを取って和訳した。

[^19]: 原文：brittle。fragile(脆弱性)とほぼ同義である。

その点、全てのJavaパッケージは即戦力だ。動作させるのに拡張する必要は無い。この即戦力的構造は派生ベースのフレームワークよりも良い。使用・保守が簡単で、お上[^20]がクラスの実装を変えたとしてもコードの安全性は保たれる[^21]。

[^20]: 原文：Sun Microsystems. Oracleに買収されたのち、仕様策定元がJava Community Process(JCP)に変わり、さらに言えば実装もオープン化して複数あるという現状から断定を避ける言い方に変更した。

[^21]: 訳注：あくまでも仮定の話であり、影響を可能な限り抑えた範囲で末端のパフォーマンス向上をする場合([C#の文字列補間のコード展開の改善](https://ufcpp.net/study/csharp/st_string.html#csharp10-improvement)など)はあっても、既存のコードを危険にさらす抜本的修正ないし破壊的変更は避ける傾向にある。今までコンパイルできていたものが通らなくなったら顧客離れを誘発するからだ。そんなことをするくらいなら、既存の機能を置き換える新しいクラス・インターフェイスや構文を追加し、ユーザーにそれを使うよう呼び掛けるはずだ。前出のjava.util.Stackクラス自体もジェネリック化の末に、まさにこの記事で述べられた方法論で`Deque`[インターフェイス](https://docs.oracle.com/javase/jp/17/docs/api/java.base/java/util/Deque.html)およびその実装クラスに置き換わっている。MFCの問題点を見るに、元記事が執筆された時代はまだそういう配慮が欠けていたと考えられる。

## まとめ

一般的には具象基底クラスと`extends`関係を避けて、インターフェイスと`implements`関係を選択すると良い。筆者の鉄則はコードの最低でも80%はインターフェイスで書くことだ。例えば、`HashMap`を参照したりしない。使うのは`Map`インターフェイスの方だ(ここでいう「インターフェイス」はかなりルーズで、`InputStream`は抽象クラスとして実装されているものの、実質的にはインターフェイスとして使える)。

抽象性[^22]を上げれば上げるほど、柔軟性は増す。今日日のビジネス環境では、要求がプログラム開発が進むほどにころころ変わるので、柔軟性は必要不可欠だ。もっと言えば、アジャイル開発手法のほとんど(Crystalやエクストリーム・プログラミングなど)はコードを抽象的にしないと成り立たない。

[^22]: 訳注：抽象クラスを使えということではない。「派生ベースのカスタマイズに頼るのは究極にもろ」いからだ。

GoFパターンをよく見ると、実装の継承の代わりにインターフェイスの継承をする方法が多数挙げられていることに気づくはずだ。それが大多数のパターンの特徴でもある。パターンは発明されたのではなく、発見されたものだというのは、原点というべき明らかな事実だ。パターンはよく書かれた、簡単にメンテナンスできる実用的なコードの中に現れる。このよく書かれた、簡単にメンテナンスできるコードが実装の継承を極力避けていることが伝わってくるはずだ。

## 終わりに

(この部分の内容は原文の最後をもとに、適宜情報をアップデートしたり、内容を追加しています。)

この記事は[APress](https://www.apress.com/)より刊行された「Holub on Patterns: Learning Design Patterns by Looking at Code」(邦訳は残念ながら無し。だからこの記事を翻訳したわけではあるのだけれど)の[37ページ](https://link.springer.com/chapter/10.1007/978-1-4302-0725-2_2)に所収である。「翻訳にあたり」で述べた通り古い本であるが、英語に明るい読者は購入して読んでみてはいかがだろうか。

### 著者について

アレン・ホルブは1979年からコンピュータ業界で働いている。コンサルタントとして、ソフトウェアに投資しない会社の役員にアドバイスしたり、トレーニング、デザインとプログラミングサービスを提供している。10冊の本を上梓しており、代表作に「Cの宝箱」(工学社、1989年)[^23] 「Taming Java Threads」(Apress、2000年)「Compiler Design in C」(Pearson Higher Education、1990年)などがある。カリフォルニア大学バークレー校エクステンションで教壇に立っていたこともある。詳しい情報は[holub.com](https://www.holub.com)をご覧のこと。

[^23]: ホルブ氏の書籍の中で唯一日本語版が確認された書籍（アレン・ホラブ名義）のため、原文にはなかったが追加した。