Object感覚の学びにくさの原因
Smalltalk の学びにくさの原因 のモジリ。内容もきっとかぶるでしょうね。 -戯
経緯。 プロトタイプベース・オブジェクト指向 の、
>なにかメッセージ送信 に関する抽象的、比喩的なもので済まされてしまっているのが問題なんでしょうか。どうしたらもっと分かりやすくなりますかね。--sumim
を請けて書き始めたつもりなので、ページ名は「…わかりにくさ」のほうが良かったか?とも
思わないでもないが、これって一度わかってしまえば(自転車 と同じ(?)で)以後ずっとわかる事
だろうと思うので、問題は「わかり始め」、つまり学びの段階に有るんだろうなと想像して、
やっぱり「…学びにくさ」のままにした。 -戯
Object感覚 (さっき考えた造語…だよね?それともガイシュツ?)ってのは、やっぱり何かが有るんだと思います。
個人的にはストンと腑に落ちた記憶しか無いのですが、落ちなかった人も世の中には一杯居るようなんで、
学びにくさ(の有無とか…)について心をめぐらしたほうが良いのかなと。 -戯
オブジェクト感覚 。皆さん、GUI寄り、ドロー系ツール寄りの思考ですね。--sumim
Object という概念は Smalltalk を学び始めた 17-8 年前ですが、たぶんこんなんやろうという“感覚”は HyperCard からですね。でも、これは Object 感覚というにはいかにも陳腐。ここ数年でまた Smalltalk やりはじめて、オブジェクト再勉強になったわけですが、やはりピンと来たのは morph をいじりはじめてから。私もどうやら、GUiやドロー系ツール寄りの思考から入っているようです。ってか、まだ分かっていないのかも(爆--sumim
CADやGraphic分野のLocal用語としてのObjectも有るんで、まぁ…(^^;
目で見えることそのものは、Object感覚(の少なくともとっかかり)としてはそう外してないと思ってます。
目に限ろうと殊更に(間違った)努力をしない限り、良いんじゃないでしょうか?
ちなむと俺は触覚とかも有りです。ガキのころ粘土遊びが好きだったせいか、頭の中で
妙な塊がくっついたり分かれたり変形したりする感じが有り。うねうねー -戯
オブジェクト感覚は、感覚なのだから、それ自体を学ぶものなのではないと思う。少なくとも私の経験では、学んだ物事を統括するために必要になっていたものであって(少なくとも、感覚とはそういうものだと思う)、感覚そのものを学んだという経験はないように思う。いつも悩むのは、どうやってそれに気付いてもらうかであったりする。--CUE ←ダブルハイフン を忘れてたぜ。
ぬ、そういやそうか。すると「Object感覚の体得しにくさの原因」とかのほうが良かったべか? --戯
「気付いてもらうか」かぁ。そういやそれはこっちもリアルタイムで感じているなあ。
気付いてくれないと一番(立場という意味でも)ヤバイような人ほど、頑迷だったりさぁ(T_T) -戯
Objectがプログラマどころかエンドユーザーにまで直接「見える」ようなシステムを扱っていまして。
こういうのは、本当ならオブジェクト感覚がビンビンくるような作りに仕上げないと
駄目 (そうしないとメリットを活かせない)だと思うんだが、
頑迷な(笑)人らは逆にそれを懸命に隠そうとするんだよね。
自分がわかってないから、あれを見せるとエンドユーザーも混乱する、と思い込んでいるんだろうな…鬱…
きっと彼ら(の大脳)は、子供のころブロック遊びもしたことが無いんだろうな…
下の とからみますが、たしか、ドン・ノーマンだったか「大事なのはメタファではなくてモデル」というようなことを言っていたのを思い出します。モデル自体を隠蔽してしまうメタファ(VC)はだめだなと。そうか。ところが、世の中には VC ががんばるソフトを書いちゃう(書けちゃう)傾向が強くあって、M の存在意義を危うくなる、と。そして、オブジェクト感覚はどんどん失われていくのですね。--sumim
では、他の感覚が体得しやすいかというと、それもダウト。
意識・無意識というものに対して多くの誤解があるように、感覚に対しても多くの誤解が見受けられるように少なくとも私には思われる。
例えば、私が関わったある人は、感覚と感情を区別しなかった。また、多くの人は、直感と感覚を混同したりする。 --CUE
学ぶといえば、こんな頁発見 -戯 > 芸術的直感力 ( これ自体も セレンディピティ なのか?)
外から来るものと内から湧くものとを正しく区別すると、「さみしい」と感じるんでしょうね。
同一だと思い込めば仲間が無数にいる錯覚に浸れる。
Object感覚
学ぶことを教える
ひとつ気になるのが、世間一般における クラスベース・オブジェクト指向 の教育が、
こっちの邪魔をしてるんじゃないか?という仮説。
彼ら(教育者)は、Objectを教えるんだけど、それはさっさとやめちゃって、さっさとClassの説明に行っちゃう…のでは?
彼ら(教育者)は、Objectを重んじろ、と教える機会を少なくしてしまっている…のでは?
人はコーディング中心主義(^^;に流れがちだから、クラスベース・オブジェクト指向 言語におけるコーディングの対象であるクラスばかり注視して、その結果生まれて存在するObjectを深く考えてくれてない…のでは?
私が自分で教えるのが面倒(もしくはそれが叶わない)なとき薦める「Smalltalk Idiom 」では、オブジェクトメモリとバイトコード、リテラルの話(^_^;)から始められています。その後はクラス−インスタンスの関係を学ぼうという流れに。「サクサク Smalltalk (The Art and Science of Smalltalk )」ではありがちなパターンで、さっとオブジェクトやメッセージングに触れて、すぐに「オブジェクトの定義と生成」に移っていますね。Smalltalk 教本は悪の枢軸?(笑)--sumim
職場に置いたままなので確認できずうろ覚えですが、“ピンソン本 ”では構造化パラダイムとオブジェクト思考パラダイムの比較からはじめていたような…。これは変わり種でおもしろいのですが、結局はコーディング中心主義の流れを汲んでいるので Object 感覚からはほど遠いかな、と。梅村本とアスキー刊ソフトカバーは、あれらを読んで Smalltalk が何たるかがわかったという記憶がないというトラウマがあるので探して開いて調べる気がしないという罠(^_^;)。Smalltalk 本ではないけど、かなり意識している石塚圭樹著の「オブジェクト指向プログラミング 」でも、いきなし「オブジェクト/メッセージ/クラス 」ときちゃってますな。--sumim
もらったままきちんと目を通していないのがばれちゃうけど、バスケの「Newtonではじめるプログラミング 」ではどうなっているか改めて興味深いところ、ではある。記憶がたしかならクラスの説明は余談程度だったはず。当たり前、っちゃあ当たり前。--sumim
NewtonScript で思い出して、SELF のチュートリアル ではどういう説明になっているんだろうかなぁ…と思って調べみたら、オブジェクトとは…というくだりはとくになかった。で、いきなりスロットの説明からはじめていた(笑)。まあ、これもある意味、コーディング中心主義かな(^_^;)。ということで“こっち”にも敵はいたというメモ。--sumim
個人体験(妄想?)ですが、ちょうど(?)Rubyを知る寸前の時期、「ゴミ袋」ってのが欲しくなったです。
(C++は言うに及ばず)JavaやDelphiの世界に疲れた(笑)頃で、要するに袋(=Object)が有り、
袋の中には名札(=変数名)が放り込んであり、名札からは(運命の赤い?)糸が伸びていて、
その糸は袋の口から出て延々のびて他の袋まで続いて…みたいな感じになっていれば、
要するにいいんじゃねーの?と思ってしまいまして。
#なんでゴミなのかは不明(藁
ちなみにメソッドのことは考えていませんでした(笑)
当時はメソッドObjectなんて便利な考え方も知りませんでしたし、
それ以前にメソッド(=実行)なんてものは"Object"指向にとっては二の次だと思っていた(いや今でもそう)し。 -戯
なお、上記の比喩が指し示す概念は、別に新しくもなんともありません。ええ(^^;;; JavaScript とか。
なるほど。戯さんにとっての object 感覚は Self の frame(ゴミ袋)− slot(名札)と相性がよさそうですね。slot が method となれるのは“二の次”で slot に object を期待してアクセスに行くと、slot に object がつながっていればそれを、そうでなければ method がこっそり起動してその返値としての object をさもそのスロットにつながっていたかのように返してくると。--sumim
>職場に置いたままなので確認できずうろ覚え
ピンソン本では、オブジェクト指向問題解決の直後に、クラスとクラスのインスタンスとしてのオブジェクトのはなしに移っています。梅村本は、object について6行(!)言及したすぐ後に、クラスとインスタンスの話をしています。メッセージなんかは後回しもいいとこです(^_^;)。アスキーの「Smalltalk 入門」は Pascal を引き合いに出して、データの抽象化の必要性を説いた後、アクターモデルをクッションにして object を説明しています。文章量はこの手の本の中では一番多くて丁寧なのですが、Smalltalk を学びたかった私にはクラスやメタクラスの説明より終わりまで読み進むのが苦痛だった記憶がまざまざと蘇りました(笑)。--sumim
>クラスの説明は余談程度だったはず
データ構造の歴史の話から入っていました。record がきて object と。オブジェクト指向については、メッセージ送信 、継承、データ隠蔽にならんでクラスの話が並んでいます。この章の最後はNewtonScript のオブジェクト指向度についての消極的な言及なのですが、これはもしかしたら私が普段 NewtonScript を Smalltalk と比べて、うだうだ言っていたのが悪影響を及ぼしてしまったのかもしれません(^_^;)。--sumim
オブジェクト指向を正しく(?)理解してもらうためには何が不要で何が必要か、という議論になると、世の中のほとんど全てのものがオブジェクト指向の対象となるが故に、どれもが不要でどれもが必要になってしまうという悪循環に陥ってしまう。思考そのものが再帰的であると気付いた時、つまり、物事には自己記述性があるのではないかと気付いた時にはじめて、全く新しい次元で物事を眺める事ができ、そして、それを再び形而下に投影しようと試みるものなのではないだろうか。例えば、Classは終端である必然性が全くないが(事実、Smalltalkに於いては終端ではない)、これを終端であると考える(卑近な言い方をすればC++流儀の)人は、やはりClassを最初に教えたがるものなのかもしれない。大抵の人は、終端を認識すれば、それが物事を支える根幹だと誤解してしまう:実際にはそれはある方向から見た時の極値でしかなく、別の角度から見ると単なる通過点でしかなかったりする。--CUE
> method がこっそり起動して
いや、起動を暗黙(自動)化するのも二の次です(^^;
例えばJavaScript みたいに後ろの括弧をつけてはじめて起動される、ってのが最近の好み。
引数を渡してあげてはじめて起動する、という感じかな。
ちなみに最近は更に、引数渡すのと起動とすら、分けたくなってしまいました。
Lispに負けないようにと思うと、それくらいの自由度が必要になるんで。六本松(岩田)がそうなる予定。
引数なしの素のメソッドObject、引数1つ渡したメソッドObject(のclone)、引数たくさん(全部)渡したメソッドObject(のclone)…
そして最後のものがCall可能になる、っていう感じ。
>引数1つ渡したメソッドObject(のclone)、引数たくさん(全部)渡した…
カリー化、ですか?--sumim
なんかそう呼ぶらしいですね>カリー。 どうやらそれです。
Objectに属性を少しづつ(急かされずに)与えるのが有りなら、関数にも引数を少しづつ与えるのが有りだろうなと。 -戯
なるほど。そういうふうに言われると理解できるような気がします。>カリー化 --sumim
ついでに言えば、メソッド というものが有るのも二の次だし(笑)。
データ(とそれらの繋がり)ばっかりでメソッドが無ければオブジェクト じゃないのでは?という声が聞こえてきそうですが、
俺にとってはオブジェクトたちは、そこに「ある」ことが大事であって、「動く」こと(手段とか)は後から考えりゃいいや、程度で。 -戯
ですから、言語なんぞに至っては三の次です(笑)。
はじめて作ってみた言語「ばぶばぶ」がPostScript(の拡張)を採用したのは、PostScript自体がエレガントであるせいも
ありますが、なによりも「実装が楽」な言語、つまり「言語作りなんぞに時間食わずに済む(笑)」から、です。
オブジェクト がそこにある事が可能になるための必要最低限の言語(のうち醜くないもの)、という位置付けです。
逆にいえば、オブジェクトモデル(ってのかな)はあのままにしといて、言語のほうは
(モデルにとって足枷とならないなら)どんな言語に交換されてもいいんです。
実際PostScript自体が使い易いとは自分もあまり思いませんでした(^^;が、
じゃあ気力と時間が出来たときに別の言語を作ればいいや、くらいな捉え方。
作りたいのはオブジェクトであり、その手段としてのオブジェクトを弄る道具であり、
その1形態としての言語はあくまで手段、なんです。
そういや、藤原氏のCプログラミング診断室 のどこか(どこだっけな)で見かけたんですが、
そこに「C言語はデータをいじるための道具でしかないんだ」みたいなことが書いてありました。
余談だが氏に「OOP診断室」は書いて欲しいかも。どうやら判ってるっぽいから。 -戯
ちなみに、そんな俺から見て、Rubyは(後から考えればSmalltalkもですが)ショッキングでした。
上記の(素朴?な)世界観と一見すごく近いRubyですが、実際に"動く"言語となるためには、
1つの大きな転換が生じている(と、俺の視点から見れば見える)んです。
それは何かというと、「言語(ソース)で書かれる部分は、(殆ど)全てが「動作」である」という点です。
他の言語にある宣言だのなんだのの類のかなり多くが、Rubyではそれ自体がメソッド呼び出しであったりします。
属性 を作るメソッド (笑)とか、そういう奴らです。
実行というものに出来るだけ背を向けよう向けようとしたら、すごく似ているはずのお隣さん(?)が
実は実行だらけだった、という…(^^;;;;
で、毒を食らわばディスクまで(謎)というわけで、PostScriptです。あれは、書かれる単語は「オペレータ」なんですよね。
ええ。「操作」。PostScriptもまた「何でも動作」で記述される言語の一派でございます。はい。あーあ…
Objectってのは、(Classが有るかどうかはさておき)似たようなObjectが「複数」有ることを
(設計に反する時以外には)認める、てのが大事だと思います。
で、windowsとかでよく見かける(笑)やりかたに、アプリの同時複数起動を禁じるってのがありますが、
あれは凄く反Object指向的だと思います。
Singletonでないと絶対に不味いアプリが全く無いとは言いませんが、さほど多くもないはず。
殆どのアプリは、同時起動を禁じないのが似合っているはずだと思う。
あるいはアプリ内のMDIでも同じことで、同種ないしは同一のModelに対して
複数のViewを同時に持てないってのは、ユーザビリティにとってかなり面倒です。
たとえばあるメールソフトでは、複数のメールを同時に見(比べ)るべく
View窓を複数同時に表示することが出来ない。ぉぃぉぃ!
こういうのをSingletonであることの妥当性をきっちり吟味せずに安易に実装してしまう人は、
Object感覚が欠けてるんだろうな、と思っています。
彼らは「メールを読むという作業」とは捉えることが出来ても、「メールというもの」とは捉えられていないんじゃないかと。
ただこれ、よくあるアプリ開発環境(IDE)にも責任は有るとは思います。
DelphiやVBは、デフォルトでは1つの窓のInstanceは1つきり、というやり方だけを支援しているっぽいので。
ちょっとコーディングすればそれは克服出来るとは言え… -戯
クラス(プロトタイプでも同じことだが)の命名を他人がしてるのを見るとき、しばしば以下のような不安を感じることが有ります。
それは、その人が次のような単語を含んだクラス名を作ってるとき。
Manager(マネージャ、管理)
Information(インフォーメーション、情報)
これらが出てくると、俺はその人のオブジェクト感覚に不安を感じてしまう…。
(大抵の場合は)不適切な命名じゃないのか?と思うので。 -戯
管理って何を管理するんだよ?
管理「される」のがこれから作ろうとしてるオブジェクト(のクラス)なんじゃないの?だとすれば管理されるのは(それがプログラムである以上)自明なんだから、わざわざ管理なんて単語を入れる意味ないじゃん?
あるいは作ろうとしてるクラスとは別に管理クラスを作るの?それならそれでいいが、「どういう意味で」管理するのか、が「管理」と言うだけでは見えてこないのが痛い。
オブジェクトはもともと情報の塊だから、わざわざ情報だなんて言う意味ないじゃん?
こういう命名をする人って、オブジェクト(やクラス)って元々どういうものなのかを理解してないんじゃないか?と思ってます。
オブジェクトは元々ManageやInfoという概念を含んでいるので、わざわざそれを命名に追加しても、白い白馬みたいなものでしかないはず。
#余談。あるいは理解してても命名に無頓着な人か。もちろん命名に無頓着な人も凄く困ります。
なんというか、管理するとか情報を持つとかいう事と、その対象とが、別々にしか考えられていないのかな、と。
管理される情報「そのもの」がオブジェクトになる、という感覚が、持ててないのかなと。
似たような話ですが、気になる単語に機能ってのが有ります。
機能のことを考えるの自体は悪いことじゃないんですが、そればっかりを考えて、
「どのオブジェクト(インスタンス)の」機能なのか、ってのを考えるのを忘れる人が、時たま居るようです。
更に言えば、その機能がオブジェクト(インスタンス)に属するか否か、を考え損ねる人が…
症例:分析or設計時に、あるメソッドを、インスタンスメソッドにすべきか、クラスメソッドにすべきか、を、なかなか(きちんと)判断できない。
逆にいえば、これを判断できない状況になったら、それは「不味い(少なくとも自分には御し切れない)設計」になってしまっている証拠だったりはするまいか?
重症例:
上記のきちんと判断できない状態の自分を、言い訳するために、こともあろうに、こう言う。
「それがクラスメソッドかインスタンスメソッドかを決める、などという実装の詳細は、今決めるべきことではない」と。 -戯
おいおい。かなーり最初にやるべきことだと思うんだがな。というか、最初に自ずと気付くもんじゃないのかな?
余談症例:
最近よく言われる「ユースケース駆動(の開発)」って、不安です。
これだけOOPを前提とする言語と開発方法論に囲まれて暮らしているのに、
わざわざオブジェクト感覚 を発動するタイミングを遅らせるなんて…
「客」はそんなにオブジェクト感覚 から遠い存在なんだろうか?
ユースケース(=機能)にしか関心がいかないものなんだろうか?
オブジェクト「で」説明したら、常にチンプンカンプンだとしか思ってもらえないものなんだろか?
リアルワールドではこれだけオブジェクト(指し示せる「もの」)に囲まれて生きてるのにさ?
「部品」を理解してる工場長さんが、そのチャチなサブセットである「部品オブジェクト」を、理解できないってのかぃ?
隠蔽 やカプセル化 やグループ化という語を単独で使ってしまうと、
それは別にオブジェクト指向の用語とは限らない。
言い換えれば、ある人がある時、隠蔽 やカプセル化 という言葉を脳裏に浮かべたからといって、
それは彼がオブジェクト指向の入り口に到達しているという証には、ならない(かも知れない)。
というのも、その語だけでは、ものごとを「どこに」隠蔽(やカプセル化)するか、とは一言も言っていないからである。
それらは実際、オブジェクト以外のものに対しても、出来てしまう。
例えば名前空間。ためしに、オブジェクト指向は搭載していないが名前空間を搭載している言語
(やその言語上でライブラリ的に実現された何か:つまるところ環境)を考えよう。
そういう言語を使うと、ものごとを「名前空間の中に」隠蔽やカプセル化できてしまう。
やり方は簡単だ。伝統的な意味でのグローバル変数や関数を、
名前空間の中に置けば(そしてグローバル空間から削除すれば)いいのだ。
それだけ。オブジェクトの出番は何処にも無い。
もちろんそれは何ら「おかしい」概念ではない。
たまたまオブジェクトと名前空間が、どっちもそれらの機能を持っている、という類似性が有るだけ。
当然ながら名前空間とオブジェクトは(実装はともかく意味的には)別物だ。
にも関わらず(ぉ)、名前空間にだって、出来てしまうのだ。
変数や手続きのグループ化や隠蔽が!!
「この変数はこの手続きだけで触れるようにしよう(by川合氏)」ということが!!
#ついでにいえば、変更への強さだとかその他多くの諸々のことが!!
で、OOエンジニアの輪! 川合史朗 さんの巻 を見ていて思ったのだが、というか世間の大勢の人らも又
ここでの氏と同じようなことを言うのが不愉快(?)なのだが、
#正確にいえば、氏はあくまで「はじまり」だと言っているだけで、今もそう思ってるわけじゃなかろうが。
「どこに」隠蔽するのか、という議論を、ついに考えない/教えないままに話を終えてしまう人が、どうにも多いようで…(T_T)
それを語らなければ(区別しなければ)、何時まで経っても、オブジェクト指向の話をしたことにはならないってのに… -戯
オブジェクトがなくともオブジェクト指向(っぽいことや、そのメリットの享受)はできるが、オブジェクト指向を語るなら“オブジェクト”と呼べるものをきちんと想定しておけ、ということでしょうか。--sumim
>オブジェクトがなくともオブジェクト指向(っぽいことや、そのメリットの享受)は
いや。あるメリットについて、そのメリットが「オブジェクト指向に固有の」メリットなのかどうか、を
考えたほうが良い場合が有るようだぞという話です。
だから、「オブジェクト指向のメリットの享受」か「否」かという問題なんです。 -戯
僕は逆に抽象データ型 とオブジェクト指向の決定的な違い、というものがよく分からないでいるんですよね。--SHIMADA
オブジェクト指向に固有のメリットは?
[ruby-list:69](大昔だな) のmatz氏の発言
なるほど。お手軽感の有無、ね。
OOPにはそれが無い、という「(世間の)誤解」は、確かに未だに消えてないような印象を受ける。
出版社としては、誤解されたままのほうが「売れる文」を作りやすいかも知れぬ:-P
未だにオブジェクト指向をテーマ(?)に据えてどうのこうのとか、やってるもんなあ。
#しかもその内容もしばしば誤解だし。たとえば、例の三大要素は「オブジェクト指向の」要素だ、という誤解を更に広めてる。
このページを編集 (19918 bytes)
以下の 4 ページから参照されています。
This page has been visited 10635 times.