プログラミング詳しいやつ来い!
■ このスレッドは過去ログ倉庫に格納されています
interfaceってやつ こいつと継承の違いがわからん 上書き前提がインターフェースってイメージ? プログラミングの質問はマジでChatGPTに聞いたほうが早いしわかりやすい その言葉の通りだろ 接続するときの形式をある程度統一して整理したい時だ 知らんけど 無能「インターフェース要らなくねー?意味なーいじゃーん」 有能「無能が見つかったようですよ」 上司「わかった」 >>5 全ての言語での話だけど 今はC#でUnityやってる ダメージ用のインターフェースとか攻撃用のインターフェースとかいる? ダメージや攻撃クラスを継承じゃだめなの? 継承とインターフェースを比べるのがよくわからん 抽象クラスって言いたいの? IRefreshインターフェースでRefreshメソッドを用意するじゃん? そうしたらIRefreshインターフェースを継承したクラスは全部IRefresh型として扱えるからRefreshメソッドを呼び出せる で、IRefreshインターフェースさえ継承してれば子のクラスは何でもいいから クラス毎に中身が違うRefreshメソッドを呼び出せる >>10 いらないってのは言ってないけどどんなときに使えばいいのかっつー話をしてるんだよ >>11 すまんそのストラテジーパターンを教えてくれ >>13 例えばプレイヤー側とエネミー側があるとするじゃん? そんでその両者で攻撃のダメージを食らう処理や攻撃を与える処理って共通だと思うのよ そんでその部分を継承元として作る→プレイヤー、エネミークラスで継承+個別の処理を行う形とするわけ そんでその継承元クラスはインターフェースにするのかわからない >>16 継承元クラスよりもインターフェース作ったほうが良い的な? 今のところ継承元クラスだけ作って継承させてるけどどうなんだろうか? C#なら多重継承できないじゃん インターフェースはいくつでもつけていいじゃん >>25 なるほどそれ用のインターフェースなのか 多重継承させないやつだとインターフェース作る必要なし? インターフェースで済むならインターフェースで実装するべし 後でやっぱり他のクラス継承させようって思ったら、もう一回作り直さないとダメでしょ? >>22 インターフェースはクラスや抽象クラスの継承より自由度が高くて多重継承も可能 言語にもよるけど クラスの継承は「元クラスの機能拡張版を作りたい」場合に使って インターフェースの継承は「このインターフェースを継承したクラスはこの機能があることを約束する」場合に使うイメージ なるほど ならインターフェースで作るか… インターフェースってメソッド名だけ定義して中身の処理は書けないんだっけか? 継承元クラスとインターフェースは別物として考えたほうが良さそうだな なんか メソッド名だけでいいならインターフェース メンバー変数も欲しいなら抽象クラス デフォルトの実装も書きたいなら継承を使う これが基本かな >>33 似てるけどな 縛りを与えることで目的が明確になるのがありがてえ >>21 一応それでもいいけど もし他のオブジェクトにもダメージ入れたくなった時に便利 if(obj is Character) else if (obj is Block) else if (obj is Car) else if (obj is Item) ... がif(obj is Idamage)の一文で済む クラス作るときはこの形で作ってね っていう雛形のイメージ クラスの継承は上下関係 「人類」クラスを継承した「新人類」クラスを作りてぇって感じ インターフェースはジャンルの設定 「人類」クラスにも「犬類」クラスにも「哺乳類」の機能を持たせてぇって感じ 今こんな形で作ってる 共通のAttackClass public class Attack : MonoBehaviour { [SerializeField] private Collider[] colliderList;//←当たり判定用のコライダーのリストを指定する。(エディター上で追加していく) private Collider attackCollider; public void OnAttackStart(int attackNumber)//←当たり判定用のコライダーをオンにする(コライダーを常時オンにしておくと攻撃モーションじゃなくても攻撃が入ってしまうから) { attackCollider=colliderList[attackNumber];//与えられた攻撃種類のIDからそれに合わせた当たり判定コライダーを選んで attackCollider.enabled = true;//オン状態にする } public void OnAttackFinished()//←攻撃モーションが終わったらオンにしていたコライダーをオフにしている { attackCollider.enabled = false; } public void OnHitAttack(Collider collider,int attackPoit)//コライダーが当たったら攻撃ポイント分当たったもののHPを減算する処理 { var targetHP = collider.GetComponent<DamageSystem>(); if (null == targetHP) return; targetHP.Damage(attackPoit); } } Player側 namespace CharacterSystem.Players { public class PlayerCombat :Attack //←Attackクラスを継承しておりOnAttackStart関数やOnAttackFinished関数が自動的に実行される?まだ試していない { //Attackの他に攻撃を回避する動作や回復動作を入れるつもり←これはエネミーでの実装はないからここのみの実装となる } } こんな形でやってる >>34 なるほど では今回のパターンは継承の方がよさそうかな? >>36 これはIdamegeインターフェースを持っているクラス全てに対してという意味でしょうか? がっつりメンバーとか関数定義書いてるから、大人しく継承した方が良さそうだね クラスを継承するにしてもインターフェースは作っといた方が良いぞ 質問: プログラミングにおける抽象クラスとインターフェースの違いについて、小学生にでもわかるように説明しなさい。 人工知能: わかった、小学生にもわかるように説明するね。 抽象クラスとインターフェースは、プログラミングの世界で、コンピュータにどんな動作をさせるか指示するための道具箱のようなものだよ。 まず、抽象クラスは、ちょっとした設計図のようなもので、どんな機能があるかを示しているんだ。ただし、どのようにその機能を実現するかはちょっとわからない部分があるんだよね。それを具体的にどう動かすかは、他のプログラマがその設計図をもとに実際の機能を作り出すことになるんだ。 それに対して、インターフェースは、もっとシンプルで、どんな機能があるかだけをリストアップしているものだよ。これはまるで、約束事のようなもので、「このインターフェースを使うなら、こういう機能が必ず使えるようにしなさい」という指示だね。具体的にどう動かすかは、実際にそのインターフェースを使うプログラマが決めることになるんだ。 つまり、抽象クラスは「設計図」のようなもので、インターフェースは「約束事」のようなものだと思ってもらえればわかりやすいかな。どちらも、プログラムを作るときに役立つ道具箱の一部なんだよ。 ちなみにC#ならインターフェースにプロパティかけるから マジでクラス継承の出番が少ない メンバー変数を使わなくても良いシーンが多いからな へープロパティ書けるんだ 10年前に触っただけだからその時とは仕様変わったんかね >>38 なるほど階層ではなく分類的に使っていくものか >>41 public interface IDamage { void Damage(int value); } void OnTriggerEnter2D(Collider2D collision) { collision.gameObject.GetComponent<IDamage>()?.Damage(5); } >>43 そうなのか、、、 どんな感じで実装すればいいのかわからん 上で言うAttackClassにIAttackInterFaceをつける感じ? >>45 そうなのか じゃあインターフェースで書き直した方がよい? >>49 途中送信しちゃった こう書けば触れたオブジェクトからIDamageを継承したObjectを自動的に抽出してダメージを与えてくれる(本当はGetComponentsの方がいいけど) IDamageを実装しているクラスならなんでも自動的に攻撃してくれる >>49 GetComponentでIDamageインターフェースを持つすべてのものに対してって感じか Damageメソッドは別のクラスに実装していないとだめですよね? 実装はわかんない(未公開)けど同じメソッドを持たせるときに使うのが Interface たとえば、Android と iOS でブラウザを開こうとするじゃん? その時 Android は Intent を飛ばすが、iOS は NSApp のメソッドを呼ぶ やることは同じなのに違う実装になる その時、BrowserInterface と Open っていうメソッドを定義して、Android と iOS でそれを実装すれば、Android , iOS どちらでも BrowserInterface.Open を呼べばブラウザが開く こんな感じで実装が違うけど同じ事やらせたいな~って時にInterfaceを使う >>52 ちなみにインターフェイスを基底クラスに実装しておけば 派生クラスはインターフェイスを実装したことになってるぞ! だから継承がしっかりできてるならあんまり直さなくてもいい >>50 そういう使い方でいいと思う 細かくしすぎてもゴチャゴチャするから どれをインターフェース化するかは慣れとセンス 例えば公式のListクラスなんかコレクション系のインターフェースを大量に継承してたりもする https://i.imgur.com/2ouGbK5.png >>14 ショートカットキーとかもそうだけど便利な機能の習得自体をめんどくさがる奴はIT向いてないぞ デコレータパターンとかだとメリットが分かりやすい サンプルコードみてみろ >>14 こんなことやりたいって書けばサンプルコード書いてくれるし、APIの使い方とかどんな時に使うのかとかの解説も丁寧でいいよ >>61 >>63 サインイン出来ねぇってさ ま~じで死んでほしい コード書きながら構造考えるなよ。継承だのコンポジションだの言うのはある程度の要素書き出してからだろ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる