第7講 ファンクションプロシージャの学習
第2話 今までのプロシージャの結合箇所と構造化プログラミングの意味
Private Sub CommandButton1_Click()
  CommandButton2_Click '社員CommandButton2_Clickに仕事を依頼
  Dim a As Integer 'ローカル変数を用意
  a = 3 '箱aに3を代入
  Cells(3, 2) = "a=" 'B3にa=と表示
  Cells(3, 3) = a '箱の中身を表示
  Cells(4, 2) = "a=" 'B4にa=と表示
  Cells(4, 3) = f(a) 'fにaを2倍してもらってからaの中身を表示
End Sub
Function f(a As Integer)
  f = 2 * a 'aを2倍してCommandButton1_Clickに報告(返す)
End Function
の結合箇所は1カ所です。
具体的には、
001
赤で結びついています。
箱aの中身3を送り、その3を2倍した6を返しています。
行って戻ってくる経路は1カ所のみです。
かつてのBASICでは、
002
のように複雑な結びつき方をしていました。
ペイントの腕が悪くて、比較的に単純なものになってしまいましたが、
実際にはWeb(蜘蛛の巣)のようにもっともっと複雑でした。
ですからプログラミングは職人技だったのです。
C言語は行ったり来たりする場所を1カ所に限定することによって、
わかりやすいプログラムを組んでいました。
Visual BasicになったVBやVBAでもまったく同じです。
構造化プログラミングにおいてはプラモデルよりもっと単純で、
部品同士は1カ所のみでつながるのです。
BASICでは結合が複雑なだけでなく、
変数はすべてグローバル変数でしたから、
どこかのサブルーチンで変数の値が書き換えられてしまう心配がありましたから、
プログラマーはすべてのサブルーチンに目配りしなければなりませんでした。
そればかりか、コード(プログラムの文章)の中身まで読まなければなりませんでした。

ですが、C言語やVBAなどでは、
関数やプロシージャのプログラミング内容までは、
プログラミングのリーダーは知る必要がありません。
その関数やプロシージャ(社員)が何の働きをするのかを知っていればよいのです。
例えばそのプロシージャは、
1から1万などの与えられた数(引数によって指定)までの素数の個数を数える役割を持つ社員である、
と言うことを知っていればよくて、
どのようにして素数をカウントしているのかという、
プログラミングの内容を知らなくてよいのです。
素数の個数を数えるだけでも初心者には結構難しいプログラミングになります。
皆さんは、電卓を日常的に使っているでしょうが、
電卓がどのような仕組みでかけ算や割り算などをしているのかは知りませんね。
電卓の構造などを知らなくても、
電卓は四則演算(足し算・引き算・かけ算・割り算)などの計算をする道具であることを知っていれば、
電卓は使えます。
それと同じで、その社員がどんな仕事をしてくれるのかを知っていればよくて、
その社員がいかなる方式や原理でその仕事をしているのかは知らなくてよいわけです。
電卓は仕組みや構造を知らなくても使い方さえ知っていれば事足りるのと同じで、
プロシージャ(社員)についてもどんな仕組みをしていていかなる原理でその仕事をしているのかを知らなくても、
何の仕事をしてくれるのかさえ知っていれば、
部品として使うことが出来ます。
002のようなスパゲッティプログラミングでは、
社員の役割さえ知っていれば済むというわけにはいかず、
コードの内容=プログラミングの内容まで知らなければならないわけです。
それに対して、C言語やVBなどの構造化プログラミングの思想がいかに素晴らしいものであるかが、
理解できると思います。
関数(社員)の用途(原料を入れるとおまんじゅうを作ってくれるなど)さえ知っていれば仕組みなどを知らなくても、
プログラミングできるという思想がこそが構造化プログラミングの思想です。

プロシージャの中身を知らなくても、使い方さえ知っていればよいということを、
最近のプログラミングの世界では、
抽象化と呼ぶのだという話はすでにしてあります。
電卓と同じで中が見えなくてもよいという意味で、
抽象化と呼ぶわけです。
使い方さえ知っていればよくて、
中の構造は知らなくてよいということなら、
抽象化より遮蔽(しゃへい)化の方がよいと私が前に言いましたが、
皆さんもそう思いませんか。
電卓も中身が見えないように、
プラスチックや金属などの器で覆われていますね。
囲む素材=器で中が見えないように遮蔽しているのです。
ですから、抽象化ではなく遮蔽化と言った方がよいと考えるわけです。
パソコンを自作するときに、
部品の用途さえ知っていれば、
部品がどのような構造しているかを何も知らなくてもよいですね。
すべての部品は中が見えないように器で遮蔽化されています。

私は、抽象と具体について一家言を持つ者です。
このテーマでだけで数冊の本が書けるほどです。
哲学の歴史とは抽象と具体の解釈の歴史であると言っても過言でないほどです。
抽象にはそれだけ深い哲学的内容があるわけです。
ハイデッガーの存在の意味を問うとは、
言いかえると抽象と具体のあり方を問うことです。
ヘーゲルはそのあり方を解明する方法として弁証法を必要としたわけです。
モンテスキューの『法の精神』においても、
法(抽象)と裁判における個々の場合への具体的な適用との関係が問題にされています。
深い内容を持つ抽象を中が見えなくてよいという意味だけで使ってほしくない、
と私は強く思います。

用途さえ知っていれば、プロシージャの中は見えなくてもよいのですが、
現在扱っているプロシージャの中身は
Function f(a As Integer)
  f = 2 * a 'aを2倍してCommandButton1_Clickに報告(返す)
End Function
というように単純なものです。
プログラミングを学ぼうとしている皆さんは、
用途だけでなくプロシージャの構造もちゃんと把握して下さいね。




第1話へ 第3話へ

トップへ