比較プログラム言語論 平成１６年７月７日 森田 彦 レポート（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 スーパクラスに何かを追加することでサブクラスのメソッドを定義する。 継承を利用した差分プログラム プログラムの拡張が効率的に！ 第１２回目レポート 本日の講義で、あなたが最も興味を持った点はどのよう な点ですか？講義の全体的な感想と共に、できる限り 具体的に、200字～400字程度で記述して下さい。 なお、上の記述を行った上で、（いつも通り）講義の感想 や質問等を付加しても結構です。 提出先：[email protected] 件名：「学籍番号（半角）+半角空白＋氏名」を記入し て下さい。 例） s02xxx 学院太郎 HPに自由掲示板を開設（6/24） 各自活用して下さい。 Java言語の例外処理 try ～ catch文 元々はGO TO文で記述していた。 try { 処理A } catch (Exception em) { エラーが起こったときの処理 } Java言語には 最初から組み 込まれる。 ＜意味＞ 処理Aの実行中にエラーが生じた場合、catch文に指定され た（エラー）処理を行う。
© Copyright 2024 ExpyDoc
