Q&A
逆に修正の影響が少ない構成を考えてはどうでしょうか。いまさらかもしれませんが
今、Javaでマリオのような２Dアクションゲームを作っています。（作っている内容は直接質問に関係ありません）
そのときに、１、２ファイルくらいの小さな変更ならすぐにできるのですが、５、６ファイル以上にまたがるような少し大きな変更（ファイルの数でくらべるのはおかしいかもしれませんが、とりあえずコンパイルするまでの一回の変更で何箇所も修正が必要な変更）を加えるときに、全部一気に解決しようとして、修正したい部分があっちにもこっちにも増えてきたりして、なかなか思うように進みません。
だから、どのように考えれば効率的に変更を加えられるか知りたいと思いました。まだまだ初心者で、プログラムの書き方が悪いからかもしれませんが、皆さんの場合はどのように変更・修正をしているのかも含めて教えていただきたいです。よろしくお願いします。
少し変更するためにソースコードの多くを直さなければいけないような設計を「結合度が高い」と言います。結合度は可能な限り低くなるよう設計するもので、高ければ高いほど保守が困難になります。
結合度を低くするためにはモジュール化を進め、モジュール同士の相互依存度を低くします。またクラスの抽象化を進め、依存性注入できるよう心がけます。
最も効果的なのは、単体テストを主体とした TDD を行うことではないでしょうか。これに慣れ、テストしやすい設計を心掛けることで、自然と結合度の低いプログラムになります。
ゲームなどはかなりの仕様変更がある事を想定して最初の設計を決めなければなりません。
流石にいきなり「マリオを3Dにしよう！！」とか言い出さない限りは問題なく変更できるようにしないといけません。一度描画と機能のクラスを分けてみるのはどうでしょうか？
多文、走るやジャンプを同じプレイヤーというクラスに書いてしまっているように感じます。
Zuishinさん
回答ありがとうございました。
今まで、TDDは面倒くさそうで、初心者だしとりあえず動くものを作ろうと思って、飛ばしてきました。これから、少しずつTDDを調べて学んでいこうと思います。
ひとつ質問があります。愚問かもしれませんが、TDDについて、すべてのメソッドに対して、テストメソッド・クラスを作るべきですか？
stdioさん
変更できるように作るべきなので、最初は何も考えず作ってあとから変更しようと思っていたのですが主軸となる考え方は決めなければならないとわかりました。ありがとうございました
ところで、２つ質問があります。
走るとジャンプを同じクラスに書いたらだめなんですか？
もしも、いきなり「マリオを3Dにしよう！！」と思ったら、変更するより１から作り直すしかないですか？
あなたの回答
tips
プレビュー
