2020/02/16「Object-Oriented Conference」で発表させて頂いた資料です。 #ooc_2020 #ooc_e
オブジェクト指向の「語る」と「示す」Object-Oriented Conference2020/02/16 14:00 共1-301#ooc_2020 #ooc_e@kawakawa
View Slide
資料の目的哲学者ウィトゲンシュタインが示した言語の限界が、オブジェクト指向においてどのように影響するのか、オブジェクトで語れること、語れないこと、語れないが示すことはできること。オブジェクト指向のまた違った見方を提示できたらと思います。「プログラミングが変わる」なんて事はおきません。ごめんなさい。でも今後、抽象化やメタファー・DCI・DDDなど、様々な考えに発展出来るようになれば・・そんなきっかけになれたら幸いです。2
自己紹介• かわべたくや• Twitter：@kawakawa• 業務系開発がメイン• 読書会によく参加してます（DDD,MPD,時を超えた建設への道、暗黙知の次元）宜しくお願いします！3
4ー１章ーオブジェクト指向で語られている「意味」と語られていない「意義」
次のクラスを例に考えてみたいと思います。5class 人 {void 水をかける（対象）;}人.水をかける（植物）;人.水をかける（水かけ地蔵）;人.水をかける（ヘレンケラー）;
このメソッドの処理内容の意味、つまり「何を行うのか⇒対象に水をかける」は理解できると思います。6人.水をかける（植物）;人.水をかける（水かけ地蔵）;人.水をかける（ヘレンケラー）;
しかし、このメソッドでは、行為の目的（意義）が語られていません。つまり「なぜ水をかけるのか」という理由です。7人.水をかける（植物）;人.水をかける（水かけ地蔵）;人.水をかける（ヘレンケラー）;
では、下のメソッドだけで、目的（意義）を見出すことはできますか？8人.水をかける（植物）;人.水をかける（水かけ地蔵）;人.水をかける（ヘレンケラー）;
多くの方は、メソッドの目的（意義）を見出すことが出来たと思います。そして、それぞれ異なると思われたのではないでしょうか。9人.水をかける（植物）;⇒育てるため人.水をかける（水かけ地蔵）;⇒願掛け人.水をかける（ヘレンケラー）;⇒水の意味を教える（イジメじゃない）
人によっては、その目的の背後にいる別の目的も想像することが出来た方もおられるかと思います。10人.水をかける（植物）;⇒育てるため ⇒収穫＆販売人.水をかける（水かけ地蔵）;⇒願掛け ⇒平穏無事人.水をかける（ヘレンケラー）;⇒水の意味を教える（イジメじゃない）⇒人らしく生きてもらうため
普段、プログラミングするよりも前に、目的・理由などが、要求や仕様書・ユースケース、ストーリーなどで提示されることが多いため、意義など気にすることなく、メソッドをプログラミングしていますが、それはメソッドの意義を理解したうえで、プログラミングしているのです。（※余談ページにて、意義を理解せずプログラミングしたらどうなるか考察しています）11
今回の例で、注目したいのは、なぜメソッドそれぞれで、意義が異なると思ったのかということです。人によっては、「水かけ地蔵」「ヘレンケラー」の水をかける行為の目的を理解できなかった方もおられたかもしれません。つまり、メソッドの意義はオブジェクトそのものからでははなく、「オブジェクトが成り立つと自分が想像している世界」から見出していることになります。12
言い換えると、メソッドの意義はオブジェクトの中ではなく、外にあるといえます。では、メソッドの意義は、普段記述していないだけで、オブジェクトの中に、記述することは出来るのでしょうかしょうか？無理やり、意義を書いてみたいと思います。13
どうだ！14class 人 {水をかける_育って欲しい_収穫いっぱい（植物）;水をかける_願掛け_平穏無事_家族健康（水かけ地蔵）;水をかける_水の意味を教える_人らしく生きて欲しい（ヘレンケラー）;水をかける_キレイにする_カッコよくしたい（車）;//他多数。。。略}
冗談です。思いつく限りの意義を記述することは可能ですが、書ききることが出来ないという問題があります。それは、コメントやドキュメントも同じです。極端に言うと仕様書に書いてある日本語の意味をすでに理解していることが前提になっているのと同様に、特定の前提を置かないと意義を表すことは出来ないのです。15
まとめると、メソッドの意味は、オブジェクトの中で語られていますが、メソッドの意義（目的、理由、価値など）は、メソッドの中にはなく、メソッドが成り立つと自分が想像している世界の中に存在しているのです。メソッド意義を語るには、自分が想像している世界を前提とする必要があり、すべてを語ることはできないのです。（※語れない理由は後ほど出てきます）16
17ー２章ーオブジェクト指向において、型が成り立つ条件は語られていない？
みなさんお馴染みの、ワンワン・ニャーのサンプルで考えてみたいと思います。18class イヌ｛鳴く(){return "ワンワン"；}｝class ネコ｛鳴く(){return "ニャー"；}｝
次にイヌ・ネコの抽象化して、動物クラスを作り、そこからイヌ・ネコを継承させることにしました。19class 動物{鳴く();}class イヌ extends 動物{}class ネコ extends 動物{}
次々に、ブタ・ゾウ・キリン・・・クラスを継承させて作っていいたところ、つぎのような質問がありました。「アイボ（aibo）も動物から継承させていいですか？」20
アイボは動物では無いと断りましたが、「私にとってはアイボは動物です！犬と同じように鳴くし、歩くし、餌（電気）も食べます！」・・勢いにまけて動物Classからの継承を許可しました。21
次に別の質問が来ました。「ファービーも継承させていいですか。口は壊れてますが、スピーカーから音は鳴ります」22
・・・収拾がつかなくなりそうなので、クラスを動物クラス → 生き物クラスに変更して電子玩具が継承できないようにしました。23
そうしたら、「体はロボットですが、脳だけ生身のイヌは生き物なので継承していいですか？」「体は生身ですが、脳だけロボットのイヌは生き物なので継承していいでしょうか？」・・・またクラスを書き換えることにしました。24
どこまで書いたらいいのでしょうか。25class 動物かつ生き物かつアイボでもなくかつファービーでもなくかつ電子玩具の類でなくかつ物身体のすべてが生身であるかつ神話上の動物ではなくかつ妖怪でもなくかつそもそも想像上の動物ではなくかつ動物兼植物のミドリムシ科の単細胞生物は含まずかつ口がついていないの動物は含まずかつ・・・略・・・の何か{鳴く();}
どうやら、型が「想定している型」として機能するのは、「自分が想定している世界」において成り立っているようです。そして、「想定している型」の条件をオブジェクト指向で語りきることはできなそうです。26
27－３章ーオブジェクト指向で語れる限界とは？
極端な例をだしてきましたが、メソッドの意義、型の成立する条件ともに共通しているのは「自分が想像（想定）している世界」となります。では「自分が想像している世界」とは何を指すのでしょうか。28
私たちがオブジェクト指向で記述する前に、対象を抽象化やモデリングを行い、ドメインモデルを作ります。遠回しに書いてきましたが、「自分が想像している世界」とは「ドメインモデル」のことを指しています。29
私たちが描くドメインモデルの世界は、現実世界の延長線上にある実現可能な世界ではなく、私たちが想像しえる世界、理解可能な世界と言えます。※理解可能な世界とは、『モンスター』や『魔法』などのゲームのように非現実でも想像することが出来る世界、自分なりの解釈で想像した世界となりなす。30
つまりドメインモデルは、単一のものではなく、人ごとに解釈が異なっているのです。31ドメインモデル言語化できて語れる部分言語化できない部分語りつくせない部分暗黙知ドキュメントやコード化できる部分
続いて暗黙知について、例を示したいと思います。32
世の中には色々なイスがあります。では、この絵をイスと認知できた規則を説明できますか？33
「座れる面があり、イスの足があること」説明はこれでよろしいでしょうか？では足が無いイスは、イスにならない？34
「座る面があればイス」それでは、これもイスになりますか？他にも、階段、花壇、噴水など多数あります。35
有限個のイスを見るだけで、数えきれないイスに当てはまる規則を理解できる、これは人間が持つ能力です。しかし、これもイス・あれもイスという個々でイスであるかどうかの判断はできますが、イスと認知した規則・ルールそのものの説明は困難です。「イスと理解すること」と「イスと理解した規則を説明すること」は異なるのです。36
語ることはできないが、理解していることこれが暗黙知と呼ばれるものになります。37
まとめると、ドメインモデルは多数の暗黙知の上でなりたっているのです。ドメインモデルをなぜそう解釈したのかという解釈のルールや、ドメインモデルが成り立つと想定しているモデル上の世界の規則や法則は語られない（語りつくせない）のです。38
オブジェクト指向で記述するオブジェクトとは、そのドメインモデルをオブジェクト化したものです。つまり、ドメインモデルで語られない部分つまり暗黙知に属する部分は、オブジェクト指向でも語られないのです。39
40ー４章ー「示す」について
最初に「示す」の説明させていただきます。先ほど、暗黙知は語れない（語りつくせない）と説明させていただきました。しかし、イスの例でありましたように、複数のイスを用意することによって、イスとは何ぞやを示そうとしました。つまり示すとは、直接語られていないモノの存在を指し示すことで認知させようとすることです。41
そして、「示す」の力を得るには、互いの暗黙知の重なりが高い必要があります。日常会話自体も、暗黙知という前提の上で成り立っています。話しが噛み合わず、意味は通じているのにチグハグした経験は有ると思います。42
もうひとつ「示す」の例をあげると、１＋１＝？と提示されて、「でっかい１」ではなく「２」と答えるような事ともいえます。「＋」記号の意味と、数の抽象という数学で必要な前提に疑いもなく従っています。それは、小中高と数学を学習してきた成果ともいえます。DDDでいうと「ドメインに入る」という表現になるかもしれませんね。43
それでは、「示す」をどのように活用できるのか考えてみたいと思います。44
45ー５章ー「示す」の活用
ひとつ問題を出してみたいと思います。将棋に新しい「銅（どう）」というコマを追加したいと思います。「銅」はどのように動きますか？46銅
おそらく、動けるマスの多さが、金銀 ＞ 銅 ＞ 桂馬 となるように考えた方は多かったのではないでしょうか。例えば、こんな感じに。47銅縦横 斜め銅銅縦横＆斜め
逆に、次のような振る舞いを考えた人は少なかったと思います。(1)他の種類の駒とまったく同じ動き(2)金や銀より多くのマスに動ける(3)好きなマスにワープできる！！新しい駒の動きを自由に考えてよいのに、なにかの制約を受けてしまったようです。その制約の正体とは何でしょうか。48
今回の場合、(1)駒ごとに動きが異なることを知っている(2)金、銀、銅の貴金属価値、オリンピックなどに見られる上下関係を、動けるマス数にも当てはめている(3)将棋が破綻するような能力は、そもそも想定から除外しているなどが考えられます。49
(2)の金銀銅のメタファーが、動けるマス数に金銀 ＞ 銅 と制約を与えているこれが、示すの活用となりなす。直接、動けるマス数を金銀より少なくしたいと指定しているわけではないのに、メタファーを使うことで、直接は語っていない規則を示すことができるのです。しかし、(1)(2)(3)ともに、将棋は知っているという前提が必要です。50
オブジェクト指向で「示す」を活用するには、ドメインモデルの相互理解を深めるのは当然として、世に溢れているドメインやメタファーを活用するというのが効果的です。コードだけでなく、会話でも示すことはできます。・赤黒処理（情報は常に追記）・信号（青＝安全、黄＝注意、赤＝エラー）・新幹線（のぞみ、ひかり、こだま）などなど51
デザインパターン、XPでのシステム・メタファー、など事例は多々あり、皆さんのほうが詳しいと思います。つまりオブジェクト指向における「示し」とは、普段から皆さんがやっていたことそのものだったのです。52
53まとめ
オブジェクト指向は2段構成で出来ています。プログラミングとして語れる個所と、語れない箇所です。オブジェクトが成り立つ前提は、語れるオブジェクトの中でなく、語れなかった箇所に存在します。オブジェクトは「示す」ことで、その語られなかったを箇所を認知させることができるのです。54
長々と書いてきましたが、少しでも、皆様の良きプログラミング人生の足しに成れれば幸いです。ご清聴ありがとうございました。55
余談 メソッドの意義を知らない場合メソッドの意義を理解しないまま、プログラミングしたらどうなるのでしょうか？例えば、将棋を全く知らない人が、ルールブックから起こした仕様書だけで将棋ゲームを作った場合、どのようなものが出来上がると思いますか？私はゲームとしては成り立つが、とても違和感を感じるものが出来上がると思います。「操作方法を理解している」だけではダメで、「対象を理解している」必要があると思います。56
余談 ドメインモデルが不明な場合前提が不明なとき、どのようにオブジェクトを書けば良いのでしょうか。私は、とりあえず色々と振る舞いを書くことにしています。そうすると想像と矛盾するところが出てきます。矛盾から境界が見え、オブジェクトを理解することに繋がります。身も蓋もなく言うと、試行錯誤です！見る聞くだけでなく、自分でやってみることが大事なのです。57
余談 対象とドメインモデルの関係一般的にドメインモデルは、対象をモデリングすることで、ドメインモデルになると思われています。58対象ドメインモデルモデリング
余談 対象とドメインモデルの関係私はこのように考えています。ドメインモデルをから、対象を眺めるのがモデリングです。59対象ドメインモデル何を抽象化とし、何を切り捨てるのかは暗黙知が影響しているドメインモデルが成り立つ条件、ドメインの意味など記述されていないことは暗黙知が都合よい解釈を行うドメインモデルがなりたつかチェック対象のどこに着目するかは暗黙知が影響している
※この図について、今回の趣旨と直接関係はしませんので、多く触れませんが、機会があればまた話したいです。60
61参考資料
●「ウィトゲンシュタイン入門」（ちくま新書）-永井均-はじめてウィトゲンシュタインの書籍を読むなら最適な一冊です。前期・後期を通して思考の流れが永井節で颯爽と語られ、スラスラと読めてしまいます。ただそうさせているのは、あくまでも入門書だからと釘は刺されております。●「ウィトゲンシュタイン「論理哲学論考」を読む」（ちくま学芸文庫）-野矢茂樹-前期ウィトゲンシュタインを中心に、後期ウィトゲンシュタインは何を否定し、何を残したのかを判りやすくまとめられた一冊です。「語りきれぬことは、語り続けねばならない」と、とらえなおすところはほんとその通りだと思います。後日出版された「語りえぬものを語る」もお勧めです。62
●「はじめての言語ゲーム」（講談社現代新書）-橋爪大三郎-後期ウィトゲンシュタインの言語ゲーム・家族的類似性を判りやすく解説されている一冊です。論理が世界と人と限界づけるのではなく、逆に世界と人の限界が論理を限定していく様を目の当たりにすることが出来ます。●「レトリックと人生」（大修館書店）-ジョージ・レイコフ-●「レトリック論を学ぶ人のために」（世界思想社）-菅野盾樹-ウィトゲンシュタインをして「それは私に強いられたのである」と言わしめたレトリック・比喩の凄さを学ぶことができます。特に「比喩とは有限の認知的資源を拡張するための基本的な知的戦略であり、ここに＜比喩の創造性＞のしるしがある」という記述は創発の本質を捉えていると思います。63
●「暗黙知の次元」（ちくま学芸文庫）-マイケル・ポランニー -「私たちは言葉にできるより多くのことを知ることができる」暗黙知にも指向があり、どう私たちがその恩恵を受けているか学ぶことができます。●「オブジェクト指向のこころ」（丸善出版）-アラン・シャロウェイ--ジェームズ・R・トロット-デザインパターンをどう使うかではなく、問題を解決していく中で、結果としてデザインパターンになっていくという、GoFが本来伝えたかっただろう事柄を丁寧に説明してくれます。64
謝辞資料をつくるにあたり多数の方に意見やアドバイス頂きました。ありがとうございます。@sugimoto_kei@spring_kuma@tunemage@smori1983@tokudiro@kazuhito_m65
ほんとの終わり自分も良きプログラミングとは？と日々、悪戦苦闘の毎日です。少しでもご意見頂ければ幸いです。今後ともよろしくお願いします<(_ _)>Twitter: @kawakawa66
kawakawa
hygradme
niftycorp
orgachem
ufried
murachiakira
fedepaol
lmi
optimisuke
nagix
tkikuchi1002
bun913
takesection
chriscoyier
gr2m
caitiem20
jonyablonski
deanohume
sferik
tanoku
cassininazir
csswizardry
rocio
jmmastey
zakiyama