６２６日目

　?.えろSTG
　ここ２日、３日くらい、全然進まなくて落ち込み
　原因は分かっていて、製作が進んでクラスの量が増えて、把握できなくなって来ている・・・
　序盤の製作スピードなら１日で二つくらいのゲームのパーツが完成して、あれだよ、あの早さくらいだったら自分的にも割と満足なのに、今ではちょっとした変更でも、どこを変えていいか・・・調べまわらないといけない。
　初めのうちなら全て手が届く範囲ってカンジで、一・二行のコード改変でいけたりしてたのに。
　
　今でもその量は変わらない気もするけど、それが多クラスにまたがっていたりして、嗚呼、考えながらやっていたハズなのに、これだけはなるまいと心がけていたハズなのに。何故・・・・・・？
　
　豆乳では、型制限が無い。
　なので他のクラスへ繋ぐ際、引数も返り値もそのクラス型にする必要がなく、言わば全オールラウンダー、どこからでも繋げてひょいひょい移れる、これを１１１はしゅばんしゅばんの状態と言い、これが最善なのでは、とおもった
　事実、nekoというクラスのなかで、
$inu.bowwow();
　などすれば、inuクラスのbowwowを呼べて、その処理の一連が終われば、nekoにまた再帰する。
　nekoの中で書くより、inuにあるんだから、そこへポイと放っちゃえば、いちばん効率的。事実書くコードが半分くらい短くなるし。と・・・
　
　しかし$inuと指定してつなぐnekoには、inuに行くこと、分かるのだけれど、肝心のinuにあるbowwow関数には、そうやって繋がれてることは明記されない。
　一見効率的な書き方のように見えてこれ、いわゆる分離、カプセル化？　が全然出来ていないのではと。
　inuにbowwow関数があるってことは当然、inuの中でも使うんでしょう、それで必要があってbowwow関数の中身を変えたりするよね。
　そしたらnekoでエラーがでる・・・
　
　なにが書くコードが半分だ、バグの量は累乗じゃねえか。一つ一つで分離してなきゃ最低なんだよ・・・
　しかし待てよ待て待て、再帰待ちというか、単に気にすればいいのはreturnの値のような気もする。例えばbowwowが返すのが、効果音のファイル名だとして、それは返すファイル名が変われば、実際、意図したのと違うのが鳴るでしょう。（＊returnする変数は変わらず、変数の内容に対する処理を変えた）
　でもむしろそこは、犬の鳴き声の登録を変えたんだから、そら変わんじゃねえ？　変声期だよ。
　同じ処理だから関数で呼び出して省略だねー、としておいて、後でそこをいじったら、変わっちまったやねえか！！　ぐらい、身も蓋もない気がする・・・
　
　やはり書くコードが半分くらいになるという、この効率は捨てがたいし、とても悪いものとは思えない。
　しかし同時に効率化ってのは諸刃の剣というか、気を付けて変えなくちゃいけない事も事実で、そしてその際、bowwow関数にはどこから呼ばれてるか記されてない、ミスを誘発しやすい、ってことね・・・
　c++なんかではむしろそんな自由に呼んでいない、各クラスが持つ変数は全部privateという規制にして、同一クラス内からでないと変数は変えれません、変える為の変数を用意して、それを一々呼び出してください、っていうものらしい
　縛られてるからこそ、規制があるからこそ、コードがむちゃくちゃに飛んでいかず、把握できるようになるのではないかと・・・
　
　C++だと引数に、受けるクラス型とかも記されるでしょう、そしたらどこから呼ばれてるか分かるのよね、もちろんこの場合、どんなクラスから呼ばれてもいい・・・って話は無くなり、そのクラス型と親子の関係にあるものぐらいしか、入れられない（キャストできない）
　たぶん・・・
　
　しかし豆乳は、もうおちんちんならオールオッケー、ビッチである
　いや実は、自分たちが作成したつもりでいるクラスより、より上位で大元のクラスを継承していて、統一の親を持っているので、キャストできるんであろう・・・
　
　まぁ言えるのは豆乳、オブジェクト指向の極右というか、”ここから入る”にしては明らかに持て余す、手続き型言語で書いた方がやりやすい、となりがちなんではと。
　そして少しは心得あるものにしたら、ちょっと機能がしょぼ過ぎる、みたいな・・・
　
　こんな危ないクラスの使い方よりか、ただ一回保存してあとは参照するだけ・・・なら、よっぽどグローバル変数の方が良いな。と思う昨今。
　あ、グローバル変数の場合は頭に$を付ける、という豆乳独自ルールは分かりやすくていいかもしれない
　(C++とか・・・Javaも、宣言する位置で判断せよ、だった気がする)