オブジェクト指向の「語る」と「示す」

46118634593ecd0c9476feebb0c78a23?s=47 kawakawa
February 16, 2020

 オブジェクト指向の「語る」と「示す」

2020/02/16「Object-Oriented Conference」で発表させて頂いた資料です。
#ooc_2020 #ooc_e

46118634593ecd0c9476feebb0c78a23?s=128

kawakawa

February 16, 2020
Tweet

Transcript

  1. オブジェクト指向の 「語る」と「示す」 Object-Oriented Conference 2020/02/16 14:00 共1-301 #ooc_2020 #ooc_e @kawakawa

  2. 資料の目的 哲学者ウィトゲンシュタインが示した言語の限界 が、オブジェクト指向においてどのように影響する のか、オブジェクトで語れること、語れないこと、 語れないが示すことはできること。 オブジェクト指向のまた違った見方を提示でき たらと思います。 「プログラミングが変わる」なんて事はおき ません。ごめんなさい。 でも今後、抽象化やメタファー・DCI・DDD

    など、様々な考えに発展出来るようになれば・・ そんなきっかけになれたら幸いです。 2
  3. 自己紹介 • かわべたくや • Twitter:@kawakawa • 業務系開発がメイン • 読書会によく参加してます (DDD,MPD,時を超えた建設への道、

    暗黙知の次元) 宜しくお願いします! 3
  4. 4 ー1章ー オブジェクト指向で 語られている「意味」 と 語られていない「意義」

  5. 次のクラスを例に考えてみたいと思います。 5 class 人 { void 水をかける(対象); } 人.水をかける(植物); 人.水をかける(水かけ地蔵);

    人.水をかける(ヘレンケラー);
  6. このメソッドの処理内容の意味、つまり 「何を行うのか⇒対象に水をかける」は 理解できると思います。 6 人.水をかける(植物); 人.水をかける(水かけ地蔵); 人.水をかける(ヘレンケラー);

  7. しかし、このメソッドでは、行為の 目的(意義)が語られていません。 つまり「なぜ水をかけるのか」という理由 です。 7 人.水をかける(植物); 人.水をかける(水かけ地蔵); 人.水をかける(ヘレンケラー);

  8. では、下のメソッドだけで、 目的(意義)を見出すことはできますか? 8 人.水をかける(植物); 人.水をかける(水かけ地蔵); 人.水をかける(ヘレンケラー);

  9. 多くの方は、メソッドの目的(意義)を 見出すことが出来たと思います。 そして、それぞれ異なると思われたのでは ないでしょうか。 9 人.水をかける(植物); ⇒育てるため 人.水をかける(水かけ地蔵); ⇒願掛け 人.水をかける(ヘレンケラー);

    ⇒水の意味を教える(イジメじゃない)
  10. 人によっては、その目的の背後にいる 別の目的も想像することが出来た方も おられるかと思います。 10 人.水をかける(植物); ⇒育てるため ⇒収穫&販売 人.水をかける(水かけ地蔵); ⇒願掛け ⇒平穏無事

    人.水をかける(ヘレンケラー); ⇒水の意味を教える(イジメじゃない) ⇒人らしく生きてもらうため
  11. 普段、プログラミングするよりも前に、 目的・理由などが、要求や仕様書・ユース ケース、ストーリーなどで提示されること が多いため、意義など気にすることなく、 メソッドをプログラミングしていますが、 それはメソッドの意義を理解したうえで、 プログラミングしているのです。 (※余談ページにて、意義を理解せずプログラミングしたら どうなるか考察しています) 11

  12. 今回の例で、注目したいのは、 なぜメソッドそれぞれで、意義が異なると 思ったのかということです。 人によっては、「水かけ地蔵」「ヘレンケ ラー」の水をかける行為の目的を理解でき なかった方もおられたかもしれません。 つまり、メソッドの意義はオブジェクト そのものからでははなく、「オブジェクト が成り立つと自分が想像している世界」から 見出していることになります。

    12
  13. 言い換えると、メソッドの意義は オブジェクトの中ではなく、外にあると いえます。 では、メソッドの意義は、普段記述して いないだけで、オブジェクトの中に、 記述することは出来るのでしょうかしょうか? 無理やり、意義を書いてみたいと思います。 13

  14. どうだ! 14 class 人 { 水をかける_育って欲しい_収穫いっぱい(植物); 水をかける_願掛け_平穏無事_家族健康(水かけ地蔵); 水をかける_水の意味を教える _人らしく生きて欲しい(ヘレンケラー); 水をかける_キレイにする_カッコよくしたい(車);

    //他多数。。。略 }
  15. 冗談です。 思いつく限りの意義を記述することは可能で すが、書ききることが出来ないという問題が あります。 それは、コメントやドキュメントも同じ です。極端に言うと仕様書に書いてある 日本語の意味をすでに理解していることが 前提になっているのと同様に、特定の前提を 置かないと意義を表すことは出来ないのです。 15

  16. まとめると、 メソッドの意味は、オブジェクトの中で 語られていますが、 メソッドの意義(目的、理由、価値など)は、 メソッドの中にはなく、メソッドが成り立つ と自分が想像している世界の中に存在してい るのです。 メソッド意義を語るには、自分が想像して いる世界を前提とする必要があり、すべてを 語ることはできないのです。

    (※語れない理由は後ほど出てきます) 16
  17. 17 ー2章ー オブジェクト指向において、 型が成り立つ条件は 語られていない?

  18. みなさんお馴染みの、ワンワン・ニャーの サンプルで考えてみたいと思います。 18 class イヌ{ 鳴く(){ return "ワンワン"; } }

    class ネコ{ 鳴く(){ return "ニャー"; } }
  19. 次にイヌ・ネコの抽象化して、動物クラス を作り、そこからイヌ・ネコを継承させる ことにしました。 19 class 動物{ 鳴く(); } class イヌ

    extends 動物{} class ネコ extends 動物{}
  20. 次々に、ブタ・ゾウ・キリン・・・クラスを 継承させて作っていいたところ、 つぎのような質問がありました。 「アイボ(aibo)も動物から継承させて いいですか?」 20

  21. アイボは動物では無いと断りましたが、 「私にとってはアイボは動物です! 犬と同じように鳴くし、歩くし、 餌(電気)も食べます!」 ・・勢いにまけて動物Classからの継承を 許可しました。 21

  22. 次に別の質問が来ました。 「ファービーも継承させていいですか。 口は壊れてますが、スピーカーから音は 鳴ります」 22

  23. ・・・収拾がつかなくなりそうなので、 クラスを 動物クラス → 生き物クラス に変更して電子玩具が継承できないように しました。 23

  24. そうしたら、 「体はロボットですが、脳だけ生身のイヌは 生き物なので継承していいですか?」 「体は生身ですが、脳だけロボットのイヌは 生き物なので継承していいでしょうか?」 ・・・またクラスを書き換えることに しました。 24

  25. どこまで書いたらいいのでしょうか。 25 class 動物かつ 生き物かつ アイボでもなくかつ ファービーでもなくかつ 電子玩具の類でなくかつ 物身体のすべてが生身であるかつ 神話上の動物

    ではなくかつ 妖怪でもなくかつ そもそも想像上の 動物ではなくかつ 動物兼植物のミドリムシ科の 単細胞生物は含まずかつ 口がついていないの動 物は含まずかつ・・・略・・・の何か{ 鳴く(); }
  26. どうやら、型が「想定している型」として 機能するのは、「自分が想定している世界」 において成り立っているようです。 そして、「想定している型」の条件を オブジェクト指向で語りきることは できなそうです。 26

  27. 27 -3章ー オブジェクト指向で 語れる限界とは?

  28. 極端な例をだしてきましたが、 メソッドの意義、型の成立する条件 ともに共通しているのは「自分が想像 (想定)している世界」となります。 では「自分が想像している世界」とは 何を指すのでしょうか。 28

  29. 私たちがオブジェクト指向で記述する前に、 対象を抽象化やモデリングを行い、 ドメインモデルを作ります。 遠回しに書いてきましたが、「自分が想像し ている世界」とは「ドメインモデル」のこと を指しています。 29

  30. 私たちが描くドメインモデルの世界は、 現実世界の延長線上にある実現可能な世界 ではなく、私たちが想像しえる世界、 理解可能な世界と言えます。 ※理解可能な世界とは、 『モンスター』や『魔法』などのゲームの ように非現実でも想像することが出来る世界、 自分なりの解釈で想像した世界となりなす。 30

  31. つまりドメインモデルは、単一のものでは なく、人ごとに解釈が異なっているのです。 31 ドメインモデル 言語化できて 語れる部分 言語化できない部分 語りつくせない部分 暗黙知 ドキュメント

    や コード化できる部分
  32. 続いて暗黙知について、例を示したいと 思います。 32

  33. 世の中には色々なイスがあります。 では、この絵をイスと認知できた規則を 説明できますか? 33

  34. 「座れる面があり、イスの足があること」 説明はこれでよろしいでしょうか? では足が無いイスは、イスにならない? 34

  35. 「座る面があればイス」 それでは、これもイスになりますか? 他にも、階段、花壇、噴水など多数あります。 35

  36. 有限個のイスを見るだけで、数えきれない イスに当てはまる規則を理解できる、これは 人間が持つ能力です。 しかし、これもイス・あれもイスという 個々でイスであるかどうかの判断はでき ますが、イスと認知した規則・ルールその ものの説明は困難です。 「イスと理解すること」と「イスと理解した 規則を説明すること」は異なるのです。 36

  37. 語ることはできないが、理解していること これが暗黙知と呼ばれるものになります。 37

  38. まとめると、ドメインモデルは多数の暗黙知 の上でなりたっているのです。 ドメインモデルをなぜそう解釈したのかと いう解釈のルールや、ドメインモデルが 成り立つと想定しているモデル上の世界の 規則や法則は語られない(語りつくせない) のです。 38

  39. オブジェクト指向で記述するオブジェクト とは、そのドメインモデルをオブジェクト化 したものです。 つまり、ドメインモデルで語られない部分 つまり暗黙知に属する部分は、オブジェクト 指向でも語られないのです。 39

  40. 40 ー4章ー 「示す」について

  41. 最初に「示す」の説明させていただきます。 先ほど、暗黙知は語れない(語りつくせない) と説明させていただきました。 しかし、イスの例でありましたように、 複数のイスを用意することによって、 イスとは何ぞやを示そうとしました。 つまり示すとは、直接語られていないモノ の存在を指し示すことで認知させようとする ことです。 41

  42. そして、「示す」の力を得るには、互いの 暗黙知の重なりが高い必要があります。 日常会話自体も、暗黙知という前提の上で 成り立っています。 話しが噛み合わず、意味は通じているのに チグハグした経験は有ると思います。 42

  43. もうひとつ「示す」の例をあげると、 1+1=?と提示されて、 「でっかい1」ではなく「2」と答える ような事ともいえます。 「+」記号の意味と、数の抽象という数学で 必要な前提に疑いもなく従っています。 それは、小中高と数学を学習してきた成果とも いえます。 DDDでいうと「ドメインに入る」という表現 になるかもしれませんね。

    43
  44. それでは、「示す」をどのように活用できる のか考えてみたいと思います。 44

  45. 45 ー5章ー 「示す」の活用

  46. ひとつ問題を出してみたいと思います。 将棋に新しい「銅(どう)」というコマを 追加したいと思います。 「銅」はどのように動きますか? 46 銅

  47. おそらく、動けるマスの多さが、 金銀 > 銅 > 桂馬 となるように考えた方は 多かったのではないでしょうか。 例えば、こんな感じに。 47

    銅 縦横 斜め 銅 銅 縦横&斜め
  48. 逆に、次のような振る舞いを考えた人は 少なかったと思います。 (1)他の種類の駒とまったく同じ動き (2)金や銀より多くのマスに動ける (3)好きなマスにワープできる!! 新しい駒の動きを自由に考えてよいのに、 なにかの制約を受けてしまったようです。 その制約の正体とは何でしょうか。 48

  49. 今回の場合、 (1)駒ごとに動きが異なることを知っている (2)金、銀、銅の貴金属価値、オリンピック などに見られる上下関係を、動けるマス数 にも当てはめている (3)将棋が破綻するような能力は、そもそも 想定から除外している などが考えられます。 49

  50. (2)の金銀銅のメタファーが、動けるマス数に 金銀 > 銅 と制約を与えているこれが、 示すの活用となりなす。 直接、動けるマス数を金銀より少なくしたい と指定しているわけではないのに、 メタファーを使うことで、直接は語って いない規則を示すことができるのです。

    しかし、(1)(2)(3)ともに、将棋は知っている という前提が必要です。 50
  51. オブジェクト指向で「示す」を活用するには、 ドメインモデルの相互理解を深めるのは 当然として、世に溢れているドメインや メタファーを活用するというのが効果的です。 コードだけでなく、会話でも示すことは できます。 ・赤黒処理(情報は常に追記) ・信号(青=安全、黄=注意、赤=エラー) ・新幹線(のぞみ、ひかり、こだま) などなど

    51
  52. デザインパターン、 XPでのシステム・メタファー、 など事例は多々あり、皆さんのほうが 詳しいと思います。 つまりオブジェクト指向における「示し」 とは、普段から皆さんがやっていたこと そのものだったのです。 52

  53. 53 まとめ

  54. オブジェクト指向は2段構成で出来ています。 プログラミングとして語れる個所と、 語れない箇所です。 オブジェクトが成り立つ前提は、 語れるオブジェクトの中でなく、 語れなかった箇所に存在します。 オブジェクトは「示す」ことで、 その語られなかったを箇所を認知させる ことができるのです。 54

  55. 長々と書いてきましたが、 少しでも、皆様の良きプログラミング 人生の足しに成れれば幸いです。 ご清聴ありがとうございました。 55

  56. 余談 メソッドの意義を知らない場合 メソッドの意義を理解しないまま、プログラ ミングしたらどうなるのでしょうか? 例えば、将棋を全く知らない人が、ルールブック から起こした仕様書だけで将棋ゲームを作った 場合、どのようなものが出来上がると思います か? 私はゲームとしては成り立つが、とても違和感を 感じるものが出来上がると思います。

    「操作方法を理解している」だけではダメで、 「対象を理解している」必要があると思います。 56
  57. 余談 ドメインモデルが不明な場合 前提が不明なとき、どのようにオブジェクトを書 けば良いのでしょうか。 私は、とりあえず色々と振る舞いを書くことにし ています。 そうすると想像と矛盾するところが出てきます。 矛盾から境界が見え、オブジェクトを理解するこ とに繋がります。 身も蓋もなく言うと、試行錯誤です!

    見る聞くだけでなく、自分でやってみることが大 事なのです。 57
  58. 余談 対象とドメインモデルの関係 一般的にドメインモデルは、 対象をモデリングすることで、ドメインモデルに なると思われています。 58 対象 ドメイン モデル モデリング

  59. 余談 対象とドメインモデルの関係 私はこのように考えています。 ドメインモデルをから、 対象を眺めるのが モデリングです。 59 対象 ドメイン モデル

    何を抽象化とし、何を切り捨てるのか は暗黙知が影響している ドメインモデルが成り立つ条件、ドメイ ンの意味など記述されていないことは 暗黙知が都合よい解釈を行う ドメインモデルが なりたつかチェック 対象のどこに着目す るかは暗黙知が影響 している
  60. ※この図について、今回の趣旨と直接 関係はしませんので、多く触れませんが、 機会があればまた話したいです。 60

  61. 61 参考資料

  62. •「ウィトゲンシュタイン入門」(ちくま新書) -永井均- はじめてウィトゲンシュタインの書籍を読むなら最適な一冊です。 前期・後期を通して思考の流れが永井節で颯爽と語られ、スラスラと 読めてしまいます。ただそうさせているのは、あくまでも入門書だから と釘は刺されております。 •「ウィトゲンシュタイン「論理哲学論考」を読む」(ちくま学芸文庫) -野矢茂樹- 前期ウィトゲンシュタインを中心に、後期ウィトゲンシュタインは何を 否定し、何を残したのかを判りやすくまとめられた一冊です。

    「語りきれぬことは、語り続けねばならない」と、とらえなおすところは ほんとその通りだと思います。 後日出版された「語りえぬものを語る」もお勧めです。 62
  63. •「はじめての言語ゲーム」(講談社現代新書) -橋爪大三郎- 後期ウィトゲンシュタインの言語ゲーム・家族的類似性を判りやすく 解説されている一冊です。 論理が世界と人と限界づけるのではなく、逆に世界と人の限界が論理を 限定していく様を目の当たりにすることが出来ます。 •「レトリックと人生」(大修館書店) -ジョージ・レイコフ- •「レトリック論を学ぶ人のために」(世界思想社) -菅野盾樹-

    ウィトゲンシュタインをして「それは私に強いられたのである」と 言わしめたレトリック・比喩の凄さを学ぶことができます。 特に「比喩とは有限の認知的資源を拡張するための基本的な知的戦略で あり、ここに<比喩の創造性>のしるしがある」という記述は創発の 本質を捉えていると思います。 63
  64. •「暗黙知の次元」(ちくま学芸文庫) -マイケル・ポランニー - 「私たちは言葉にできるより多くのことを知ることができる」 暗黙知にも指向があり、どう私たちがその恩恵を受けているか 学ぶことができます。 •「オブジェクト指向のこころ」(丸善出版) -アラン・シャロウェイ- -ジェームズ・R・トロット- デザインパターンをどう使うかではなく、問題を解決していく中で、

    結果としてデザインパターンになっていくという、GoFが本来伝えた かっただろう事柄を丁寧に説明してくれます。 64
  65. 謝辞 資料をつくるにあたり多数の方に意見や アドバイス頂きました。ありがとうござい ます。 @sugimoto_kei @spring_kuma @tunemage @smori1983 @tokudiro @kazuhito_m

    65
  66. ほんとの終わり 自分も良きプログラミングとは? と日々、悪戦苦闘の毎日です。 少しでもご意見頂ければ幸いです。 今後ともよろしくお願いします<(_ _)> Twitter: @kawakawa 66