iwatam's server guestbook

編集や削除のご要望がありましたら個別にやります。遠慮なくおっしゃって下さい。

「役割」と「役柄」、2つの特徴を端的に表す良い対比だと思います。
なお、「役柄」という言葉を「演劇で役者が演ずる役の種類」という意味にとった時の話です。(辞書を引くと別の意味もあったので)

　今まで漠然とマンチキン批判→なりきり重視のような流れを想像していたので、こちらのサイトの説明で目からうろこが落ちました。
　TRPGは初プレイが全員初心者、見事失敗で終わり。羨みながらリプレイ読みつつ縁遠くなるも、心の隅に残り続けておりました。１５年ほど昔のことです。
　MORPGは未プレイでしたので、実情はまったく知らないものの「面白そうだけど、金や時間がなぁ」といった感じでした。
実情は「ゲームプレイ」に非ずとしたら、「コミュニケーションツール」でしょうか？

　残念ながら、現在のMMORPGは「チャット付きドラクエ」という言葉がいちばん当てはまります。ゲームの内容は普通のコンピュータRPGとほとんど変わらず、ただ多人数でできるというだけです。ゲーム性に期待したらおそらく期待外れに終わるでしょう。
　それでもこんなに人気が出るのがコミニュケーションの楽しさでしょう。実際楽しいです。時間は非常にたくさん食い潰しますが、その間他の遊びはできない(くらいにハマる)ので、時間単価で見るとそんなに高くはありません。ただ常時接続でないと事実上やってられません。
　チャットソフトとして見るとなかなか巧妙なつくりをしています。文字だけのチャットと違ってアバター(キャラ)がいるから臨場感が出ますし、話がなくなった時にとりあえず暇潰し(ゲーム)もできます。チャット仲間がいない時でもやる事(経験値上げ)があるので困りませんし、偶然の出会いで知り合いが増えることもあります。本当は「チャット付きドラクエ」ではなく「ドラクエ付きチャット」なのかもしれません。

読ませていただいております。
私は、機械屋なので、プログラムのことはあまりよく分かりません、ただ、古代の遺物のリレーシーケンスは読めます。
UML、ですか、何のことか分かりませんが、
多分、我々機械屋でも、非常に図面において、製図法にうるさい人がいます。
ただ、図面はある機能を満たすために、みなに分かるように書くためのものであるからして、厳格に書かねばならぬという理由はすごく分かります。
しかし、えてして、このことにあまりにもこだわる人の中には、目的である、機能を十分満足する、ということ忘れている人がいます。本当に大事なのはその思想なんです。私は、仏教徒ですが、わりと皆本当に大事なことを忘れているのではないかと思ってます。教典に書いてあるのは文字です。そういう意味では機会の図面はよくできてると思います。
最後に、とても興味深く読ませていただいております、今後もご活躍を期待しております。

いわゆる「道具に使われる」というところでしょうか。図面も文章も(UMLも)「人に伝える」というのが目的ですから、わかりやすく書くのを目標にすべきですね。ある程度までは「わかりやすく書く」イコール「正しく書く」ですが、「正しく」には際限がないので、そのうち必要限度を越してしまいます。何事も目標を見定めて必要十分を心がけよう、というところでしょうか。
宗教の話が出たので、私の宗教のスタンスも書いておきます。私はまともな宗教ならどれも(もちろん仏教も含めて)いい事を言っているので、どれも等しく学びたいと思っております。でも仏教はキリスト教などに比べてなかなか難しくて……いまだにきちんと思想を理解できていません。
最後に、あまり更新頻度は高くありませんが、ぼちぼち更新しますのでよろしくお願いします。

お誉めの言葉大変嬉しく思います。
ところで、UMLからのコード自動生成についてですが、否定するのには2つの理由があります。
　第一は、UMLでモデル化するのは対象とする世界であり、プログラムそのものではないからです。コード自動生成を使うと、どうしても「コードにするためのモデル」になってしまいます。コードの事は考えないでモデルを書かないといけないのですから、そこからコードが出来てしまってはおかしいのです。
　第二に、プログラムコードというのは決して書きにくいものではないということです。VBなどは論外ですが、C++やJAVAやLispなどのまともな言語ならば、プログラムを書くのならばUMLで書くよりずっと書きやすいはずです。
　ちょっときつい言い方をすると、Javaですらプログラムが書けない人はUMLでもやっぱり書くことはできないだろうということです。プログラムを作りたいならプログラムの作り方を勉強しなくてはなりません。そしてそれはUMLやモデリングとはまた別物です。それを素人に勘違いさせる「コード自動生成」という言葉はまさにタイトル通りの「落し穴」だと思います。
　「コード自動生成」ではなく、UMLという言語からマシンコードへのコンパイラだと思っていただければわかると思います。JavaがUMLになっただけでは、結局のところ何も変わらないのです。

回答ありがとうございました。

>否定するのには2つの理由があります。
2つともおっしゃる通りだと思います。
しかし、できれば、UMLの一つ（実際は複数図）のメンテナンスが魅力です。

>JavaがUMLになっただけでは、結局のところ何も変わらないのです。
一次元的（コード）なものが２次元的（図）になっていると思うのですが…。

あと、「オブジェクト指向とはクラス・継承・多態性だ」は間違っていると切り捨てていますが、なぜ間違っているのかを教えてもらえますか？
ちなみに、私は、間違っていないと思うのですが…。

「オブジェクト指向にはクラス・継承・多態性がある」というのは間違っていません。「オブジェクト指向とはクラス・継承・多態性だ」というのは間違っています。継承というのは道具であって本質ではないということです。
　オブジェクト指向の本質は世界のモデル化とにあり、これがないものはオブジェクト指向とは呼べません。しかし、継承がなくても立派にオブジェクト指向になります。だから「オブジェクト指向とは継承である」とは言えないわけです。（多態性も同様です）
　オブジェクト指向の本質が継承にあると勘違いしてしまうと、「継承はした方がいい/しなくてはならない」と間違って解釈してしまいます。継承はただの道具です。使いこなすのはいいですが道具に使われてしまってはいけません。必要な所にだけ使い、必要のない所には使わなければいいのです。
　余談になりますが、道具と本質を見間違えるのはプログラマの悪い癖です。何をするかではなく、何であるかを見極めなくてはならないというのもメッセージの一つです。

JavaとUMLでは、１次元か２次元かという違いがありますが、１次元か２次元かという違いしかありません。本来は「プログラム」と「対象世界」という、もっと本質的な違いがあるはずなのです。
　世の中には２次元で記述するプログラミング言語もいくつか存在します。しかしそれはあまり流行っていません。その理由は、たいして便利ではないからです。マウスという入力効率の悪いデバイスが必須になってしまうというのも欠点の一つです。
　実際のところ、UMLのコード自動生成というのはここで強く非難するほど悪いものではありません。便利な道具であり、うまく生かせば手間を大幅に省くことができます。しかしそれでも敢えて非難するのは、そこに目を向けてしまうと本質を見失ってしまうからです。
　UMLというのは、Javaを２次元にしたという程度のちっぽけなものではなく、もっともっとすごいものなのです。それを理解した後で使うのならいいと思うのですが、その頃にはコード自動生成は本質ではなく、あると便利だがなくてもかまわない、と思うでしょう。

『本質を見極める』ですね！
ご指導、ありがとうございました。

しかし、『本質を見極める』は、難しい...。
すなわち、オブジェクト指向は難しい...。

iwatam's serverのゲストブック 過去ログ

iwatam's serverのゲストブック過去ログ