Object感覚の学びにくさの原因
Smalltalk の学びにくさの原因 のモジリ。内容もきっとかぶるでしょうね。 -戯プロトタイプベース・オブジェクト指向 の、＞なにかメッセージ送信 に関する抽象的、比喩的なもので済まされてしまっているのが問題なんでしょうか。どうしたらもっと分かりやすくなりますかね。--sumim 自転車 と同じ(?)で)以後ずっとわかる事オブジェクト感覚 。皆さん、ＧＵＩ寄り、ドロー系ツール寄りの思考ですね。--sumimObject という概念は Smalltalk を学び始めた 17-8 年前ですが、たぶんこんなんやろうという“感覚”は HyperCard からですね。でも、これは Object 感覚というにはいかにも陳腐。ここ数年でまた Smalltalk やりはじめて、オブジェクト再勉強になったわけですが、やはりピンと来たのは morph をいじりはじめてから。私もどうやら、ＧＵｉやドロー系ツール寄りの思考から入っているようです。ってか、まだ分かっていないのかも(爆--sumim CUE ←ダブルハイフン を忘れてたぜ。下の とからみますが、たしか、ドン・ノーマンだったか「大事なのはメタファではなくてモデル」というようなことを言っていたのを思い出します。モデル自体を隠蔽してしまうメタファ（VC）はだめだなと。そうか。ところが、世の中には VC ががんばるソフトを書いちゃう（書けちゃう）傾向が強くあって、M の存在意義を危うくなる、と。そして、オブジェクト感覚はどんどん失われていくのですね。--sumimCUE 芸術的直感力 ( これ自体も セレンディピティ なのか？)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 JavaScript とか。なるほど。戯さんにとっての object 感覚は Self の frame（ゴミ袋）− slot（名札）と相性がよさそうですね。slot が method となれるのは“二の次”で slot に object を期待してアクセスに行くと、slot に object がつながっていればそれを、そうでなければ method がこっそり起動してその返値としての object をさもそのスロットにつながっていたかのように返してくると。--sumim ＞職場に置いたままなので確認できずうろ覚え ピンソン本では、オブジェクト指向問題解決の直後に、クラスとクラスのインスタンスとしてのオブジェクトのはなしに移っています。梅村本は、object について６行(!)言及したすぐ後に、クラスとインスタンスの話をしています。メッセージなんかは後回しもいいとこです(^_^;)。アスキーの「Smalltalk 入門」は Pascal を引き合いに出して、データの抽象化の必要性を説いた後、アクターモデルをクッションにして object を説明しています。文章量はこの手の本の中では一番多くて丁寧なのですが、Smalltalk を学びたかった私にはクラスやメタクラスの説明より終わりまで読み進むのが苦痛だった記憶がまざまざと蘇りました(笑)。--sumim ＞クラスの説明は余談程度だったはず データ構造の歴史の話から入っていました。record がきて object と。オブジェクト指向については、メッセージ送信 、継承、データ隠蔽にならんでクラスの話が並んでいます。この章の最後はNewtonScript のオブジェクト指向度についての消極的な言及なのですが、これはもしかしたら私が普段 NewtonScript を Smalltalk と比べて、うだうだ言っていたのが悪影響を及ぼしてしまったのかもしれません(^_^;)。--sumim CUE ＞ method がこっそり起動して JavaScript みたいに後ろの括弧をつけてはじめて起動される、ってのが最近の好み。＞引数1つ渡したメソッドObject(のclone)、引数たくさん(全部)渡した… なるほど。そういうふうに言われると理解できるような気がします。＞カリー化 --sumim メソッド というものが有るのも二の次だし(笑)。オブジェクト じゃないのでは？という声が聞こえてきそうですが、オブジェクト がそこにある事が可能になるための必要最低限の言語(のうち醜くないもの)、という位置付けです。Ｃプログラミング診断室 のどこか(どこだっけな)で見かけたんですが、属性 メソッド (笑)とか、そういう奴らです。
Manager(マネージャ、管理)
Information(インフォーメーション、情報)
管理って何を管理するんだよ？
管理「される」のがこれから作ろうとしてるオブジェクト(のクラス)なんじゃないの？だとすれば管理されるのは(それがプログラムである以上)自明なんだから、わざわざ管理なんて単語を入れる意味ないじゃん？
あるいは作ろうとしてるクラスとは別に管理クラスを作るの？それならそれでいいが、「どういう意味で」管理するのか、が「管理」と言うだけでは見えてこないのが痛い。
オブジェクトはもともと情報の塊だから、わざわざ情報だなんて言う意味ないじゃん？
オブジェクト感覚 を発動するタイミングを遅らせるなんて…オブジェクト感覚 から遠い存在なんだろうか？隠蔽 やカプセル化 やグループ化という語を単独で使ってしまうと、隠蔽 やカプセル化 という言葉を脳裏に浮かべたからといって、ＯＯエンジニアの輪！ 川合史朗 さんの巻 を見ていて思ったのだが、というか世間の大勢の人らも又オブジェクトがなくともオブジェクト指向（っぽいことや、そのメリットの享受）はできるが、オブジェクト指向を語るなら“オブジェクト”と呼べるものをきちんと想定しておけ、ということでしょうか。--sumim 僕は逆に抽象データ型 とオブジェクト指向の決定的な違い、というものがよく分からないでいるんですよね。--SHIMADA オブジェクト指向に固有のメリットは？ [ruby-list:69](大昔だな) のmatz氏の発言 このページを編集 (19918 bytes)
以下の 4 ページから参照されています。
This page has been visited 10637 times.
