【オブジェクト指向】言語学習が先？概念学習が先？

1 名前：デフォルトの名無しさん [04/01/10 14:56] VisualBasicやCといった手続き型言語をずっとやってきた人が、 C#やJavaといったオブジェクト指向言語をマスターする場合 オブジェクト指向の概念・概論を学ぶのが先がいいのか、 それとも、C#やJavaの言語を学ぶのが先がいいのか、 どっちがいいと思われますか。 237 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 01:16:12 ] クラスライブラリの体系をおぼえるのが ものすごく、めんどくさい。 238 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 01:18:15 ] オブジェクトはキャラクターです パラディンクラスはナイトクラスを継承します 新たに技を追加できます オーバーライドすることで既存の技を強化することも可能です 239 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 02:12:37 ] >>238 >オブジェクトはキャラクターです この時点で>>236の言っていることそのままじゃん 240 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 02:17:25 ] オブジェクトは職業・技能です とか？ 241 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 02:29:04 ] クラスは役割、役です はどう？ 242 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 02:44:27 ] くらすが個別にインスタンシエーションがつまりmalloc()の コンストラクタがごごごと動いて どうも、オブジェクトです、 クラスのインスタンスです、ご用件をどうぞ free(); または、もしもし五味屋さんはやくきてよ のような、認識。 今年中によむ、本(予定)。 * 結城本 * エッケルのThinking in Java * GOF本 243 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 02:57:57 ] >>237 マトモに設計されたライブラリなら一部を覚えればあとは類推で何とかなると思うが。 244 名前：デフォルトの名無しさん [2005/04/30(土) 04:27:33 ] オブジェクトを汎化したものがクラスです。 245 名前：デフォルトの名無しさん [2005/04/30(土) 04:32:08 ] >>123 > 分析レベルだと、あんまりインスタンスという言葉は使われない。 おいおい、ユースケースのをインスタンス、とか言うだろ？ 使われないのはオブジェクトという意味の「クラスインスタンス」だろ？ 246 名前：デフォルトの名無しさん [2005/04/30(土) 11:29:38 ] インヘリタンス 247 名前：デフォルトの名無しさん [2005/04/30(土) 12:41:43 ] 混濁箪笥 248 名前：デフォルトの名無しさん [2005/04/30(土) 13:23:24 ] オブジェクト指向ってつまるところ 「そういう仕様」だと思うよ、 現実を表現しやすく、管理しやすい仕様ではあるが 現実に無理して当てはめてわかった気になっても 習熟していくと騙されたと気づくんじゃないかな？ 249 名前：デフォルトの名無しさん [2005/04/30(土) 13:32:57 ] 騙されたって気にはならないなあ 用意周到なクラスライブラリを理解していくに連れて なるほどという気持ちになる あでもそういう汎用クラスライブラリを作る側は大変だろうな 習熟して騙された気になるってそういうレベル？ 250 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 13:47:11 ] アルゴリズムと一緒で あーこういう組み方するのか〜うまいね〜ってな感じ しかし、それほどデザインパーﾀﾝに執着は無い クラスの関係図を書くと何階層にもなってしまうので 新規作成時はいいんだけど、後から入ってきた人が もしそれほど知識無いとしたら修正お願いしてもわかりませんので 251 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 15:43:55 ] 「現実に無理して当てはめた説明」に騙されたって言ってるんだけど デザインパターンは現実の構造を示してるんじゃなくて、 工学的な定石に名前をつけたもんでしょ 現実ってリアルワールドね 252 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 15:46:52 ] 習熟してくるとその辺の神話のうそがわかってくるって いいたいんですよ 253 名前：さかな ◆xT/ZtgSAnQ mailto: [2005/04/30(土) 15:55:55 ] その「神話」とやらを教えてる方の人間も、 理解を助けるための方便として言ってる場合だけじゃなく 自分も本気で信じてる場合もあるから たちが悪い。 254 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 16:05:05 ] 結局プライドの戦いと言うわけになるのだな 255 名前：デフォルトの名無しさん [2005/04/30(土) 17:22:36 ] アプリケーション、ツール、フレームワーク、クラスライブラリ、クラス設計に関して、 自分で実際にそれらを作ってみると、設計の妥当性/妥協点がわかる、という事実がある。 もちろん、自分でそーゆーのを作れない泡沫エンジニアへのセールスポイントや使いやすさ も提供するわけだがｗ 大枠や細かな所は、「現実的な作りやすさ」で決まってくるもんなんだよね。 だから、ｵｰﾌﾟﾝソースで自分で中見て改善する練習をする事が重要なんだ。。。 Smalltalkしかり、Linuxしかり 256 名前：デフォルトの名無しさん [2005/04/30(土) 18:00:34 ] 制御系でOOPってどれぐらい浸透している？ ナビ開発をやっているんだけど、現行の手続きOnlyなやり方だと分り難くないかな。 257 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 18:10:45 ] >>256 new封印で使ってる 258 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 18:52:27 ] 騙される方が悪いのか騙す方が悪いのか信じる者は掬われる？ 259 名前：池沼くんのレス mailto:sage [2005/04/30(土) 18:55:05 ] 88 名前： 番組の途中ですが名無しです 投稿日： 2005/04/29(金) 14:21:36 ID:HlHAQf7m0 まぁ、オブジェクト指向隆盛の現在、 Viewを客受けの良いものにchangeしたのは正しい決断だな。 260 名前：デフォルトの名無しさん [2005/05/01(日) 07:24:28 ] C++の設計者はなんで shout << なわけねーだろ！ にしなかったんだろ… 261 名前：デフォルトの名無しさん mailto:sage [2005/05/01(日) 21:17:22 ] orz << "入れてよし" 262 名前：デフォルトの名無しさん mailto:sage [2005/05/01(日) 21:38:53 ] プリプロセッサで文法変更すりゃ終了。 263 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 20:50:37 ] >>261 orz┤ 264 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 02:13:09 ] じゃあ、言語学習と概念学習は同時にやっていくってことで終了でいいですか 265 名前：デフォルトの名無しさん [2005/05/08(日) 12:32:01 ] ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝来了＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 266 名前：デフォルトの名無しさん [2005/05/11(水) 00:24:46 ] いがぴょんが痛すぎるんだけど、マゾかなんかですか？ 267 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 00:27:54 ] 逝け沼さん、こんにちは 268 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 02:36:01 ] >>263 orz=3=3=3=3 ﾌﾞﾌﾞｯﾌﾞﾘﾌﾞﾘﾋﾞﾁﾋﾞﾁﾌﾞﾌﾞﾌﾞ 269 名前：デフォルトの名無しさん [2005/05/15(日) 11:01:52 ] いつの間にかクダスレになっとるわい 270 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 11:26:23 ] >>196 型付きの手続き型言語の理論としては、 型付λ計算が広く受け入れられている。 ただし、オブジェクト指向言語では 「オブジェクト指向」の本質といったものを明確にするのは難しいので、 広く受け入れられた理論というのは、まだない。 271 名前：デフォルトの名無しさん [2005/05/15(日) 15:14:43 ] どういった単位でクラスを作っていけばいいんですか？ 趣味程度で自分しか使わないコードを書く人間としては、 ついというか癖でだらだらと関数を山ほどForm1のなかに書いてしまうのですが… 272 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 17:59:10 ] 本当にﾌｶｷｮﾝ似だね 273 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 19:43:17 ] >>271 いくら使い捨てコードといっても、一発で動いて後は永遠にメンテ不要なんてケースはまずないわけで。 自分で書いたコード読んでイライラしない？ 274 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:41:36 ] >>271 >どういった単位でクラスを作っていけばいいんですか？ 殴り書きでいいのだが、 見つけたオブジェクトを見つける 見つけたオブジェクトの単位でクラス図を書く クラス図にメンバ変数を追加する クラス間のメンバ関数を時系列にそってシーケンス図として書く メンバ関数をクラス図に追加する これらの手順を納得できるまで繰り返す 収まりがついたらコーデングする 動作としてはこうなんだが、 それぞれの段階で知識や経験が入り込む 275 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:42:51 ] >>274 ×見つけたオブジェクトを見つける ○オブジェクトを見つける 276 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:44:40 ] C の struct をベースに、データ構造を基準にすると分かりやすい どれだけの物を１つにまとめ、どれとどれを分けるかの判断は経験則 277 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:45:43 ] >>274 コーダー乙。 分析レベルのOOを認識できてないあたりが、 机上の勉強だけの糞コーダ臭いな 278 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:52:39 ] どうでも良いが、わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える必要性が分からん 279 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 20:53:24 ] 第一の山は、 概念レベルのオブジェクトをいかに抽出し、 現実世界のモデルを作るか？ 第二の山は、 ユーザ要求なり機能要求を、 分析レベルでいかに取り込んでいくか 第三の山は、 １で作った概念モデルと ２で作った機能要求モデルを いかに整合させていくか 第四の山は、 １、２、３で作ったモデルの実装方法の検討。 ここらへんがアーキテクトの仕事。 このあたりまでやって、ようやく開発レベルのOOになる もちろん、対象分野の開発に慣れていて、 なおかつ新しい設計をしないならば、 1〜4は楽勝だけどな。実際はそれをOOに不慣れな人間がやる事が多いから、 下流の人は大変みたいだ。 機能分割とDB設計から割り出したクラス図を受け取って、あとはウォータフォールとかｗ 280 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 21:05:52 ] 最初の質問に戻って ＞どういった単位でクラスを作っていけばいいんですか？ 趣味のプログラミングということで、基準がわからないのだが、仮に 1.開発技術のスキルアップ 2.設計〜コーディングにおける作りやすさ 3.拡張のし易さ あたりを基準に考えていこう。 1.に関しては、薄っぺらいOO開発プロセスの本を追っかけてみると、 　UMLやオブジェクト指向分析設計の概観が得られて、勉強になると思う。 　とりあえずの推薦図書は、 　・ユースケース入門―ユーザマニュアルからプログラムを作る 　　www.amazon.co.jp/exec/obidos/ASIN/4894713772/ 　・ワークブック形式で学ぶ UMLオブジェクトモデリング 　　www.amazon.co.jp/exec/obidos/ASIN/4797320192/ 281 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 22:08:24 ] >>278 > わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える もし設計/実装レベルのみに着目してソフトウェア開発を行うと、 開発者の関心と努力は、実装可能な事/実装が難しい事に集中してしまい、 結果として下記のような問題が発生します。 (1) 本来の要求(やりたかった事)の実現が、 　　おざなりになったり、歪んだ形になってしまう事。 　　（結果として、ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術は素晴らしいが、 　　　使う人にとっては判りにくい、使いにくいものになってしまいがちです） (2) 拡張や機能追加に耐えないクラス設計になってしまう事。 　　（拡張や機能追加に耐えるしっかりした構造を持たせるには、 　　　普遍的な概念モデルや、プログラム対象分野の知識体系に基づく、 　　　抽象的なレイヤーが必要です。 　　　この抽象的なレイヤーは、汎化クラス抽出の方法でもある程度得られますが、 　　　ボトムアップに実装から抽出する方法では、充分な汎用性をえられません。） (3) プラットフォームや実装技術と、コアなアルゴリズムの切り分けが不充分になる。 　　もし、実装技術やプラットフォームに基づいて、アプリケーションの設計を行ったら、 　　それは将来のOS/環境のバージョンアップ時に、大きな変更作業が必要になるでしょう。 　　OS/環境依存部、プログラム対象分野の知識体系、アプリケーション、を分けるには、 　　レイヤー・パターンが有効ですが、そのレイヤーを切り分けるためにも、 　　OO分析の作業が重要なのです。 他にも書くべき事があるのですが、とりあえずここで筆を置きます。 　　 282 名前：278 mailto:sage [2005/05/15(日) 22:20:01 ] >>281 ＞もし設計/実装レベルのみに着目してソフトウェア開発を行うと、  いやいや、最終的に両方ともやらなければいけないのは分かっているんだけど、 ある程度のフィードバックが、実装レベルから分析レベルに伝播するから、 わざわざ分けずに一言で纏めちゃっても良いんじゃないかって言う勝手な話 283 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 22:31:16 ] 分析レベルで抽出されるオブジェクトと、 設計レベルで抽出され、実装に反映されるオブジェクトは、 かなり距離感がある これが、二つのプロセスを分離している理由です。 もちろん、シェアウェアとか個人でプログラムを作成されている方の中には、 実装技術ベッタリで素晴らしいアプリを作成されている方も多いようですし、 貴方の信じる道を行けば良い、と思います。 284 名前：278 mailto:sage [2005/05/15(日) 22:50:32 ] ああ、なんとなく雰囲気が掴めました 目的から作成するオブジェクトと、実装技術から発生させるオブジェクト…… ……これらを最終的に一致させるように、今まで考えていたのですが、これじゃダメなんでしょうか (ひとつになった最終形を眺めて、278 を考えていたです) っていうか経験不足です 企業に入ってそこそこのプロジェクトに参加するようになったら、改めて考えてみますです 285 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 22:51:30 ] なんだろ。目的と実装を一致させるのではなく、実装を目的でラップするとか、そういう意味合いで 286 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 04:30:20 ] ・・・・・・。 287 名前：デフォルトの名無しさん [2005/05/16(月) 20:38:55 ] うむ。わざわざ別の用語にするほどのこととは思えないな。 >>284のような「設計方針」「心構え」で申し分ない。 288 名前：デフォルトの名無しさん [2005/05/16(月) 20:41:57 ] いや、だから個人で勝手にやる分には全然構わないけど、 内容的には大きな差があるんだって。 ＞＞分析モデルと設計モデルの間の深い溝。 俺はこの分野に入ってすぐ、気付いたけどなぁ〜 289 名前：デフォルトの名無しさん [2005/05/17(火) 08:50:54 ] 具体的に 290 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:58:47 ] いや、そーゆーのは仕事で覚えるものだから、 素人グラマーに意見するつもりはない。 291 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 09:00:14 ] だいたい趣味がプログラムの >>289は、 朝っぱらからこんな所でなにやってんの？ 292 名前：デフォルトの名無しさん [2005/05/17(火) 09:14:29 ] 結局具体例もないわけね 293 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 09:16:13 ] 餓鬼と判定。以降スルー 294 名前：デフォルトの名無しさん [2005/05/17(火) 09:24:49 ] 自演臭い 295 名前：デフォルトの名無しさん [2005/05/17(火) 09:26:12 ] 俺の思いを分かるのは俺だけ！ﾌﾟ 296 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 09:27:07 ] VIP板に（・∀・）ｶｴﾚ 297 名前：デフォルトの名無しさん [2005/05/17(火) 20:38:12 ] ジサクジエンイクナイ 298 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 22:13:32 ] >>282 そういう思考が肥満児クラスを産む、 なんてな。 299 名前：デフォルトの名無しさん [2005/05/18(水) 23:29:45 ] 良い設計モデルの作り方(前編)　www.atmarkit.co.jp/farc/rensai/goodmodel01/goodmodel01.html ◇ 目指すべき分析モデルの形 　分析モデルの作成方法については、多くの設計者や方法論者がさまざまな方法を主張しています。 　ここでは詳細には述べませんが、例えば、 　　・ワード・カニンガム（Ward Cunningham）による「CRC分析法（ブレーンストーミング）」（注1）や 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　「名詞・動詞分析法」（注2）、 　　・ピーター・コード（Peter Coad）により『Java Modeling in Color with UML』（Prentice Hall刊）の中で紹介されている設計手法（注3） 　などがあります。 　注1: CRC分析法（ブレーンストーミング） 　　　クラス（Class）、債務（Responsibility）、協調（Collaboration）に分けられたCRCカードを用いて分析していく方法です。 　　　詳細は『Object Design: Roles, Responsibilities, and Collaborations』（Rebecca Wirfs-Brock／Alan McKean著、Addison-Wesley刊） 　　　をご参照ください。 　注2: 名詞・動詞分析法 　　ユースケースや用語集から、名詞、名詞句を探し出して、クラスの候補とし、動詞、動詞句を探し出して、メソッドの候補として作成していく方法。 　注3: 『Java Modeling in Color with UML』（Prentice Hal刊）の中で紹介されている設計手法 　　　4つのアーキタイプ、瞬間―時間間隔、役割、パーティ／場所／物、説明に分類し、色分けして、パターンに当てはめて分析していく方法。 　　　特に分析モデルに限ったものではありませんが、最初のモデルを作成する場合の強力な手法となっています。 300 名前：デフォルトの名無しさん [2005/05/18(水) 23:30:12 ] ◇ 設計モデルの理想 　設計モデルの段階における理想的なモデルとはどんなモデルでしょうか。設計段階のモデルに従って実装が行われ、 　その結果システムが出来上がるわけなので、生産性が高く、保守性や拡張性が考慮されていなければなりません。 　そのうえで、実装担当者にとって理解しやすいモデルが「良い設計モデル」ということになります。 　最近のアジャイル系開発プロセスでは、モデリングを分析段階と設計段階に分けず、 　モデリング＝設計（Design）と考えたり、XPのように、コーディング作業にモデリング作業を含んでしまうプロセスもありますが、 　本稿では、分析と設計の考え方の違いを解説するために、あえて分析モデルと設計モデルを分けて表現しています。 301 名前：デフォルトの名無しさん [2005/05/18(水) 23:57:53 ] なんかPascal臭い感じだな（意味分かる？） 302 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 00:11:29 ] しらねぇよ屑 303 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 00:12:39 ] てめえは御託並べる前に、構造化プログラミングとデータ中心アプローチくらい覚えろよｗ 304 名前：デフォルトの名無しさん [2005/05/19(木) 08:27:55 ] なんか初心者にはスレッショルドの高いスレになっちまったな 305 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 08:37:57 ] >>299-300のボーランド@IT記事がいいと思うよ。 匿名掲示板で数文字でノウハウ聞き出そうとするアンタは、ギブアンドテイクつう言葉がわからんヒッキーだろ 306 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 17:18:03 ] また電波とばす。受信したい奴だけ受信してくれ。 C# だと、オブジェクトの派生になるが C と同じような構造体が扱える 宣言は 『 struct Struct1 { 〜 } 』 でインスタンス生成は 『 new Struct1() 』 それに対し、オブジェクトの宣言は 『 class Class1 { 〜 } 』　でインスタンス生成は 『 new Class1() 』 なんだけど、 これ、宣言が 『 object Object1 { 〜 } 』 の方が分かりやすくないか？って電波だ。 struct の宣言では、定義してあるのが 『構造体』 で、作成されるのが 『構造体のインスタンス＝構造体』 だからまあ良い。 だけど class の下りは、定義してあるのが 『クラス』 で、作成されるのが 『クラスのインスタンス＝オブジェクト』 だから 定義された物と作成される物が異なっていて気持ち悪いかもしれないと言うこと。 異なっていて気持ち悪いのならば、いっそのこと 『 object Object1 { 〜 } 』 にしてしまえば……ってコトです。 もちろん、object の宣言を行っていても 『これはクラス Class1 のインスタンス』 という表現は行える筈。 クラスって言葉は、『部門』 とかの分類を表す意味があるから。レベルとかと同じ意味で。 C# では、構造体のインスタンスもオブジェクトと言っているから、まあ気にし過ぎかもしれないけど、 C から入った俺は、なんとなく 『構造体の定義から生まれたモノ＝構造体』 にしたくて。 ……って、なんとなくクラスとインスタンスの区別がついてないっぽいな。すまぬ。 307 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 19:30:00 ] ＝＝＝＝＝　電磁シールド　＝＝＝＝＝ シンタックス・シュガー作っても本質は変わらない。 クラスと構造体を同一視するのなら、サルもミジンコも同じ。 クラスとオブジェクトの違いもわからずに、 そんなに細かいところをあれこれ弄る必要ナッシング。 308 名前：デフォルトの名無しさん [2005/05/19(木) 21:41:58 ] structで定義しているのは構造体の構造 実際に作成する時作成されるのは構造体 この違いがクラスとオブジェクトの違い 309 名前：デフォルトの名無しさん [2005/05/19(木) 21:44:36 ] けれどクラスという概念をなくしてしまってもいい オブジェクトの構造・仕組みという抽象的なもので コード上は現れないようにしても問題ないだろうよ 310 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 21:47:54 ] なんか変なのが居ついてるな 311 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 06:01:04 ] >>309 そういう道を進んでいる言語もある。 プロトタイプベースと呼ばれているようだが。 312 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 09:11:17 ] 今頃プロトタイプ・ベースを語るとは・・・ｸｵﾘﾃｨﾃﾗ高杉 313 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 09:43:14 ] プログラムもろくに書けない負け犬は、 古臭い脳内知識で妄想勝利するしかやる事がないんだな プロトタイプベース言語が提供する インスタンスに対する属性/メソッドの付加は、 Composit, Decoration, Delegation, Factoryあたりで実現できる。 プロトタイプベース言語は、それらの機能を言語仕様に取り込んでいるだけｗ 314 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 09:45:58 ] Composite, Decorator, Prototype パターン ＋ Delegation (委譲による処理) な 315 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 10:59:30 ] クラスベース　　　 ＝オブジェクト間にメタ関係を設け、 　　　　　　　　　　　　　メタ関係上位にあるオブジェクト(クラス)に、オブジェクト生成や継承の仕組みを任せて、 　　　　　　　　　　　　　メタ関係下位にあるオブジェクト(インスタンス)の内部実装の簡略化を図ったもの プロトタイプベース＝全てのオブジェクトに、オブジェクト生成や継承の仕組みを提供するもの。 　　　　　　　　　　　　　概念は単純になるが、言語実装技術やﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術のハードルは高くなる。 　　　　　　　　　　　　　(静的型付けやLiskov置換則による安全性を、言語レベルで提供しにくくなる) 概念学習への初期投資を惜しむような人間が、プロトタイプベースを選択するのはナンセンス。 プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。 316 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 18:25:30 ] >>315 いい比較だと思うが、それだとクラスがファーストクラスな存在に読めるかも。 317 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 18:35:42 ] またファーストクラス厨房か。 Smalltalkでクラス・ベースのオブジェクト指向が確立した後で、 あらためて Self等でプロトタイプ・ベースのオブジェクト指向言語が研究されたのだから、 　　　クラス-オブジェクト関係 (メタ関係 あるいは インスタンス関係) の方が広く受け入れられてる概念だと思うよ。 Abadi & Cardellaの本もまずクラスベース言語、次にオブジェクトベース言語という展開だし。 318 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 18:40:05 ] あ、もっとレベル低い人か。 Smalltalk等、クラスをファーストクラスなオブジェクトとして扱うのが第一世代、 CLOS等、手続き型の延長線上にクラスレスなOOを定義したのが第二世代、 C++等、クラスをオブジェクトが共有する構造体として扱うのは邪道な第三世代、 Java等、クラスをリフレクション等駆使して、実行時に参照可能なオブジェクトとして扱えるようにしたのが第四世代 だよん。（てきとー 319 名前：いやん mailto:sage [2005/05/20(金) 18:40:57 ] × Cardella → ○ Cardelli 320 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 18:43:46 ] Selfとか、プロトタイプ・ベースの言語が研究されるようになったのは、C++とJavaの中間くらいからかな。第3.5世代・・・新しい開拓地 321 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 19:08:23 ] >>318 プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。 322 名前：デフォルトの名無しさん [2005/05/20(金) 19:29:24 ] おまえの事だよ 323 名前：デフォルトの名無しさん [2005/05/20(金) 21:19:08 ] プログラム書かない・・・情報処理言語の研究者なのかも 324 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 21:22:43 ] 豆な人？ 325 名前：306 mailto:sage [2005/05/21(土) 14:42:19 ] やっぱり混乱の元になったか…… クラスベースについて疑問を思っているんじゃなくて、ただ単に 『表記法』 について疑問に思っただけだったんだけどな クラスベースとかインスタンスベースとか、正直どうだって良いんだけど >>308 ＞structで定義しているのは構造体の構造 同様に、class で定義しているのはオブジェクトの構造つまりクラス それは分かる。struct および class が 『定義そのもの』 を指すのか 『定義した生成物』 を指すのかの違いのような。 気分的には、生成物を指したい 326 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 14:46:28 ] いろんな「何を」や「何は」が抜けていて、「何に」ついて言いたいのかさっぱりわからない。 327 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 14:51:43 ] 頭おかしい人だから、放置しとけ 328 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:03:52 ] >>325 君が誤解している(もしくは不完全な理解をしている)のは、 クラスやオブジェクト等のＯＯの概念ではなくて、型という概念だ。 Cardelliでも読んで、型とは何か、型を宣言するとはどういうことか、 じっくり考えてみたらいい。 329 名前：306 mailto:sage [2005/05/21(土) 15:05:19 ] 頭おかしいって言われちまったい ^_^; んじゃ書き直す ====== C# の表記法について、 class では 『定義そのもの』 を指していることは明確であるが、 struct は 『定義そのもの』 と 『定義によって生み出される生産物』 の、どちらを指すのか分かり難いと俺は思う 言いたい事はこれだけ ====== >>307 C# ではクラスと構造体が同一になっちゃってるから困っているんです >>308 構造体の構造を定義するのならば、キーワードは 『struct_struct』 であるべきという気もします 『struct』 単体ならば、それは 『定義に代って生み出される生産物』 を指すのでは？ 330 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:12:33 ] 国語の問題な気がしてきた。 331 名前：306 mailto:sage [2005/05/21(土) 15:12:37 ] >>328 了解……出来るように頑張ります Pascal の 『レコード型』 とか、C の 『構造体型』 とかと同じように考えると、class では 『クラス型』 を定義している筈。 しかし生成物の方は 『レコード型のレコード』 『構造体型の構造体』 とは異なり 『クラス型のインスタンス』 だから、 前２者に揃える場合、これを 『オブジェクト型のオブジェクト』 にしたほうが簡潔ではないかと思いまして。 332 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:13:00 ] >>330 正解 333 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:31:29 ] ドーナツの穴について話す時、 「ドーナツ」という単語が付いていると、あたかも「ドーナツ」が存在しているかのように感じる。 だから、「穴の穴」というのが正しいぃぃぃぃーーーーーーーーーーーーーー 334 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:33:18 ] 「ドーナツの穴」って、まるで穴の部分にドーナツがみっちり詰まってるみたいで、誇大広告だよな（ﾋﾟｰﾋｬﾗ 335 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:35:15 ] 人間という単語と、その実体を考えるとき、 実体は単なる人なのに、 単語に「間」という漢字がついているのが、直感に反する。 これからは、「人間」という単語を使うのはやめよう 336 名前：デフォルトの名無しさん mailto:sage [2005/05/21(土) 15:49:42 ] >>333-334 スレ違い。こっち行け ドーナッツの穴は空洞か存在か？ academy3.2ch.net/test/read.cgi/philo/1049436081/l50 337 名前：デフォルトの名無しさん mailto:sage [2005/05/22(日) 08:11:20 ] >>306 そのobjectってVBでいうところのモジュールだよな？ classと違うだろ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef