‫このレッスンでは､ 具体的な例を使って､ 独自のインターフェースを作成し､ 実装する方法を学びます｡
‫特に､ 私たちのクラスが互いに関係を持たず､ したがってベースクラスを共有しない場合に､ なぜインターフェースが使われるのか､
‫その理由を知ることができます｡
‫だから､ そのような相続は選択肢にない｡
‫プレイヤーが物を破壊できるビデオゲームを制作していると想像してください｡ しかし､ 破壊するものはすべて､
‫破壊されたものによって異なる挙動を示すことになります｡
‫例えば､ 椅子を破壊すると､ 破壊音が鳴り､ 破壊された椅子のパーツが生まれます｡
‫しかし､ 車を破壊すると爆発音が鳴り､ 火災が発生し､ 近くにある他の物も破壊されます｡
‫このゲームでは､ furniture クラスを継承した椅子と vehicle クラスを継承した車を用意しました｡
‫では､ そのクラスを実際に見てみましょう｡
‫この椅子はfurnitureを継承しています｡ この椅子には単純なコンストラクタがあり､
‫作成されるオブジェクトに指定された内容に基づいて､ 色と素材を設定します｡
‫しかし､ もちろん､ このクラスは家具を継承しています｡ そのため､ 先ほど椅子クラスで使用した色と材質のプロパティがここにあります｡
‫そして､ ここにあるコンストラクタは､ デフォルトのコンストラクタで､ これらの値はデフォルトで設定されることになります｡
‫そのため､ 色と素材はデフォルトで白と木になります｡
‫そして､ 色と素材をデフォルトで設定するシンプルなコンストラクタも用意しました｡
‫なるほど､ 派手さはありませんが､ もちろん車もありますし､ 先ほど述べたように椅子と車を破壊できるようにしたいですね｡
‫では､ 実際にクルマを見てみましょう｡
‫ここでは､ vehicleを継承したcarのサブクラスで､ 車のスピードと色を設定しています｡
‫ところで､ ここで行うように､ 単純なコンストラクタを使用しています｡
‫しかし､ もちろんここでも､ 色だけでなくスピードもパスして､ ベースを使うことができたはずです｡
‫ですから､ これも有効なオプションであり､ ここでこれを使う必要はないでしょう｡
‫もちろん､ 2種類の方法があるわけです｡
‫なるほど｡
‫そして､ この車はvehicleを継承しており､ もちろんスピードや色も定義する必要があります｡
‫このクラスには速度､ 色､ デフォルトのコンストラクタがあり､ 速度には時速120キロメートル､
‫色には白が設定されていることがわかります｡
‫そして､ 車両オブジェクトに与えられた値に基づいて速度と色を設定する単純なコンストラクタがあります｡
‫また､ 当然ながら､ 例えば自動車などの継承対象にも｡
‫なるほど｡
‫では､ これらの異なるクラスがすべて揃い､ どのように構成されているかがわかったところで､ 実際の破壊機能を見てみましょう｡
‫では､ そのような破壊機能を作るには､ どのようなアプローチが良いのでしょうか？
‫なぜなら､ C-Sharpは単一継承言語であり､ 複数継承言語ではないからです｡
‫つまり､ 車はvehicleから､ 椅子はfurnitureからすでに継承されているのです｡
‫だから､ 他のものから継承することはできない｡
‫例えば､ ここにある乗り物ですが､ ほら､ C-Sharpでは複数のベースクラスを持つことができないので､
‫これを許しません｡
‫C-Sharpでは､ 1つのクラスが複数のベースクラスを持つことはできません｡
‫つまりプラス､ 車と椅子は全く別のものになるので､ どうせ1つのベースクラスを共有する具体的な関係はないわけですよね？
‫ここにあるようなクラスのそれぞれに､ 例えばdestroyメソッドという普通のメソッドを実装してしまうと､
‫メンテナンスが大変になります｡
‫将来､ 破壊システムを完全に変更したり､ 破壊可能なオブジェクトに視覚効果を追加することになったらどうするのですか？
‫実際に各クラスを調べて修正するのは面倒でしょう｡
‫なぜなら､ この場合､ いわば2つのサブクラスしかないからです｡
‫そうですね｡
‫しかし､ ゲーム内に50種類､ あるいは100種類のクラス､ 100種類のオブジェクトがあるとします｡
‫そうすると､ いちいち調べて､ それに合わせてコードを調整しなければなりません｡
‫だから､ それは本当に負担で､ 私たちはそれを経験したくありません｡
‫だからこそ､ より良い解決策を見出す必要があるのです｡
‫必要なのは､ コントラクトのように､ それを使用するすべてのクラスに､ 私たちのdistractibleの動作を強制する方法である｡
‫そして､ インターフェースに関するビデオをご覧になった方は､ インターフェースは私たちが作ることのできる契約であることをご存知でしょう｡
‫そこで､ この場合､ 最適な方法はインターフェースを使うことであり､ これをI Destroy Ableと呼ぶことにする｡
‫そして､ このインターフェースを実装するクラスは､ クラス自身によって､ 我々の破壊要件に従うと同時に､
‫カスタマイズを強いられることになります｡
‫では､ さっそくそのようなインターフェイスを作ってみましょう｡
‫したがって､ ここでプロジェクトに行き､ 新しいアイテムを追加し､ ここでインターフェイスを選択し､ 名前を付けることができます｡
‫だから､ これを呼ぶことにしたんです｡
‫インターフェイスを使うときは､ ファイル名の最初にIを付けて､ これがインターフェイスになることを示すのがおわかりいただけると思います｡
‫では､ このインターフェイスを追加してみましょう｡
‫つまり､ このインターフェースは､ 破壊を実行したときに実行されるオーディオファイル（破壊音）を格納するプロパティを持っているだけなのです｡
‫そして､ オブジェクトを破壊するメソッドを用意し､ このメソッドをdestroyと呼ぶことにします｡
‫何も返さない､ ただ何かを破壊するだけ｡
‫だから､ 例えば､ 持っているグラフィックを返すこともできる｡
‫そのため､ 例えば車が破壊されたとか､ 椅子が破壊されたとか､ アイテムが破壊された時点で表示したいオブジェクトを表示します｡
‫では､ 実際にこのインターフェースを実装し､ インターフェースの内容､ つまり破壊音と破壊メソッドを実装するクラスを作成しましょう｡
‫どうすればいいのでしょうか｡
‫では､ 例えば車を見てみましょう｡ 車には､ クラス定義の一番上にコンマを追加して､
‫このI destroy ableインターフェイスを使う必要があります｡
‫例えば､ このように自動でコードを作成してくれます｡
‫だから､ それは空白､ 破壊､ できる破壊を作成し､ それは私たちのために破壊音を作成することになります｡
‫これは自動生成されたバージョンですが､ 手動で行うこともできます｡
‫何の問題もありません｡
‫そこで､ ここでは例えば破壊音を実装することができます｡
‫そして､ 破壊されたオブジェクトを近くに保存するプロパティが欲しいのです｡
‫だから､ 車が破壊されたら､ その近くのオブジェクトも破壊されるはずです｡
‫そして､ このリストもタイプ別になる｡
‫I destroy able､ つまりこのインターフェイスを実装した任意のオブジェクトを格納することができ､ そのインターフェイスのプロパティとメソッドにのみアクセスすることができます｡
‫そこで､ それを作成するために､ I destroy all objectsの公開リストを作成し､ 近くにあるdestroy
‫ballsと呼ぶことにします｡
‫では､ 次にコンストラクタを拡張してみましょう｡
‫だから､ 一方では､ 音の初期化をしっかり行いたい｡
‫だから､ 爆発音は必ず出すようにしています｡
‫例えば､ 車の爆発音アンプ3という音があるとします｡
‫そして､ 破壊可能なオブジェクトのリストを初期化したいと思います｡
‫つまり､ 例えばこれは破壊されたオブジェクトの新しいリストになり､ あとはdestroyメソッドを実装するだけです｡
‫だから私はこれを破壊する｡
‫さて､ ここでもまだ不満があるようで､ destroyメソッドを実装するよう求められています｡
‫つまり､ インターフェイスを実装するときは､ そのメンバーを実装する必要があるということです｡ このインターフェイスは2つのメンバーを持っているので､
‫その両方を実装する必要があります｡
‫つまり､ ここに戻って､ 実際にdestroyメソッドを実装する必要があります｡
‫だから､ それをやるために本当にさっとやってしまいましょう｡
‫ここで付け加えたいのは､ まず､ 2つの文言になります｡
‫右のラインステートメントを使うだけでいいんです｡
‫ここではゲームを作るわけではなく､ インターフェースの概念を理解するためのものなので､
‫シンプルに説明します｡
‫ですから､ 車が破壊されたときには､ 破壊音を再生して､ 火災のエフェクトを作りましょう｡
‫ここでは､ 実際に音を再生するように模倣しています｡ 「OK､ 車の爆発アンプ3の音を再生して､
‫それから火を作ります｡
‫だから､ すべてが火の車なんです｡
‫車が破壊されたので､ すべてが燃えている｡
‫では次に､ 近くにあるすべての破壊を一つ一つ確認し､ 実際に破壊してみましょう｡
‫ここでは､ 破壊されたボールのリストの近くにある､ 破壊されたオブジェクトをひとつひとつ見ていきます｡
‫私たちはそれを「デストロイ・オール」と呼んでいます｡
‫つまり､ すべてのアイテムが破壊されたボールになるわけですが､ これは基本的にローカル変数の名前に過ぎません｡
‫そこで､ ID Storableインターフェイスを実装する破壊されたオブジェクトは､ for eachループの中でdestroy ballと呼ばれるようにします｡
‫つまり､ コレクションを繰り返し処理し､ 近くにあるボールを破壊します｡ これは I destroy
‫オブジェクトのリストで､ 基本的に ID stretchable インターフェースを実装したオブジェクトを破壊し､
‫destroy メソッドを呼び出すだけです｡
‫ですから､ 基本的にはここで連鎖反応を起こし､ 破壊されたすべての周りのものを破壊し､ それがまた車などにもなるのです｡
‫そこで今回は､ 2台の車が隣り合っていて､ その隣に椅子をたくさん置いているとします｡
‫そこで､ 自動車はこのdestroyメソッドを呼び出し､ 近くにあるアイテムを破壊することになるわけです｡
‫そうですね｡
‫音が出るので､ どのアイテムも音が出ます｡
‫さて､ もちろん､ 何かが燃えてから実際に爆発が起こるまで必要なタイマーを作ることもできます｡
‫でも､ ここではシンプルに考えています｡
‫だから､ 他の車だけでなく､ 他の椅子も壊しているんです｡
‫そのため､ それぞれのクルマは､ 近くにある他のアイテムを取り囲むように感染します｡
‫これは､ 例えば10メートル先や5メートル先､ あるいはアメリカのシステムでいうところの何インチ先にあるものすべてが対象となります｡
‫でも､ 基本的にはそういうことになりますね｡
‫では､ 椅子を見てみましょう｡ 椅子も同じようなアプローチをとることになりますから､
‫椅子の破壊を確認したいのですが､ 椅子の破壊の仕方は全く異なります｡
‫そこで､ ここではインターフェイスも追加することにします｡
‫椅子がバラバラになり､ 木が砕ける音が聞こえるので､
‫まったく違う破壊になります｡
‫だから､ ここではまったく違う音になる｡
‫そしてもちろん､ 破壊音もコンストラクタの内部で定義したいと思います｡
‫だから､ 椅子の破壊音が鳴ればいいということになりますね｡
‫いつまでも変わらない｡
‫だから､ 議長の宣言でここに追加していないのです｡
‫だから､ ここではシンプルにまとめています｡
‫もちろん､ 爆発音が異なる椅子を用意することも可能です｡
‫そして､ それをコンストラクタのパラメータとして先頭に追加します｡
‫さて､ それでは実際にdestroyメソッドを実装してみましょう｡
‫そして､ この場合､ 何が起こるかというと､ 何かを破壊するわけですが､ まず､ 椅子の持っている色に基づいて､ 色のついた椅子を破壊することになります｡
‫それを書いてから､ 破壊音を鳴らします｡
‫そして､ いよいよ椅子のパーツを産み出します｡
‫つまり､ 私たちの場合は､ コンソールに書き込むだけです｡
‫しかし､ 実際のゲームでそれをどのように行うか想像してみてください｡ ビデオゲームで何かを破壊する最善の方法は､
‫実際にすべての破壊を行う物理的なものではないのですが､ 特に場合として構築することは非常に困難です｡
‫いろいろなことをする大きなチームを持ってはいけない｡
‫そうすると､ 基本的には大きな爆発や破壊のアニメーションを作って､ その周りに転がっている個々のパーツの破壊された部分をスポーンしていくだけです｡
‫つまり､ この破壊方法からは連鎖反応が起きないことがわかります｡
‫つまり､ 椅子のdestroyメソッドの実装と乗り物のdestroyメソッドの実装は大きく異なりますが､ どちらもI
‫destroy ableインターフェースを継承しているので､ destroyメソッドを実装しなければならず､ 独自の方法で実装することが可能なのです｡
‫つまり､ インターフェースはある種の多重継承を可能にするものです｡
‫なるほど｡
‫それでは､ プログラム「CSS」にアクセスして､ 新しく作成したクラスを実際に使ってみましょう｡ そうしないと､
‫つまらないですからね｡
‫では､ さっそく椅子を2つ作ってみましょう｡
‫そこで､ オフィスチェアはブラウンとプラスチック､ そしてゲーミングチェアはレッドとウッドを予定しています｡
‫そして､ 新しいクルマも作ってみましょう｡
‫だからこの車はスピードが80で､ 青色で､ ダメージカーになる｡
‫そして､ 近くにある2脚の椅子､ この破損した車を追加します｡
‫そこで､ 破損した車の近くに破壊されたホイールとして追加しています｡
‫オフィスチェアだけでなく､ ゲーミングチェアも､ ここで破壊されたと見ると､ 車を作るときにはこのリストは空になるので､
‫近くにあるわけです｡
‫でも､ もちろん､ ここは公開リストですから､ 項目を追加することは可能です｡
‫そこに破壊された全アイテムを追加する｡
‫また､ 破壊されたボールの近くに椅子を追加できるのはなぜか？
‫まあ､ 椅子はこのインターフェイスを実装しているからね｡
‫それを部族と呼んでいたこと｡
‫つまり､ 椅子はタイプIの破壊対象として認められるようになったのです｡
‫つまり､ 近くにいる邪魔者として追加できるようになったということです｡
‫これで､ 車を破壊することができるようになったわけです｡
‫そこで､ ダメージを受けた車のdestroyメソッドを呼び出して､ 爆発に参加できるようにしましょう｡
‫爆発音が始まったり､ いいことづくめです｡
‫では､ これを実行してみましょう｡
‫もちろん､ 実際の3Dグラフィックなどを見るようなゲームではなく､ どちらかというとアドベンチャーゲームになると思います｡
‫そこで､ 破壊音､ 車の爆発音を鳴らし､ 火を起こす｡
‫ブラウンの椅子が破壊された｡
‫椅子破壊音アンプ3の破壊音を再生しています｡
‫次に､ 茶色の椅子のパーツを生成しています｡
‫そして､ 赤い椅子が破壊された｡
‫椅子破壊音アンプ3の破壊音を再生し､ 赤い椅子の椅子パーツを産み出しているところです｡
‫だから､ ほら､ ほとんどそうでしょう｡
‫つまり､ 自分でインターフェースを作る方法と､ その使い方を紹介するわけです｡
‫そして､ インターフェイスで何ができるのか､ インターフェイスの良さを理解していただけたのではないでしょうか｡
‫ここで重要なことは､ インターフェースは､ そのインターフェースを実装しているクラスの種類を気にしない､
‫類似または非類似の2つのクラス間の通信に使用されることです｡
‫ちょうど､ 自動車が椅子と通信してdestroyメソッドを呼び出したように､ 同じインターフェイスを実装しているだけなのです｡
‫ですから､ 一見するとわかりにくいインターフェースですが､ 私たちに大きなメリットを与えてくれます｡
‫それらの特典は､ コードの可読性です｡
‫つまり､ インターフェースは意図に関する宣言を構成し､ クラスの能力を定義するものなのです｡
‫つまり､ あなたのクラスができることは､ 例えばAI sortableを実装すれば､ あなたのクラスのオブジェクトはソートできることを明示していることになるわけで､
‫それならコードセマンティクスはどうなるのか｡
‫インターフェイスを提供し､ それを実装することで､ 積極的に概念を分離し､ インターフェイスは動作モデル､
‫オブジェクトができることの定義を行い､ これらの概念を分離することで､ コードのセマンティクスをより明確に保つことができるのです｡
‫そして､ コードがある｡
‫保守性の高いインターフェースは､ 結合を減らし､ 基本的なコードに影響を与えることなく､ 同じコンセプトの実装を容易に交換することができます｡
‫そして､ デザインパターンがあります｡
‫オブジェクト指向プログラミングに不可欠なコントラクト､ 抽象化､ インターフェースの活用という大きな流れの中で､
‫人間の理解や複雑なシステムアーキテクチャを実現しているのです｡
‫だから､ 本当に基本的には人間としての理解を深めてから､ 多重継承をすることです｡
‫つまり､ インターフェイスはC-Sharpで多重継承を利用するための入り口となるのです｡
‫そこで､ あるライブラリを書いて､ それをユーザーが変更できるようにしたいとします｡
‫インターフェイスとそのクラスの実装を書くのです｡
‫あなたのライブラリを使用する他の開発者は､ 同じ結果を得るために異なる技術やアルゴリズムを使用した独自の実装クラスを作成することができます｡
‫これは､ 私たちが使っているライブラリで多くのインタフェースに出会うのに､ 自分でライブラリを書かないために､
‫自分でインタフェースを書く必要性をほとんど感じない理由でもあります｡
‫最後に､ 重要なことは､ この時点でインタフェースがどのように実装されているかを理解することです｡
‫もちろん､ WPFやASP.NETなど､ さまざまな技術に触れていくうちに､ その技術に対応できるようになります｡ .NETやCシャープマスタークラスでは､ インターフェイスをより多く使うようになるので､
‫今後､ インターフェイスの理解が深まるでしょう｡
‫わかりました｡
‫それでは､ このビデオを見ていただき､ どうもありがとうございました｡
‫次回作でお会いしましょう｡