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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 10:54 / Filesize : 242 KB / Number-of Response : 947
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん [04/01/10 14:56]: VisualBasicやCといった手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
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と違うだろ。
338 名前：デフォルトの名無しさん [2005/05/24(火) 06:19:22 ]: おれはstructで構造体の構造が定義されてるって自然に感じるけどな
んでその構造を持つ変数を同時に生成することもできると
339 名前：デフォルトの名無しさん [2005/05/24(火) 09:52:10 ]: >>331
PascalやCのほうを『レコード型のオブジェクト』、『構造体型のオブジェク
ト』って思ってみては？

オブジェクトとインスタンスは、まぁ、同義ということで。
340 名前：306 mailto:sage [2005/05/24(火) 17:24:00 ]: 色々とすまなかった。整理したら間違いに気付いたよ。
こんな馬鹿をやったのは久しぶりだ。今は後悔している OTL

【正しいこと】

・C# の《クラス》には『クラス』『インタフェイス』『構造体』の３種類が存在する
・『インタフェイス』と『構造体』は、Object クラスを継承している

【俺が間違っていたこと】

・《クラス》と『クラス』を混同し、宣言時のキーワード「class」が主に《クラス》を指す物と考えてしまった
・『クラス←構造体』に代表される「言語系外での継承」が、一般の継承と完全に同じであると信じて疑わなかった

その結果、俺は「class」と「struct」が同一レベルの概念ではないと錯覚した

そして、「class」と「struct」のレベルを同じにしようと思い、「class」を《クラス》から『クラス』にするために
　「《クラス》には『オブジェクト』『インタフェイス』『構造体』の３種類が存在する、と言い換えたらどうか」
と提案した (>>306)
(実際は「class」は『クラス』であり、単なる言葉遊びだった orz)
341 名前：最凶VB厨房 mailto:sage [2005/05/25(水) 00:25:55 ]: 全く意味わからんなｗ
【正しいこと】に書いてある内容が正しくない。
342 名前：デフォルトの名無しさん mailto:sage [2005/05/25(水) 00:36:00 ]: だからまず国語を勉強するべきだって。
つまり言語学習を先にするべき。
343 名前：306 mailto:sage [2005/05/25(水) 13:28:06 ]: >>342
悪い。相変わらず間違えてたみたい。

=====

「C# の《クラス》には『クラス』『インタフェイス』『構造体』の３種類が存在する」ってのは、
「Java の《クラス》には『クラス』『インタフェイス』の２種類が存在する」っていうどっかの本の台詞のパクリだった
この《クラス》は、Smalltalk のメタクラスに該当するんかな。よく分からんけど

それはともかく、構造体はクラス階層の中に含まれているから、よく考えたらこの中に入れちゃいけないのかもしれない

=====

インタフェイスは対応するクラスが無いから、Object から派生しているとは言えないでした
(ただし、インタフェイスを実装したクラスのインスタンスは Object であることは確定なので、Object として扱える)

ここのところは訂正しておきます
344 名前：306 mailto:sage [2005/05/25(水) 13:38:42 ]: 結局、まだ理解できていないことは

　実質「class StructA: System.Struct { ～ }」なクラスを「struct StructA { ～ }」と記述させる C# において、
　キーワード「class」と「struct」を同列に置くことが果たして妥当なのかどうか

つまり

　System.Struct からの実際の継承は、神の領域において行われる (ソースとして記述できない) が、
　神の領域において、結局はクラスである構造体が、クラスと同じレベルまで昇進しているのかどうか

……自分でも未だ混乱していることがありありと分かりますな
あとで Smalltalk でも勉強しよう……
345 名前：最凶VB厨房 mailto:sage [2005/05/25(水) 19:09:30 ]: 間違った前提知識からは(正しい推論をしたとしても)間違った結論しか得られんぞｗ

実質～の部分が既に間違ってますがなｗ
MSDN読め
346 名前：デフォルトの名無しさん mailto:sage [2005/05/25(水) 19:15:01 ]: 太陽が西から昇るなら、このレスは346である
347 名前：デフォルトの名無しさん mailto:sage だsageだsage持ってこーぃ [2005/05/25(水) 19:24:49 ]: www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/csref/html/vcrefStructTypes.asp

解説
struct 型は、Point、Rectangle、Color などの軽量のオブジェクトを表すのに
適しています。点はクラスで表現できますが、一部の事例では構造体の方が
より効果的です。たとえば、1,000 個の Point オブジェクトから成る配列を
宣言する場合は、各オブジェクトの参照用に新たにメモリが割り当てられます。
この場合は、構造体を使用した方がリソースを使用しません。

構造体に対して既定の (パラメータなしの) コンストラクタを宣言するとエラー
になります。構造体メンバを既定値に初期化する既定のコンストラクタが常備
されています。

構造体のインスタンスフィールドを初期化するとエラーになります。

new 演算子を使用して struct オブジェクトを作成すると、オブジェクトが作成
されて適切なコンストラクタが呼び出されます。クラスとは異なり、構造体は
new 演算子を使用せずにインスタンスを作成できます。new を使用しなかった
場合、各フィールドは未割り当てのままになり、すべてのフィールドが初期化
されるまでオブジェクトを使用できません。

クラスには継承がありますが、構造体には継承がありません。構造体は、
他の構造体やクラスから継承できず、基本クラスになれません。
ただし、構造体は、基本クラス Object から継承します。
構造体は、クラスの場合とまったく同じ方法でインターフェイスを実装できます。

C++ とは異なり、キーワード struct を使用してクラスを宣言できません。
C# では、クラスと構造体は、意味が異なります。構造体は値型ですが、
クラスは参照型です。
値型の機能の詳細については、「値型」を参照してください。
348 名前：306 mailto:sage [2005/05/25(水) 21:23:41 ]: >>347
あ、もしかして struct って System.Struct の継承じゃない……のか？
でもインスタンスを作成しているわけじゃないし……なんなんだろう。

=====

それはともかく、え～っと……アロエリーナに聞いたらヒントを教えてくれました。

　＞キーワード「class」と「struct」を同列に置くことが果たして妥当なのかどうか
　「妥当じゃないです」

　＞クラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
　「そんなわけないです。クラスと構造体は別物」

　＞じゃあ、クラスと構造体はどうして同じような構文になっているの？
　「それが利便性ってもんです」

……俺、この時点で納得しちゃって良い？
「クラス定義と構造体定義は別物だけど、分かりやすいように同じ構文になっている」で OTL
349 名前：デフォルトの名無しさん mailto:sage [2005/05/25(水) 21:38:25 ]
350 名前：306 mailto:sage [2005/05/25(水) 21:43:54 ]: …… System.Struct なんて無いじゃん orz 昼間俺が見てたのは幻か～ orz

え～っと……ってことは、struct は実質 System.ValueType の継承……じゃなくて……
　「struct で定義した構造体は、オブジェクト指向の世界からは System.ValueType を継承したオブジェクトのように見える」
……で良いんか？
351 名前：デフォルトの名無しさん mailto:sage [2005/05/25(水) 21:53:05 ]: 構造体はオブジェクト指向の外に属するのん？
352 名前：デフォルトの名無しさん [2005/05/26(木) 00:49:27 ]: なにこの素人？
353 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 08:53:23 ]: ちょっとありえないバカだな。
知識がないだけなら調べることで補えるが、
知識がないことに自覚がない上に無根拠な自信に満ち溢れて混乱した言葉を垂れ流すレベルになると
矯正はかなり困難。
354 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 08:57:33 ]: 構ってクンのつまらんﾈﾀだな
355 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 08:59:58 ]: 考えるな、推測するな、勝手に言葉を定義するな。仕様書を読め。
356 名前：構ってクンうざい mailto:sage [2005/05/26(木) 09:21:27 ]: >>355
　>>347
357 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 16:05:10 ]: >>1
まあ、その問題は、エロ本によるオナニーがさきか、それとも
実戦のセックスが先か、みてーなもんだ。どっちにも固有の良さはある。
でも、いつまでもオナニーに留まってるわけにはいかない。
そーゆーもんだ。
358 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 19:11:11 ]: >>1
> VisualBasicやCといった手続き型言語をずっとやってきた人が、
> C#やJavaといったオブジェクト指向言語をマスターする場合
> オブジェクト指向の概念・概論を学ぶのが先がいいのか、
> それとも、C#やJavaの言語を学ぶのが先がいいのか、
> どっちがいいと思われますか。

1. オブジェクト指向の概念・概論を学ぶ
2. その概念を、ずっとやってきたVisualBasicやCで実現してみる
3. 次にC#やJavaの言語を学び、2でやっていたことが言語のprimitiveとして
　存在することの良し悪しを考察する
4. VB5ってある意味オブジェクト指向の塊だよなあと感慨にふける
359 名前：306 mailto:sage [2005/05/26(木) 20:13:05 ]: >>352-355
おお、なんか世界の裏まで知り尽くしているっぽい発言ですな
恐れ入ります

で、結局「C# の構造体」って何者なんでしょね
360 名前：306 mailto:sage [2005/05/26(木) 20:22:49 ]: >>353 >>355

『使うだけ』ならば仕様書を読めば事足りる
細部まで理解したいのならば、それだけじゃ全然足りない

……って素直に思った
最低だな俺 OTL
っていうかそれ以前に仕様書をマトモに読めよって OTL

どうする？ＮＧ登録したければコテ付けるけど、それとも 306 のままで良い？
361 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 20:24:40 ]: 306でおっけーです。NG登録しときました。
362 名前：306 mailto:sage氏にたいですorz [2005/05/26(木) 20:27:33 ]: 去るってのも選択肢の１つか……って、そういやもうネタ無いじゃないか

メモ帳にしちまって正直すまんかった OTL
もうちょっと精進できるよう頑張ってみるよ
363 名前：デフォルトの名無しさん mailto:sage [2005/05/26(木) 20:31:57 ]: ＮＧ登録完了

でも、>>360 にはとりあえず同意しておく
「全然足りない」ときに「自己流の解釈をする」ってのは方法として間違っていると思うが

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

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