比較プログラム言語論 平成１６年７月７日 森田　彦

レポート（6/30）総括 　＜　テーマ　＞　 本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。 ＜論点のピックアップ＞ 　GO TO文の位置づけ 　プログラムの読みやすさ・書きやすさ 　言語の進化 　ソフトウェア危機 　差分プログラム

GO TO文の位置づけ① 私は大学二年目の講義でプログラミングを学んだが、やはり構造の流れがつかめないと自らがプログラムをしていてもまったく理解できないときがあった。そのためGOTO文は初めてプログラムをする人には難敵になる。よってダイクストラの主張は正しく、GOTO文は必要ないというより使ってはいけないのではないか。GOTO文は構造化定理へたどり着くまでの過程、または模索段階として考えた方が良いと私は考える。 プログラムの間に入れるだけで、処理したい場所に飛ぶ事が出来るGOTO文は、本日の講義で少し聞いただけで、簡単に理解する事が出来るほどわかりやすいものなので、プログラムを記述する段階では非常に有用な物であった事がよく分かります。 しかし・・・（略）見直した時や、他の人が見た場合に、（略）非常に見づらく、バグの補正が大変になる事も想像出来る・・・（略）。その後「連接」、「分岐」、「繰り返し」を処理の順につなげるだけで処理するという、構造化定理が登場しましたが、記述する段階での分かりやすさだけを取り上げれば、やはりGOTO文にはかなわないと思うので、数十行程度のプログラムを練習する初心者にとっては今でも有用な文なのではないかと思います。

GO TO文の位置づけ② GO TO文とはある処理の前に必要な処理をあとから付け足し、GO TOを使うことによって処理する順番を指定させるもので、いってみれば処理順番を歪曲させるというものに対し、構造化定理は現在使われているIFなどを用いて処理順番どおりに記述していくものでしたが、今思えば現在普通だと思っているものが何故当時GO TO文を使っていた人たちは気づかなかったのかと思いました。はじめからGO TO文ではなく構造化定理のほうが普及していたならばプログラミングはより発展していたのではないか（厳しく言ってしまえばGO TO文が普及していた時間は無駄だったのではないか）と思いました。 GO TO文は無駄だったのだろうか・・・？

補足 GO TO文の意義 あらゆる（計算可能な）アルゴリズムは「IF+GO TO」文を用いれば記述可能。 ダイクストラは、それらは連接・分岐・反復の３つの構造で置き換えられる事を証明。 それでも・・・ ある特別な条件の時に処理を終了あるいは中断する場合など、GO TO文を用いた方が便利な処理は存在した。　→　例外処理などの様に、構造化された構文として組み込まれて行った。 GO TO文は必要な処理を見出し、それが確定するまでのパイロット的な役割を果たした。 補足：GO TO文の方が処理速度が速かった。→コンピュータの性能が高くなかった時には、GO TO文は必要だった。

プログラムの読みやすさ・書きやすさ 構造化プログラミングのフローチャートは、GOTO文のフローチャートに比べてなんと読みやすいことか。・・・（略）構造化の前はこんなに読みにくかったんですね。GOTO文は思いつくまま書いて後で処理を繋げるもので、行き当たりばったりな感じです。対して構造化プログラミングは、実際にコンピュータに記述する前から、ある程度全体の流れを決めなければいけないものです。効率的です。読みやすいです。でも、設計段階からはっきりとした最終目標を持っていないと作れません。 正直GO TO文ちょっといいなと思いましたが、後に重大な欠点があることも思いしらされました。作るときには「楽」なのかもしれませんが、後の拡張や再利用性を損ない「使い捨てプログラム」になってしまう危険があることと「見易さ」の大切さを知りました。

補足：読みやすさ ／ 書きやすさの視点から構造化プログラミングを見ると・・・ 「IF+GO TO」文の世界→思いつくままに記述できる。→書きやすい（特別な訓練なしでも書ける）。 しかし、後から見ると読みにくい。→開発効率に限界 一方、構造化プログラミングの世界では・・・ 基本構造さらにはモジュールの組み合わせで（処理順に）記述する。→記述する際にプログラムの全体構造を把握しておく必要がある。→慣れるまで訓練（教育）が必要。 出来上がったプログラムは読みやすい。→開発効率は上がる。 構造化プログラミングの普及→教育の必要性増大 元々PASCAL言語は構造化プログラミングを教育するために開発されたもの 書きやすさから読みやすさへ

プログラミング言語の進化① 今日の授業で関心があったことは、先生が言った「今の言語はもう完成されているかのようにみえる（思われている）」というようなことを言っていたことです。私は、最初からすでに完成されてる言語を習っているのだとずっと思っていました。・・・（略）でも歴史を振り返ってみると、以前にはGOTO文というのがあり、それが進化して分岐や繰り返し文などがでてきて、よりいっそうプログラミングがしやすくなって、今のIF文などの文法が出てきたんだなと思いました。つまり、言語や文法は進化し続けていて、そのプログラミングの効率を上げるために、いろいろな考え方や試行錯誤の結果から今、私たちが習っている、文法にたどりついたんだなと、あらためて実感しました。きっと今の文法も新たな文法や言語に開発され直されると思います。だから今の文法や言語は完成形ではなく、まだまだ通過点に過ぎないんだなと思いました。 　今、皆が目にしている言語は、現段階での到達点。Javaもその一つ。 　言語は、今後も時代の要請を受けて発展（進化）する。

プログラミング言語の進化②－期待 GO TO文の魅力は物凄い。無限に付箋をつけるような物だから、使いやすいが判りにくいのは見たままである。この魅力から離れたことは英断と感じる。しかし、これで生産性が向上したと、いいことだけで終わらないのが面白い。構造化プログラミングにしても、今度はソフトウェア危機に直面した。まるでプログラミングの更なる発展を、強く促しているようで本当に面白い。未来のプログラミングはどうなるのか。 問題が起これば放棄しない限り、それを乗り越えようと発展するが、プログラミングはまだ向上できるのだろうか。 そう考えるとまだまだ世の中は面白い。 （略）なんにせよ、Javaは最終形態の言語ではないなと思います。どんな必要がJavaに突きつけられたとき、どんな言語に進化するのか・・・楽しみに思いました。

ソフトウェア危機 スライドの「ソフトウェア危機」の部分で「使う方は天国、作る方は地獄」とありましたが、全くその通りだと思いました。私がよくプレイするゲームの公式ホームページで製作スタッフの日記があるのですが、これがまた酷くて一週間寝ないとかずっと自分の家に帰らないとかが普通のようです。このような現状を見ると、初心者の人がこのような事を知るとやる気が落ちてしまうのではないかとも思いました。 印象深かったのがソフトウェアの危機です。構造化プログラミングによってソフトウェアの生産性が向上したことにより、ソフトウェアの生産性をさらに引き上げなくてはならない状況になっている。人間の欲は無限だなぁと思いました。

補足 ソフトウェア開発におけるユーザの要求と開発者の技術力の連鎖 補足　ソフトウェア開発におけるユーザの要求と開発者の技術力の連鎖 ユーザ 開発者 要求 技術力 この連鎖を止めることは困難 この連鎖が技術革新を生んできた。 現代は、需要と技術のあやういバランスの上に成り立っている。 ソフトウェアシステムの開発技術レベルを把握しておかなければトラブルが生ずる。 例：みずほ銀行のシステム障害 皆はどう思いますか？

オブジェクト指向プログラミングへの期待 ソフトウェア危機をオブジェクト指向で、どう乗り越えたかが非常に気になりました。 ソフトウェアの需要増に、ソフトウェアの生産が追いつかないといったソフトウェアが危機に陥っていることを知った。そんな中で、オブジェクト指向プログラムが注目されている。これからどのようにしてソフトウェア危機を改善していくのか楽しみです。

差分プログラム 自分は差分プログラムに興味を持ちました。どのように既存部分をいじらないで修正するのか知りたいです。 １つ気になったのは、モジュール再利用の問題点、差分プログラムの徹底という下りです。つまりこれは、すべて書き換えるとメジャーアップデートになると思っていいのでしょうか。

１ オブジェクトとは何か？ ２ オブジェクトの基本概念 ３ オブジェクトの拡張 オブジェクト指向の考え方 ＜本日のテーマ＞ ＜内容＞ オブジェクト指向の考えのエッセンスを学習し、それをプログラム開発に応用した場合にどのようなメリットがあるかを理解する。 ＜内容＞ １　オブジェクトとは何か？ ２　オブジェクトの基本概念 ３　オブジェクトの拡張

１．オブジェクトとは何か？ オブジェクトの例 カプセル化（プロパティとメソッド） オブジェクト指向的考え

オブジェクトの例 人、車、黒板、机などのモノのこと。 オブジェクト指向の世界では→（自身の）状態に関する情報と、（自身に対する）操作を有するモノ。 例）　車 　状態：型式、色、排気量、マニュアルかＡＴか、等々。 　操作：走る、停止する、等々。

カプセル化（プロパティとメソッド） オブジェクト→自身の状態を表すデータ＋（自身に対する）操作を有するモノ データと操作の（オブジェクトへの）カプセル化　 １セットにするという意味 車オブジェクト 色 排気量 走る 停止する データ プロパティ 操作 メソッド ・・・

オブジェクト指向的考え ある用途のためのオブジェクトがあれば･･･ そのオブジェクトのメソッドを操作することで、処理を実現 　　そのオブジェクトのメソッドを操作することで、処理を実現 例）　ゼミでコンパを企画する。 　オブジェクト→コンパ係　　メソッド→企画 　オブジェクト指向的記述→コンパ係．企画　（ドット記法） 　（意味：コンパ係に企画を依頼する。→コンパ係オブジェクトに企画せよというメッセージを送る。）　　　 プロパティとメソッドがカプセル化されたオブジェクトを用いれば、手続き指向プログラミングよりも効率が上がる!? 操作（メソッド）の詳細を知る必要がない。

補足 カプセル化の意味 関連のあるメソッドとプロパティを組み合わせて１セットにする。 補足　カプセル化の意味 関連のあるメソッドとプロパティを組み合わせて１セットにする。 そのオブジェクトの（メソッドの）使い方以外は、情報を見せない→情報の隠蔽（データの保護という意味もある） 利用者は、オブジェクトの内部の詳細を知ることなく、オブジェクトに備わった機能（メソッド）を利用できる。

２．オブジェクトの基本概念 長方形オブジェクト クラスとインスタンス メソッドの継承 スーパクラスとサブクラス

長方形オブジェクト 長方形：高さと幅をプロパティとして持っている。 （ここでは）面積を求めるメソッド（操作）考える。 クラスの概念の登場 長方形Ａ 高さ：７ 幅：１０ 面積は？ 　　　高さ×幅 プロパティ（幅、高さ）の値によって、様々なオブジェクトがある。 幅と高さというプロパティは共通 一まとめに定義した方が便利 クラスの概念の登場

クラスとインスタンス クラス→共通の性質を持ったものの集まり 抽象化 実例 長方形クラス 長方形オブジェクト（インスタンス） 高さ：　　幅： 面積は？ 　　高さ×幅 抽象化 長方形クラス （プロパティとメソッドの定義を持つ） 長方形オブジェクト（インスタンス） 実例 長方形Ａ 高さ：７　幅：１０ 長方形Ｂ 高さ：９　幅：５ （　個々に異なるプロパティの値（のみ）を持つ　） メソッドはクラスから引き継ぐ

メソッドの継承 インスタンス（オブジェクト）がメッセージを受け取った時→自分が属するクラスのメソッドを起動する→メソッドの継承 長方形クラス 高さ：　　幅： 面積は？ 　　高さ×幅 長方形クラス 長方形オブジェクト（インスタンス） 長方形Ａ メッセージ 　面積は？ 高さ：７　幅：１０ 面積は？ 　　高さ×幅 ７０

スーパクラスとサブクラス 長方形と正方形の関係 正方形は長方形の一部→「高さ＝幅」が成り立つ特別な長方形 　正方形は長方形の一部→「高さ＝幅」が成り立つ特別な長方形 長方形：広い範囲のインスタンスをカバーするクラス→スーパクラス 正方形：スーパクラスの一部のインスタンスのみをカバーするクラス→サブクラス

サブクラスを利用した正方形の定義 長方形クラス スーパクラス 継承 正方形クラス サブクラス 正方形オブジェクト（インスタンス） 長方形 高さ：　　幅： 面積は？ 　　高さ×幅 長方形クラス スーパクラス 継承 ＯＭＴ(Object Modeling Technique)の記法 正方形 高さ＝幅 正方形クラス サブクラス 正方形Ａ 幅：１０ 正方形オブジェクト（インスタンス）

クラスの階層図（図形クラスの例） スーパクラスとサブクラスという概念は相対的なもの 図形 四角形 三角形 長方形 台形 正方形 サブクラス（下位のクラス）はスーパクラス（上位のクラス）の性質を全て引き継ぐ。　　＋　新たなプロパティあるいはメソッドを持つ。　

３．オブジェクトの拡張性 ソフトウェアの生産性向上 単純なクラスに機能を付加→複雑なクラスを定義可能 既存のクラスに機能を付加→目的に応じたクラスを容易に定義できる ソフトウェアの生産性向上 オブジェクト指向プログラミングはソフトウェア危機の救世主!?

三角形クラスの定義 （多態性） 長方形クラスと三角形クラス、それぞれに異なる「面積は？」メソッドを定義 プログラムの拡張が容易に！ 三角形クラスの定義　（多態性） 長方形．面積は？ 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　高さ×幅／2 三角形．面積は？ 同じ「面積は？」メッセージを受け取っても、長方形と三角形オブジェクト（インスタンス）では、振る舞いが違う。 ポリモフィズム（polymorphism:多態性） 長方形クラスと三角形クラス、それぞれに異なる「面積は？」メソッドを定義 プログラムの拡張が容易に！

デフォルトメソッドと上書き （定義の改良） デフォルトメソッドと上書き　（定義の改良） 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　高さ×幅／2 デフォルトメソッド 多くの（しかし全てではない）インスタンスに適用できるメソッド メソッドの上書き サブクラスでメソッドを定義し直すこと ＜三角形クラスの異なる定義＞ プログラムの拡張が容易に！

スーパ疑似変数と差分プログラム 「高さ×幅」の重複をなくす。 super：スーパ擬似変数 継承を利用した差分プログラム 図形 高さ：　　幅： 長方形 面積は？ 　　高さ×幅 三角形 　　super．面積は？／2 super：スーパ擬似変数 　　一つ上のクラスを表す。 拡張時にプログラムの重複を排除する上で有効 スーパクラスに何かを追加することでサブクラスのメソッドを定義する。 継承を利用した差分プログラム プログラムの拡張が効率的に！

第１２回目レポート HPに自由掲示板を開設（6/24） 各自活用して下さい。 本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。 なお、上の記述を行った上で、（いつも通り）講義の感想や質問等を付加しても結構です。 提出先：hiko@edu.sgu.ac.jp　 件名：「学籍番号（半角）+半角空白＋氏名」を記入して下さい。 　　　例）　s02xxx 学院太郎 HPに自由掲示板を開設（6/24）　各自活用して下さい。

Java言語の例外処理 try ～ catch文 元々はGO TO文で記述していた。 try { 処理A } catch (Exception em) { 　　エラーが起こったときの処理 Java言語には最初から組み込まれる。 処理Aの実行中にエラーが生じた場合、catch文に指定された（エラー）処理を行う。 ＜意味＞