今は､ 実際にコードが動いているのを見るのが一番の学習方法です｡
では､ 理論上､ 実際に自分のクラスをコーディングしてみましょう｡
全部削除して一からやり直します｡
例えば､ 私たちがゲーム会社のために働いていて､ そのゲーム会社が､ ハリー・ポッターのような魔法使いのゲームを作りたいと考えているとしましょう｡
さて､ オブジェクト指向プログラミングとは､ どのように考えればいいのだろうか｡
まあ､ まず必要なのは､ 選手の確保ですね｡
そうですね｡
各プレイヤーには､ 必要なキャラクターがいます｡
では､ ここにクラスを作り､ playerと呼ぶことにしましょう｡
キャラクター
もう一度｡
クラスなので命名規則に注意｡
と｡
もう一つのルールは､ 通常､ 複数形ではなく単数形にすることです｡
つまり､ 設計図だからプレイヤーキャラクターとは言えないんですね｡
この設計図から､ たくさんのキャラクターを作ることになりますが､ それらはオブジェクトになります｡
だからプレイヤーキャラクター､ 単数形ではシングル｡
ここで､ いくつかのことをやってみますが､ 注意していただきたいのは､ 最初は分かりにくいかもしれませんが､
我慢してください｡
説明します｡
その中にアンダースコア､ underscoreを定義するのです｡
アンダースコア､ アンダースコア｡
さて､ ここからは自己紹介です｡
そして､ それに名前をつける｡
キャラクターの名前です｡
ここからは､ もう一度Colinを行います｡
そして､ シンプルにセルフドット・ネームと言ってください｡
名前に等しい｡
まいったなぁ｡
ここで何が起こったのか？
もう一度言いますが､ これが何をするものなのか説明するのは控えて､ もう少し意味のあるコードを書きましょう｡
ここに別のメソッドを書いて､ 例えば各プレイヤーが実行できるrunメソッドを定義します｡
そして､ この中にもう一度､ この奇妙な自己病棟を作り､ この中で単純に印刷と言うことにします｡
走る｡
さて､ それではこのクラスを作成しました｡
まだ､ ちょっとわかりにくいですね｡
この中がどうなっているのか､ 自己がどうなっているのか､ この全く新しい姿は本当にわからないのです｡
しかし､ それはちょっと無視して､ 単純に言ってしまいましょう｡
プレイヤー
1つは､ プレイヤーキャラクターと等しく､ そのプレイヤーをインスタンス化することです｡
だから､ あれ｡
プレーヤーをプリントして､ このプレーヤーがどうなっているのかを確認することができます｡
実行」をクリックすると
よし､ 空気を読もう｡
タイプの空気です｡
必要な位置引数名が1つ不足していると表示されます｡
わかりました｡
ここで一旦休憩して､ 何が起こっているのか見てみましょう｡
これが見えるか？
メソッドは特別なメソッドです｡
ここに2つのアンダーラインがありますね｡
これをダンダー方式､ マジック方式という｡
そして､ これについては､ 特にビデオを用意する予定です｡
でも､ クラスを作るとき､ 普通は一番上にこれが表示されますよね｡
そして､ これはよくコンストラクタ・メソッドとかinitメソッドと呼ばれるものです｡
そして､ これはインスタンス化するたびに自動的に呼び出されます｡
Instantiateの意味は､ クラスを呼び出してオブジェクトを作成することだと覚えておいてください｡
このようにすると､ このコードブロックにあるものはすべて自動的に実行されます｡
で､ これを実行すると､ ここにあるオンライン9というエラーが出るんですね､ オンラインで｡
9つです｡
そして､ プレイヤーキャラクターをインスタンス化しようとすると｡
その中で走って､ 自己を行おうとする｡
名前は名前に等しい｡
しかし､ 問題は引数名をつけていないことです｡
そしてそれは､ 呼び出すときに､ selfの後にあるものをパラメータとして受け入れるからである｡
名前
だから､ この文字の名前をつける必要がある｡
では､ 名前をシンディとしましょう｡
ここを実行」をクリックすると
わかりました｡
プレイヤーキャラがいるようです｡
そして実のところ､ このメモリ位置にオブジェクトがあることまで示してくれているのです｡
つまり､ 私たちのコンピューター上では､ 今､ ここにプレイヤーキャラクターのプレイヤー1が位置しているわけです｡
とてもクールです｡
しかし､ この自分というキーワードは何なのか､ このコードは何のためにオンラインにあるのか｡
これは､ 私たちが定義するための方法です｡
まあ､ セルフセルフはプレイヤーキャラのことですけどね｡
これは､ これからプレイヤー1を作成する際に､ このプレイヤーキャラクターを参照し､
self dot nameをパラメータ名と同じにしたい､ と言っているのです｡
プレイヤー・ドット・ネームをここに置いて､ 実行をクリックすると､ そのプレイヤー・ドット・ネームが表示されるようにします｡
シンディがいる
そして､ なぜシンディなのか？
まあ､ パラメータのプレイヤーキャラを出したからなんですけどね｡
そして､ インスタンス化するときに､ nameパラメータを渡しています｡
デフォルトのパラメータはselfで､ クラスでは､ メソッドを定義するときのデフォルトの最初のパラメータは常にselfであることがわかります｡
そして今､ 私は自分ドットネームに名前をつけています｡
ここでこれを削除して､ 実行をクリックするとどうなりますか？
object has no attribute nameと表示されているのがわかりますね｡
なぜなら､ 私が「おい､ プレイヤーに名前を付けたいんだ」と言うためには､ セルフドットと言う必要があるからです｡
selfはプレイヤー1を指すからです｡
ですから､ リストがあるときは､ dotとやってからappendと言わなければならなかったのを覚えていますか？
誰かがこの追加コードを書いて､ 追加コードの中でself dotと言うことになります｡
リストに追加して､ selfはドットの左側にあるものを指すとしよう｡
このように､ まだ作成されていないものへの参照を持つことができるようになるわけです｡
プレイヤー1 そして､ 作成時､ インスタンス化時､ プレイヤー1にこのname属性を持たせて､
別のプレイヤーを作成したときに､ プレイヤーTomがプレイヤー2になるようにしてほしいということを伝えています｡
プレーヤーを名前にプリントして､ 実行をクリックすると｡
2つの名前の違うプレーヤーがいるんです｡
同じコードを使っても､ selfは､ インスタンス化するたびに､ 初回のプレイヤー1､ 次に2回目のプレイヤー2を参照するので､
異なる値を持つことができたのです｡
さて､ 自己というのは､ 本当に､ 本当に､ 理解するのが難しいものの一つです｡
そして､ このビデオを何度か見る必要があるかもしれませんが､ ここでのキーはあなたにとって明白であるはずです｡
つまり､ 一度だけコードを書くことができるようになったのです｡
原理原則のドライブを覚えていますか？
繰り返さないこと｡
そして､ オブジェクトのために作成するこのデータは動的なもので､ 与えるものによって変化すると言うことで､
動的なものにすることができました｡
そうすれば､ さまざまな属性の選手を作ることができます｡
しかし､ まだ同じコードを使用してください｡
これで､ ここに複数のものを置くことができるようになりました｡
例えばHを持つことができ､ もう一度自己のhがHに等しいと言うことができます｡ そして､ シンディは､ 例えば44とトーマス21をパスしなければならないでしょう｡
ここでもう一度､ 私が歳をとったらということですね｡
属性も違うだろうし｡
つまり､ これらのオブジェクトが持つ属性やプロパティは､ ドット記法でアクセスし､ プロパティ自体にアクセスすることができることを覚えておいてください｡
ここに括弧がないのは､ メソッドではなく､ 行動を起こしていないからだとわかりますね｡
これは､ 「この属性にアクセスしたいんだけど」というだけの話です｡
ここでドットを打つと､ 編集者が実際に教えてくれて､ おい､ お前は属性と年齢と名前にアクセスできるぞ､
という記号ができるんです｡
そして実は､ このメソッドを実行するためのアクセス権も持っているので､ 「実行」をクリックすると､ そのメソッドが実行されます｡
まあ､ ランはメソッドであることをお忘れなく｡
そのため､ このバインドメソッドを取得しても､ 何も印刷されず､ アクションも実行されません｡
そこで､ もう一度､ 括弧を付けなければならない｡
ヒット､ ラン
そして､ 見てください｡
ランができるようになった｡
そうすると､ 何も出てこないんです｡
次に21．
なぜ､ こんなものが出てくるのでしょうか？
なし？
なぜなら､ これは何も返さない関数であることを忘れてはならないからです｡
ある関数が何も返さないとき､ 私たちは何を得るのでしょうか？
私たちは何も得られません｡
だから､ 返品完了と言えばいいのかもしれませんね｡
実行」をクリックすると
これでよしとする｡
私たちは21を実行しました｡
さて､ このビデオを終える前に､ 最後にもう一つ｡
ここで面白いのは､ もし私がプレーヤー1をやった場合です｡
そして､ プレイヤー2､ これをプリントして､ 「実行」をクリックします｡
プレイヤーキャラクターを手に入れることができるのがわかると思います｡
しかし､ これらのオブジェクトは､ プレイヤー1とプレイヤー2がそれぞれ異なるメモリ位置にあります｡
だから､ 1つのコード､ 1つのブループリントで複数の選手を作ることができるんです｡
しかし､ この選手たちは同じではない｡
同じ設計図から作られたものなのに､ 記憶の中では違う場所に住んでいるのです｡
というのも､ 納得ですよね？
トムとシンディが同じ選手であることは避けたい｡
二人は別のプレーヤーなのです｡
こうすることで､ 安全性を保つことができるんですね｡
そして､ プレイヤー2に加えるものは､ たとえば､ プレイヤー2が攻撃できるようになったとします｡
そして攻撃は50になるだけの物件になります｡
さて､ ここで私が攻撃しなければ､ プレイヤー2が攻撃しているのがわかりますね｡
攻撃する｡
しかし､ もし私がプレイしたり､ 攻撃を望むなら
エアーを用意する
オブジェクトに属性がない｡
攻撃する｡
授業の威力を実感していただけたのではないでしょうか｡
最初は理解しにくいかもしれませんが｡
この設計図をもとに､ 何度も何度も自分のモノを作ることができるようになると､
その威力は明らかになります｡
次の動画でさらに掘り下げてみましょう｡