8-5 CG 描画ソフトの作成 (2) −処理の分割−
【基礎課題 8-4】において、ほとんどの人は手続き Yoko を control ユニットに記述したと思います。それを呼び出すのが control ユニット (の ButtonDrawClick イベントハンドラ) ですからこれは自然なことです。ところが、Yoko は必ずしも (それを呼び出す) control ユニットに記述する必要はありません。実際、display ユニットに定義することも可能です。
一般に、後の拡張性やプログラムの再利用性を考えると、手続きや関数は関連する用途あるいは機能毎にまとめておく方が良いとされています。そこで、各ユニットの意味を改めて考えてみましょう。
Control ユニットには「線を描け。」などのように何を描くかを指示する所、つまり指示命令を書き込むところという意味がありそうです。一方、display ユニットは CG を描く描画領域およびその展示場所を提供するという役割を担っていると考えられます。そこで、改めて手続き Yoko の意味を考えましょう。これは、横線を描く命令ですが、個別の図形を描く道具類と捉える事ができます。そして、その図形描画の道具類を独立させておくと、例えば表示盤 (displayユニット) のデザイン等を変更したときでもそのまま使うことができます。
そこで、第3のユニットとして図形描画の道具類 (手続きや関数) を納める tools というユニットを作り、そこに、Yoko を納めることにしましょう。
【基礎課題 8-5】
「ファイル」→「フォームの新規作成」で第3のフォーム Form3 を作り、「ファイル」→「名前を付けて保存」で「tools」という名前で保存してください。そしてそしてこの tools ユニット内に、手続き Yoko を定義してください。同時に、control ユニット内の Yoko 定義部分および宣言部分を削除してください。
このとき、[描く] ボタンクリックのイベントハンドラは次のように修正しなければなりません。
procedure TForm1.ButtonDrawClick(Sender: TObject);
begin
Form3.Yoko(10, 20, 30, clRed);
end;
つまり、外部ユニット (Form3)の手続きを呼び出すので、省略していた市外局番 (フォーム名 Form3) をつける必要があるのです。また、control ユニットの uses 節にtools を付け加える必要があります。さらに、もはや control ユニットから display ユニットを参照する必要がなくなったので display は削除することができます。したがって、control ユニットの uses 節は次の通りとなります。
これにより、control ユニットは tools ユニットから描画ツールを呼び出す (描画の指示を出す)。tools ユニットの Yoko は display ユニットの描画領域上に横線を描く。そして、display ユニットは描画領域および作品の展示場所を提供する、というように役割分担が明確になりました。
現時点での各ユニットの関係は、次のようになっています。
コラム どうしてユニット化するの? ベストなユニット化とは?
今回は上のように3つのユニットを作りました。これは、CG を描くという作業は、どこに何を描けば良いかをデザインするデザイナー (control) とその指示通りに図を描く職人 (tools)、そして描いた図の展示場所 (大げさに言うとギャラリー) (display) という要素 (ユニット) に分解できるという考えに基づいています。
一見するとただ面倒な事をしているだけのように思えるかもしれませんね。しかし、このようにユニット化しておけば、職人 (tools) が同じでもデザイナー (control) を変えるだけで作品が素晴らしくなるかもしれませんし、また、ギャラリー (display) を変えることで、作品の見映えが良くなるかもしれません。つまり、このように、各ユニットで専門化が進めば作業の効率や達成度が上がるという思想が背景にあるのです。
それでは、どのようなユニットをいくつ作るのがベストなのでしょうか? 残念ながらそれには"正解"というものはありません。上の例で言うと、例えばより芸術的な作品を作る場合には、デザイナー (control) と職人 (tools) を一つにして artist というユニットを作った方が良いという考えもあるでしょうし、その他にも色々な考えがあるでしょう。
実際、ある一連の処理をどのようにユニット化すれば良いかは、一般に難しく、現在でもソフトウェア工学の分野で研究が進められています。またシステムエンジニアの現場でも、ある作業行程を適切なユニットに分割できる、という意味での設計力を持った人材が切に求められています。ここに、プログラミングの世界では、適切な単位に分けられたユニットの条件とは、プログラミングがしやすく、モジュール性が高く (ユニットを他人にあげたり他人からもらったりしやすい)、保守 (プログラムの誤りを修正したり後からプログラムを拡張したりすること) しやすいことであるとされています。
本テキストでは、これ以上突っ込んだ学習はできないのですが、将来システムエンジニア等を目指している人は、今後の専門ゼミや卒業研究での少し本格的なプログラム開発を通じて、ユニット化の経験を積んで欲しいと思います。