04/01/10 14:56
VisualBasicやCといった手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
2:１
04/01/10 14:57
実は私が今そうで、ずっとVBをやっていたのですが、
時代の流れもあって、C#を勉強を始めました。
C#の言語を勉強していると、
「オブジェクト指向とはどういうものかを知らないと効率悪いよな」と思い
憂鬱なプログラマのためのオブジェクト指向開発講座って本を読み始めたら
「やっぱ、言語を知らないと効率悪いよな」って思うようになって
鶏が先か、卵が先か状態になってしまいました。
皆さまは、どのようにマスターされました？
3:デフォルトの名無しさん
04/01/10 15:03
単発スレにマジレス。
概念、言語仕様を学ぼうとするのはどちらが先でも結構だが、
結局一番重要なのは実践であってそれは本では学べない。
よって、さっさとそのC#とやらを使え
4:デフォルトの名無しさん
04/01/10 15:08
漏れも単発スレにマジレス。
>>3
> 結局一番重要なのは実践であってそれは本では学べない。
あと、いい先生に逢うこと。
実践から得られた経験を整理して理解する時間と、
それを助けてくれる先生を得ることが大切。
5:デフォルトの名無しさん
04/01/10 15:46
>>1
習うより慣れろ。阿都市ね。
6:デフォルトの名無しさん
04/01/10 16:59
概念だけ覚えてもプログラムは作れない
言語だけでも、プログラムにはなる
7:デフォルトの名無しさん
04/01/10 17:05
じゃーオブジェクト指向言語を学ぶ必要は無いな
8:デフォルトの名無しさん
04/01/10 19:20
>>4
プログラミングは独学でも学べるぞ
9:デフォルトの名無しさん
04/01/10 19:28
OOの何が難しいのかが俺には分からない。
手続き型言語と基本的には同じだと思うんだが。
10:デフォルトの名無しさん
04/01/10 19:48
>>9
> 俺には分からない。
分かるように努力していない奴には
一生分からない。
11:デフォルトの名無しさん
04/01/10 20:04
>>10
少なくともお前よりは出来るし分かる。
12:デフォルトの名無しさん
04/01/10 20:09
>>11
ぷぷぷ。出来ない奴の気持ちがお前にはわからないってことだよｗ
13:１
04/01/10 20:14
>>3 >>4
実践の場ですか？
実業務は、まだVisualBasicを使っているので、
（近いうちにC#に移行という話は出ている。
話が出ているだけで、誰もやろうとはしない・・・）
仕事としてはありませんが、
フリーウェアでソフトを作るなりして
実践の場を、作っていこうと思っています。
先生は当然いません。
周りでC#もJavaもつかっている人がいないから
14:デフォルトの名無しさん
04/01/10 21:27
>>13
VB使えるならデータ中心的なプログラムスタイルは分かってるだろう。
後はただの言語仕様のお遊びだ。気負うことはまったくないと思われ。
スレ立てる暇あったらJDKインストールして適当な入門書買ってこいと。
15:デフォルトの名無しさん
04/01/10 21:34
うるせえ、いいから書いてコンパイルして走らせろ。
話はそれからだ
16:デフォルトの名無しさん
04/01/12 21:13
OO（OOAとか含まれる）じゃなくて、OOPするなら、
OO概念とプログラミング両方書いてある入門書で両方学べ。両方だ。
あと、先生がいないなら、JAVAのよいソースを読め。つか、先生なんてふつういるか？
あと結城のデザパタ盆とか呼んで実践してみるのもOOセンスつくかもな。
そしてOOの考え方やOOでの書き方で疑問がわいたらここでもどっかでもスレに書け。
運がよければよい叩きをしてくれる椰子が現れるだろう。
17:デフォルトの名無しさん
04/01/12 21:14
>>16
本厨か・・・
18:デフォルトの名無しさん
04/01/12 21:19
本中って何？
19:影
04/01/12 22:23
動くようにgotoでバシバシ飛ばしちゃえば、gosubなんていらねーんだよ。
うへへ、俺は天才だぁー。
20:デフォルトの名無しさん
04/01/12 22:25
>>19
まぁ、ある意味事実だ。
21:つぐみ
04/01/12 22:39
スパゲッティは自分のだけにしてよね。シッシッ。
22:デフォルトの名無しさん
04/01/12 22:50
必要になってから身につければ良いのでは？<OO手法
必要になってから身につけたのでは遅いかも。<言語
23:デフォルトの名無しさん
04/01/12 22:54
OO手法ってOOAとか？
つかOO手法が必要になる時ってどういうとき？
>>19 は事実だよ？
24:デフォルトの名無しさん
04/01/12 23:03
人とオブジェクトを共有する手法＜OO手法
25:デフォルトの名無しさん
04/01/12 23:39
> 1
どっちがいいと思われますか。
smalltalk(VisualWorks or Squak)を勉強すれば、両方習得
できると思うけど。
26:デフォルトの名無しさん
04/01/12 23:42
プログラミングをはじめてやるという奴にはSquakはいいんだけどね・・・
27:貧乏紙
04/01/12 23:53
「憂鬱なプログラマのためのオブジェクト指向開発講座」
すごい名前の本！！！
28:デフォルトの名無しさん
04/01/12 23:56
Squakから始めるとギャグみたいなコード書くようになってSquakから抜けられないと読んだことがある俺は小咄未経験。
29:デフォルトの名無しさん
04/01/13 00:05
Smalltalk, Squeak ね。言語より概念より、実装から入った方が良いんじゃね?
30:デフォルトの名無しさん
04/01/13 00:09
>27
いや、それめっさ定番の本なんだが...。
興味を持ったあなたは運がいい。ぜひ一読をおすすめします。
...とマジレスしてみる。
31:デフォルトの名無しさん
04/01/13 00:11
結論：
実装⇔概念
のスパイラルで。
32:デフォルトの名無しさん
04/01/13 00:21
よくSmalltalkを勧めるヤシがいるが、Smalltalk系のOOがC++/Java系のOO以上に
広まることがあるだろうか。実用を考えればやっぱり後者では？
URLﾘﾝｸ(sumim.no-ip.com:8080)
マイナーな世界で純粋を遊びたいなら、Smalltalkなぞ汚くてやってられん、という人も多いし。
ｽﾚﾘﾝｸ(tech板)
33:デフォルトの名無しさん
04/01/13 00:35
Smalltalk を勧めるのはデザインパターンとかのからみもあるのでは。
34:デフォルトの名無しさん
04/01/13 00:36
>>31
激同。概念だけだと、犬が「ワン」猫が「ニャー」の話で終わる。
そう思って憂鬱本と同じアプローチで社内研修をやってみた。
コードはJava用とVB.NET用と両方用意、VBしか知らない人のためのコードの説明も加えた。
…生粋のCOBOLerから「わからん」と苦情がきますた…
35:デフォルトの名無しさん
04/01/13 01:11
>>33
GoFならJavaでも++でも出来んじゃん。って事ではなくて？
36:デフォルトの名無しさん
04/01/13 02:15
欧米のOOコミュニティではSmalltalkは現役だから。
プロトタイピングしやすいし、概念やデザインの説明に Smalltalk 使われたりするし。
37:デフォルトの名無しさん
04/01/13 04:59
>>36
ソースプリーズ。
つか、OOコミュニティって何よ？小咄コミュニティとか言う落ちじゃ？
38:デフォルトの名無しさん
04/01/13 05:36
oopsla とかに出かけていく奴らじゃねぇの?
それより、C++ と Java を一括りにして、Smalltalk と線引きしている基準が分からん。
>Smalltalk系のOOがC++/Java系のOO以上に
39:デフォルトの名無しさん
04/01/13 05:52
Kent Beck とか Ward Cunningham は Smalltalker だよね。
40:デフォルトの名無しさん
04/01/13 09:48
GoF本のRalph JohnsonもSmalltalkerだし
サンプルコードにも結構Smalltalkのが入ってるな。
41:デフォルトの名無しさん
04/01/13 11:02
36って恥ずかしい
42:デフォルトの名無しさん
04/01/13 22:55
ANSI 準拠の言語で、もっとも早くオブジェクト思考の機能を言語使用に
盛り込んだのはCommon Lisp。
よってLispをしなさい。
43:デフォルトの名無しさん
04/01/13 22:57
>>42
ANSIって言語機能の標準とか規定してたの？CLRみたいだな。
44:自分で整理できてないが
04/01/15 19:54
>>38
C++,Java データ型が思考のベース。
小噺 なにはなくともオブジェクトとメッセージ送信ありき。
前者は、問題対象がオブジェクトの世界。後者は問題記述空間が（も？）オブジェクトの世界。
で、後者が半端だという人達は、ｽﾚﾘﾝｸ(tech板) へ。
45:名無しさん＠Linuxザウルス
04/02/18 21:02
こんな感じで概念が学べるなら楽しそうでいいんだが
[190]名無しさん＠Linuxザウルス<>
04/02/16 21:49
>>184
妹クラスを作って１２人の妹を派生させて
呼びかけると
お兄い様
お兄いちゃん
お兄いたま
(ry
と応答させて
おお ポリモーフィズム マンセー！！
という感じで理解しろという事かな
46:デフォルトの名無しさん
04/02/18 21:24
>>45
俺ならそんなもんが出た瞬間速攻でPC叩っ壊す。
そして氏んでくれ
47:最凶VB厨房
04/02/18 21:36
>>45
お前の発想はキモイ。
48:デフォルトの名無しさん
04/02/18 23:44
28 名前： デフォルトの名無しさん 投稿日： 03/05/21 10:00
フサギコはギコ猫のサブクラスだから、
フサギコクラスを作るときに「フサフサだぞ」メソッドを記述すれば、
ギコ猫から継承したメソッド「逝ってよし」「ゴルァ」が存在し、
（さらに）フサギコ特有のメソッド「フサフサだぞ」が存在するクラスになる。
49:デフォルトの名無しさん
04/02/18 23:49
>>48は基礎。>>45に到達して初めてOOのおもしろさが分かる。
50:最凶VB厨房
04/02/19 00:07
キモイやつだけがわかるOOのおもしろさを語られてもねぇ。
51:デフォルトの名無しさん
04/02/19 18:52
馬鹿か！！
オブジェクト指向ってなんだよわかんねーとか言ってるやつは
明らかに実戦不足なんだよ！
実戦経験が豊富であれば、自然とわかるものなんだよ！！
52:デフォルトの名無しさん
04/02/19 23:01
>>51
そうだな。実践で生半可なOOを振り回すと火傷する。
53:デフォルトの名無しさん
04/02/21 15:09
>>51と>>52は反対のことを言ってる気がするんだが。
どちらかというと>>52に同意
54:デフォルトの名無しさん
04/02/22 01:46
> 51
オブジェクト指向言語て、Cや、Pascal、Fortranのよう
な手続き型に
1.構造体のメンバーに対して、アクセス制御ができる。
2.ダウンキャストができる。
3.（引数が違えが）同じ名前の関数を何個定義できる。
を仕様として加えただけだ。
cで書かれた有名なopen sourceソフトを解析すると、
2.3はトリッキーな事をしない限り無理だか、１は、
自主的に制御している。
55:デフォルトの名無しさん
04/02/22 01:47
>>54
オーバーロードとOOって関係あるのか？
56:デフォルトの名無しさん
04/02/22 01:58
て言うか、>>54 は >>52 が指摘してるタイプの奴だと思う。
57:デフォルトの名無しさん
04/02/22 10:57
Javaでオブジェクト指向を学ぶならJavaの基礎的な言語学習から始めた方が
わかりいいな。
「独習Java」でもそこそこいけるもんかな。
それから他の本に手を出すという要領で。
C言語経験者ならちょっとだけJavaの基礎をしっておけばすぐにとびつける。
58:デフォルトの名無しさん
04/02/22 11:17
ぶっちゃけ、オブジェクト指向を学ぶなら
結城浩の「Java言語で学ぶデザインパターン入門」でも
かなりの収穫はあると思うが。
59:830
04/02/22 11:23
りんごの色=赤い プロパティ。
りんご 投げると放物線を描いて飛んでいく。がメソッドだよ。
このりんごを派生させんのが、ポリもフィズ無だ簡単だ。
60:デフォルトの名無しさん
04/02/22 12:54
＞りんご 投げると放物線を描いて飛んでいく。がメソッドだよ。
メソッド名に具体的な挙動まで定めちゃったらポリモルのしようがないと思うのだがどうか？
61:デフォルトの名無しさん
04/02/22 17:32
メッセージとメソッドは別
「投げる」メッセージを受信すると「放物線でとんでく」メソッドを起動するんならいいんじゃない
62:デフォルトの名無しさん
04/02/22 17:35
>>61
それなら良いんだが>>59からそれが感じられないんで
63:デフォルトの名無しさん
04/02/22 17:40
object '宇宙のリンゴ' implements method '投げる' invokes '直線で飛んでいく'
64:デフォルトの名無しさん
04/02/22 17:44
object: '宇宙のリンゴ' accepts message: '投げる' invokes method: '直線で飛んでいく'
65:デフォルトの名無しさん
04/02/24 20:18
>>45
よかったな、おまえ向きの連載がはじまったぞｗ
ｽﾚﾘﾝｸ(tech板:205-番)
66:デフォルトの名無しさん
04/05/02 00:43
UML勉強して、GOF本、リファクタリング読んで、
どっちもそれなりに理解していろいろプログラム組んでる
んだが、他にOOP関連で勉強しておいた方がいいモンて
ある？
67:デフォルトの名無しさん
04/05/02 02:00
ＯＯプログラミングはなぜ使いやすいかって考え出すと非常に難しい
ポリモーフィズムによる一貫性が、人間にやさしいと思うんだけどね
真の人間の生理学を知らないと分からないと思う
ＯＯプログラミングやると勝手にプログラミング上手くなっていくっていうのは
もともと人間に備わっている能力を引き出すからだと思う
もともと備わってる能力を知るってのは、こりゃ難しい やってみないとわからないんだから
やってみると意外とできてしまうってのは不思議だ
68:デフォルトの名無しさん
04/05/02 02:02
んでまぁ、プログラミング覚える一番の早道はＯＯな言語でＯＯなライブラリを使ってプログラミングすることだと思うよ
身につけるっていう感覚に近い 数学の解き方覚えるようなもんだ
69:デフォルトの名無しさん
04/05/02 02:09
おもむろに Java、C#、Ruby のどれかでプログラミングをする。
ある程度書いていると「何か違うなぁ」の壁にぶち当たる。
そこでオブジェクト指向の概念本、デザインパターン本を読む。
これが一番近道だと思う。概念から入るのは余りお勧めできない。
「オブジェクト指向のほうが自然で楽だわ」という感覚を体感できないから。
70:デフォルトの名無しさん
04/05/02 03:03
そして速度を求め初めてCやアセンブラに回帰する
71:デフォルトの名無しさん
04/05/02 03:35
>>70
ただの回帰に見えるが実は螺旋の構造になっている。
戻ると1つ上のステージになっているでしょう。
72:デフォルトの名無しさん
04/05/02 04:47
>>67-71
未消化丸出し
73:デフォルトの名無しさん
04/05/02 11:36
>>72
消化できてる香具師なんているのか
74:デフォルトの名無しさん
04/05/02 20:47
実践が先です。
75:デフォルトの名無しさん
04/05/02 21:03
コードを書かずに覚えることはできません。
76:デフォルトの名無しさん
04/05/03 01:01
続きはこちらで
ｽﾚﾘﾝｸ(tech板)
77:デフォルトの名無しさん
04/08/21 08:17
BASICから始めて、C言語とかそういうパターンでやってた人は
カプセル化とか、ポリモーフィズムとか言う概念が言語で実装されてるのみたら
すぐに飛びつくと思うんだよね。
なんて言ってもそれで一番苦労するから
というわけで概念に一票
78:デフォルトの名無しさん
04/11/03 16:35:28
保守
79:デフォルトの名無しさん
04/11/03 17:35:21
こんな糞スレ保守してな(ry
80:デフォルトの名無しさん
04/11/04 01:02:35
>>67
そういう考えは、間違ってはいないが、しかし、それがオブジェクト指向を困難にしていると思う
「オブジェクト指向でなぜ作るのか」を読むと、その敷居をとりさってくれるよ。
81:デフォルトの名無しさん
04/11/04 01:17:17
オブジェクト指向とは働き蟻が効率的にモジュール＝クラスを利用するための技術なので
概念や哲学は必要ありません。
82:デフォルトの名無しさん
04/11/04 01:24:51
「オブジェクト指向でなぜ作るのか」って本は大分前に本屋で立ち読みしたんだけど
手続き型のプログラミングではグローバル変数を除去出来ないとかいう
ふざけたことが書いてあったんで俺の中では糞本認定されてます。
83:デフォルトの名無しさん
04/11/04 06:28:11
生まれたときからＴＶがあったような奴にはラジオの有難味は分からんて
84:デフォルトの名無しさん
04/11/04 06:50:22
まったく。
グローバルな破壊的代入を制御し隠蔽するためにどれだけの苦労が払われてきたか理解できないのだろうな。
85:デフォルトの名無しさん
04/11/07 16:12:17
>>1
きみ自身が
「手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合」
なんて事を前提にしているんだから、
オブジェクト指向の概念・概論を学ぶのが先がいいに決まってる。
さもないとこういうマヌケなことになる。
ｽﾚﾘﾝｸ(tech板:83-85番)
86:デフォルトの名無しさん
04/11/07 18:49:36
もうあきた
87:デフォルトの名無しさん
04/11/07 18:50:11
なんで同じようなことを別スレでなんどもなんども…
88:デフォルトの名無しさん
04/12/11 00:25:56
学習もスパイラルがいい。作りながら概念も同時に学べ。
どっちかが先とか言う奴は糞ウォーターフォール推奨者。
89:デフォルトの名無しさん
05/02/05 10:31:17
age
90:デフォルトの名無しさん
05/04/10 02:40:23
自分の意見を言わせていただきます。
『概念学習』を先にしたほうがいいと思います。
自分C言語はできたのですが、学校でJavaを習っていた時全く理解できませんでした。
よく言われるような『どこが分からないのか分からない』状態でした。
でどうしても分からないままでいたくないのでオブジェクト指向の載っている本を2,3冊買いました。(多分悪書の部類の本)
全く理解できませんでした。
長々と説明されているのですが、全く理解できませんでした。
でも日経系の本でオブジェクト指向のことが書かれている記事を見ていたら『あれ？もしかしたらこういうことかな?』と
うっすらと分かりかけてきたところを何度も見ていたら理解できるようになりました。
急にわかるようになってくると今までやってきたところがすぐ理解できました。
っていうかね
Javaを教える先生が『オブジェクト指向』の概念学習より言語学習を教えることをメインにおいたために、生徒の全員が全く理解できませんでした。
毎回何十個も言語学習をするよりも、半年かかってもいいから概念学習をしっかりさせたほうがいい。
これは多分英語でもいえると思う。
大学に在学していたとき、アメリカ人の先生が
『今学校の方針でこのような学習法(言語学習)をしているけど、正直概念学習のほうがいい。
単語を暗記させるよりも、辞書片手に英語の新聞の翻訳をさせたほうがよっぽどいい勉強になる』
と言った気持ちがオブジェクトをなんとなく分かりかけたときに理解できた。
どこのプログラマーでも困ったら本見るんだからそれでカバーできない概念学習をしっかりしたほうがいいと思う。
91:デフォルトの名無しさん
05/04/12 23:39:23
オブジェクトって単に関数を要素にとれる構造体でそ？
92:デフォルトの名無しさん
05/04/13 13:22:12
つるな
93:90
05/04/19 15:05:07
先生。何かこの教科書、教科書名の後ろに㊦って書いてあるんですが。
しかも重要なところに『上書参考』って・・・・。
94:デフォルトの名無しさん
05/04/19 19:48:34
両方バランス良くやった方がいいって。
概念がわかっても、それが一体何の役に立つのかわからなくてイライラしたやつが
暴動起こして終わると思うな。
95:脳内PG
05/04/19 20:00:19
私は言語が先だと思います
言語をやる内に、オブジェクト指向は理解できると思いますし
96:デフォルトの名無しさん
05/04/19 20:06:42
ＯＯなんぞが知れ渡る前から、擬似オブジェクト指向Pやってると、
どうしても概念レベルで、実装が頭をよぎっちまわない？
酷いときは妥協のしどころまで考えてたり。
97:デフォルトの名無しさん
05/04/19 20:25:33
日本語で話せよ。
98:デフォルトの名無しさん
05/04/20 01:44:48
>>93
与えられた本しか読まない馬鹿にはどんな本を与えても無駄。
99:デフォルトの名無しさん
05/04/23 20:03:38
ぉぃぉい結局どっちなんだよ？始めようと思ったのに出来ねーじゃねーか！もぅCとJava勉強すりゃいいのか？どうなんだよﾎﾞｹがぁぁぁぁぁぁぁぁぁ！
取り敢えず手始めにCでもするかな…
100:デフォルトの名無しさん
05/04/23 21:09:17
どちらが先なんて決めつけないで
糾える縄の如く理解していけばいいし
実際みなそうしている
101:デフォルトの名無しさん
05/04/25 07:53:16
VBなどで経験があるなら、階層化プログラミングはわかっているんだよね。それなら、
「カプセル化」と「継承」は実戦から入ったほうが手っ取り早い。
｢多態性オブジェクト」とか「仮想関数」は、概念の勉強を先にしたほうがいいかな。
102:デフォルトの名無しさん
05/04/25 09:18:55
>>101
継承・仮想関数も全てポリモーフィズムのためにあるわけだから、
どっちが先もクソもないだろ。
103:デフォルトの名無しさん
05/04/25 11:46:52
「階層化プログラミング」と言う奴の言うことですからｗ
104:デフォルトの名無しさん
05/04/25 20:03:08
ガイネンガクシュウ
略して
ガイガク
105:デフォルトの名無しさん
05/04/26 08:10:22
オブジェクト指向を教えるとき、どの言語がよいでしょうか？
106:デフォルトの名無しさん
05/04/26 08:56:31
ｓｍａｌｌｔａｌｋ
107:デフォルトの名無しさん
05/04/26 15:03:01
>>105
メッセージングまんせーなら Smalltalk
クラスまんせーなら Java か C++
108:デフォルトの名無しさん
05/04/26 15:04:26
>>105 >>107
オブジェクトまんせーならSelfか。
109:デフォルトの名無しさん
05/04/26 15:25:29
ここ数年、オブジェクト指向を覚えるときには、Javaが使われてきました。
Javaを使うのには、いくつかの理由があります。
・広く知られている
・C を基本とした文法（一般的なスタイルとなりつつあります）
・フリーで高性能な開発環境が利用可能である
・Javaの知識があれば仕事に就ける
こういった理由から、私はJavaの使用をやめさせようとはしませんでした
（C#にもこういった特徴があり、いずれC#が代わりになるだろうと指摘してはいたんですが）。
ただ、Javaだけに任せようとは思っていません。
Java、C#、C++はいずれも、オブジェクト指向プログラミングのある形を提示してくれていますが、
誰かにオブジェクト指向を紹介するならば、選択肢も紹介してあげるといいでしょう。
選択肢とは、RubyとPythonのことです。
両言語とも、動的型言語です。静的型言語と一緒に使えるようになってれば便利だと思います。
どちらも大変便利な言語です。ちょっとしたスクリプトで自動化して解決するような仕事はたくさんあります。
技術者たるもの、１つくらいはスクリプト言語を隠し持っているべきですね。
110:デフォルトの名無しさん
05/04/26 21:17:07
SmallTalk以外はオブジェクト指向のフレーバーがある偽物といへり
111:デフォルトの名無しさん
05/04/26 21:49:16
Smalltalkによるプログラミングは、私にとって今でもお気に入りの経験だから、
その気持ちは分かります。
私のようなSmalltalkファンですら、もう何年もSmalltalkの環境（image）を立ち上げていません。
112:デフォルトの名無しさん
05/04/26 21:50:19
個人的には、Rubyが気に入っていますけど。
広く使われている（かつ利用可能な）のはPythonですし、
Rubyはより純粋なオブジェクト指向ですので（学ぶのには最適です）
私にとってみれば、すがすがしい感じがします。
あと、Rubyにはブロック（コード群を簡単にオブジェクトとして扱う機能）がありますね。
ブロックは強力なプログラミングツールで、コードの構造化についての多くの考え方を
学ぶことができます。
他のやり方だと、なかなかこうはいきません。関数型言語の入門用にも良いですね。
スクリプト言語の強みは、プロのプログラマが日常的に使えることなんです。
113:デフォルトの名無しさん
05/04/26 22:03:54
なあ、オブジェクトとクラスとインスタンスの違いを説明してくんない？
オブジェクト指向の本読むと、みんなごっちゃでわけわかんなくなるの･･･
114:デフォルトの名無しさん
05/04/26 22:10:28
クラスというのは、型情報。
基本的に、プログラム内では一意に決まり、いつ参照しても同じ結果が得られる静的な情報。
インスタンスというのは、クラスという型情報を元に、メモリ上に生成されるデータの実体。これをオブジェクトともいう。
プログラムの処理とともに内部変数を変化させる動的な存在。必要に応じて複数生成されることも多々ある。
115:デフォルトの名無しさん
05/04/26 22:20:11
>>114
教えてくれてありがと
クラス＝型
オブジェクト＝インスタンス＝メモリ上の実データ
という理解でいいの？
オブジェクトのメンバ関数のメモリ上の実コードはどういう言い方するといんだろ？
クラスのメンバ関数って言った方が正しいのかな？
116:デフォルトの名無しさん
05/04/26 22:22:10
>>115
おっと、
オブジェクト＝クラスのインスタンス
と書いているみたいですね。
117:デフォルトの名無しさん
05/04/26 22:26:42
メンバ関数には、クラス所属のものと、インスタンス（オブジェクト）所属のものがある。
たとえば
class Hoge
{
void foo();
static void bar();
};
というC++クラスの場合、fooはインスタンス所属で、barはクラス所属。
クラス所属の関数は、インスタンスを作らなくてもコールできる。
こんなふうに
Hoge::foo();
一般にこれをクラスメソッドとか、クラス関数と呼ぶ。
インスタンス所属の関数は、当然インスタンスを作らないとコールできない。
Hoge *hoge = new Hode();
hoge->bar();
あんまりいわないけど、あえて言うならインスタンスメソッド。
118:デフォルトの名無しさん
05/04/26 22:29:02
オブジェクトとインスタンスはほぼ同じ意味だが、ニュアンスの違いがある。
オブジェクトのほうがより抽象的で、インスタンスのほうが具体的なニュアンスを持つ。
でも、かなり混同もされる。
119:117
05/04/26 22:30:38
ごめん間違えた。
Hoge::bar();
と、
hoge->foo();
だった
120:デフォルトの名無しさん
05/04/26 22:48:24
>>118
そう、そのニュアンスの違いが“理屈で”解らない。
ストラゥストラップの「プログラミング言語C++」を読んでると、
ニュアンスの違いがどこにあるのか解らなくなる
ストラ先生は、オブジェクト＝クラスという意味で使っているみたい
そしてインスタンスって用語は出てこない。
で、他の本を読むとオブジェクト≒クラス、オブジェクト≒インスタンス
のような意味で使う。
オブジェクト指向を特集している今売りの雑誌でも、
オブジェクト＝物だといいつつ、
明確に定義しないまま“クラス”と“インスタンス”という用語を使う
書き手によってさまざま。困ってしまいます。
121:デフォルトの名無しさん
05/04/26 22:53:48
俺もそのへんが未だによく分からない。
オブジェクトはクラスもインスタンスも含む概念で、
言語や状況によって、インスタンス=オブジェクトと見なせる場合があるのだと
強引に理解しているが、根拠はない。
122:デフォルトの名無しさん
05/04/26 22:58:34
>>119
static関数と非static関数の違いは理解してるつもり
staticメンバ関数はthisポインタがなく、引数、auto変数/定数を除くと
クラスのstatic変数/定数しか直接参照できない。
非staticメンバ関数は（暗黙の）thisポインタがあり、
上に加えてメンバ変数を参照できる。
Hoge myHoge; //と宣言すると
myHoge.foo(); // static関数と
myHoge.bar(); // 非static関数は同じ呼び出し方になる
123:デフォルトの名無しさん
05/04/26 23:02:03
>>120
確かに、オブジェクトというのは微妙な言葉だな。
場合によってはクラスを表現するオブジェクトというものもあらわれる。
たとえば、Javaだと、クラス情報をランタイムに参照できるようにメモリ上にクラス情報を置いてくれる。これはつまり「クラス情報のオブジェクト（インスタンス）」といえる。
このランタイムクラス情報は、あくまでもクラスについての情報を保持する別のオブジェクトであって、クラスそのものではない。
というあたりが自分のもっているイメージ。
あと、
オブジェクト指向は、「分析」と「設計」で分けて語られる。
「分析」は対象領域を抽象的に分類、整理する手段としてのオブジェクト指向で、
「設計」は実際にプログラムに落とすためのオブジェクト指向。
どっちの話をしているのか意識しないとすぐ混乱する。
分析レベルだと、あんまりインスタンスという言葉は使われない。
設計レベルではやたらと増える。
そういう意味でもインスタンスは具体的なニュアンスを与える。
124:デフォルトの名無しさん
05/04/26 23:04:49
object classがすべてのclassの親で、その子のmetaclass classがすべてのmetaclassのclassで、すべてのmetaclassのinstanceがclassで、という親子関係はすべてのObjectOriented言語に継承されているのかどうか
125:デフォルトの名無しさん
05/04/26 23:05:23
>>122
static関数と非static関数が逆転してたす。
126:デフォルトの名無しさん
05/04/26 23:06:13
必ずしも、親子関係とはいえないような気がする。気がするだけだけど。
127:デフォルトの名無しさん
05/04/26 23:11:41
>>123
＞クラスを表現するオブジェクト
GoF本に、“クラスオブジェクト”という用語がでてきます。
型情報を持ったオブジェクトと理解しています。
具体的には、WindowsのCOMコンポーネントがtypeライブラリ情報をもっているイメージ。
SmallTalkは私のプログラマ・センスでは理解できません。
＞「分析」と「設計」で分けて語られる
オブジェクトはアナリスト用語
クラスとインスタンスはプログラマ用語
と使い分けられるといいのに･･･
128:デフォルトの名無しさん
05/04/26 23:12:55
集合論で解釈してはどうか
要素の集まりが集合
しかし集合を要素とする集合も考える
ある集合の要素を作ろうとするなら
要素としての集合に対して操作をする
操作の対象はあくまで要素というわけ
129:デフォルトの名無しさん
05/04/26 23:14:34
>>126
確かに
親子関係とは集合の包含関係のこと
集合とその要素との関係も親子関係と言ったのは間違い
130:デフォルトの名無しさん
05/04/26 23:21:28
>>124
>metaclassのinstanceがclass
これは、C++のtemplateを理解しようとする時に出てくる概念の壁(^^)
template関連以外ではこういう言い方は成り立たないのでは？
というか、templateのパラメータとしてのクラスと
オブジェクトの型であるクラスを混同してしまい、
最後にはちゃぶ台をひっくり返すケースだと思いますけど
131:デフォルトの名無しさん
05/04/26 23:26:11
すべてはobject
instanceとはclassに所属しているobjectであることを強調したもの
132:デフォルトの名無しさん
05/04/26 23:42:19
>>131
オブジェクト≡クラスのインスタンス
というのが、おおかたの書籍にでてくる理解で
インスタンス≡クラスのオブジェクト
という理解は、そもそも不要で混乱のもとだと思います
133:デフォルトの名無しさん
05/04/26 23:49:02
>>132
なぜかね？
classによって産み出されるobjectのことをそのclassのinstanceと呼ぶのだが
つまりinstanceとはclassという概念に従属していることを強調する用語
134:デフォルトの名無しさん
05/04/26 23:50:54
>>124に関して、
相撲流遠く (綴り、Smalltalkだっつーの)では
・クラス継承関係
・インスタンス関係
の他に
・メタクラス関係
があるのが興味深いんだ。
C++みたいな静的言語では、おもいっくそネグっちゃってるが、
JavaやC#では、リフレクションとかメタデータって名前で復活してる。
ちなみに相撲流遠くのクラス階層は、およそこんな感じ。
Object
△├－－－－－－－－┬－－－(略)
├｜－－－－－－－┐｜
｜↓instance ｜↓ instance
MetaClass Class
△ superclass △ superclass
｜ ｜
FooMetaClass ←－－ FooClass
metaclass ｜
｜instance
↓
aFooInstance
【Class変数/メソッド担当】【Instance変数/メソッド担当】
135:デフォルトの名無しさん
05/04/26 23:53:19
リファレンスは、例えば
OO広場 Happy Squeaking！の32ページ目あたり
URLﾘﾝｸ(www.ogis-ri.co.jp)
136:134
05/04/27 00:05:33
ぁ、>>134の最終行。。。とりあえず無視しといてね(はぁーと
137:デフォルトの名無しさん
05/04/27 00:22:15
>>134のMetaClass, FooMetaClass, Class, FooClassの状況は若干修正が必要だろう
MetaClassはFooMetaclassのclass（FooMetaclassはMetaClassのinstance）
FooClassはFooMetaclassのinstance（FooMetaclassはFooClassのclass）
ClassがFooMetaclassのsuperclass（FooClassはClassのinstanceとしての性格を継承）
138:デフォルトの名無しさん
05/04/27 00:36:12
ああ、すまそ。
うろ覚えで書いちまった。(記憶力の減退か・・・)
正確な所は、
URLﾘﾝｸ(www.ogis-ri.co.jp)
見てね(はぁーと
相撲流遠くのクラス階層は
・メタ関係にあるオブジェクト(クラス)がインスタンスを生成する
というルールに基づいてる、と。
139:デフォルトの名無しさん
05/04/27 00:43:43
僕は、オブジェクト指向の概念をまず学習すべきだと思うな。
もちろん、目指すゴールによって一概には言えないけど。
クラス使うと便利な面が多々あるし、
しらなきゃその恩恵を受けられないわけだし。
確か、ドラクエのモンスターを題材として
オブジェクト指向を説明しているいい本があったな。あれですぐ飲み込めた。
なんていう本かは忘れた。
140:デフォルトの名無しさん
05/04/27 00:46:12
オブジェクト指向を教えるのに、言語を使ったほうが良いかどうか？
言語を使わない案というのは、原則について議論するということになるでしょうね。
おそらくはUMLを描くとか、そんな感じでしょうか。
私は、まずは言語を使って、何かできるようになるほうが断然いいと思いますね。
私にとってソフトウェア設計とは、数学みたいなものなんです。
読んだり聞いたりするだけでは、なかなか理解が深まりません。
実際にやってみないと理解なんかできません。
だから、本当にオブジェクト指向を理解したいのなら、実際に何かを作ってみるべきです。
141:デフォルトの名無しさん
05/04/27 08:44:48
僕は私。
142:デフォルトの名無しさん
05/04/27 19:25:42
００ってなに？
143:デフォルトの名無しさん
05/04/27 19:28:45
クラスオブジェクトインスタンス
と
クラスインスタンスオブジェクト
は異なるわけか。
144:デフォルトの名無しさん
05/04/28 00:04:45
Objectって、目的というか対象というか、そっちの(英語の)意味で考えると個人的にはしっくりきたり。
（下手に訳すのがいけないのかも。）
145:デフォルトの名無しさん
05/04/28 00:08:58
this じゃなくて self な文化だと、物って訳した方が自然に感じるよ
146:デフォルトの名無しさん
05/04/28 00:32:03
>>145
意味ワカンネ
147:デフォルトの名無しさん
05/04/28 08:56:43
目的物
148:デフォルトの名無しさん
05/04/28 08:58:19
>>143
その二つはなに？
149:デフォルトの名無しさん
05/04/28 10:21:03
俺も見た記憶があるなぁ
何気にRPGとかだとクラスの有効利用をカンタンに理解できそうなきガス
150:デフォルトの名無しさん
05/04/28 11:24:27
>>143
> クラスオブジェクトインスタンス
new Point(1,2)
> クラスインスタンスオブジェクト
Point
かな？
151:デフォルトの名無しさん
05/04/28 13:56:31
実際オブジェクト指向を勉強して
それをどうプログラミングしていくかというところで、ぽかーん
という状態です。
152:OO太郎
05/04/28 15:22:59
プログラミングの初心者の俺が教えてやろう。オマエラよく聞け。
オブジェクト指向というのは、プログラミングのスタイルだ。JavaやC++は
オブジェクト指向言語だといわれるけど、非オブジェクト指向的な
プログラミングをしようと思ったら出来る。オブジェクトなんて使わなくても
同じように動くプログラムは作れる。
だから、プログラミングスタイルとしてオブジェクト指向をしっかり覚えないと
いつまでたってもオブジェクト指向のプログラミングは出来るようにならない。
俺みたいにBASICで育った者は特にそうだ。
153:OO太郎
05/04/28 15:40:00
オブジェクト指向がなんでこんなにもてはやされているかというと、
いまの、ウインドウズを中心としたいわゆるGUIのプログラミングに
ぴったりな概念だからだ。
オブジェクトはそれほど大騒ぎするほど難しい概念じゃない。巷に溢れる
説明の下手な著者の書いた本がくどくど説明するほど抽象的な概念
でもない。オブジェクト＝物だ。ウインドウズだったら、それぞれの
窓はオブジェクトだ。あるいは、窓の中にあるボタンの一つ一つが
全てオブジェクトだ。
トランプのゲームだったら、トランプの一枚一枚がオブジェクトだ。
クラスというのは、オブジェクトを作る型みたいなもの。トランプには
必ずマークと数字がある。そういう決まりをまとめたものがクラスだ。
トランプクラスからトランプの一枚一枚を作り出すと、それがオブジェクト
になる。例えば
Trampu tramp1 = new Trampu (ハート、A）；
Trampu tramp2 = new Trampu (ハート、２）；
・・・・・・・・・
Trampu tramp52 = new Trampu （クローバー、K）;
という感じにトランプオブジェクトが５２個作れる。それぞれが
トランプクラスのインスタンスになるわけだ。
154:OO太郎
05/04/28 15:52:20
あと、オブジェクトの面白いのは、トランプの例のようにマークと
数というようなデータだけじゃなくて、いわゆるサブルーチンのような
機能（これがメソッドだ）も一まとめにしてしまうことが出来るってこと。
例えば、トランプゲームだったら、「持ち札」なんてクラスが定義できる
カも知れない。プレーヤーが4人いたら、それぞれ持ち札があるわけ
だから、持ち札１、持ち札２、持ち札３、持ち札４というような
オブジェクトが作れる。例えば「持ち札１」には、ハートの３、
スペードの４、クローバーのA、ダイヤの７がある。それはみんな
インスタンス変数になる。で、メソッドとして、「カードを引く」
「カードを捨てる」「カードの枚数を得る」「同じマークを捜す」
「同じ数を捜す」などなどいろいろなメソッドが考えられる。
それらを全てクラスで定義しておいて、実際に「持ち札１」にたいして
そういうメソッドを呼ぶことによって、「持ち札１」の内容を変更
したり、内容を見たりすることが出来る。
155:OO太郎
05/04/28 16:06:15
トランプゲームだったら、もう一つ、真ん中においておく「カードの山」
なんて、クラス考えてもいいかもしれない。そこから作られる、
インスタンスとしての「カードの山」オブジェクトはインスタンス変数
として、カードの数、カードの種類などをもっていて。メソッドとして
は、「カードを出す」、「カードを切る」など考えられるかもしれない。
156:OO太郎
05/04/28 16:21:57
あと、もう一つGUIプログラミングのもう一つの特徴は、イベント指向
ということだ。昔のプログラミングみたいに、一行目から始まって、
順々にコンパイラでもインタープリターでも読んでいって、順次実行
していく、いわゆる手続きがたのプログラミングとは違う。
プログラムは、キーボートや、マウスといった入力装置からの割り込み
あるいはメッセージを待っていて、マウスがクリックされたというと、
それを処理するルーチンがある、マウスがドラッグされた、というと
それを処理するルーチン、というように、そういう各々のイベント
処理を中心にプログラムが構築されていく。
で、そういう処理が、アル程度OSに任されてしまっているので、
プログラマーにはコントロールできない部分がある。例えば、描画
にしても、自分が、「描け」と命令するというよりも、絵を特定の
机の上に置いておくと、システムが定期的に来て、それを持っていって
画面に貼り付けてくれる、というようなイメージだ。絵を変化させ
たいばあいは、別の絵を描いといて、それをまた特定の机の
上に置いておいて、システムが持っていくのを待つ。
こういった思考パターンによるプログラム作りにがつまり、
オブジェクト指向のプログラミングということだろうと、
素人の俺は思うんだが。
157:131
05/04/28 16:22:19
>>133
すいません、寝ちまいましたm(_ _)m
オブジェクト指向プラグミングする際に
1. まず、プログラミング対象を分析した結果としてオブジェクトを抽出する
2. 次に、オブジェクトの設計・実装の結果としてメンバ変数とメンバ関数による
オブジェクトの定義であるクラスを導出する
3. 最後に、プログラムの実行の結果としてクラスのインスタンスがメモリ上に
割り振られる
この場合、オブジェクトという用語に必要な概念は、
プログラミング対象を分析した結果としてオブジェクトという用語であって、
それ以外の、
インスタンス≡クラスのオブジェクト
の“オブジェクト”の用語の使い方は、 “一般概念としてのオブジェクト”という用語の適用を
オブジェクト指向プラグミングというコンテキストに持ち込むことになるからです。
つまり、オブジェクト指向プラグミングというコンテキストでの“オブジェクト”の用語の
因果関係、つまり順序性の意味を無視しているということです。
「色即是空・空即是色」という禅問答は、アカデミック（学術）的な思考の中では
成立するのかもしれませんが、エンジニアリング（技術）的な思考の中では、
「色即是空」であるか、さもなければ、「空即是色」のどちらかでなければ、
未知の技術に対する理解は混乱するだけなのです
158:OO太郎
05/04/28 17:04:55
インスタンスって、英語で「事例」とか「実例」という意味で、
クラスに具体的なデータを与えて作ったインスタンスつまり
「具体例」がオブジェクトなんでしょ？
クラスは基本的に、オブジェクトを作るための枠組みであって、トランプ
でいったら、白紙でマークや数字が印刷される前の状態だと思う。
159:デフォルトの名無しさん
05/04/28 17:38:16
初心者に教えてもらいたくない
160:デフォルトの名無しさん
05/04/28 19:05:35
オブジェクト指向自体はわかったんだけど、大規模なシステムのソースを理解するのが大変なんだよね。
こういうのってどうやってるんだろ・・・。
継承されまくりでどこにメソッドがあるのかもよくわからないし・・・。
161:デフォルトの名無しさん
05/04/28 19:40:53
>>160
とりあえずdoxygen通してみるとか。
162:160
05/04/28 20:50:27
>>160
なるほど、よさげですね。
ためしてみます。アドバイスありがとうm(_ _)m
163:デフォルトの名無しさん
05/04/28 21:09:51
>152-156
素人の説明って結局わからん、ってのはよくわかった、
164:デフォルトの名無しさん
05/04/28 21:29:38
俺は、C-magazine創刊号に載ってたトランプゲームによるOO説明(ソース付き)
思い出しちまったよ。
OOトランプの役者としては、
・トランプの各カード
・カードの山
の他に、
・ゲーム (トランプがルール知ってる訳じゃなくて、ゲームにルールがある)
・プレイヤー (一人(占い等)または複数)
・ゲームの場 (占いの内容とか、ゲームが何回戦目かとか)
も要るな。
165:デフォルトの名無しさん
05/04/28 21:34:09
>>163
そうかね？よく理解していると思ったが
>>158
Integerクラスのインスタンスが1,2,3などの整数
Integerクラスを任意の整数と捉えることも可能だが
任意の整数の全体と捉えることの方をおすすめしておこう
166:デフォルトの名無しさん
05/04/28 21:36:55
素人(アル中)が素人に説教するインターネッツ
167:デフォルトの名無しさん
05/04/28 21:39:15
おまいの議論って、
結局 Smalltalkのクラス階層として結晶した概念を、
後付で説明しようともがいているだけだな。
>>165
＞Integerクラスのインスタンスが1,2,3などの整数
＞Integerクラスを任意の整数と捉えることも可能だが
＞任意の整数の全体と捉えることの方をおすすめしておこう
誰もそんな事、話題にしてないしｗ
168:デフォルトの名無しさん
05/04/28 22:04:12
結局概念だけで説明しようとするとかえって分かりにくくなるような気がする。。
概念→実装ほどかけ離れてるもんはない。
169:デフォルトの名無しさん
05/04/28 22:06:37
Smalltalkのクラス階層として結晶した＝Smalltalkで実装された話
つう事。
概念
↓
実装
↓
実装を概念として騙ってる ←このスレ
170:デフォルトの名無しさん
05/04/28 22:26:45
Smalltalk以外のオブジェクト指向言語は
オブジェクト指向の風味がある偽物
偽物の腐った概念であれ>>152-の理解は正しい
171:デフォルトの名無しさん
05/04/28 22:30:37
>>167
なぜかね？
>>158の捉え方も可能だが
任意よりも全体と捉える方をおすすめする
172:デフォルトの名無しさん
05/04/28 22:36:47
>>165 の一行目に基づき、
「整数」を「インスタンス」と置き換えてみよう。
二行目「クラスを任意のインスタンスと捉える」
というような荒唐無稽な話は、(>>165と>>171以外)誰も言っていない。
三行目「クラスはインスタンスの全体と捉える」
これは、クラスを集合と捉える考え方だね。
173:デフォルトの名無しさん
05/04/28 22:51:41
>>170
オブジェクト指向の定義は千差万別人それぞれ。
俺はリフレクションさえあれば何でも良し。C++ 逝ってﾖｼ!!
URLﾘﾝｸ(www.shiro.dreamhost.com)
174:デフォルトの名無しさん
05/04/28 22:56:20
>>172
荒唐無稽と言うほどでもない
クラスの概念は集合と似ているが同じではない
集合を任意要素として表現することもあり
オブジェクトとクラスの関係を理解する一つの方法として
>>158の捉え方もあながち捨てたものではない
なお>>158をよく理解していると褒めてはいない
>>152-の例が例としてよくまとまっていると褒めた
175:チラシの裏
05/04/28 23:10:28
集合論ではsetと同じような意味でclassという単語が使われる
ことがあるけど、オブジェクト指向のクラスも元々はそこからとった
言葉じゃないのかなと俺は思う。
176:デフォルトの名無しさん
05/04/28 23:30:05
>>175
正しいかもしれないがたとえ集合論と関連させたものだったとしても似た用語を援用しただけであろう
なぜならば集合論におけるクラスは他のクラスの要素にならないからだ
Smalltalkのクラスはメタクラスのインスタンスでありその点が大いに異なる
また集合論では許されない無限降下列も存在している
MetaClassのメタクラスはMetaClassのインスタンスである
177:デフォルトの名無しさん
05/04/29 05:11:02
>>174-176
２０分おきに連投ご苦労。で、結論出た？
セットとクラスの違い、
数学基礎論でいうクラスと、OO言語のクラスの違い
タイプ理論、
まで説明が終わったら、起こしてくれ。それまで一休みｗ
178:デフォルトの名無しさん
05/04/29 07:45:21
>>177
結論とは何かね？
179:デフォルトの名無しさん
05/04/29 08:09:08
>>157
忘れていた
あまりよい理解ではないが
インスタンス＝クラスのオブジェクト
で理解しても構わない
ここで言うオブジェクトももちろんオブジェクト指向言語におけるオブジェクト
すべてはオブジェクトでありクラスに従属していることを強調する場合はインスタンスという用語を使う
selfに入っているものはオブジェクトでありそれは何らかのクラスのインスタンス
180:デフォルトの名無しさん
05/04/29 08:21:05
蛇足ながら
集合論ではすべては集合（無定義概念）
何らかの集合に所属している場合は要素と呼ぶ
さらに蛇足ながら
クラス概念のある集合論の場合
すべてはクラス（無定義概念）
何らかのクラスの要素である場合は集合
181:131
05/04/29 11:13:10
>>179
慣用的に、"すべてはオブジェクト”という理解があることは承知しています。
ですが、157で述べたとおり、クラスを導出する“オブジェクト”という言葉と、
クラスから導出される“オブジェクト”という言葉は、その導出の順序性と
目的において異なる意味を持っています。
"すべてはオブジェクトである”とい論理は、じつは、ふたつの“オブジェクト”
という言葉が、それぞれ異なる意味を持った言葉でありながら、言葉の
形式的音韻的な同一性に拠ってのみ成立している論理だと思うのです。
そして、このような“オブジェクト”という技術用語の本来の意味をあいまいな
方向に誘導する学術系の論理は、オブジェクト志向プログラミングへの理解
を初手から阻害している重要な原因の一つだと考えているのです。
182:デフォルトの名無しさん
05/04/29 11:15:25
クラスとセットのちがい
クラスの定義を説明する例として、「国連」が例示されることが多い。
すなわち、
o 国連のメンバーは国々であり、
o 国のメンバーは、例えば、日本国なら日本人だが、
x 日本人は国連のメンバーではない、
という説明がされる。
しかし、セットの観点からすれば
x 日本人の集合は、いくら日本人を加わえても、
日本人の集合であって、日本国にはならない。
つまり、「男」と「女」を使った例で言えば、「男」と「女」の集合を起点にして、
「個人 」あるいは「法人」というクラスを形成するためには、
タイプ（Ｎ－１）とタイプＮ の間には、「概念の飛躍（抽象化）」が起こっているのである。
概念の一般化は論理和ではない。
183:デフォルトの名無しさん
05/04/29 11:24:35
>>181
そこに書かれた「二つのオブジェクト」とは
君の言うプログラム設計手法としての「クラスを導出するオブジェクト」と
書かれたプログラム・実際に動く際の「クラスに導出されるオブジェクト」という意味か？
そのような違いを念頭に書いたことはないし実際気にする必要があるとも思えない
184:デフォルトの名無しさん
05/04/29 11:43:24
タイプ理論
20世紀初頭、集合論を使って数学の基礎を再構築する試みが開始された。
数学基礎論の源流には、以下の３つの流派があった。
（１）論理主義 （ラッセルに代表される考え方）
（２）形式主義 （ヒルベルトに代表される考え方）
（３）直観主義 （ブラウワーに代表される考え方）
ラッセルの提示したや り方が「タイプ（type）理論」（the theory of types）である
（ラッセルの提示したタイプ理論は「分岐タイプ理論」と云うが、
ラムゼー（Ramsey F.P.）は、それを簡素化して、単純タイプ理論にした）。
ラッセルの導入したタイプ理論を要約すれば、以下の２点が主張 である。
（１）モノは、（以下に記述するように）いくつもの階層（＝型）から構成されている
（これを、 「高階」の構成という）。
タイプ０：個体｛ａ, ｂ, ｃ,...｝
タイプ１：個体の性質 ｆ(x) [つまり、「関数」]
タイプ２：個体の性質の性質 ｇ(ｆ(x))[ つまり、「関数の関数」のこと ]
：
タイプ（Ｎ－１）
タイプＮ
（２）代入規則：タイプＮの 関数は、タイプ（Ｎ－１）の対象を代入項とする。
したがって、「Ｗ∈Ｗ」（同じレベルの代入）は無意味となる（「タイプ理論」ではＷ∈｛Ｗ｝が正しい扱いとなる）。
ちなみに、Ｗ＝｛Ｗ｝が成立することもある。これを「不動点」という。
数学者たちが、モノを「高次に（高階に）構成された構築物」と観る原点が、ここにある。
モノは「無定義語」であって、「関係 （関数）」のなかで扱われるパラメータ（項）に過ぎない。
185:デフォルトの名無しさん
05/04/29 12:23:27
素朴な集合論は様々な矛盾を誘発し現在は公理化されている
そこでは通常はＷ∈ＷおよびＷ＝{Ｗ}なるものは拒否されている
揚げ足取りのつもりないが気になったので指摘させて頂くが
関数の関数を書く場合はg(f)(x)とした方がよいだろう
もっと正確には(g(f))(x)であろうか
g(f(x))は通常は関数の合成の意味を持たせているからだ
186:デフォルトの名無しさん
05/04/29 12:25:41
いつの間にか蛆虫が沸いている。
187:デフォルトの名無しさん
05/04/29 12:26:50
誤解されぬよう書いておくが>>185は蛇足である
188:デフォルトの名無しさん
05/04/29 12:45:31
枝葉の指摘ご苦労。
じゃ素朴な集合論の話はここまでにして、
次は ZF公理に基づくプログラミングを騙ってくれ。
よろしく
189:デフォルトの名無しさん
05/04/29 13:10:50
>>188
それはHaskellのことか？
190:デフォルトの名無しさん
05/04/29 13:20:08
いや、きっと>>185は、
公理的集合論、例えばZF公理系に基づいて
オブジェクト指向を説明してくれる事と思う。
191:デフォルトの名無しさん
05/04/29 13:29:04
>>190
ご期待には添いかねる
192:デフォルトの名無しさん
05/04/29 13:32:57
あ、そ。
なんだ、自分の頭で考える事ができる人かと思ったら、
受け売りをくどくど書いてるだけの人か。
つまんね
193:デフォルトの名無しさん
05/04/29 13:38:04
>>192
無駄なことはしない
>>185を書いたのは>>184に紹介さえていることが現代的ではなかったことと記法が気になったことだ
特にそれ以上の意図はない
194:デフォルトの名無しさん
05/04/29 13:39:52
うんだから、
その現代的でない理論でオブジェクト指向が成り立っているのか、
あるいは、もっと現代的な説明が可能なのか？
＞無駄なことはしない。
そのあたりをちゃんと説明しろってこと。
195:デフォルトの名無しさん
05/04/29 13:41:37
オブジェクト指向は集合論に基づいているわけではない
以前から似ているが違うと書いているのだが？
196:デフォルトの名無しさん
05/04/29 13:44:41
ラッセルの型理論つのは、型付プログラミング言語に関する
一番最初の説明として、有効だと考える。
で、おまいさんが現代的ではないとおっしゃるのだから、
じゃそれを現代的にして下さい、って事。
197:デフォルトの名無しさん
05/04/29 13:46:54
>>196
ご期待には添いかねる
198:デフォルトの名無しさん
05/04/29 13:47:50
現代的な型理論としては、
MartinLofの型理論 なんつうのもあるな
199:デフォルトの名無しさん
05/04/29 14:00:11
揚足鶏だらけのインターネッツですねｗ
200:デフォルトの名無しさん
05/04/29 14:02:44
初心者相手のゆるい説明に、
いちいちピラニアみたいに食いついてくるのが、
ちゃねらーですから。
201:デフォルトの名無しさん
05/04/29 14:04:30
んなのばっかだと初心者はどん引きして、
近寄ってこないと思うよｗ
202:デフォルトの名無しさん
05/04/29 14:08:30
その方が初心者にとっても身のためだったりしてｗ
203:デフォルトの名無しさん
05/04/29 14:12:44
荒しが活躍し過ぎると、一般人はどん引きして、
２ちゃねらー離れが加速するだけだと思うよｗ
204:デフォルトの名無しさん
05/04/29 14:18:06
今度から俺も、間違えて荒しちまった後で
「他意はない」って言い訳しよ。
それでも突っ込まれて、ほとほと己の無力さ加減に絶望したら、
「期待には添いかねる」
とレスを返す事にしよう。
205:デフォルトの名無しさん
05/04/29 14:20:57
>>204
ご期侍には添いかねる
206:デフォルトの名無しさん
05/04/29 14:33:39
>>205
他意はない
207:デフォルトの名無しさん
05/04/29 14:35:20
>>206
無駄なことはしない。
208:デフォルトの名無しさん
05/04/29 14:37:10
>>207
似ているが違う
209:デフォルトの名無しさん
05/04/29 14:38:53
ゆるい説明をくどくどする奴に限って、
ゆるゆる議論のほころびの一つに突っ込むと、
猛反発をしてくるの法則
210:デフォルトの名無しさん
05/04/29 14:41:05
>>209
ちゃねらーですから。
211:デフォルトの名無しさん
05/04/29 17:24:52
Animal
<-Dog
<-Cat
こんな継承することは現実のプログラミングの現場ではありえない
実装してみて、インターフェースが共通化できそうなら継承木をつくるのであって
概念としてひとくくりにできるから継承やってると泥沼にはまる
だいたいそれでうまくいくんならデザインパターンなんていらないわけで
オブジェクト指向は手段、言語や実装無しに概念としての価値はあまりない
212:デフォルトの名無しさん
05/04/29 17:39:37
>>211
>>123
213:211
05/04/29 17:43:08
> Animal
> <-Dog
> <-Cat
>
> こんな継承することは現実のプログラミングの現場ではありえない
補足します
ゲームやシミュレーションの世界ではこういう書き方もするが、
言語自体の記述力の限界もあって、
概念をそのまま記述することにとらわれると足かせになりがち
煮え切らない文章すまそ
214:211
05/04/29 17:50:49
>>212
オブジェクト指向という言葉しかつかっていませんが、
オブジェクトを型、インスタンスのどちらでとらえるかで
意味が変わりますかね
215:デフォルトの名無しさん
05/04/29 18:14:57
オブジェクト指向言語を実現する方法として、C++型とsmalltalk型と二つの方法があるってことか？
どっかで似たような話を聞いたな。
このスレでも>>157がそういうようなことを言っているけど。
216:131
05/04/29 18:19:04
>>211
> Animal
> <-Dog
> <-Cat
これはPROTOTYPEパターンだね
217:131
05/04/29 18:28:36
>>215
C++は静的なオブジェクト指向プログラミングを実現する仕組みで
コンパイラでできること仕組みの多くを実現している一方の究極。
動的なオブジェクト指向プログラミングを実現する仕組みの究極は、
Perlだと思う。型変換も実行時に簡単にできるし、同一ベースクラスの
サブクラスの多重継承を（現状がいいかは別問題として）矛盾なく
サポートできる。どちらも、静的なコンパイラ言語であるC++では困難
Smalltalkは理解不能ゆえ、私には論評できません。
218:デフォルトの名無しさん
05/04/29 18:32:16
>>214
詳しく
219:デフォルトの名無しさん
05/04/29 18:33:03
>>216
> Animal
> <-Dog
> <-Cat
これ見て
>これはPROTOTYPEパターンだね
とは、あんたエスパーかｗ
まず "<-"演算子の意味を定義しろってｗ
220:デフォルトの名無しさん
05/04/29 18:33:40
>>182, >>184
T型ERからの引用だな。
221:デフォルトの名無しさん
05/04/29 18:35:19
>>219
俺も最初、
Class Animal {}
Class Dog extends Animal {}
Class Cat extends Animal {}
て話かと思った。
Cat extends Dog {}
なんてｱﾌｫな話題を誰が持ち込んだんだｗ
222:デフォルトの名無しさん
05/04/29 18:35:50
型がオブジェクトと言われることって・・・・？
223:デフォルトの名無しさん
05/04/29 18:36:38
>>220
佐藤さんだけじゃなくて、
外国の超大物も書いてるみたいだよ、このスレ。
224:デフォルトの名無しさん
05/04/29 18:38:32
ああ、ブリキの人ね。
彼も日本語が上手くなったなぁ
225:デフォルトの名無しさん
05/04/29 18:40:32
>>220
で、現代的な型理論と
公理的集合論の話の続きは？
226:デフォルトの名無しさん
05/04/29 18:47:45
ProjectBuilderってOOとしてどう？
227:デフォルトの名無しさん
05/04/29 19:42:32
いや佐藤さん本人ではないだろう。
無断借用じゃないの。
228:デフォルトの名無しさん
05/04/29 21:13:25
>>221
にゃんって鳴く犬が猫なんだよｗ
229:デフォルトの名無しさん
05/04/29 21:30:01
>>211
デザインパターンなんていらないんじゃないの？
230:デフォルトの名無しさん
05/04/29 22:04:49
>>229
再利用とかメンテとかがいらなければ、いらないねっ。
231:デフォルトの名無しさん
05/04/29 22:06:31
【オブジェクト指向】言語学習が先？概念学習が先？
1 名前： デフォルトの名無しさん 投稿日： 04/01/10 14:56
VisualBasicやCといった手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
232:デフォルトの名無しさん
05/04/29 22:10:01
>>231
C#やJavaでオブジェクト指向プログラミングしなくても
ぜんぜんに構わない
オブジェクト指向プログラミングにC#やJavaを使わなくても
ぜんぜん構わない
233:デフォルトの名無しさん
05/04/30 00:00:14
C#やJavaでOOしないのはかえって大変
非OO言語でOOするのはストレスたまりまくりんぐ
234:デフォルトの名無しさん
05/04/30 00:07:05
>>120
>ストラ先生は、オブジェクト＝クラスという意味で使っているみたい
って誤読だろ？明らかに
235:デフォルトの名無しさん
05/04/30 00:48:24
>>234
完全に誤読だよな。
236:デフォルトの名無しさん
05/04/30 01:00:16
オブジェクト＝物 って説明すると
初心者は日本語で言うところの「物」を創造してしまい
「動作・ふるまい」を物とは考えることが出来なくなる
物ありきで、その物に対して「動作・ふるまい」をメソッドとして実装することしか頭に浮かばなくなる
237:デフォルトの名無しさん
05/04/30 01:16:12
クラスライブラリの体系をおぼえるのが
ものすごく、めんどくさい。
238:デフォルトの名無しさん
05/04/30 01:18:15
オブジェクトはキャラクターです
パラディンクラスはナイトクラスを継承します
新たに技を追加できます
オーバーライドすることで既存の技を強化することも可能です
239:デフォルトの名無しさん
05/04/30 02:12:37
>>238
>オブジェクトはキャラクターです
この時点で>>236の言っていることそのままじゃん
240:デフォルトの名無しさん
05/04/30 02:17:25
オブジェクトは職業・技能です
とか？
241:デフォルトの名無しさん
05/04/30 02:29:04
クラスは役割、役です
はどう？
242:デフォルトの名無しさん
05/04/30 02:44:27
くらすが個別にインスタンシエーションがつまりmalloc()の
コンストラクタがごごごと動いて
どうも、オブジェクトです、
クラスのインスタンスです、ご用件をどうぞ
free(); または、もしもし五味屋さんはやくきてよ
のような、認識。
今年中によむ、本(予定)。
* 結城本
* エッケルのThinking in Java
* GOF本
243:デフォルトの名無しさん
05/04/30 02:57:57
>>237
マトモに設計されたライブラリなら一部を覚えればあとは類推で何とかなると思うが。
244:デフォルトの名無しさん
05/04/30 04:27:33
オブジェクトを汎化したものがクラスです。
245:デフォルトの名無しさん
05/04/30 04:32:08
>>123
> 分析レベルだと、あんまりインスタンスという言葉は使われない。
おいおい、ユースケースのをインスタンス、とか言うだろ？
使われないのはオブジェクトという意味の「クラスインスタンス」だろ？
246:デフォルトの名無しさん
05/04/30 11:29:38
インヘリタンス
247:デフォルトの名無しさん
05/04/30 12:41:43
混濁箪笥
248:デフォルトの名無しさん
05/04/30 13:23:24
オブジェクト指向ってつまるところ
「そういう仕様」だと思うよ、
現実を表現しやすく、管理しやすい仕様ではあるが
現実に無理して当てはめてわかった気になっても
習熟していくと騙されたと気づくんじゃないかな？
249:デフォルトの名無しさん
05/04/30 13:32:57
騙されたって気にはならないなあ
用意周到なクラスライブラリを理解していくに連れて
なるほどという気持ちになる
あでもそういう汎用クラスライブラリを作る側は大変だろうな
習熟して騙された気になるってそういうレベル？
250:デフォルトの名無しさん
05/04/30 13:47:11
アルゴリズムと一緒で
あーこういう組み方するのか～うまいね～ってな感じ
しかし、それほどデザインパーﾀﾝに執着は無い
クラスの関係図を書くと何階層にもなってしまうので
新規作成時はいいんだけど、後から入ってきた人が
もしそれほど知識無いとしたら修正お願いしてもわかりませんので
251:デフォルトの名無しさん
05/04/30 15:43:55
「現実に無理して当てはめた説明」に騙されたって言ってるんだけど
デザインパターンは現実の構造を示してるんじゃなくて、
工学的な定石に名前をつけたもんでしょ
現実ってリアルワールドね
252:デフォルトの名無しさん
05/04/30 15:46:52
習熟してくるとその辺の神話のうそがわかってくるって
いいたいんですよ
253:さかな ◆xT/ZtgSAnQ
05/04/30 15:55:55
その「神話」とやらを教えてる方の人間も、
理解を助けるための方便として言ってる場合だけじゃなく
自分も本気で信じてる場合もあるから
たちが悪い。
254:デフォルトの名無しさん
05/04/30 16:05:05
結局プライドの戦いと言うわけになるのだな
255:デフォルトの名無しさん
05/04/30 17:22:36
アプリケーション、ツール、フレームワーク、クラスライブラリ、クラス設計に関して、
自分で実際にそれらを作ってみると、設計の妥当性/妥協点がわかる、という事実がある。
もちろん、自分でそーゆーのを作れない泡沫エンジニアへのセールスポイントや使いやすさ
も提供するわけだがｗ
大枠や細かな所は、「現実的な作りやすさ」で決まってくるもんなんだよね。
だから、ｵｰﾌﾟﾝソースで自分で中見て改善する練習をする事が重要なんだ。。。
Smalltalkしかり、Linuxしかり
256:デフォルトの名無しさん
05/04/30 18:00:34
制御系でOOPってどれぐらい浸透している？
ナビ開発をやっているんだけど、現行の手続きOnlyなやり方だと分り難くないかな。
257:デフォルトの名無しさん
05/04/30 18:10:45
>>256
new封印で使ってる
258:デフォルトの名無しさん
05/04/30 18:52:27
騙される方が悪いのか騙す方が悪いのか信じる者は掬われる？
259:池沼くんのレス
05/04/30 18:55:05
88 名前： 番組の途中ですが名無しです 投稿日： 2005/04/29(金) 14:21:36 ID:HlHAQf7m0
まぁ、オブジェクト指向隆盛の現在、
Viewを客受けの良いものにchangeしたのは正しい決断だな。
260:デフォルトの名無しさん
05/05/01 07:24:28
C++の設計者はなんで
shout << なわけねーだろ！
にしなかったんだろ…
261:デフォルトの名無しさん
05/05/01 21:17:22
orz << "入れてよし"
262:デフォルトの名無しさん
05/05/01 21:38:53
プリプロセッサで文法変更すりゃ終了。
263:デフォルトの名無しさん
05/05/06 20:50:37
>>261
orz┤
264:デフォルトの名無しさん
05/05/07 02:13:09
じゃあ、言語学習と概念学習は同時にやっていくってことで終了でいいですか
265:デフォルトの名無しさん
05/05/08 12:32:01
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝来了＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
266:デフォルトの名無しさん
05/05/11 00:24:46
いがぴょんが痛すぎるんだけど、マゾかなんかですか？
267:デフォルトの名無しさん
05/05/11 00:27:54
逝け沼さん、こんにちは
268:デフォルトの名無しさん
05/05/11 02:36:01
>>263
orz=3=3=3=3 ﾌﾞﾌﾞｯﾌﾞﾘﾌﾞﾘﾋﾞﾁﾋﾞﾁﾌﾞﾌﾞﾌﾞ
269:デフォルトの名無しさん
05/05/15 11:01:52
いつの間にかクダスレになっとるわい
270:デフォルトの名無しさん
05/05/15 11:26:23
>>196
型付きの手続き型言語の理論としては、
型付λ計算が広く受け入れられている。
ただし、オブジェクト指向言語では
「オブジェクト指向」の本質といったものを明確にするのは難しいので、
広く受け入れられた理論というのは、まだない。
271:デフォルトの名無しさん
05/05/15 15:14:43
どういった単位でクラスを作っていけばいいんですか？
趣味程度で自分しか使わないコードを書く人間としては、
ついというか癖でだらだらと関数を山ほどForm1のなかに書いてしまうのですが…
272:デフォルトの名無しさん
05/05/15 17:59:10
本当にﾌｶｷｮﾝ似だね
273:デフォルトの名無しさん
05/05/15 19:43:17
>>271
いくら使い捨てコードといっても、一発で動いて後は永遠にメンテ不要なんてケースはまずないわけで。
自分で書いたコード読んでイライラしない？
274:デフォルトの名無しさん
05/05/15 20:41:36
>>271
>どういった単位でクラスを作っていけばいいんですか？
殴り書きでいいのだが、
見つけたオブジェクトを見つける
見つけたオブジェクトの単位でクラス図を書く
クラス図にメンバ変数を追加する
クラス間のメンバ関数を時系列にそってシーケンス図として書く
メンバ関数をクラス図に追加する
これらの手順を納得できるまで繰り返す
収まりがついたらコーデングする
動作としてはこうなんだが、
それぞれの段階で知識や経験が入り込む
275:デフォルトの名無しさん
05/05/15 20:42:51
>>274
×見つけたオブジェクトを見つける
○オブジェクトを見つける
276:デフォルトの名無しさん
05/05/15 20:44:40
C の struct をベースに、データ構造を基準にすると分かりやすい
どれだけの物を１つにまとめ、どれとどれを分けるかの判断は経験則
277:デフォルトの名無しさん
05/05/15 20:45:43
>>274
コーダー乙。
分析レベルのOOを認識できてないあたりが、
机上の勉強だけの糞コーダ臭いな
278:デフォルトの名無しさん
05/05/15 20:52:39
どうでも良いが、わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える必要性が分からん
279:デフォルトの名無しさん
05/05/15 20:53:24
第一の山は、
概念レベルのオブジェクトをいかに抽出し、
現実世界のモデルを作るか？
第二の山は、
ユーザ要求なり機能要求を、
分析レベルでいかに取り込んでいくか
第三の山は、
１で作った概念モデルと
２で作った機能要求モデルを
いかに整合させていくか
第四の山は、
１、２、３で作ったモデルの実装方法の検討。
ここらへんがアーキテクトの仕事。
このあたりまでやって、ようやく開発レベルのOOになる
もちろん、対象分野の開発に慣れていて、
なおかつ新しい設計をしないならば、
1～4は楽勝だけどな。実際はそれをOOに不慣れな人間がやる事が多いから、
下流の人は大変みたいだ。
機能分割とDB設計から割り出したクラス図を受け取って、あとはウォータフォールとかｗ
280:デフォルトの名無しさん
05/05/15 21:05:52
最初の質問に戻って
＞どういった単位でクラスを作っていけばいいんですか？
趣味のプログラミングということで、基準がわからないのだが、仮に
1.開発技術のスキルアップ
2.設計～コーディングにおける作りやすさ
3.拡張のし易さ
あたりを基準に考えていこう。
1.に関しては、薄っぺらいOO開発プロセスの本を追っかけてみると、
UMLやオブジェクト指向分析設計の概観が得られて、勉強になると思う。
とりあえずの推薦図書は、
・ユースケース入門―ユーザマニュアルからプログラムを作る
URLﾘﾝｸ(www.amazon.co.jp)
・ワークブック形式で学ぶ UMLオブジェクトモデリング
URLﾘﾝｸ(www.amazon.co.jp)
281:デフォルトの名無しさん
05/05/15 22:08:24
>>278
> わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える
もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
開発者の関心と努力は、実装可能な事/実装が難しい事に集中してしまい、
結果として下記のような問題が発生します。
(1) 本来の要求(やりたかった事)の実現が、
おざなりになったり、歪んだ形になってしまう事。
（結果として、ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術は素晴らしいが、
使う人にとっては判りにくい、使いにくいものになってしまいがちです）
(2) 拡張や機能追加に耐えないクラス設計になってしまう事。
（拡張や機能追加に耐えるしっかりした構造を持たせるには、
普遍的な概念モデルや、プログラム対象分野の知識体系に基づく、
抽象的なレイヤーが必要です。
この抽象的なレイヤーは、汎化クラス抽出の方法でもある程度得られますが、
ボトムアップに実装から抽出する方法では、充分な汎用性をえられません。）
(3) プラットフォームや実装技術と、コアなアルゴリズムの切り分けが不充分になる。
もし、実装技術やプラットフォームに基づいて、アプリケーションの設計を行ったら、
それは将来のOS/環境のバージョンアップ時に、大きな変更作業が必要になるでしょう。
OS/環境依存部、プログラム対象分野の知識体系、アプリケーション、を分けるには、
レイヤー・パターンが有効ですが、そのレイヤーを切り分けるためにも、
OO分析の作業が重要なのです。
他にも書くべき事があるのですが、とりあえずここで筆を置きます。
282:278
05/05/15 22:20:01
>>281
＞もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
いやいや、最終的に両方ともやらなければいけないのは分かっているんだけど、
ある程度のフィードバックが、実装レベルから分析レベルに伝播するから、
わざわざ分けずに一言で纏めちゃっても良いんじゃないかって言う勝手な話
283:デフォルトの名無しさん
05/05/15 22:31:16
分析レベルで抽出されるオブジェクトと、
設計レベルで抽出され、実装に反映されるオブジェクトは、
かなり距離感がある
これが、二つのプロセスを分離している理由です。
もちろん、シェアウェアとか個人でプログラムを作成されている方の中には、
実装技術ベッタリで素晴らしいアプリを作成されている方も多いようですし、
貴方の信じる道を行けば良い、と思います。
284:278
05/05/15 22:50:32
ああ、なんとなく雰囲気が掴めました
目的から作成するオブジェクトと、実装技術から発生させるオブジェクト……
……これらを最終的に一致させるように、今まで考えていたのですが、これじゃダメなんでしょうか
(ひとつになった最終形を眺めて、278 を考えていたです)
っていうか経験不足です
企業に入ってそこそこのプロジェクトに参加するようになったら、改めて考えてみますです
285:デフォルトの名無しさん
05/05/15 22:51:30
なんだろ。目的と実装を一致させるのではなく、実装を目的でラップするとか、そういう意味合いで
286:デフォルトの名無しさん
05/05/16 04:30:20
・・・・・・。
287:デフォルトの名無しさん
05/05/16 20:38:55
うむ。わざわざ別の用語にするほどのこととは思えないな。
>>284のような「設計方針」「心構え」で申し分ない。
288:デフォルトの名無しさん
05/05/16 20:41:57
いや、だから個人で勝手にやる分には全然構わないけど、
内容的には大きな差があるんだって。
＞＞分析モデルと設計モデルの間の深い溝。
俺はこの分野に入ってすぐ、気付いたけどなぁ～
289:デフォルトの名無しさん
05/05/17 08:50:54
具体的に
290:デフォルトの名無しさん
05/05/17 08:58:47
いや、そーゆーのは仕事で覚えるものだから、
素人グラマーに意見するつもりはない。
291:デフォルトの名無しさん
05/05/17 09:00:14
だいたい趣味がプログラムの >>289は、
朝っぱらからこんな所でなにやってんの？
292:デフォルトの名無しさん
05/05/17 09:14:29
結局具体例もないわけね
293:デフォルトの名無しさん
05/05/17 09:16:13
餓鬼と判定。以降スルー
294:デフォルトの名無しさん
05/05/17 09:24:49
自演臭い
295:デフォルトの名無しさん
05/05/17 09:26:12
俺の思いを分かるのは俺だけ！ﾌﾟ
296:デフォルトの名無しさん
05/05/17 09:27:07
VIP板に（・∀・）ｶｴﾚ
297:デフォルトの名無しさん
05/05/17 20:38:12
ジサクジエンイクナイ
298:デフォルトの名無しさん
05/05/18 22:13:32
>>282
そういう思考が肥満児クラスを産む、
なんてな。
299:デフォルトの名無しさん
05/05/18 23:29:45
良い設計モデルの作り方(前編) URLﾘﾝｸ(www.atmarkit.co.jp)
◇ 目指すべき分析モデルの形
分析モデルの作成方法については、多くの設計者や方法論者がさまざまな方法を主張しています。
ここでは詳細には述べませんが、例えば、
・ワード・カニンガム（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:デフォルトの名無しさん
05/05/18 23:30:12
◇ 設計モデルの理想
設計モデルの段階における理想的なモデルとはどんなモデルでしょうか。設計段階のモデルに従って実装が行われ、
その結果システムが出来上がるわけなので、生産性が高く、保守性や拡張性が考慮されていなければなりません。
そのうえで、実装担当者にとって理解しやすいモデルが「良い設計モデル」ということになります。
最近のアジャイル系開発プロセスでは、モデリングを分析段階と設計段階に分けず、
モデリング＝設計（Design）と考えたり、XPのように、コーディング作業にモデリング作業を含んでしまうプロセスもありますが、
本稿では、分析と設計の考え方の違いを解説するために、あえて分析モデルと設計モデルを分けて表現しています。
301:デフォルトの名無しさん
05/05/18 23:57:53
なんかPascal臭い感じだな（意味分かる？）
302:デフォルトの名無しさん
05/05/19 00:11:29
しらねぇよ屑
303:デフォルトの名無しさん
05/05/19 00:12:39
てめえは御託並べる前に、構造化プログラミングとデータ中心アプローチくらい覚えろよｗ
304:デフォルトの名無しさん
05/05/19 08:27:55
なんか初心者にはスレッショルドの高いスレになっちまったな
305:デフォルトの名無しさん
05/05/19 08:37:57
>>299-300のボーランド@IT記事がいいと思うよ。
匿名掲示板で数文字でノウハウ聞き出そうとするアンタは、ギブアンドテイクつう言葉がわからんヒッキーだろ
306:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/05/19 19:30:00
＝＝＝＝＝ 電磁シールド ＝＝＝＝＝
シンタックス・シュガー作っても本質は変わらない。
クラスと構造体を同一視するのなら、サルもミジンコも同じ。
クラスとオブジェクトの違いもわからずに、
そんなに細かいところをあれこれ弄る必要ナッシング。
308:デフォルトの名無しさん
05/05/19 21:41:58
structで定義しているのは構造体の構造
実際に作成する時作成されるのは構造体
この違いがクラスとオブジェクトの違い
309:デフォルトの名無しさん
05/05/19 21:44:36
けれどクラスという概念をなくしてしまってもいい
オブジェクトの構造・仕組みという抽象的なもので
コード上は現れないようにしても問題ないだろうよ
310:デフォルトの名無しさん
05/05/19 21:47:54
なんか変なのが居ついてるな
311:デフォルトの名無しさん
05/05/20 06:01:04
>>309
そういう道を進んでいる言語もある。
プロトタイプベースと呼ばれているようだが。
312:デフォルトの名無しさん
05/05/20 09:11:17
今頃プロトタイプ・ベースを語るとは・・・ｸｵﾘﾃｨﾃﾗ高杉
313:デフォルトの名無しさん
05/05/20 09:43:14
プログラムもろくに書けない負け犬は、
古臭い脳内知識で妄想勝利するしかやる事がないんだな
プロトタイプベース言語が提供する
インスタンスに対する属性/メソッドの付加は、
Composit, Decoration, Delegation, Factoryあたりで実現できる。
プロトタイプベース言語は、それらの機能を言語仕様に取り込んでいるだけｗ
314:デフォルトの名無しさん
05/05/20 09:45:58
Composite, Decorator, Prototype パターン ＋ Delegation (委譲による処理) な
315:デフォルトの名無しさん
05/05/20 10:59:30
クラスベース ＝オブジェクト間にメタ関係を設け、
メタ関係上位にあるオブジェクト(クラス)に、オブジェクト生成や継承の仕組みを任せて、
メタ関係下位にあるオブジェクト(インスタンス)の内部実装の簡略化を図ったもの
プロトタイプベース＝全てのオブジェクトに、オブジェクト生成や継承の仕組みを提供するもの。
概念は単純になるが、言語実装技術やﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術のハードルは高くなる。
(静的型付けやLiskov置換則による安全性を、言語レベルで提供しにくくなる)
概念学習への初期投資を惜しむような人間が、プロトタイプベースを選択するのはナンセンス。
プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
316:デフォルトの名無しさん
05/05/20 18:25:30
>>315
いい比較だと思うが、それだとクラスがファーストクラスな存在に読めるかも。
317:デフォルトの名無しさん
05/05/20 18:35:42
またファーストクラス厨房か。
Smalltalkでクラス・ベースのオブジェクト指向が確立した後で、
あらためて Self等でプロトタイプ・ベースのオブジェクト指向言語が研究されたのだから、
クラス-オブジェクト関係 (メタ関係 あるいは インスタンス関係)
の方が広く受け入れられてる概念だと思うよ。
Abadi & Cardellaの本もまずクラスベース言語、次にオブジェクトベース言語という展開だし。
318:デフォルトの名無しさん
05/05/20 18:40:05
あ、もっとレベル低い人か。
Smalltalk等、クラスをファーストクラスなオブジェクトとして扱うのが第一世代、
CLOS等、手続き型の延長線上にクラスレスなOOを定義したのが第二世代、
C++等、クラスをオブジェクトが共有する構造体として扱うのは邪道な第三世代、
Java等、クラスをリフレクション等駆使して、実行時に参照可能なオブジェクトとして扱えるようにしたのが第四世代
だよん。（てきとー
319:いやん
05/05/20 18:40:57
× Cardella → ○ Cardelli
320:デフォルトの名無しさん
05/05/20 18:43:46
Selfとか、プロトタイプ・ベースの言語が研究されるようになったのは、C++とJavaの中間くらいからかな。第3.5世代・・・新しい開拓地
321:デフォルトの名無しさん
05/05/20 19:08:23
>>318
プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
322:デフォルトの名無しさん
05/05/20 19:29:24
おまえの事だよ
323:デフォルトの名無しさん
05/05/20 21:19:08
プログラム書かない・・・情報処理言語の研究者なのかも
324:デフォルトの名無しさん
05/05/20 21:22:43
豆な人？
325:306
05/05/21 14:42:19
やっぱり混乱の元になったか……
クラスベースについて疑問を思っているんじゃなくて、ただ単に 『表記法』 について疑問に思っただけだったんだけどな
クラスベースとかインスタンスベースとか、正直どうだって良いんだけど
>>308
＞structで定義しているのは構造体の構造
同様に、class で定義しているのはオブジェクトの構造つまりクラス
それは分かる。struct および class が 『定義そのもの』 を指すのか 『定義した生成物』 を指すのかの違いのような。
気分的には、生成物を指したい
326:デフォルトの名無しさん
05/05/21 14:46:28
いろんな「何を」や「何は」が抜けていて、「何に」ついて言いたいのかさっぱりわからない。
327:デフォルトの名無しさん
05/05/21 14:51:43
頭おかしい人だから、放置しとけ
328:デフォルトの名無しさん
05/05/21 15:03:52
>>325
君が誤解している(もしくは不完全な理解をしている)のは、
クラスやオブジェクト等のＯＯの概念ではなくて、型という概念だ。
Cardelliでも読んで、型とは何か、型を宣言するとはどういうことか、
じっくり考えてみたらいい。
329:306
05/05/21 15:05:19
頭おかしいって言われちまったい ^_^;
んじゃ書き直す
======
C# の表記法について、
class では 『定義そのもの』 を指していることは明確であるが、
struct は 『定義そのもの』 と 『定義によって生み出される生産物』 の、どちらを指すのか分かり難いと俺は思う
言いたい事はこれだけ
======
>>307
C# ではクラスと構造体が同一になっちゃってるから困っているんです
>>308
構造体の構造を定義するのならば、キーワードは 『struct_struct』 であるべきという気もします
『struct』 単体ならば、それは 『定義に代って生み出される生産物』 を指すのでは？
330:デフォルトの名無しさん
05/05/21 15:12:33
国語の問題な気がしてきた。
331:306
05/05/21 15:12:37
>>328
了解……出来るように頑張ります
Pascal の 『レコード型』 とか、C の 『構造体型』 とかと同じように考えると、class では 『クラス型』 を定義している筈。
しかし生成物の方は 『レコード型のレコード』 『構造体型の構造体』 とは異なり 『クラス型のインスタンス』 だから、
前２者に揃える場合、これを 『オブジェクト型のオブジェクト』 にしたほうが簡潔ではないかと思いまして。
332:デフォルトの名無しさん
05/05/21 15:13:00
>>330
正解
333:デフォルトの名無しさん
05/05/21 15:31:29
ドーナツの穴について話す時、
「ドーナツ」という単語が付いていると、あたかも「ドーナツ」が存在しているかのように感じる。
だから、「穴の穴」というのが正しいぃぃぃぃーーーーーーーーーーーーーー
334:デフォルトの名無しさん
05/05/21 15:33:18
「ドーナツの穴」って、まるで穴の部分にドーナツがみっちり詰まってるみたいで、誇大広告だよな（ﾋﾟｰﾋｬﾗ
335:デフォルトの名無しさん
05/05/21 15:35:15
人間という単語と、その実体を考えるとき、
実体は単なる人なのに、
単語に「間」という漢字がついているのが、直感に反する。
これからは、「人間」という単語を使うのはやめよう
336:デフォルトの名無しさん
05/05/21 15:49:42
>>333-334
スレ違い。こっち行け
ドーナッツの穴は空洞か存在か？
ｽﾚﾘﾝｸ(philo板)l50
337:デフォルトの名無しさん
05/05/22 08:11:20
>>306
そのobjectってVBでいうところのモジュールだよな？
classと違うだろ。
338:デフォルトの名無しさん
05/05/24 06:19:22
おれはstructで構造体の構造が定義されてるって自然に感じるけどな
んでその構造を持つ変数を同時に生成することもできると
339:デフォルトの名無しさん
05/05/24 09:52:10
>>331
PascalやCのほうを『レコード型のオブジェクト』、『構造体型のオブジェク
ト』って思ってみては？
オブジェクトとインスタンスは、まぁ、同義ということで。
340:306
05/05/24 17:24:00
色々とすまなかった。整理したら間違いに気付いたよ。
こんな馬鹿をやったのは久しぶりだ。今は後悔している OTL
【正しいこと】
・C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する
・『インタフェイス』 と 『構造体』 は、Object クラスを継承している
【俺が間違っていたこと】
・《クラス》 と 『クラス』 を混同し、宣言時のキーワード 「class」 が主に 《クラス》 を指す物と考えてしまった
・『クラス←構造体』 に代表される 「言語系外での継承」 が、一般の継承と完全に同じであると信じて疑わなかった
その結果、俺は 「class」 と 「struct」 が同一レベルの概念ではないと錯覚した
そして、「class」 と 「struct」 のレベルを同じにしようと思い、「class」 を 《クラス》 から 『クラス』 にするために
「《クラス》 には 『オブジェクト』 『インタフェイス』 『構造体』 の３種類が存在する、と言い換えたらどうか」
と提案した (>>306)
(実際は 「class」 は 『クラス』 であり、単なる言葉遊びだった orz)
341:最凶VB厨房
05/05/25 00:25:55
全く意味わからんなｗ
【正しいこと】に書いてある内容が正しくない。
342:デフォルトの名無しさん
05/05/25 00:36:00
だからまず国語を勉強するべきだって。
つまり言語学習を先にするべき。
343:306
05/05/25 13:28:06
>>342
悪い。相変わらず間違えてたみたい。
=====
「C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する」 ってのは、
「Java の 《クラス》 には 『クラス』 『インタフェイス』 の２種類が存在する」 っていうどっかの本の台詞のパクリだった
この 《クラス》 は、Smalltalk のメタクラスに該当するんかな。よく分からんけど
それはともかく、構造体はクラス階層の中に含まれているから、よく考えたらこの中に入れちゃいけないのかもしれない
=====
インタフェイスは対応するクラスが無いから、Object から派生しているとは言えないでした
(ただし、インタフェイスを実装したクラスのインスタンスは Object であることは確定なので、Object として扱える)
ここのところは訂正しておきます
344:306
05/05/25 13:38:42
結局、まだ理解できていないことは
実質 「class StructA: System.Struct { ～ }」 なクラスを 「struct StructA { ～ }」 と記述させる C# において、
キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
つまり
System.Struct からの実際の継承は、神の領域において行われる (ソースとして記述できない) が、
神の領域において、結局はクラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
……自分でも未だ混乱していることがありありと分かりますな
あとで Smalltalk でも勉強しよう……
345:最凶VB厨房
05/05/25 19:09:30
間違った前提知識からは(正しい推論をしたとしても)間違った結論しか得られんぞｗ
実質～の部分が既に間違ってますがなｗ
MSDN読め
346:デフォルトの名無しさん
05/05/25 19:15:01
太陽が西から昇るなら、このレスは346である
347:デフォルトの名無しさん
05/05/25 19:24:49
URLﾘﾝｸ(www.microsoft.com)
解説
struct 型は、Point、Rectangle、Color などの軽量のオブジェクトを表すのに
適しています。点はクラスで表現できますが、一部の事例では構造体の方が
より効果的です。たとえば、1,000 個の Point オブジェクトから成る配列を
宣言する場合は、各オブジェクトの参照用に新たにメモリが割り当てられます。
この場合は、構造体を使用した方がリソースを使用しません。
構造体に対して既定の (パラメータなしの) コンストラクタを宣言するとエラー
になります。構造体メンバを既定値に初期化する既定のコンストラクタが常備
されています。
構造体のインスタンス フィールドを初期化するとエラーになります。
new 演算子を使用して struct オブジェクトを作成すると、オブジェクトが作成
されて適切なコンストラクタが呼び出されます。クラスとは異なり、構造体は
new 演算子を使用せずにインスタンスを作成できます。new を使用しなかった
場合、各フィールドは未割り当てのままになり、すべてのフィールドが初期化
されるまでオブジェクトを使用できません。
クラスには継承がありますが、構造体には継承がありません。構造体は、
他の構造体やクラスから継承できず、基本クラスになれません。
ただし、構造体は、基本クラス Object から継承します。
構造体は、クラスの場合とまったく同じ方法でインターフェイスを実装できます。
C++ とは異なり、キーワード struct を使用してクラスを宣言できません。
C# では、クラスと構造体は、意味が異なります。構造体は値型ですが、
クラスは参照型です。
値型の機能の詳細については、「値型」を参照してください。
348:306
05/05/25 21:23:41
>>347
あ、もしかして struct って System.Struct の継承じゃない……のか？
でもインスタンスを作成しているわけじゃないし……なんなんだろう。
=====
それはともかく、え～っと……アロエリーナに聞いたらヒントを教えてくれました。
＞キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
「妥当じゃないです」
＞クラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
「そんなわけないです。クラスと構造体は別物」
＞じゃあ、クラスと構造体はどうして同じような構文になっているの？
「それが利便性ってもんです」
……俺、この時点で納得しちゃって良い？
「クラス定義と構造体定義は別物だけど、分かりやすいように同じ構文になっている」 で OTL
349:デフォルトの名無しさん
05/05/25 21:38:25
350:306
05/05/25 21:43:54
…… System.Struct なんて無いじゃん orz 昼間俺が見てたのは幻か～ orz
え～っと……ってことは、struct は実質 System.ValueType の継承……じゃなくて……
「struct で定義した構造体は、オブジェクト指向の世界からは System.ValueType を継承したオブジェクトのように見える」
……で良いんか？
351:デフォルトの名無しさん
05/05/25 21:53:05
構造体はオブジェクト指向の外に属するのん？
352:デフォルトの名無しさん
05/05/26 00:49:27
なにこの素人？
353:デフォルトの名無しさん
05/05/26 08:53:23
ちょっとありえないバカだな。
知識がないだけなら調べることで補えるが、
知識がないことに自覚がない上に無根拠な自信に満ち溢れて混乱した言葉を垂れ流すレベルになると
矯正はかなり困難。
354:デフォルトの名無しさん
05/05/26 08:57:33
構ってクンのつまらんﾈﾀだな
355:デフォルトの名無しさん
05/05/26 08:59:58
考えるな、推測するな、勝手に言葉を定義するな。仕様書を読め。
356:構ってクンうざい
05/05/26 09:21:27
>>355
>>347
357:デフォルトの名無しさん
05/05/26 16:05:10
>>1
まあ、その問題は、エロ本によるオナニーがさきか、それとも
実戦のセックスが先か、みてーなもんだ。どっちにも固有の良さはある。
でも、いつまでもオナニーに留まってるわけにはいかない。
そーゆーもんだ。
358:デフォルトの名無しさん
05/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
05/05/26 20:13:05
>>352-355
おお、なんか世界の裏まで知り尽くしているっぽい発言ですな
恐れ入ります
で、結局 「C# の構造体」 って何者なんでしょね