[過去ﾛｸﾞ] 【ゲームエンジン】Unityなんでも質問スレpart3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
178(2): 2021/02/08(月)22:01 ID:oiCGlHqI(1/2) AAS
>>175
スクリプトってのはUnityだとクラスだから、「1クラスにいろんな機能を放り込んだほうが楽じゃね？」という発想という前提で話をしてみる
結論から言うと「最初は楽かもしれないが、長期的には地獄を見る可能性がある」という感じ
以下解説、長文なので分割兼先に謝っとくね
オブジェクト指向設計原則またはSOLIDの原則と呼ばれるものがあって、その1つに「単一責務の原則」ってのがある
1つのクラスには1つの責務（機能）しか持たせない方が良いという原則
この原則に徹底的に反して、1つのクラスやオブジェクトにありとあらゆる責務をもたせちゃってるのがアンチパターンの1つ「神オブジェクト」ってやつ
フィールド（変数）やメソッドが1つのクラスの中にやたらめったらあると
たった1つのフィールドやメソッドを変更した時に他のメソッドに影響が出る可能性が出てくる
変数を変更してバグが出た後に「えっこのメソッドこの変数見てたの！？」って気づくような状況ね
省2
179: 2021/02/08(月)22:01 ID:oiCGlHqI(2/2) AAS
>>178つづき
神オブジェクトの危険性としては
自分一人の開発で神オブジェクトの中身をすべて把握しているなら影響範囲はわかっているだろうけど、1年後2年後もそれを覚えていられる人はまれ
影響範囲を忘れた後神オブジェクトの変更をしなきゃいけないとしよう（神オブジェクトはあらゆる機能を持つため変更も頻繁に入る）
どこに影響がでるかわからないからおいそれと変更できず、まず影響範囲を調査することから初めなきゃならなくなる
極端な例だけど100個のフィールド、100個のメソッドがある神オブジェクトの影響範囲を調べないといけないとしたら、それだけでうんざりするだろう
そして調査をすり抜けたメソッドがまったく思いもしなかったバグを生む・・・それが発覚するのは納品/公開後・・・みたいな悪夢も考えられる
蛇足だけどCorgi Engineの作者は最初の頃キャラの能力（走るとかジャンプとか）をもたせるクラスを1つだけつくって
その中にすべての能力の処理を書いていたらしいけど、メンテナンスが難しくなったので各能力ごとにクラスを分ける形に変更したそうな
ちなみにこうすることで新たな能力の追加をする際既存コードに手を加えなくて済むという「開放/閉鎖の原則」にも従った設計になってるんだけどさすがに割愛
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s