設計には、方針が必要です。本書で扱う設計の基礎を紹介します。
設計をする理由は、目的を達成しやすくすることです。
たとえば、ゲームを作ることを考えます。いきなり、Unity Hubを起動して、プロジェクトの新規作成ボタンをクリックしました。さて、プロジェクト名をどうしたらよいでしょうか。とりあえず、今日の日付をプロジェクト名にして、Unityを起動させたとします。次に何をしたらよいでしょう。1つ作業を進めるごとに、行き当たりばったりで考えながらゲームを作るのは、無理がありそうです。
そこで、次のようなことをします。
学生活動では、このぐらいのことを検討しておけばよいでしょう。企業活動になると、予算という重要な制約が加わります。
決めるべきことを決めておけば、開発はスムーズに進められます。タイトルは設計時に決めたものをつければよいですし、プロジェクトを作成したあとは、スケジュールに従って作業を進めればよいのです。スケジュール通りに作業リストを終えれば、目的を達成する要件を満たしたゲームが完成します。
もちろん、すべてが予想通りに進むことはほぼありません。そのような場合は、目的やスケジュールに近づくように軌道修正をします。もし、目的やスケジュールを決めずに開発していたら、開発が脱線していることに気づくことも、修正するための方針を立てることも、難しくなります。
設計することによって、開発をスムーズに進められます。また、開発が期待通りに進んでいるかを確認する指針となり、問題が発生したら、それを修正する方向を指し示す基準になります。一定以上の規模のプロジェクトや、チームで作業をする場合、設計をするかどうかは、完成率や完成品のクオリティに大きく影響するのです。
目的がない活動には、設計は要りません。たとえば、小さい子供の遊びには、目的がなく、設計は必要ありません。ただ、ぐるぐる回るとか、誰かを追いかけるとか、ボールを転がすことをひたすら繰り返して、満足します。
学習の初期段階も同様です。目についたコードを入力してみたり、思いついたコードを書いてみることに、設計は不要です。この段階は、ツールや環境に慣れることが大切なので、とにかく触って、動かして、観察することが大切です。
経験を積むと、単純な反応に飽きてきます。ボールを転がすだけでは物足りなくなって、投げて離れた的に当てるとか、蹴ってゴールに入れるとか、目的が欲しくなります。目的ができると、それを達成するための方法を考えるようになります。ここからが、設計の出番です。
開発するシステムを抽象化することは、プログラムの設計では大切です。抽象化とは、本質的な共通点によって物事をとらえることです。
抽象化をするには、システムを構成するオブジェクトを列挙して、それらの共通点を見つけます。似ているものをグループ化して、共通する部分をインターフェースや親クラスとして定義します。定義したものに、異なる部分を加えて、バリエーションを増やします。
抽象化する部分と、具象的に作る部分を切り分けることで、同じコードや分岐文を削減できます。また、変更に強い構造になります。