【オブジェクト指向】 ..
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
＞もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
いやいや、最終的に両方ともやらなければいけないのは分かっているんだけど、
ある程度のフィードバックが、実装レベルから分析レベルに伝播するから、
わざわざ分けずに一言で纏めちゃっても良いんじゃないかって言う勝手な話
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5389日前に更新/242 KB
担当:undef