Upgrade to Pro — share decks privately, control downloads, hide ads and more …

オブジェクト指向で楽しい人生を送る

 オブジェクト指向で楽しい人生を送る

「オブジェクト指向」を媒介にして、プログラミング、ギリシャ哲学、パーソナルコンピュータ、メディア論まで、刺激的に感じた繋がりをコラージュしてお伝えします。

F60fb427aabbd7a12bfa73272de0a7a5?s=128

AITC - ISID

June 13, 2022
Tweet

More Decks by AITC - ISID

Other Decks in Technology

Transcript

  1. オブジェクト指向で楽しい人生を送る 電通国際情報サービス(ISID) X(クロス)イノベーション本部 AIトランスフォーメーション部 御手洗 拓真 東京学芸大学「情報教育とキャリア形成」 2021/12/01

  2. 2 アジェンダ 00:自己紹介やお仕事 01:本日お話すること 02:そもそもオブジェクト指向とは? 03:クラス重視のオブジェクト指向プログラミング 04:オブジェクト指向とプラトン 05:アラン・ケイととマクルーハンのメディア論 06:おわりに

  3. 3 自己紹介やお仕事 00

  4. 4 御手洗拓真 所属: 電通国際情報サービス クロスイノベーション本部 AIトランスフォーメーションセンター 経歴: 2015年3月:慶應義塾大学総合政策学部卒(近代史・社会学専攻) 2015年4月:新卒でSBテクノロジー株式会社に入社し、 機械学習システム導入案件などを担当

    2020年2月:ISIDへ中途入社 現在は、顧客支援と並行してAIを使った自社サービス開発に尽力中 業務: 機械学習システム開発・導入、自社のAIソフトウェアの開発、製品開発チームのマ ネジメント Qiita : https://qiita.com/tamitarai 趣味: コーヒー、ウィスキー、アイドルなど 略歴
  5. 5 最近の主なお仕事 最近のメインの業務はAI製品を開発するチームのマネジメントですが、 好きなので実装やお客様へのコンサルティングもしています お仕事の比率イメージ AI製品を開発するチームの マネジメント系業務 (実質MTGとその準備) 事務 処理

    AI製品の開発 (設計など含む) 勉強会な どの資料 準備や記 事執筆 40~60% 20~40% 10% 10%
  6. 6 大学時代やっていたこと 基本的には、人文系の勉強と、研究室のQOL改善と、アイドルオタク 一年 休学 二年 三年 四年 近代日本史系のゼミに入り、研究室を快適にしたり、勉強会したりしながら友達を作る。 ひめキュンフルーツ缶という愛媛県のローカルアイドルに出会い、一生応援することを心に誓う。

    「やりたいこと見つからないし東大目指すか・・・。」と考え仮面浪人を始めるが、夏くらいで心が折れる。 一応、幸いにも仮面浪人中に近代日本史や哲学に興味を持てたので、大学でそれをやることにする。 歌が上手くなりたくてアカペラサークルに入り、1か月後に「ここは歌が上手くなりたい人が来る場所ではないのだ。」 と気づく。そして「自分はいったい大学に何をしに来たのだ。。。」と悩み、休学する。 人文系の勉強と、研究室のQOL改善と、アイドルオタクをしながら楽しく過ごす。 人文系の勉強と、研究室のQOL改善と、アイドルオタクをしながら楽しく過ごす。
  7. 7 人文系の勉強 以下のようなことを学びながら、勉強会をしたりして友達を作っていた 日本近代史(研究テーマ) 最初は「なぜ日本は戦争をしたのか」という動機だったが、調べるうちに関心が変わり、 最終的に「なぜ1930年代にあるニッチな国家主義的な学生団体に学生が集まったのか?」について 調査し論文を書いた。 社会学(それなりにしっかり) そこそこ広めにやった。社会学の教科書に書いてある人ならだいたい説明できた。 (今もある程度は覚えている)

    哲学(ちょいちょい) 哲学史の教科書に出てくる人の概念なら分かる程度。
  8. 8 研究室のQOL向上 お金がなかったので交通費を浮かせる目的で研究室に寝泊まりするようになり、 以下のようなアイテムによって生活環境改善に努めた。 炊飯器 ケーキやパンも作れて、 生活が一気に豊かに。 クッキングヒーター 火を使うと怒られるが、 クッキングヒーターなら

    怒られずに鍋パができる 食料・お米など 人が来ても振舞える。 布団・寝袋 いわずもがなの必需品。 時々干さないとカビが生 えるので注意。
  9. 9 アイドルオタク 愛媛県松山市の「ひめキュンフルーツ缶」というアイドルのオタクをし、 毎年数回松山市に遊びに行っていた。愛媛県松山市、温泉もあるし本当に良いところ。 ※ 権利関係がわからないため画像は資料配布時は削除予定

  10. 10 本日お話すること 01

  11. 11 はじめに まず、私が本日一番お伝えしたいことは「自由な学びを楽しんでください」ということです。 学びの楽しみ方はいろいろあるとは思いますが、 私個人は、いろいろと学ぶ過程で一見関係無さそうな知識が相互に結び付き、 自分のなかでこれまで見聞したものも異なった様相をもって知覚される(=認知が更新される) 経験が学びの醍醐味だと思っています。 本日は、皆様にもなじみ深い「オブジェクト指向」を媒介にして、 プログラミング、ギリシャ哲学、パーソナルコンピュータ、メディア論まで、 私がいままで刺激的に感じた繋がりをコラージュしてお伝えします。

    一つ一つの内容と、それぞれが結び付く感覚が皆様の好奇心の糧になれば幸いです。
  12. 12 そもそもオブジェクト指向とは? 02

  13. 13 質問 「オブジェクト指向」という言葉は聞き覚えがありますか? あるというという人は挙手お願いします。(※ 当てたりはしません)

  14. 14 Wikipediaを開いてみると、様々な「オブジェクト指向ほげほげ」があることはわかる そもそも「オブジェクト指向」とは? 出典:https://ja.wikipedia.org/wiki/オブジェクト指向

  15. 15 Wikipediaを開いてみると、様々な「オブジェクト指向ほげほげ」があることはわかる それぞれの「オブジェクト指向ほげほげ」は違うものなのか?同じものなのか? そもそも「オブジェクト指向」とは? 出典:https://ja.wikipedia.org/wiki/オブジェクト指向

  16. 16 例えば、「オブジェクト指向プログラミング」と「オブジェクト指向分析」は (特にオブジェクト指向プログラミングを学ぶときは)違うものだと捉えた方がよいという議論がある ※ 私もこれに同意します。 ちがう物だと考えた方がいい説 “1990年代には、数多くのオブジェクト指向分析・設計方法論が提唱され ました。また、OOPの仕組みが現実世界の様子とよく似ていることから、 オブジェクト指向で現実世界の様子を整理して、それをそのままプログラ ミングすればうまくいくはずだとする考え方も生まれました。

    しかし、こうした考え方にはまぎらわしい落とし穴がありました。そ れは、OOPの仕組みと現実世界の様子にはよく似ているところがあるもの の、まったく同じではないことです。(中略)人間が行う仕事をオブジェ クト指向で整理し、それをそのままプログラミングしようとしても実際に はうまくいきません。” 平澤 章著『オブジェクト指向でなぜつくるのか 第三版』 非常に分かりやすくかつ実用的にオブジェクト指 向技術が解説されている名著。オブジェクト指向プ ログラミングについて説明する自身がない方は必読。 https://cdnshop.nikkeibp.co.jp/0000/catalog/S00180/S0018 0_thumb_pc.jpg
  17. 17 一方で、「オブジェクト指向」という言葉をより汎用的に使える概念として捉えている議論もある 汎用的に使える概念なのだという説 https://www.seshop.com/static/images/product/7595/L.png “多くのオブジェクトはただそこにあって摘み取られるのを待っている。 そのようなオブジェクトはそのソフトウェアが適用される物理的な世界の ものをそのままモデル化したものである。実際、オブジェクト技術の強味 の一つはモデリングツールとしての能力にある。ソフトウェアのオブジェ クトの型(クラス)を使って物理的なオブジェクトの型をモデル化し、オ ブジェクト型の間の関係(顧客、継承)を使って、集合や特殊化などの物

    理的なオブジェクトの型の間に存在する関係をモデル化する” バートランド・メイヤー著、酒匂 寛 訳 『オブジェクト指向入門 第2版』 「オブジェクト指向入門」の上巻で800P以上ある。 「品質」を目的として演繹的にオブジェクト指向の 原理について徹底的に述べている。私もまだ読んで いる途中。なお著者のメイヤーはフランス人で、本 書の記述スタイルはデカルトなどフランス近世哲学 を意識している気がする。
  18. 18 結論:よくわからない (※ 正確には、頑張れば「オブジェクト指向ほげほげ」に共通の要素は取り出せるが、 全く別物と捉えた方が個別の「オブジェクト指向ほげほげ」は習得しやすいという状況になっていると思う) そもそも「オブジェクト指向」とは?

  19. 19 なぜ、よくわからないのか? 結論:よくわからない (※ 正確には、頑張れば「オブジェクト指向ほげほげ」に共通の要素は取り出せるが、 全く別物と捉えた方が個別の「オブジェクト指向ほげほげ」は習得しやすいという状況になっていると思う) そもそも「オブジェクト指向」とは?

  20. 20 そもそも「オブジェクト指向」という言葉は1960年台後半に、 プログラミングの文脈でアラン・ケイという人によって作られた。 しかし、最初にケイが「オブジェクト指向」という言葉を作ったときに指していたものと、 現在我々が今使っている「オブジェクト指向プログラミング」は全く異なるものになった。 さらに、業務分析など様々な領域にも応用されていき、よくわからなくなっていった。 「オブジェクト指向」はなぜ良くわからないのか?

  21. 21 「オブジェクト指向」はなぜ良くわからないのか? そもそもの始まりである オブジェクト指向プログラミングから考えてみよう そもそも「オブジェクト指向」という言葉は1960年台後半に、 プログラミングの文脈でアラン・ケイという人によって作られた。 しかし、最初にケイが「オブジェクト指向」という言葉を作ったときに指していたものと、 現在我々が今使っている「オブジェクト指向プログラミング」は全く異なるものになった。 さらに、業務分析など様々な領域にも応用されていき、よくわからなくなっていった。

  22. 22 オブジェクト指向プログラミングには、大きく分けて2つの流れがある 「オブジェクト指向プログラミング」とは? メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの • 「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された

    クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング
  23. 23 メッセージング重視のオブジェクト指向では、 オブジェクトとは、ネットワーク上でメッセージを送り合う、独立した個別の役割を持つコンピュータのメタファー であり、現代のインターネットをプログラミングできるようなイメージ メッセージング重視のオブジェクト指向プログラミング メッセージング重視型 オブジェクト あるオブジェクトから送信されたメッセージは、送信時点ではまだ意味が確定されてお らず、受けてのオブジェクトに解釈されて初めてメッセージに意味が割り当てされる。 (これをクラス重視のオブジェクト指向プログラミングとの違いと考えるとイメージし

    やすい) これを「徹底的に遅らせた割り当て(extreme late binding)」と呼ぶ。 各オブジェクトは完全に独立しているので、外部環境が変わり仕様変更が発生しても、 該当するオブジェクトだけを変更/追加をすることで柔軟に変化に対応できる 役割だけ教えてくれれば、 具体的な仕事は自分で決めて判断します!
  24. 24 クラス重視のオブジェクト指向プログラミングでは、 オブジェクト指向とはコードを再利用し、想定外の挙動をさせないためにコードを抽象化するというコンセプト。 メッセージング重視のオブジェクト指向プログラミング クラス重視の オブジェクト 開発者視点に立ち、システムの品質を向上させながら開発を楽にするという工学的な目 的のもとに作られた。次頁に掲載する三大要素は、この目的を実現するための仕組み。 メッセージング重視のオブジェクト指向との違いは、想定外の挙動をさせないために、 「契約(コンストラクト)」によって最初にクラスの仕事を明確にすること、と考える

    と分かりやすい。 最初に定義された仕事内容を途中で変えたりしません! きっちり定められた通りにやります! (※ これだけではわかりづらいので後で具体例を出します)
  25. 25 小まとめ ⚫ 「オブジェクト指向」自体についてはよくわからないことがわかった ⚫ 「オブジェクト指向プログラミング」は「メッセージング重視」と「クラス重視」の二つの流れがある ⚫ メッセージング重視の方は、現代のインターネットのような仕組みをプログラムするイメージ。 オブジェクトがどのような仕事をするかはメッセージが届いてからではないと分からない。 ⚫

    クラス重視の方は、コードを再利用しやすくしつつ、想定外の動きをさせないための言語。 オブジェクトがする仕事は最初から決まっているため、仕事の結果が保証される。
  26. 26 クラス重視のオブジェクト指向プログラミング 03

  27. 27 本章のおことわり 資料のなかにはコードがたくさん出てきますが、 今回のメインテーマはコードの解説ではないので、講義の時間ではあまり触れません。 興味がある方は、後で読んでみてください。

  28. 28 そもそも「オブジェクト指向プログラミング」から二つあることがわかった。 まずは、なじみ深い「クラス重視のオブジェクト指向」についておさらいする。 クラス重視のオブジェクト指向おさらい メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの •

    「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング
  29. 29 クラス重視オブジェクト指向プログラミングの3大要素 インスタ ンス1-A インスタ ンス1-B インスタ ンス1-C クラス(カプセル化) 継承

    ポリモーフィズム クライアント (呼び出し元) FileReader クラス - 変数file - open() - close() • 変数(=データ)とメソッドをひとま とめにして外から隠蔽 • クラスを雛形に、インスタンスをたく さん作る • クラスの定義で共通している部分 をまとめる • 異なるクラスでも メソッドの呼び出し方を共通にする Readerクラス (スーパークラス) - open() - close() FileReader クラス - 変数file - open() - close() IOReader クラス - open() - close() クラス重視のオブジェクト指向は、ソフトウェアの品質向上と開発効率化のためにコードを抽象化する技法。 この目的を達成するための仕組みが、以下のオブジェクト指向の三大要素。 (※ テストでよく出ます。そして仕事でシステム作る場合も必修なので覚えておくと二度お得です。) FileReaderクラスも、 IOReaderクラスも、 open(), close()という共 通のメソッドで呼び出 せる open(), close()という二 つのクラスに共通のメ ソッドを抽象化してま とめる メソッド呼び出し 継承 継承 実現 メソッドは同じで、 変数に格納された値だ けが異なる
  30. 30 品質と効率性を上げることを示す例題 オブジェクト指向による品質向上と開発効率化のメリットをイメージしてもらうために、 具体的な課題をもとに考えてみる ◼ 背景設定 ◼ あなたはきびなご中の給食を作る人兼 pythonの日曜プログラマー ◼

    ある日、中学校の先生と生徒を管理するプログラムの一部を書いてほしいと依頼された ◼ 欲しい機能 ◼ 先生と生徒に関する情報をそれぞれのフォーマットで表示する ◼ 先生と生徒の情報を新たに登録する ◼ 先生と生徒の入力値が間違っている場合は日本語でメッセージを表示する ◼ データの制約 ◼ 生徒:名前、年齢(12歳以上15歳以下)、クラス、出席番号(1~40)のフィールドを持つ ◼ 先生:名前、年齢(18歳以上60歳以下、担当クラスのフィールドを持つ
  31. 31 ◼ 背景設定 ◼ あなたはきびなご中の給食を作る人兼 pythonの日曜プログラマー ◼ ある日、中学校の先生と生徒を管理するプログラムの一部を書いてほしいと依頼された ◼ 欲しい機能

    ◼ 先生と生徒に関する情報をそれぞれのフォーマットで表示する ◼ 先生と生徒の情報を新たに登録する ◼ 先生と生徒の入力値が間違っている場合は日本語でメッセージを表示する ◼ データの制約 ◼ 生徒:名前、年齢(12歳以上15歳以下)、クラス、出席番号(1~40)のフィールドを持つ ◼ 先生:名前、年齢(18歳以上60歳以下、担当クラスのフィールドを持つ プログラマー1年目(タスクベース) プログラミング一年生がやりがちな、とりあえずタスク・機能をベースに作る関数を考えてみるというアプローチ。 print_info()関数があれ ばいいかな register()関数かな それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう
  32. 32 プログラマー1年目(タスクベース) print_info()関数があれ ばいいかな

  33. 33 プログラマー1年目(タスクベース) print_info()関数があれ ばいいかな

  34. 34 プログラマー1年目(タスクベース) print_info()関数があれ ばいいかな register()関数かな

  35. 35 プログラマー1年目(タスクベース) print_info()関数があれ ばいいかな register()関数かな それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう

  36. 36 やりがちな失敗:プログラム それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう それぞれの関数で、先生と生徒の入 力があってるかチェックをしよう print_info()関数があれ ばいいかな register()関数かな

  37. 37 プログラマー1年目(タスクベース):できたコード 呼び出す側 プログラム

  38. 38 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変

    • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要
  39. 39 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変

    • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要
  40. 40 If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変 • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要

    プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) 重複 重複 重複 重複
  41. 41 プログラマー1年目(タスクベース) :問題点 問題点 (※ほかにもたくさん問題があるが、簡単のため二つだけにする) If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、pirnt_info関数のif 文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変

    • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 個人が趣味で作るシステムなら良いが、製品としてのソフトウェアの場合には 「再利用しづらい」「修正が大変」なコードを書くとメンテナンスが破綻し、 バグ修正以外のことができなくなりビジネスが破綻する
  42. 42 プログラマー2年目(共通性に注目) 問題点 対応案 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる

    • 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい If文が多すぎて読みづらく、他の人が再利用しづらい • 使う側は「teacher」の情報出力処理の内容だけを知りたくても、 pirnt_info関数のif文を全て読む必要がある 入力値の検査などで重複が多すぎて、修正が大変 • 例えば「gender」という変数が追加されたら両方の関数の検査を修正する必要がある。 • 同様に、例えばroleに「親」が増えたら両方の関数の修正が必要 他人の痛みが分かるようになったプログラマー2年目は、タスクだけではなく共通性に注目して、 他の人が辛くならないように関数を切り出す。
  43. 43 プログラマー2年目(共通性に注目) 対応案 プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる

    • 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい
  44. 44 プログラマー2年目(共通性に注目) 対応案 プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる

    • 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい
  45. 45 対応案 プログラマー2年目(共通性に注目) プログラム 対象ごとに関数を分けてみる • 具体的には、teacherとstudentで関数を分ける。 利用する人は、「teacher_hogehoge」「student_hogehoge」の関数 だけ見ればよい。 共通の処理を関数に関数を切り出してみる

    • 具体的には、入力値チェック用の関数を切り出す。 • こうすれば、Genderという変数が追加されても、入力検査用の関数だけ変更 すればよくなる。 • 例えばroleに「parent」が増えても、parent用の入力検査関数を作ればよい
  46. 46 プログラマー2年目(共通性に注目) 呼び出す側 プログラム

  47. 47 1年目と2年目の違い プログラムは重複が減り、目当てのコードを読むための負担は軽減された気がする before After

  48. 48 1年目と2年目の違い 呼び出す側は、teacherとstudentの関数を分けたことで、引数が減った before After 減った引数

  49. 49 1年目と2年目の違い 呼び出す側は、teacherとstudentの関数を分けたことで、引数が減った before After 減った引数 しかし、まだ問題はある

  50. 50 残った問題 ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ

    を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない 問題点 プログラム側 呼び出す側
  51. 51 オブジェクト指向(クラス) 問題点 対応案 ⚫ 入力検査の処理を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする

    ⚫ セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない
  52. 52 オブジェクト指向(クラス) 問題点 対応案 クラス(カプセル化)で、 データと処理をセットにする ⚫ 入力検査の処理を通ったデータに対してしか、 他の処理を適用できないようにする ⚫

    データと処理のセットをたくさん複製できる ようにする ⚫ セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする ⚫ プログラム:新しい処理を追加するときに入 力検査用の関数を入れ忘れるかもしれない ⚫ 呼び出す側:扱うデータが増えると関数の引 数に渡す変数を間違えるリスクが増える ⚫ 両方:処理の途中で変更されたくないデータ を間違って更新してしまい、 予定外の挙動を引き起こすかもしれない
  53. 53 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫

    セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする プログラム
  54. 54 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫

    セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする プログラム
  55. 55 オブジェクト指向(クラス) 対応案 ⚫ 入力検査関数を通ったデータに対してしか、 他の処理を適用できないようにする ⚫ データと処理のセットをたくさん複製できる ようにする ⚫

    セットになるデータと処理を一つにまとめて、 途中でデータが変更されないようにする 呼び出す側
  56. 56 オブジェクト指向(クラス) 呼び出す側 プログラム

  57. 57 2年目とオブジェクト指向との違い プログラム側は、多少行数は増えたが、先ほどよりもすっきり見やすくなった印象がある before After

  58. 58 2年目とオブジェクト指向との違い 呼び出し側は、同じ変数を何度も関数に渡す必要がなくなり、ミスをしづらくなった before After

  59. 59 1年目とオブジェクト指向との違い 参考まで、1年目とオブジェクト指向との違いも掲載する

  60. 60 1年目とオブジェクト指向の違い Before After プログラム側では、Teacher, Studentという「オブジェクト」でコードが分かれており、見たい処理がすぐ分かる。 コードの重複が減ったことで、メンテナンス性も高い。

  61. 61 1年目とオブジェクト指向の違い Before After 呼び出し側では、データと処理が隠蔽されているため途中でおかしなデータが入ることがない。 また、各クラスが最初に入力検査をしてくれているので、呼び出す側は各関数で入力検査がされているか気にしなくて良い。

  62. 62 何をしたのか? 以下の手順でコードを抽象化してクラスにまとめて隠蔽化し(=カプセル化)、 さらに呼び出すメソッドをクラスで共通にする(=ポリモーフィズム)ことで、 プログラムの品質と、開発効率を向上させた。 1. 2年目:共通している処理を抽象化して関数にする ➢ 重複を減らし、読み手の負荷を軽減 2.

    オブジェクト指向:セットになるべきデータと関数をクラスとしてまとめる ➢ 利用する側は、クラスをインスタンス化して利用すること入力チェックなどを意識せずに済む ※できれば、この後さらに以下まで行えるとなお良いが、今回は割愛する • nameやageなどの変数もクラスとして定義し、入力値チェック処理をそちらに委譲する • 今後Parentクラスなどが増えることを考慮し、共通のフィールドと関数を持つスーパークラスUserを用意して継承させる
  63. 63 ※できれば、この後さらに以下まで行えるとなお良いが、今回は割愛する • nameやageなどの変数もクラスとして定義し、入力値チェック処理をそちらに委譲する • 今後Parentクラスなどが増えることを考慮し、共通のフィールドと関数を持つスーパークラスUserを用意して継承させる 何をしたのか? まず、持つべき情報とすべき振る舞いを「抽象的なオブジェクトであるクラス」として定義し、 次に、「具象的なオブジェクトであるインスタンス」を生み出す、という思考法 1.

    2年目:共通している処理を抽象化して関数にする ➢ 重複を減らし、読み手の負荷を軽減 2. オブジェクト指向:セットになるべきデータと関数をクラスとしてまとめる ➢ 利用する側は、クラスをインスタンス化して利用すること入力チェックなどを意識せずに済む 以下の手順でコードを抽象化してクラスにまとめて隠蔽化し(=カプセル化)、 さらに呼び出すメソッドをクラスで共通にする(=ポリモーフィズム)ことで、 プログラムの品質と、開発効率を向上させた。
  64. 64 クラス重視のオブジェクト指向とプラトン 04 ※ ここから話が飛びます

  65. 65 「クラス」という仕組み自体は純粋に工学的な目的から編み出されたものだが、 よく考えてみると、「クラス→インスタンス化」という仕組みは、 現実とは逆の世界観になっていることに気づく 「抽象を具象化する」という発想 現実の人 オブジェクト指向 抽象的な 犬の概念 抽象的な犬

    の概念 (クラス) プードル (インスタンス) コーギー (インスタンス) チワワ (インスタンス)
  66. 66 プラトン (紀元前427年 - 紀元前347年) 2000年前に同じことを考えた人がいた • 古代ギリシャの哲学者 • 「イデア論」などで有名

    • 一応高校の倫理でも出てくる https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%A9%E3%83%88%E3%83%B3
  67. 67 質問 プラトンについて、名前以外に何か知っていることがありますか? あるというという人は挙手お願いします。

  68. 68 「我々が、大きさも形も、何もかも違うおにぎりとピラミッドを 両方とも同じ三角形だと思えるのはなぜか?」 プラトンの問い 一見「何いってるんだ?」と思えるが、確かによく考えると結構不思議なことに気づく。 我々は学校で三角形を習ったが、それ以前の社会でもこれを「三角形」として抽象化するのはなぜなのか? 例えばチンパンジーは「三角形」を思い描けるのか?

  69. 69 天上界には三角形のイデア(ideal=理想的 の語源)があり、 我々人間はその三角形のイデアをある程度知覚できるため、 「おにぎり」の背後に「三角形のイデア」を見ることができる プラトンの仮説:イデア論 一見、荒唐無稽な説に見えるが、 「人間には他の動物とは違い、複雑な自然を幾何的な図象として抽象化する能力が備わっている」 という認識論として読むと、一考に値する気がしてくる

  70. 70 イデアとは何か? ある洞窟内には、我々によく似た囚人が拘束されている。 囚人は、生まれつき鎖に繋がれており洞窟の奥の壁側しか見ることしかできない。 壁には、太陽の光に照らされた動植物の人形の影だけが揺れ動いている。 生まれたときから影しか見ていないため、 囚人たちは人形の影が世界の全てだと思い込んでいる。 そのため、人形の影が消えると囚人たちは、それが世界から消えたのだと捉える。 ある日、囚人たちは鎖から解放され、初めて外の世界を目にする。 しかし、まだ目が慣れていないため、最初は眩しくて何も見ることができない。

    光に目をならす訓練をすると世界が活き活きとした動植物で溢れていたことを知る。 イデアについてもう少し理解するために、有名な「洞窟の比喩」の話を聞いてみる ※ 私によるサマリです https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82% A4%E3%83%AB:Plato_-_Allegory_of_the_Cave.png
  71. 71 洞窟の比喩が意味すること ここから、プラトンは何が言いたかったのだろうか? ⚫ 洞窟内の囚人 = 我々現実の人間 ⚫ 洞窟内の移ろいゆく影 =

    現実世界のモノ ⚫ 外の世界の動植物 = イデア(理想の形) ⚫ 太陽の光 = イデアを成り立たせ現実世界にもたらしているイデア ※ プラトンはこの「全てのイデアが与る(あずかる)ところのイデア」を「善のイデア」と言ったりもした。
  72. 72 ⚫ 洞窟内の囚人 = 我々現実の人間 ⚫ 洞窟内の移ろいゆく影 = 現実世界のモノ ⚫

    外の世界の動植物 = イデア(理想の形) ⚫ 太陽の光 = イデアを成り立たせ現実世界にもたらしているイデア 洞窟の比喩が意味すること ※ これは皆さんで考えてみてください。いろいろな人がいろいろな読み方をしています。 ちなみに、私は以下のような読み方が好きです。 「人間は、世界を活き活きと認識するための枠(=イデア)のようなものを持っているが、 その枠を使いこなすためにはある種の能力(太陽の光)が必要であり、 その能力は少しずつ訓練をして得ていくしかない」 ここから、プラトンは何が言いたかったのだろうか? ※ プラトンはこの「全てのイデアが与る(あずかる)ところのイデア」を「善のイデア」と言ったりもした。
  73. 73 クラス重視のオブジェクト指向とプラトン プラトンのイデア論における考え方(イデアの実体化)は、 オブジェクト指向の考え方(クラスのインスタンス化)と相似形になっているように思える。 善の イデア イデア 現実世界の モノ クラス

    インスタンス Javaの new演算子 太陽の光 現実の 動植物 影 洞窟の比喩 イデア論 Java
  74. 74 ずっとなんの話をしていたのか 全く関係無さそうに思える2000年前の哲学と、現代のオブジェクト指向プログラミングの間に、 (実際の影響があるかどうかは分からないが)繋がりを見出すこともできる 哲学などの人文学の知見も、もしかしたら現代の技術に応用できるかもしれない。 (仮に応用できなかったとしても、具体的な技術を捉え返すことで、すこし違った物として世界を眺められるかもしれない。)

  75. 75 ずっとなんの話をしていたのか 全く関係無さそうに思える2000年前の哲学と、現代のオブジェクト指向プログラミングの間に、 (実際の影響があるかどうかは分からないが)繋がりを見出すこともできる 哲学などの人文学の知見も、もしかしたら現代の技術に応用できるかもしれない。 (仮に応用できなかったとしても、具体的な技術を捉え返すことで、すこし違った物として世界を眺められるかもしれない。) 実際に人文学の知見から気づきを得て、 ITの歴史を作った人がいた

  76. 76 アラン・ケイとマクルーハンのメディア論 05

  77. 77 質問 アラン・ケイについて名前を聞いたことがある方はいますか? 聞いたことがあるというという人は挙手お願いします。 (※ どこで聞いたのか程度は質問するかもです)

  78. 78 アラン・ケイ パーソナルコンピュータの父であり、チューリング賞受賞者であり、元プロのジャズギタリスト。 アラン・ケイによるGUIコンピュータSmalltalkのデモがスティーブ・ジョブズを触発し、Macintoshが開発された。 「パーソナルコンピュータ」「オブジェクト指向」などの言葉を作った人でもある。 アラン・ケイ(1940~ ) https://en.wikipedia.org/wiki/Alan_Kay 2歳で文字が読めたり、6歳で年間400冊本を読んだり、 中学を退学させられてプロのギタリストになったり、

    紆余曲折を経て2002年チューリング賞を受賞している様子
  79. 79 アラン・ケイ 実は、最初の方に出てきていた メッセージング重視のオブジェクト指向プログラミング • 作った人:アラン・ケイ(パーソナルコンピュータの父とも呼ばれる) • 最初にアラン・ケイが「オブジェクト指向」という言葉を作ったときに指していたもの • 「新たなメディアとしてのコンピュータと人間との関わり方」を目指して開発された

    クラス重視のオブジェクト指向プログラミング • 作った人:ビャーネ・ストロヴストルップ(C++の開発者) • 一般に「オブジェクト指向プログラミング」と言われ場合はこちらを指す • ソフトウェアの品質を向上させ、開発を効率化するという工学的な目的で作られた メッセージング重視のオブジェクト指向プログラミング クラス重視のオブジェクト指向プログラミング
  80. 80 ジョブズに衝撃を与えたSmalltalk https://en.wikipedia.org/wiki/Xerox_Alto ※ 画像は1976年版のSmaltalk-76。 アラン・ケイが中心となり、誰もが使えるパーソナルコンピュータ「Dynabook(※注)」構想の 暫定版として開発された、オブジェクトを直接操作することが可能な言語。 ウィンドウを重ねるGUIなど、後のMacintoshやwindowsのベースとなる機能がほぼそろっていた ※なお、Smalltalk-72はエミュレータがあるため以下のURLにアクセスするとブラウザ上で触れる https://lively-web.org/users/Dan/ALTO-Smalltalk-72.html

    ※注)東芝のDynabookとは全く別物です
  81. 81 Dynabook構想 アラン・ケイは「誰もが使えるパーソナルコンピュータ Dynabook」を構想したが、 その構想の背後には、コンピュータを「目的達成のためのツール」ではなく、 「人々の創造性を拡張するインタラクティブなメタ・メディア(※注)」として捉える発想の転換があった。 コンピュータをこのように捉えることで、コンピュータは高価な限られた人のツールではなく 「パーソナル・コンピュータ」にならなければいけない、という考えに至った。[Kay 1977] まだMacintoshすら発売されていない1970年代にアラン・ケイが構想した「Dynabook」のモック。

    20年以上後の2010年に発売されたipadを完全に先取りしているように見える Alan Kay「Personal Dynamic Media」1977 ※注) メタ・メディアとは、さまざまなメディアをシミュレートできる(つまりメタな)メディアのこと
  82. 82 Dynabookとマクルーハン アラン・ケイがコンピュータを人間の創造性を拡張するメタ・メディアとして捉えたのは、 マクルーハンのメディア論の強い影響を受けたことによる。 例えば、「Dynabook」(dynamic:動的 + book:本)の名称も、 マクルーハンが展開したメディア論から取られている “解釈主義的な中世を科学的な社会に変えた支配的な力は印刷機であるというマクルー ハンの主張を軽視してはならない。特に、印刷機は単に本を入手しやすくしただけで

    はなく、読むことを学んだ人々の思考パターンを変えたという点が重要である。 (中略) しかし、パソコンは、静的な表現を超えて動的なシミュレーションを行うことにより、 本を超えて新しい種類のルネッサンスをもたらすことを約束していた。 (中略> 私は、このノートサイズのコンピュータのアイデアを、来るべきシリコンでのマク ルーハンのメタファーを表現するために「Dynabook」と名付けた。” アラン・ケイ「ユーザーインタフェースー個人的見解」
  83. 83 マクルーハンとは? ⚫ カナダ人の思想家で、メディア論の最重要人物の一人だが、 学者なのかどうかは難しいところ。 ⚫ 「メディアはメッセージである」という言葉で有名。 ⚫ 1960年代にはマクルーハン・ブームが巻き起こる マーシャル・マクルーハン(1911~1980

    ) https://en.wikipedia.org/wiki/File:Marshall_McLuhan.jpg
  84. 84 質問 マクルーハンという名前を聞いたことがある人はいますか? もしいたら、挙手お願いします。(※ どこで聞いたのか程度は質問するかもです)

  85. 85 マクルーハンのメディア論 マクルーハンにおけるメディアとは、「メディア = テクノロジー = 身体の拡張 = 感覚の拡張」。 「メディア」というキーワードを非常に広い意味で捉えなおし、メディア論を文明論に拡張した。

    車輪 足の拡張 服 皮膚の拡張 自動車 全身の拡張 メディア 身体拡張
  86. 86 声を出さなくても(=身体操作なしに)知識を得る ことが可能になり、「知」と「身体」が完全に分離 された。そして世界を自己から引き離して客観的に、 合理的に世界を捉える見るという文化をもたらした。 グーテンベルクの銀河系 メディア=テクノロジーのなかには、人の世界認識を変え、人類史を大きく動かしたものも存在する。 その一つが、グーテンベルクに代表される活版印刷の技術。 活版印刷によって、それまでは超エリートしか読めなかった本を誰もが読めるようになり、 以下のようなことに繋がった。(マクルーハンが言ったこと以外も含みます)

    プロテスタントの誕生 国民国家の誕生 個人主義の発生 世界の分節化 本が安価に印刷されるようになったことで、 「個人で聖書を読む」という体験が可能になり、そ れによって「聖書を読むことを通じて、個人が神が 結び付く」というプロテストタントが成立した。 活版印刷によって始めて、均質な知識を多数の人に 教えられるようになった。これにより「国家」とい う非常に広い範囲の人を「国民」という同じ集団と して組織することが可能になった。 個人主義を実現するためには、「身分」を無化させ る必要がある。そしてそのためには、身分に関わら ず同じ知識を持つことが必要であり、それは活版印 刷によってはじめて可能になった。
  87. 87 人類史とメディアの関係 活版印刷以外にも、以下のようなメディアが人類史を決定づけてきた、という議論を展開した。 このように、マクルーハンにおけるメディアとは、それ自体がパワーを持ち社会の構造を変えてしまうもの。 主要なメディア/ テクノロジー 時代区分 世界の認識 / 感覚の在り方

    会話 古代 (中世よりも前) ・ さまざまな感覚が統合されており、過去・未来・現在といった形に、時空を線形に整理する認 識はまだ一般的ではなかった。 ・人々は「いまここ」を生きるような在り方で存在していた 筆記文字技術 中世 ・ アルファベットのような表音文字の登場により、ある一定の方向に世界を秩序立てる世界認識 が生まれた。 ・人々は時空を「過去・未来・現在」という線形な流れを持ったものとして把握 印刷技術 近代 ・活版印刷によって世界を合理的に秩序立てて捉える見方が一気に広範囲に広がり、人々の均質 性がもたらされた。 ・この均質性によって、Nation(国家)が形成され、個人主義が生まれた。 電子技術 現代 ・古代のように様々な感覚が統合された時代に回帰する。 ・人々の神経が電子につながることで世界は急速に近づき、地球が一つの「村」のようになる
  88. 88 メディアはメッセージである マクルーハンの有名な言葉に「メディアはメッセージである」というものがある。 これは、メディアとはメッセージを運ぶ単なる道具ではなく、 メディアそれ自体が強いメッセージとしての機能を持っており、 前頁に掲載したように社会環すら変えてしまう力を持つ、ということ。 アラン・ケイは「Dynabook」を、 社会を変える力をもつ「メディア」すらもシミュレートして統合する 「メタ・メディア」として捉えた

  89. 89 そしてオブジェクト指向へ 私はマクルーハンの『Understanding Media』(19641年)を読んで、 あらゆるコミュニケーション・メディアについて最も重要なことは、 メッセージの受け取りは、まさにメッセージの復元であるということ だと理解しました。つまり、メディアに埋め込まれたメッセージを受 け取りたいと思う人は、まずそのメディアを内面化し、それを「引き 算」してメッセージを残せるようにしなければならないのです。「メ ディアはメッセージである」と言ったのは、「メディアを使うなら、

    自分がメディアにならなければならない」という意味です。 Alan Kay「User Interface:A Personal View」1989 オブジェクトは、生物の細胞やネットワーク上の各コンピュータのようなもので、 メッセージでしか通信できないと考えました(そのため、メッセージングは最初か ら存在していましたが、プログラミング言語でメッセージングを効率的に行う方法 を見つけ出すのには時間がかかりました)。私は、データをなくしたいと思いまし た。B5000は、信じられないようなHWアーキテクチャーによって、これをほぼ実 現していました。細胞/全体コンピュータのメタファーがデータを取り除くことに なり、"<-"は単なるメッセージトークンであることに気がつきました(私はこれら の記号をすべて関数や手続きの名前だと考えていたので、このことを考えるのにか なり時間がかかりました)。(中略)私にとってのオブジェクト指向プログラミン グとは、メッセージング、状態処理のローカル保持・保護・隠蔽、あらゆるものの 極端な遅延結合だけを意味します。 Alan Kay「Dr. Alan Kay on the Meaning of “Object-Oriented Programming”」2003 マクルーハンの議論とアラン・ケイの書き物をいくつか結び付けると、アラン・ケイのオブジェクト指向においては、 「オブジェクト」とはコンピュータの比喩であり、つまりメディアであり、 したがって、オブジェクト=メディアそれ自体にメッセージが埋め込まれており、 人はそのオブジェクト=メディアを身体の一部(=内面化)として扱える必要がある、とも読めるかもしれない。 (「読める!」と断言するには資料調査が不足している。。。)
  90. 90 そしてオブジェクト指向へ 最初に紹介した、以下の「メッセージング重視のオブジェクト指向」とは、 言い換えれば「メディアとしてのオブジェクト」指向なのかもしれない。 だからデータの確実な送受信ではなく、オブジェクト=メディア自身が、メッセージの意味を決めるのかもしれない。

  91. 91 未完のオブジェクト指向プログラミング アラン・ケイが提唱した最初の「オブジェクト指向プログラミング」とは、 様々なメディアをシミュレートする「メタ・メディア」であるDynabookを本当に活用するために 必要な仕組みだったのかもしれない。 そして、それはまだ十分には実現されていないかもしれない。

  92. 92 おわりに 06

  93. 93 おわりに 本日は「オブジェクト指向」を狂言回しとして、 プログラミングから始まり、プラトンを経て、パーソナル・コンピュータ思想と マクルーハンのメディア論までたどってきました。 私が本日このようなテーマにしたのは、実は 最後のアラン・ケイとマクルーハンのお話をしたかったからでした。 実は、私が冒頭でお伝えした「自由な学びを楽しむ」は、 アラン・ケイがやろうとしたことを、私なりに解釈したものでした。 今回、この機会を頂いたことで、私も改めてアラン・ケイの書いた論文などに触れることができ、

    本当に大きな学びになりました。まことにありがとうございます。 本日の講義も皆様の自由で楽しい学びに貢献するものになったら幸いです。
  94. CONFIDENTIAL 【 お 問 い 合 わ せ 先 】

    X(クロス)イノベーション本部 AIトランスフォーメーションセンター 製品開発グループ 御手洗拓真 MAIL:mitarai.takuma@isid.co.jp TEL :03-6713-6135