- 1 名前：デフォルトの名無しさん [03/12/08 21:30]
- オブジェクトを複製または継承によって生成を行う言語，
プロトタイプベース・オブジェクト指向言語について語りましょうよ．
関連リンク >>2
- 220 名前：デフォルトの名無しさん mailto:sage [04/01/30 02:44]
- >>214
今時C++つついてる奴も結構趣味に走ってると思うが。特にtemplate方面。
- 221 名前：デフォルトの名無しさん mailto:sage [04/01/30 09:28]
- >>220
趣味だけど実益兼ねているでしょ、アレは。
boost、Loki あたりはウチの会社じゃ普通に使ってるし。
- 222 名前：デフォルトの名無しさん mailto:sage [04/01/30 09:43]
- ベンチャーかな？
あんなの使ったら強制デスマーチですが何か？
- 223 名前：デフォルトの名無しさん mailto:sage [04/01/30 10:09]
- 一応、大手って言われてます。
- 224 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:06]
- Lokiなんか使うなとかは低レベルなやつが言ってるだけだろ。
会社じゃ低レベルな奴が足引っ張るみたいだな。
勘弁してほしい。
- 225 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:29]
- >>224
> 会社じゃ低レベルな奴が足引っ張るみたいだな。
むしろ自分が使いたい言語の利点をきちんと説得できないのを恥じるべし
- 226 名前：デフォルトの名無しさん mailto:sage [04/01/30 16:44]
- >>222
それはいくらなんでもスキル低すぎだろ。
- 227 名前：デフォルトの名無しさん mailto:sage [04/01/30 19:51]
- >>225
いや俺会社員じゃないし。
話し聞いてると会社がそういうとこらしいのが嫌だなってこと。
- 228 名前：デフォルトの名無しさん mailto:sage [04/01/30 19:53]
- C++の話題はスレ違いです
- 229 名前：デフォルトの名無しさん mailto:sage [04/01/31 00:41]
- プロトタイプベース言語で開発するときは、分析モデルの中にクラスは登場するの?
実装モデルには当然クラスは出てこないんだろうけど
基本的にオブジェクトの発見がメインで、ドメインモデルでもクラスは見つけないのかな。
- 230 名前：デフォルトの名無しさん mailto:sage [04/01/31 00:43]
- プロトタイプベース言語で大規模プログラミングの例はありますか？
- 231 名前：デフォルトの名無しさん mailto:sage [04/01/31 01:43]
- すれ違い覚悟で書くけど、
www.radiumsoftware.com/0312.html#031250
こういうのどうよ？
クラスの意味論？とかの観点を語れそうじゃね？
- 232 名前：デフォルトの名無しさん mailto:sage [04/01/31 04:48]
- 訂正。後半のXenの事ね。
www.radiumsoftware.com/0312.html#031205
- 233 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:22]
- プロトタイプベースのオブジェクト指向も、ある程度妥協してるよな。
prototypeなんてのを持ち込むくらいなら、素直にclassを認めた方がいいかなと
思ったり。
- 234 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:38]
- それをクラスと呼んだ瞬間に、色々余計な概念が持ち込まれるのが嫌だったんでしょう。
クラスなんて本質的に必要なものじゃないし。
Ruby みたいに、クラスのインスタンスだけど後からあれこれ出来ますってのが、厨避け
には良かったのかもしれない。
- 235 名前：デフォルトの名無しさん mailto:sage [04/01/31 20:49]
- >>233
プロトタイプはクラスとしても使える、という話じゃなくて？
- 236 名前：デフォルトの名無しさん mailto:sage [04/01/31 21:37]
- いや、本来は継承元のメンバも全て自分が持ってるべきでしょ。
それをメモリ効率とかの観点から、prototypeを導入したわけだ。
それなら雛型としてのclassを認めた方が、むしろシンプルかなと思った。
- 237 名前：デフォルトの名無しさん mailto:sage [04/01/31 21:50]
- >>236
1,2 行目と 3 行目の繋がりが良く分からないな。「classを認める」というのは具体的に何を
イメージされてるのですか。
- 238 名前：デフォルトの名無しさん mailto:sage [04/01/31 22:18]
- >>237
プロトタイプベースでも多くの場合、クラスとインスタンスの関係に近い
オブジェクトをいろいろ用意して使うことになるよね。
それは、暗黙のうちにクラス的なオブジェクトとインスタンス的なオブジェクトを
使い分けてるってことで、なら割り切って、他にも利点のあるクラスベースの方が
いいんじゃないかなぁと思った。
なんというか、プロトタイプは中途半端な気がする。やるならプロトタイプも
なくしてしまえ! と。(w
あー思いつきで適当に書きすぎた。
- 239 名前：デフォルトの名無しさん mailto:sage [04/02/01 00:17]
- class なんて特別なものをなくして、 simple にしたんだと思うけどなぁ…
class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
ところで prototype をなくす利点ってどのへん？
派生先が派生元の変更に影響されなくなることくらいかな…
- 240 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:09]
- "特別扱いな部分が少ない言語 == シンプル && 優れている" っていう意識があったけど、
よく使いそうな機能は言語のコアに最初から組み込んでおくべきなんだって考えの人も
居るみたいね。>>232 のリンク先の論文とか。
- 241 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:14]
- そういう見方もあるけど、
プログラム=データ構造+アルゴリズムという観点で見ると、
なにか重要な示唆が含まれているような気もする。
- 242 名前：デフォルトの名無しさん mailto:sage [04/02/01 01:34]
- >>238
>なら割り切って、他にも利点のあるクラスベース
ここはトレードオフなんだよね。割り切って切り捨てられてしまったものが
結構便利だったりする。対象領域によってはクラス化しない方がシンプルな
場合も多いだろうし。
- 243 名前：デフォルトの名無しさん mailto:sage [04/02/01 02:59]
- >>239
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
そんなのclassの実装次第でしょ。
- 244 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:22]
- >>243
それならそれを prototype と呼んでも良いわけだ。
よし、この FOO 言語のクラスは従来のクラスにあった制限を一切取っ払った実装にしよう。
ついでに名前も変えて prototype と呼ぼう。これで BAR 言語で出来なかったこんな事や
あんな事も出来るようになるぞ。
- 245 名前：デフォルトの名無しさん [04/02/01 03:26]
- 型＝インスタンス
ということ自体は全然構わないんだが、
グローバルにしたくないものをグローバルにする必要があったり
メソッドの追加が煩雑だったりするのがかなわん
実用上大問題だと思うんだがどうよ？
- 246 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:35]
- >>244
> ついでに名前も変えて prototype と呼ぼう。
そのFOO言語のclassがclassというよりむしろprototypeであることを
ちゃんと理由を付けて説明できるのならね。
- 247 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:36]
- >>245
> 型＝インスタンス
> ということ自体は全然構わないんだが、
誰がそんな事を言っているのですか？
このスレでは該当する者はいないようですが・・・
- 248 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:47]
- >>246
実装次第でどうとでもなるなら、名前付けにも意味は無いですよねって事なんだけど。
- 249 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:55]
- >>248
とりあえず>>94読め。
- 250 名前：デフォルトの名無しさん mailto:sage [04/02/01 03:58]
- >>249
それを読むべきなのは >>243 だろうね。クラスの制約の話をしていて、実装次第と
いう答えはどうかと。
- 251 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:11]
- >>250
おいおい、>>94に書いてあるのは、インスタンス生成機能をどこに配置するかという問題で、
それはクラスへの制約ではなくインスタンスへの制約なのだが。
クラスが一般のインスタンスと同様の機能を持つクラスベースOOPLだって存在するし、
そのOOPLでのクラスはプロトタイプではなく、あくまでクラスだ。
よってクラスへの制約は実装次第ということで間違ってはいない。
- 252 名前：デフォルトの名無しさん mailto:sage [04/02/01 04:25]
- >>251
クラスへの制約なんて話は今まで出てきてないけど、インスタンス生成に関する制約
って事かな。
だいたい、>>94 はインスタンス生成機能だけじゃなく、オブジェクトの分類にも
触れていると思うけど。その上で、モデリングの違いで使い分ければ良いとも読める。
- 253 名前：デフォルトの名無しさん mailto:sage [04/02/01 05:01]
- >インスタンス生成機能をどこに配置するかという問題で、
>それはクラスへの制約ではなくインスタンスへの制約なのだが。
ｽﾏｿ。ちゃんと読んでなかった。で、クラスへの制約って何?
- 254 名前：デフォルトの名無しさん mailto:sage [04/02/01 06:45]
- >>253
それは>>239に聞かないとわからん罠
- 255 名前：デフォルトの名無しさん mailto:sage [04/02/01 07:13]
- >>239 にはクラスへの制約なんて言葉は書いてない。>>251 の空想の中にしかない
概念なんだろうね。自分で参照したレスもちゃんと読んでないみたいだし。
でももう良いよ、終わりにしよう。説明するのも疲れた。
- 256 名前：94=249 mailto:sage [04/02/01 07:24]
- >>239より引用
> class にしかできないこととか、 class にはできないこととか、そういう制約もなくなるし。
これがクラスへの制約でなくて何だと言うのだろうか・・・
- 257 名前：デフォルトの名無しさん mailto:sage [04/02/01 08:00]
- なんか頭の痛くなる会話してるな
>>255
>でももう良いよ、終わりにしよう。説明するのも疲れた。
説明がちゃんとできてないし、話もお互い通じてないな
おまえら、ろくな定義もされてないあやふやな概念を
一方通行にただ垂れ流してるだけだ
それで余計に疲れるんだろ
- 258 名前：デフォルトの名無しさん mailto:sage [04/02/01 10:29]
- で、分析モデルにクラスは出るのか出ないのか?
- 259 名前：1 mailto:sage [04/02/01 11:18]
- >>132 SeRuby
はRubyでSelfライクを実現，ですが
こちらはJavaScriptライク
mput.dip.jp/?date=20030912
特異メソッド/クラス定義 凄い便利だよな．楽しいよな
Rubyが完全にプロトタイプベースだったら…
- 260 名前：239 mailto:sage [04/02/01 15:41]
- え〜と、説明不足だったかな、ごめん。
class にしかできないことっていうのは、 instance とか subclass の生成あたり。
あとは処理系の柔軟性のなさに応じて、 method や property の追加・削除とか、superclass 変更とか。
class にはできないことのほうは、確かに柔軟な言語にはないかも。
普通の object として複製したり、書き換えたり渡したりってあたりを想定してたけど。
充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
subclass 作ったり method 書き換えたりはしても、 class じゃない instance は作らないっていう。
で、これを簡潔にしたのが prototype-based OOP だと思う。
もう class なんて概念もいらなくなって、世界には object だけあればいい、っていう。
- 261 名前：デフォルトの名無しさん mailto:sage [04/02/01 16:46]
- >>260
> 充分に柔軟な処理系なら、全部の object を class にしちゃえば、最大限柔軟にできるよね。
整数とかはどうする？
整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
クラスとインスタンスの区別があったほうがずっとシンプルにならない？
クラスの有り無しは目的ではなくて手段にすぎないんだから、
「クラスを無くすには」「クラスを導入するには」ってのは
処理系実装以外のシチュエーションではナンセンスだと思う。
- 262 名前：238 mailto:sage [04/02/01 18:41]
- スレ伸びてるなぁ．びっくり．
>>239
classとobjectを区別しないprototypeでも，実際に使うと自然に
classとinstance的なものを考えるようになる．
だから，classとinstanceは本質的に違うものであって，それを
prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
> ところで prototype をなくす利点ってどのへん？
> 派生先が派生元の変更に影響されなくなることくらいかな…
これは結構大きい．派生元の影響を受けるから，自然にclass, instanceの
を区別する使い方をしてしまうんだと思う．
シンプル，という観点から見れば，prototypeすらないのが一番素直．
ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
そんな中で，prototype-basedは，やっぱりちょっと中途半端な気がする．
- 263 名前：デフォルトの名無しさん mailto:sage [04/02/01 19:16]
- >>262
プロトタイプすらないってどういうのを想像しているの？
オブジェクトの拡張はどうやってやるんでしょうか…
- 264 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:32]
- 丸ごとコピーして変更じゃねーの？
- 265 名前：デフォルトの名無しさん mailto:sage [04/02/01 20:39]
- >>261
> 整数をオブジェクトにして、かつ、ユーザによる拡張を可能にするんなら、
> クラスとインスタンスの区別があったほうがずっとシンプルにならない？
あんまり差が思いつかない…どんなとこが違いそう？
>>262
> だから，classとinstanceは本質的に違うものであって，それを
> prototype-basedな言語は無理矢理まとめてしまった…とも考えられる．
役割分担するにしても、厳格に分けないほうがやりやすいと思う。
それぞれの object を class とか instance って呼んでもいいけど、
いつでも役割交代させたり、一人二役させたりできる…っていう。
> シンプル，という観点から見れば，prototypeすらないのが一番素直．
> ある程度メモリ効率とかを気にして，classやprototypeが考案されたと．
効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
使う library 切り替えるときとか、関係する object 全部書き換えるのは大変だし。
それに、全部複製して持たせちゃうような method も、簡単に書けるよね。
どっちを default にするかの違いでしかないと思う。
両方用意するほうが親切だろうけど。
- 266 名前：263 mailto:sage [04/02/01 21:25]
- >>264 なるほど．
>>265
>効率もあるだろうけど、派生先に影響できることって、たまに便利だと思う。
たまにじゃなくて，ほとんどの場合影響して欲しいと思うけど．
- 267 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:38]
- そうかなぁ．継承関係はあっても，モノとしては全然関係ないobjectどうしが
影響し合うするのは良くないと思うけどなぁ．
- 268 名前：デフォルトの名無しさん mailto:sage [04/02/01 21:45]
- >>267
その、「良くないと思う」レベルが
classベースと、
prototypeベースと、
なんも無しと、
で違うだけだよ。
- 269 名前：デフォルトの名無しさん mailto:sage [04/02/01 22:02]
- >>268
影響し合うのはprototype-basedだけじゃない?
- 270 名前：263 mailto:sage [04/02/01 23:20]
- >>269
クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑
- 271 名前：デフォルトの名無しさん mailto:sage [04/02/02 09:20]
- >>270
> クラスの変更がそのインスタンスに影響与えなかったらうけるな(笑
そういう言語もアリだと思うけど。
instance creationした瞬間のclassがそのobjectのclassってことでしょ？
- 272 名前：デフォルトの名無しさん mailto:sage [04/02/02 17:59]
- 多くのクラスベースな言語では，実行時にクラス変更なんて出来ないし，
出来たとしても，>>271のようになるのが自然だと思う．
- 273 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:33]
- >>272
> 出来たとしても，>>271のようになるのが自然だと思う．
そんなこたーない。普通はクラスを変更したらインスタンスも変更される。
- 274 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:47]
- 普通はって、普通は実行時にクラスを変えられないような。
- 275 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:52]
- >>274
普通はって、「出来たとしても」という条件を満たした上での「普通は」でしょ。
文脈からいって。
- 276 名前：デフォルトの名無しさん mailto:sage [04/02/03 00:56]
- 「普通は」が含まれている文章は、普通、普通でないことを言っている。
- 277 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:00]
- すみませんが、どなたかプロトタイプならではって例をﾋﾞｼっと出して利点
を説明してくれませんか？
- 278 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:06]
- >>275
それはそうなんだけど、普通はって言うほどサンプルが無い気がして。
メソッドサーチの時にクラスをルックアップするのが普通の実装だから、クラスを変更
したらインスタンスも変更されるでしょうって事かな。
- 279 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:24]
- それって「君の普通」でしょ？
- 280 名前：デフォルトの名無しさん mailto:sage [04/02/03 01:32]
- そんなに実行時にクラスを変更出来る言語あったっけか。それなら済まない。
- 281 名前：デフォルトの名無しさん mailto:sage [04/02/03 02:22]
- >>277
実務での使用だと利点は無い。
なのでみんなクラスベースを使ってる。
- 282 名前：デフォルトの名無しさん mailto:sage [04/02/03 03:20]
- >>277
rapid prototyping的に、モノを動かしながら要求分析する時とか。
- 283 名前：デフォルトの名無しさん mailto:sage [04/02/03 08:35]
- いやだから、具体的に
- 284 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:04]
- >>283
いくつかオブジェクトは出てきているけど
どれとどれが似ていて、どれとどれがどう関連していて
どのオブジェクトがどんな情報を持っているのかはっきりしていない状況では、
クラスを通して間接的にオブジェクトの振舞いを変えていくよりも、
目の前にあるオブジェクトを直接イジれたほうがやりやすい。
特にユーザーインターフェースデザインでは効果的。
クラスベースよりもずっとオブジェクトを直接触っている感覚があるし、
お客さんにもわかりやすい。
そうやって、お互いの理解を深めた上でクラスベースの分析設計に入ればいい。
これ以上は自分で体験してもらわないことには、言葉で伝えるのは難しい。
Smalltalk上にプロトタイプベースな環境を構築したものはいくつかあるから、
どれか試してみるといい。
まあ、今でも使えるものということになるとSqueakが一番手頃かな。
ちょっとクラスベースの匂いが残ってるけど。
- 285 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:05]
- > モノを動かしながら要求分析する時とか。
動かす前にやったらダメかね。
- 286 名前：デフォルトの名無しさん mailto:sage [04/02/03 09:07]
- >>285
紙芝居でもいいから動くものが目の前にあったほうが、
お互いに自分の考えを言葉にしやすいわな。
- 287 名前：デフォルトの名無しさん mailto:sage [04/02/03 14:06]
- 漏れ思うに、クラスベースのOOの利点ってのは
・強い型付けと組み合わせて、最適化が図れる。
・クラスに着目して設計が可能なので、クラスの個数＞＞インスタンスの個数であれば
設計やコード読むのが楽になることがある。
って程度じゃない？でもまあ後者はとても強い利点だと思う。
自由度を制限することによって得られるものもあると思う。主観ばかりでスマソ。
- 288 名前：デフォルトの名無しさん mailto:sage [04/02/03 14:27]
- >特にユーザーインターフェースデザインでは効果的。
これなんてプロトタイプ/クラスベース関係ないんじゃない？
デザインの変更にコードをいぢるのかと。
みんなが納得のプロトタイプ利点の実例ってないですか？
- 289 名前：デフォルトの名無しさん mailto:sage [04/02/03 15:27]
- >>288
> これなんてプロトタイプ/クラスベース関係ないんじゃない？
とても関係ある。実際にやってみれば大きな違いがわかると思う。
> デザインの変更にコードをいぢるのかと。
当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。
どんな情報をどのような時にどのように見せるのか、
これを変えようとしたらコードをいじることになるのは当然でしょ。
その時、目の前にあるGUIが生きたオブジェクトになっていて、
動かしながらそのオブジェクトのコードや変数を直接いじれる。
生きたオブジェクトをプロトタイプからコピってきて、生きたGUIの上に置ける。
そして置いたオブジェクトに変数を定義したりメソッド変えたり、
この直接オブジェクトを作り上げていく感覚はクラスベースではなかなか出てこない。
Smalltalkでさえ、クラスをいじってる限りは間接的な感じがある。
- 290 名前：デフォルトの名無しさん mailto:sage [04/02/03 16:28]
- >当然いじるでしょ、ボタンの位置を1ピクセル動かすとかでない限り。
>どんな情報をどのような時にどのように見せるのか、
>これを変えようとしたらコードをいじることになるのは当然でしょ。
別に当然じゃないでしょ。
UIの情報をコードと分けてて後から自由にいじれる
クラスベースのシステムだってあるよ。
- 291 名前：デフォルトの名無しさん mailto:sage [04/02/03 16:55]
- >>290
> UIの情報をコードと分けてて後から自由にいじれる
> クラスベースのシステムだってあるよ。
で、そのUIの情報とやらには何が入るわけ？
GUIってのはViewだけじゃないよ。
MVCで言えば、MVC全部でUIを構成するんだよ。
それを動かして見せようとしたら、M同士の相互関係も必要だよ。
当然、何らかの計算が必要なら、それを実装するんだよ。
それが>>289で言った
> どんな情報をどのような時にどのように見せるのか、
ということ。
- 292 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:40]
- GUIのデザインっていったらViewだけを指すと思うけど。
MVC全部って言ったらそれはもうシステム全体じゃん。
- 293 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:56]
- >>291 が今無能を晒しました。
- 294 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:06]
- >>292
> GUIのデザインっていったらViewだけを指すと思うけど。
おいおい、Controllerまで外す香具師は初めてだぞ。
> MVC全部って言ったらそれはもうシステム全体じゃん。
そんなこたーない。
何を表示するか、Modelの吟味無しにマトモなUIデザインができるわけないじゃん。
ミドルティアっぽい部分についてもバックエンドとかパフォーマンスとか頑健性とか
エラー処理とかロギングとか、GUI用のプロトタイピングでは無視していいファクター
は沢山ある。オモチャみたいなロジックでいいから、動かすことに意味がある。
ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？
ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
そういうのはあくまでUIデザインの結果にすぎない。
- 295 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:14]
- だからそういうのはGUIのデザインじゃなく
システムのデザインだろ。
- 296 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:17]
- >>294
やめとけ
フォーム描きがUIデザインだと思ってる馬鹿には何言っても無駄
しかしコントローラ抜きのUIデザイン藁た
- 297 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:21]
- >>295
> システムのデザインだろ。
システムデザインにバックエンドもパフォーマンスも頑健性もエラー処理も不要ならば
君の言う通りだ。
しかし、画面上で関連するModel間の関係だけでシステムデザインができるほど
世の中甘くないんだよ。
- 298 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:21]
- ｼﾞｻｸｼﾞｴｰﾝ(･∀･)
- 299 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:29]
- >ちょっと刺がある言い方するけど、UIデザインを甘く見てるんじゃない？
>ボタンの位置とかフォントとか色とかだけがUIデザインじゃないよ。
>そういうのはあくまでUIデザインの結果にすぎない。
甘く見るも何もUIデザインなんてかなり地道な作業だとおもうけど。
プログラマというよりほとんどオペレーターというか。
いや毎日そんなんばっかりでなんか愚痴りたくなって。すんまそん。
- 300 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:39]
- プロトタイプ的なものをクラスベースで書けないわけじゃないし。
本格的に開発に入って他言語に置き換えるんだったら、
始めからクラスベースの言語で書いた方がイイと思うんだが。
- 301 名前：300 mailto:sage [04/02/03 18:41]
- あと、UI のデザイン(アクセシビリティとかも含む)って
UI 専門の部署から回ってくるもんじゃないの？
うちの会社じゃそうしてるけど。
- 302 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:51]
- 会社の大きさによります。
- 303 名前：デフォルトの名無しさん mailto:sage [04/02/03 18:53]
- >>300
プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、
実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
特に、プロトタイプが必要になるような探求的なプロジェクトではね。
そういう時には、プロトタイプベースのほうがその場で手早く手直しして見せられる。
その場で手直しして見せることで、お客さんも自分が何を必要としているのかが
だんだん見えてくる。
もちろんクラスベースでもできないことはないけど、プロトタイプベースのハンディさ
はなかなか得られない。
あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
同じ言語/環境を使うにしても、最初から書き直したほうがいい。
考慮すべきファクターが全く違うから。
- 304 名前：300 mailto:sage [04/02/03 19:12]
- > プロトタイプを2,3回作って「ハイ、オッケー」ならいいけどね、
> 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
無論、プロジェクトが終わるまで何度も打ち合せはするだろうけど、
なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。
ほとんどの場合、ヒアリングで解決することだし。
> あと、プロトタイプで使ったコードを本番に使い回すのはよくないと思うよ。
そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。
抽象的な話が多すぎて利点が良く分からん。
具体的にどんな仕事でどういう風に使えば、どういう利点があるの？
- 305 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:15]
- GUIはオブジェクト指向の考え方が非常に良く当てはまる，
非常に稀な例だからなぁ．
- 306 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:20]
- > 実際の所、お客さん自身が自分達の要求が何なのかわかってない事が多い。
なんかいやな仕事だな。
いやな客にすばやく対応できるとかじゃなく
もっと明るい利点はないですか？
- 307 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:27]
- 実行時にクラスを変更できる言語は知らないけど，
クラスベースで，オブジェクトへの動的なメンバ追加を許す言語はある(はず)．
メンバの動的変更はプロトタイプベースの特権ではない．
- 308 名前：1 mailto:sage [04/02/03 19:27]
- 具体例，具体例って五月蝿いやつは
まずクラスベースでの具体例だせよ…
クラスあるとこいういう風に綺麗に作れるけど，
プロトタイプベースじゃこうはいかないだろ？
と．
- 309 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:36]
- 開発方法論のウォーターフォールvsスパイラルで
やってることと同じ内容で言い争ってる？
問題点はもう少し整理しないと。
- 310 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:39]
- >>308
プロトタイプベースでもクラスベースでも同じ書き方ができるんなら，
実行効率や型チェックの面で圧倒的にクラスベースの方がいい．
問題は，プロトタイプベースでうまく書けるが，クラスベースではうまく書けない
例がどの程度存在するか，そしてそれは必要なのか，という点．
- 311 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:43]
- >>304
> なるべく短期間で客の要求を的確に割り出すのが仕事じゃないのか。
そのためのラピッドプロトタイピング。
> ほとんどの場合、ヒアリングで解決することだし。
十分に枯れたドメインなら言葉だけでいいかもしれんけどね・・・
プロトタイプを動かしながらお客さんの指示に従って変えていくヒアリングもアリだよ。
> そりゃまぁ適当に書いたコードを使い回したりするのはマズいだろうけど、
> キチンとしたコードなら一向に構わないと思うんだけど。具体例きぼんぬ。
プロトタイピングはキチンとしたコードを書くのが目的ではなくて、
お客さんの要求を引き出すために必要十分に動けばいい。
むしろエラー処理やスケーラビリティがキチンとしたコードを書くために
プロトタイプ作成が遅くなるのでは本末転倒になりかねない。
それよりも、目の前にいるお客さんに一秒でも早く動きを見せたほうがいい。
もちろん本番のコードはキチンと書く。当然だよね。
具体例は、俺が実際に経験したプロジェクトを具体的に書くと
狭い業界だからお客さんや俺自身が特定されかねないんで、勘弁。
- 312 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:43]
- 個人的には，>>267はプロトタイプベースのデメリットだとおもう．
- 313 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:49]
- 客への対応とかはもうどうでもいいよ…．
- 314 名前：デフォルトの名無しさん mailto:sage [04/02/03 19:51]
- 結局ここでもLISPが最強ということだな。
- 315 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:08]
- Lisp は歴史上の通過点として、プロトタイプベース言語の中でも大きな位置を占めているね。
- 316 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:15]
- 記述能力については、プロトタイプ言語は（クラスレスであるという）その本質的な特徴よりも、
大抵の実装でオブジェクトがスロット付きであって、メソッをド含むスロットの追加・削除が
動的に可能だということの方が支配的だと思うな。
- 317 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:22]
- >>316
良い事言った！
俺もそう思うよ。
- 318 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:25]
- >>316
同意．ただ，>>307をどう見るかですな．
- 319 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:36]
- クラスが有るか無いかは（この文脈では）それ程大きな問題では無いから、当然 hybrid な
言語があっても良いでしょうね。Ruby みたいな。
- 320 名前：デフォルトの名無しさん mailto:sage [04/02/03 20:43]
- 結局ここでもRubyが最強ということだな。
|
 |
