持つべきか、あるべきか？

車と飛行機は乗り物なので、これらのクラスがVehicleという共通の基底クラスから拡張されるべきなのは明らかです。これは典型的な学問的例であるが、これらのクラスを継承関係でバインドすることを決定する際には、いくつかの結果に注意しなければならない。

図1 継承関係の実装

この場合、クラスは互いに密接にリンクしている。つまり、各クラスの動作の変更は、ベース・クラスを変更することで実現できる。 コード.これはメリットにもデメリットにもなり得ますが、どのような振る舞いを期待するかによります。継承を適用するタイミングを誤ると、新しい関数を追加する際に、作成したクラスモデルに適合しないため、実装が困難になる可能性があります。コードを重複させるか、モデルを再編成するかのどちらかを選択しなければなりません。継承関係を実行するコードを "オープン・クローズド "と呼ぶことができる。Vehicleクラスに、すべての乗り物の一般的な、定義されたエンジン操作があると仮定すると、エンジンのない乗り物（例えばバイク）のモデルをクラス階層に追加したいと思った瞬間に、クラスに重大な変更を加えなければなりません。

クラス Vehicle
  def start_engine
  終了

  def stop_engine
  終了
終了

クラス Plane < 乗り物
  def move
    エンジン始動
    ...
    エンジン停止
  終了
終了

構成

既存のクラスの動作の一部にしか興味がない場合、継承に代わる良い方法はコンポジションを使うことだ。すべての振る舞い（必要なものも、まったく必要でないものも）を継承するサブクラスを作る代わりに、必要な関数を分離し、その関数への参照でオブジェクトを装備することができる。そうすることで、オブジェクトが の一種である。 という主張を支持している。 それには プロパティの一部のみ

図2 コンポジションの使用

このアプローチに従えば、エンジンの動作を担当するコードをEngineと呼ばれる自律クラスに分離し、エンジンを持つ車両を表すクラスにのみそのコードを参照させることができる。コンポジションを使って関数を分離することで、ビークルクラス構造がよりシンプルになり、個々のクラスのカプセル化が強化されます。これで、車両がエンジンに影響を与える唯一の方法は、そのパブリック・インターフェースを使用することです。さらに、異なるタイプのエンジンを異なる車両で使用したり、プログラム実行中に交換したりすることも可能になる。もちろん、コンポジションを使用することは完璧ではない。私たちは、簡単に拡張でき、変更の余地がある、緩くつながったクラスセットを作っている。しかし同時に、各クラスは他の多くのクラスとつながっており、それらのインターフェイスに関する情報を持っていなければならない。

クラス 車両
終了

クラス Engine
  def start
  終了

  def stop
  終了
終了

クラス Plane < 乗り物
  def initialize
    エンジン = Engine.new
  終了

  def move
    エンジンスタート
    エンジン停止
  終了

  def change_engine(new_engine)
    エンジン = new_engine
  end
終了

選択

どちらのアプローチにも利点と欠点がある。継承は特殊化なので、「is-a」型関係が存在する問題にのみ適用するのがベストだ。継承はクラス同士を緊密に結びつけるので、まず、コンポジションを使うかどうかを常に検討する必要があります。コンポジションは、"has-a "の型関係が存在する問題に適用されるべきである。飛行機は部品から構成されているが、それだけで何かそれ以上のものである。この例をさらに進めると、個々の部品は異なる専門家のバリエーションで発生する可能性がある。

継承もコンポジションもプログラマーが自由に使えるツールに過ぎないので、特定の問題に対して適切なツールを選択するには経験が必要です。だから、練習して失敗から学ぼう ᙂ。