レポート抜粋（７月７日）

＜テーマ＞

本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。

＜GO TO文は無駄だった？＞

今日の講義で一番興味があったところは、みんなが先週にコメントしたGo　To文についてです。私もGo　To文を否定していました。私と同じように否定をしていた人がいました。しかし、どのようにしてGo　To文が普及していったのか、処理が速くなるのに必要だったことを知り、Go　To文を理解することができました。なので、Go　To文は無駄だったのではなく、プログラミング言語が発展してきた過程だと私は思います。Go　To文は効率化を図った過程だと思います。　Go　To文を使わなくなったということは、プログラミング言語が発展してきたということだと思います。
GoTo文の必要性と不必要性の話が今回一番印象に残りました。Goto文を使うと簡単にプログラムを書けるけど修正するときに多くの時間を使ってしまい時間がかかるなどは無駄なプログラムの証拠なのかなと思ったりしました。しかし、感想であったGoto文を使っていた時代は無駄な時代であると言うのは言いすぎだと思いました。Goto文の失敗がなければよりよい言語を作ろうというような動きも起きなかったと思うからGoto文を使っていた時代は無駄ではないと思う。
今日の講義で興味のあった点は、GOTO文のプログラムの読みやすさと書きやすさについてです。GOTO文を使うとどんなプログラムも記述できて、便利だけれども後からは読みにくいということでした。ですがこの文の良さを生かすとすれば、プログラムを書く人のメモのようなものになるのではと思いました。短いプログラムを思うままGOTOで書いておいてプログラムとして使うときには構造化する。GOTO文でも実行してみることはできるから、とりあえずやってみるといった時には便利なのではないか。（中略）GOTO文は無駄だったというようなことがありましたが、読みにくくわかりづらいという点より、さほど学習しなくても書けることが便利とされ要求されることがある限りは無駄ではなかったと考えます。

＜ソフトウェア危機について＞

前回の感想の中のソフトウェア危機の部分の感想に共感できると思いました。前回はGOTO文のところに興味を持ち、ソフトウェア危機の部分はあまり見ていなかったので、今週ソフトウェア危機の感想部分を読み、まさにそのとおりだと思った。「使用するほうは天国、作るほうは地獄」というのはまさにそのとおりだと思う。使用するほうはただ「便利だ」や「面白いな」と思ってやっているだけだが、作るほうにしてみればいかにいいものを使ってもらうか考えに考えて作っているんだ、ということを考えさせられた。今後も作るほうはこのような努力を続けていくんだな、と思うと使用者はただ単にソフトを使用するのではなく、作るほうの人々のためにもそのソフトを有効に使用していかなければならないな、と思った。
みずほ銀行のシステム障害：うろ覚えなのですが、当時のニュースのインタビューでシステムの開発者（技術者？）が、かなりの強行スケジュールを強いられ、「あれでは、システムに障害が出て当然」のようなことを言っていたような記憶があります。ユーザー（銀行側）と開発者側の温度差がうかがえました。あれこそまさに「作るは地獄」、「使うは天国」ではないでしょうか。
みずほ銀行の問題のように開発者に頼り過ぎてしまうことは、ユーザーの無責任さにも関係するとは思いますが、ある程度の緊張感のあるような要求というものは必要だと思います。何らかのリスクを追わなければいけないということを、ユーザーは理解すべきです。そのリスクを終えないユーザーは、少しの疑問を持った時点でそこから引き上げるべきです。そこまでの責任感は、サービスを受ける側のユ－ザー持つべきであると感じました。

＜オブジェクト指向の基礎概念について＞

オブジェクトという言葉はよく耳にしていたけれど、ハッキリした意味や概念みたいなものは知りませんでした。だけれど、私たちの日常生活において、"オブジェクト"という言葉に置き換えられることがたくさんあると思いました。誰かに役割を決めて、それぞれに機能を持たすことでさまざまな処理が可能になるということは、講義でもあげられていたように、効率的に思えます。オブジェクトの中のメソッドを利用することで処理ができるということは、中身まで知っていなくてもひとつのメソッドがそれぞれ、必要に応じた処理をしてくれるのだから、かなり時間短縮で、より効率的になると考えられます。また、共通のメソッドであっても、オブジェクトごとに実現する内容が異なるので、メソッドを何個も作る必要もないのだし、理解しやすいのではないでしょうか。メソッドの上書きによって、プログラムの拡張が容易であるのだし、オブジェクト指向が効率的と言えると思います。
今日の講義では、オブジェクトについてやりました。プログラミングの授業を受けていたときから、オブジェクトという言葉は出てきていましたが、ただ漠然と、オブジェクトというものがあるのだというぐらいでしか考えていませんでした。でも、今日の授業でオブジェクトの例についてやったときに、それは人、車、黒板、机などのものの事だということを知り、そんな簡単な考えで良かったのかと思いました。車の例をあげて、状態や操作について説明してあったところが、すごくわかりやすかったです。
今回の講義で、今まではっきりと理解していなかった、オブジェクト・プロパティ・メソッドを理解することができた。オブジェクトは一つのもので、その中のデータを司るものがプロパティであり、操作の命令が置いてあるのがメソッドということ・・・ですよね？

＜カプセル化について＞

今回の講義で興味を持った点というのは、補足としてスライドにあったカプセル化の意味についてです。それは、関連のあるメソッドとプロパティを1セットにすることによってそのメソッドの使い方以外見せない。そのことによって情報を隠蔽して利用者が内部について理解できていなくてもその機能を利用することができる、ということは自分たちの日常生活の中にも結構ありふれた考え方の応用だと思ったからです。例えばTV等の場合私たちは機械の中身がどのようになっているかなどはまったく理解していません。しかしチャンネルで電源を入れると見られるというように使い方を理解して使っています。この様なことからカプセル化の考え方が応用されていると思いました。
今回はカプセル化という言葉に興味を持った。私自身もプログラミングの講義を受けてわかったことだが、プログラムを実行したときの詳細を表示されてもなにがなんなのかよくわからない。（そこで）必要最低限の情報のみを見せ、必要のない情報は隠すというこのカプセル化はとても画期的だと思った。
自身のデータ（プロパティ）と操作（メソッド）を１セットにするオブジェクト指向のカプセル化を行うことにより効率が上がることと情報の保護をすることが出来るということで、カプセル化は必要なことなのだと感じた。

＜オブジェクト指向的考えについて＞

今までにもオブジェクト指向という言葉はよく耳にしてきたのですが、あまりよく理解していませんでした。でも今日の授業の中でオブジェクト→コンパ係、メソッド→企画　オブジェクト指向→コンパ係・企画、という例え話を聞いてよく理解することができました。
一番興味を持ったのは、オブジェクト指向的考え方です。この考え方でいくと、もしかしたら身の回りのものはすべてオブジェクトとメソッドを用いて考えることができるのかなと思いました。車オブジェクトがあるのなら、「人間オブジェクト」も可能なのでしょうか・・・？ゼミでコンパを企画することを、オブジェクト指向で表現できるなんて思いませんでした。
今日の講義で印象に残ったのは、オブジェクト指向の考え方です。去年、プログラミングでjavaを習っていましたが、いまいち、このオブジェクト指向の考え方がよく分かっていませんでしたが、プログラミングのSAで培った知識と今回の講義で分かったような気がしました。　既存の処理プログラムをまた1から作るのではなく、簡単に複製、または拡張することができるようになったことはプログラマーにとって、とても革新的だと思いました。

＜オブジェクトの拡張性について＞

今日の講義で興味を持ったのはオブジェクトの拡張性についてです。デフォルトプログラムによってプログラムの拡張が容易となり、差分プログラムによって効率的になったりとオブジェクト指向プログラミングはプログラミングをより扱いやすいものとしたということは間違いないと思います。特に差分プログラムは継承を利用することでプログラムの重複を排除する上でとても重要だと感じました。プログラムを書いている上で重複していたりするとやはり見づらくわかりづらくなる要因となるからです。
今回の講義で一番興味を持ったのは、オブジェクトの拡張性についてです。生産者が最初に作ったときには単純で使い道があまりないプログラムだったとしても、そのプログラムがオブジェクト指向プログラミングだったら、あとから気がついたときにサブクラスを追加していくことによってより良いものに進化していくので、オンラインのゲームなどでさらに機能を追加したいときにこの方法を使えば利用者を常に長い期間楽しませることができるようになると考えたからです。
図形を利用した説明がすごくわかりやすく理解が深まりました。実際の例ではもっと複雑だからこそ効力を発揮するのだとは思いますが、デフォルトのメソッドをサブクラスで書き直して定義するだけで拡張できる、というのはとても便利だし、プログラミング言語というのは発展していく過程で実に多くの「無駄を省くやり方」「見やすくわかりやすくするためのやり方」が考えられてきているのだなと思いました。

＜スーパクラスとサブクラスについて＞

私が今回興味を持ったのは、スーパクラスとサブクラスについてです。スーパクラスが広範囲にインスタンスをカバーしているのに対し、サブクラスはスーパクラスの一部をカバーしているとのことですが、それは、継承してという点で明らかだと思います。ある意味、家系図に似ている、と思いました。というのも、人に置き換えてみると、親子の関係等と似ていると感じたためです。そう考えると、スーパクラスの性質を全て引き継いでいるサブクラス、相対的なこの二つのクラスの関係は、理解しやすいのではないかな、と考えました。
スーパクラス、サブクラスのところでは、サブクラスはスーパクラスの性質をすべて引き継ぐということで、図形が一番上で、そこから、四角形、三角形と分かれていく図でもわかるように、下のものは、上のものの性質を引き継いでいるというのがよくわかりました。
今回の講義で興味を持ったところは、スーパクラスとサブクラスのところです。サブクラスはスーパクラスの性質を引き継ぎ、新たなプロパティやメゾットを持つ。単純なクラスに機能を付加することによって、複雑なクラスを定義可能になる。既存のクラスに機能を付加することによって、目的に応じたクラスを容易に定義できるとあった。１つのことだけではなくいろいろなことに対応する事が出来るということは、とてもいいことだと思った。
ス－パクラス、サブクラス：いままで講義などではひとつのプログラムでひとつの事を行うプログラムしか作ったことがなかったので、クラスなどはただの初期設定ぐらいにしか思って、あまり気にしていませんでしたが、多機能なプログラム、無駄な文の削減ができる重要なものであることに気づかされました。

＜スーパ擬似変数と差分プログラムについて＞

最も興味深かった点は、デフォルトメソッドを継承して拡張するスーパ擬似変数と差分プログラムについてです。というのも、オブジェクト指向プログラミングの一つの醍醐味がこの差分プログラムにあると思うからです。メソッドの操作経緯が解らなくともカプセル化された処理を命令すれば動くように、スーパクラスの詳細が解らずとも、組み込みたい操作のみを組み込める「メソッドの上書き・追加」システムは画期的です。何よりスーパクラスのメソッドに上書きをして新たなクラス（サブクラス）を生成するという多態性はそれまで世界では表しきれなかった発想だと思います。その上で重複記述を無くすという考えは、コンパクトで見やすいプログラムを実現し、更には私のようなコンストラクタ名省略を日々心がけるようなぐうたらにも優しく書くほうの手間も省ける一石二鳥の定義だと感じました。
スーパ擬似変数に興味を持ちました。効率よくできるということで重複する部分を何回も記述しなくてもよい！という点でとても便利だと思いました。メソッドの継承をすることにより、スーパクラスの性質を全てサブクラスは受け継ぐので、何度も同じことを書かなくてもよいので、理解することでわかりやすいし、見やすくなると思いました。サブクラスで新たに違うことを命令したいときも付け足すことで新たに定義できるので面倒くさくなくていいです。
差分プログラムの見易さがすごいなぁと思った。同じ数式を書く代わりに「super．」という変数を使うことでさらに見やすくなっている。今後もどんどんプログラムの記述は読みやすく洗練されて、分かりやすいものへとなっていくのだろうなと思った。
今日の講義で最も興味・関心があったものは差分プログラムのところです。今日の説明を聞いて初めて、その意味が分かりました。この差分プログラムによって、プログラムの拡張が効率的になるということもわかりました。

＜オブジェクト指向プログラミングの発展性－著作権の問題について＞

今回の講義でソフトウェア危機という、無限の需要からくる開発問題を、オブジェクト指向ならば、避けられることがよくわかった。しかし、ソフトウェア（ソースプログラム）には、侵害されない権利が発生する。だから、需要を受けてＡを作ったからといって、他の誰かが簡単にＡを改良したものや、ＡをベースにしたＡ+が作られるわけではない。他の誰かはＡとは別のＢを作らなくてはいけない。それが競争原理を生むわけだが、・・・（中略）権利の関係上侵害はできないが、権利が切れたものは順次使用できる、このことからもう少し先になれば、オブジェクト指向の真価を発揮できるのではないか。（画像形式ＧＩＦの権利はきれましたよね？）
独自に開発されたクラスももし企業秘密として扱われて、その企業内でしか使われないのであれば、言われるほど効果を挙げないのではないでしょうか？　オブジェクト指向はソースがオープンになってこそ真価を発揮するような気がします。

＜オブジェクト指向プログラミングの難しさ＞

クラスについて理解はしているつもりなんですが、どうも実際使いこなせていない。ゼミの課題等で使っているのですが、細かいところが分からなくなってしまうんです。クラスに何のメソッドを残して、アプリケーションのほうで何のプロパティを入れればいいのか。Returnでどう返せばいいのか。色々わかりません。まさに「使うは天国、作るは地獄」だと実感しています。
今日の授業で最も興味を持ったのは、スーパ疑似変数と差分プログラムです。これがうまく使えるようになれたら、もっと効率的なプログラムが書けると思いました。今日習ったところは、他の授業でも習ったことが多かったので、よくわかったと思います。しかし、クラスの継承の理論はわかるのですが、実際にやると難しいように思いました。
思ったのは、やっぱりJavaは手がかかってもやりがいがあるなということでした。「ものの本質を理解できないとオブジェクト指向は難しい」などと脅されたことがありましたが、データベースの理論と少し関連しているところもあってそれもまた楽しいですし、「ものの本質」を征服してやろうという気力も湧いてきます。
　なのでJavaもとても難しいのですが、今は半分くらいは理解できる楽しみのために触れています。こんな複雑でよく分からないものでアプリケーションを組めたら面白いだろうな、というのが今のやる気に繋がっています。オブジェクト指向を徹底されるともはや哲学の気しかしないので、じっくりやりたいと思います。
　ですが、こんなに難しくてオブジェクト指向は本当に現場で取り入れられているものなのでしょうか？　オブジェクト指向で開発効率を上げようとすると、長い時間をかけて勉強しなければなりません。

＜感想・意見＞

オブジェクト指向は、ひとつのモノと考えてそれをカプセル化にするということであることが、今日の講義でやっとイメージがつかめたような気がしました。今までJAVAはオブジェクト指向と聞いていたけど、それが何なのかがよくわかりませんでした。しかし、オブジェクト指向によってプログラミングの効率やソフトウェアの再生産性もあがったのはすごいことなんだなと、思いました。オブジェクトの拡張性が進歩したことで、単純なクラスに機能をつけ複雑なクラスを定義することが可能になり、目的に応じたクラスを容易に定義できるようになったことなども、オブジェクト指向はソフトウェアの危機を救った救世主といわれるまでに成長したことになるんだなと思いました。
今回の講義ではオブジェクト指向に興味を持ちました。GOTO文を使ったプログラムの考え方は、「～に飛ぶ」という単純な機能で全てのプログラムを結びつけようとした結果、分かりにくいプログラムになってしまったのに対し、オブジェクト指向の考え方は単純な機能に、その要素を引き継いだ単純な機能を加える事を繰り返し、階層的に並べる事で、誰が見ても分かりやすいだけでなく、発展性があり生産性の高いプログラムが作れるように工夫されているという事が理解出来ました。
２年次のプログラミングの授業で出てきた内容を、講義形式で体感することができました。普段日常で行っていることや物などをオブジェクトで表現できることを知り、おもしろかったです。関連することがらを継承・拡張することで、より容易に物事を定義できたり、効率よく表現できたりすることが可能となるということを実感できました。今回の講義でオブジェクト指向についての理解が少し深まったと思います。
今回の講義は、オブジェクトやメソッドなどといった専門用語を身の回りの身近なものに置きかえて説明されており、とても分かりやすかった。
先週の講義では、このオブジェクト指向の考え方こそが「ソフトウェア危機」などのプログラマーの苦悩を回避できるだろうと紹介されていましたが、その言葉の意味が今週の授業で理解でき、とても興味深かったです。
プログラミングだけに限ったことではありませんが今の時代、物事が進化するスピードがとても速いです。それは、日々開発している人たちの努力の証ですがそれらを使う側も絶えず理解していく努力が必要だと感じました。
やっぱり、プログラミングの授業を受けながらこの授業も受けていれば理解できていたのではないかと思います。プログラミングのときはほんとに何がなんだかよくわからないままで、ただやっていたので理解できていませんでした。

＜疑問＞

オブジェクト指向の考え方については、プロパティとメソッドがカプセル化されたものを用いれば手続き指向のプログラミングよりも効率が上がるのでは？といことをいっていましたが、確かにカプセル化することで、やることが明確にはなりますが、オブジェクトの内部を知らなくても理解することが本当に可能なのかという疑問が出てきました。大体のことは知らなくても理解できるかも知れないが、やはり中身を知る必要があるときもあるのではと思いました。
またプロパティとメソッドがカプセル化されたオブジェクトというのは初めて知りました。そのオブジェクトの使い方以外は、情報を見せない→情報の隠蔽が行われ、利用者は、オブジェクトの内部の詳細をしることなく、オブジェクトに備わった機能を利用できるというので、それは内部の詳細を知らないで利用することがよいのかどうかよくわからなかったのですが、どうなのですか？
今日はオブジェクト指向プログラミングのいいところだけを聞いて、ソフトウェア危機の救世主と聞かされてもなるほどと思ってしまいますが、オブジェクト指向に欠点はないのでしょうか。
一つ疑問に思ったことがあるのですが、スライドの「クラスの拡張性」の部分でもあるように、複雑なクラスを次々と増やしてしまったら、混乱するのではないかな？と思いました。
この前オブジェクトの話を聞く機会ありました。予報士から見たとき"天気"はオブジェクトになると言われましたが実際は状態のことではないのでしょうか？
"ひし型"は四角形に含まれると思うのですが、式が異なるので四角形のサブクラスになると思いますが、どうでしょう？