あなたたち、オブジェクトとかインスタンスとか…

前から言おう言おうと思って黙ってたけど、この機会に言うよ！
オブジェクトの別名がインスタンスなんじゃなくて
クラスをインスタンス化したオブジェクトをインスタンスと言うんだからね！
勘違いしないでよね！！

違うだろ
オブジェクトをクラス化したインスタンスをクラスと言うんだろ

クラス化ってなんだよ
そんなのねーよw
JAVAの絵本でも読んでろwww

ふーん

てかちがうだろ

はあ？
おまえどこ中よ？

>>1
ワロタ。

「クラスをインスタンス化したオブジェクト => インスタンス」

一瞬うまい説明かと思ったけど、トートロジーで説明になっていない件ｗ

おまいら、オブジェクト指向の本を読んだほうがいいよ
馬鹿にしていってるんじゃなくて、読んでおいた方がいいよ
俺頭悪いから、人に何かを説得するだけの力ないけど、とにかく読んでおいた方がいいよ
3回いったよ

>>1
>勘違いしないでよね！！ 

ツンデレ？

でもオブジェクト指向とかプログラム書くやつがみんな知っている必要は無い
そんなの期待してたら仕事にならんからなｗ

クラスをオブジェクト化したのがインスタンス？

インスタンス＝クラスのオブジェクトじゃねーの？
プリミティブとオブジェクトを分けてるのは言語上の都合だろ。

クラスをオブジェクト化したのがインスタンス

インスタンスをクラス化したのがオブジェクト

オブジェクトをインスタンス化したのがクラス

愉快なスレだなｗ

クラスのインスタンスが、オブジェクト

名前や関数をポッチンで繋げて書くのがオブジェクト指向
引数がいっつも関数の()で指定するのが手続き型言語

反論は認めない

「メソッド」=「関数」

否、メソッド=振る舞い、関数=関数

いいかげんネカマから卒業してください

クラスをインスタンス化したオブジェクトがクラスである場合もあるんだからね！

論旨がみえん

インスタンスとオブジェクトのどっちが強いかだろ？
もちろんインスタンス

インスタンス＝実行単位
オブジェクト＝メモリ上の状態

class = instance builder object

なにそれ？

サーバーインスタンスという言葉がある
データベースオブジェクトという言葉もある

ルーチン！ルーチン！

鋳型=クラス
鋳物=インスタンス
どっちもオブジェクト

コルーチン！コルーチン！コルーチンコルーチンコーチンコ！チンコ！

じゃあクラスでないオブジェクトは何て言うの？

問題は、

オブジェクトとは何か？
インスタンスとは何か？

だろ？

インスタンスは相対的な言葉だよね

プリミティブ型クラス
プリミティブ型インスタンス
結局全部オブジェクト。

よーするによくわからん
ってことだな

正解

「構造体」＝「クラス」

C++はC言語の中途半端なオブジェクト指向拡張でしかないからなぁｗ

クラスベースのオブジェクト指向しか扱ったことがないやつには理解できまい

C++最強って思っていた時期が
オレにもありました

>>38
たしかに私はC++とJavaしか嗜んでおりません

javaはかなり無理をしてるがプリミティブにもクラス型があるからOOPに近い。

JavaはOOPLといえるだろう
あとは使い手の問題

そこでRubyですよ。

Rubyはアラン・ケイにも認められてるOOPLだからね。
JRubyとかいうのがもしかしたら、将来最強になるかも。ねーよｗ

インスタンスを日本語にすると、実体？実態？　
なんかどっちでも書いてあったりするけど、実体だよなぁ？

文脈によって使い分けりゃいんじゃね

若いの　オラが村では派遣の問題を口にしちゃなんねーだ
お前さんはまだわけぇから言いたいこともあるべぇ
だべな、派遣問題を口にするとムキになって怒る者がおるでよぉ
問題の指摘は駄目だっぺぇ
派遣のことは口にしちゃなんねぇ
この村みたいな糞田舎で悲惨な生活するためにはよぉ
北朝鮮と一緒でよ、駄目のものを駄目と言ってはなんねえだべさ

Wikipediaにはインスタンスの定義についてこう書いてある。

インスタンス
http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9

計算機科学でのインスタンス（instance）とは、オブジェクトの実体のことをいう。
instanceとは、英語で「実例」を意味する。オブジェクト指向言語においては、
多くの場合クラスと呼ばれるものを元に作成したオブジェクトの実体を指す。
データモデルやオブジェクト指向設計においても用いられる用語である。
インスタンスを生成することをインスタンス化（instantiate）という。

(略)


このように、同じオブジェクトでもメソッドなどの動きによってオブジェクトの状態が異なる。
そのときの一つ一つの状態のことをインスタンスと呼ぶ。

一般には、インスタンスはオブジェクトと同義として扱う事が多い。

オブジェクトの状態をインスタンスと呼ぶ？

大丈夫かこの説明・・・

ちんこ＝オブジェクト
まんこ＝オブジェクト
俺のチンコ＝インスタンス
読めのマンコ＝インスタンス
セクロス＝メソッド

ちんこまんこにセクロスメソッドはあるけど
ちんこまんこだけではセクロスできない。
俺のチンコと読めのマンコというインスタンスがあってはじめて
セクロスメソッドは可能なのである。

鋳型と鋳物の関係だろ

>>49
むしろ非常にうまい説明だろ


というか、OOPLだとしても言語によって用語の使い方が微妙に違ったりするが・・・

>>49
きになるなら、Wikiを修正してみてはどうだろう？

>>28-30
クラス（鋳型）からできたインスタンス（鋳物）にメッセージを送れば反応する。インスタンスはオブジェクト。
クラスにnewというメッセージを送ると反応する。クラスもオブジェクト。
オブジェクトOSならウィンドウにメッセージを送れば反応する。ウィンドウはオブジェクト。

たぶん、クラス＝newメソッドがあるオブジェクトと説明しないから皆こんがらがる。
もちろんnewメソッドがないクラスもある。

>>50
その例はいい！
それでWiki書き換えてｗ

オブジェクト＝インスタンス
は違和感ある
インスタンスは、オブジェクトの状態を表す
は、ある意味そうだ
オブジェクトとインスタンスは対象が同じだから同じものとして
扱われる事もあるけど、意味は違う。
「ちんこ」は、その物体を表しているにすぎないからオブジェクト。
「俺のちんこ」は、「ちんこ」が「俺」上で稼動状態にあるからインスタンス。

オブジェクトとインスタンスって同じ意味だと思ってた？違うの？

クラス＝オブジェクトの仕様みたいの
オブジェクト＝クラスの実体化したもの
インスタンス＝オブジェクトの別名

じゃないの？

オブジェクト＝クラスの実体化したもの
インスタンス＝稼動状態のオブジェクト

オブジェクト＝車
インスタンス＝エンジンがかかってる車
一般に、両者は「車」と呼ばれて区別しないが、「車」に付随する状態があるかないかの違いがある

つまり

インスタンス＝オブジェクトのメンバの変数の状態

のことか

車だと

エンジンがかかっている/かかっていない
窓が開いている/開いていない

みたいな、その時々の情報まで考慮したオブジェクトのこと

その情報は「実行中である」に限定されてるけどね
念のため、「実行中ではない」＝オブジェクトではない

クラスから作られた実態がインスタンス。
クラスとかそういうのに関係なく単に実態を示すのがオブジェクト。

どうしておまいらはどうでもいい話題だとこんなに張り切るのか・・・

・専門用語の意味がわかった（つもり）のヤツほど講釈をたれたがる
・さらに、自分の方言が標準語だと思い込んでるヤツが他の方言を訂正したがる

馬鹿ばっかりだからマジレスしておく

クラスをインスタンス化したオブジェクトはエンティティだ

>>28
> 鋳型=クラス
> 鋳物=インスタンス
それはいいとして、

> どっちもオブジェクト
それはちょっと違うと思う。オブジェクトになるものはSingletonのような
staticなインスタンスしか生成できないクラスだけなものだけ。
Singletonなオブジェクトは、インスタンスにしても一切変更できないし
どんな場合でも確実にインスタンス＝オブジェクト
という状態が成り立つ。

不変クラスのオブジェクトについても同様に
インスタンス＝オブジェクト
の関係が成り立つ。


現実世界を基準にすれば、別の意味では、森羅万象を構成するすべての
ものという意味で、オブジェクトと言うことになるけれども
プログラムの中ではちょっと違うかな。


一方、可変クラスのオブジェクトの場合は、
オブジェクトを生成したとき、そのオブジェクトのインスタンスは、
生成後も「可変クラスのオブジェクト」つまり「可変オブジェクト」ということで変化しうるので
同じオブジェクトでも状態が変化するから一つのオブジェクトでも異なるインスタンスを持つことができる。
よって、可変クラスのオブジェクトの場合は
インスタンス≠オブジェクト
という関係になる。

●可変クラスの場合
オブジェクトとインスタンスとの関係は　1対多
クラスとオブジェクトとの関係も1対多

●不変クラスの場合
インスタンスを生成後、インスタンスを一切変更できないため

オブジェクトとインスタンスとの関係は1対1
クラスとオブジェクトとの関係は1対多

●Singletonの場合
インスタンスを一つしか生成できないため
(オブジェクトも一つしか生成できない)

オブジェクトとインスタンスとの関係は1対1
クラスとオブジェクトとの関係も1対1

>>55
だめだろ。
つうか>>50の場合
ちんこまんこはクラスで
俺のちんこまんこはオブジェクトまたはインスタンス

>>57
> オブジェクトとインスタンスって同じ意味だと思ってた？違うの？
> クラス＝オブジェクトの仕様みたいの

それは合っている。
例としてここでは「人間」


> オブジェクト＝クラスの実体化したもの

それは合っている。だが、厳密には、実態と言ってもそのとき
その瞬間の実体を表すものとはいえない。

例として、ここでは「ある人間Ａ」。
ある人間Aは0歳の乳児であっても10代の少年であっても
20代の若者であっても40代の中年であっても
100歳の老人であっても、とにかく「ある人間A」というオブジェクトを表す。

ゆえに、newで生成したら、そいつはnullになるか再度newされたりFactoryなどから
makeされるまでずっと同じオブジェクト。


> インスタンス＝オブジェクトの別名
> じゃないの？

違う。インスタンス＝オブジェクトの実態
そのときその瞬間の実体を表すもの。


例として、ここでは「ある人間Ａが50歳の時の姿」

newで生成されてから、インスタンスメソッドによって変更されれば、異なるインスタンスと見なされる。

>>63
オブジェクト指向プログラミングになれてくると
確かにどうでもいいが、初心者が気にするようなので。

>>64
そこでＵＭＬの出番だ

>>65
それも良いが。
実体をわざわざエンティティ
と英訳しただけに見えてしまうが

俺はあえて抽象度合で区別すると

クラス＞インスタンス＞メソッド

だと思ってたんだけどちんこまんこ議論見てて自信なくなってきた

×クラス＞インスタンス＞メソッド
○クラス＞インスタンス＞オブジェクト

メモリの中に存在するのはインスタンスとクラスのみ
メモリのなかにオブジェクトは存在しない

BY　どっかのだれか

>>73
> 俺はあえて抽象度合で区別すると
> クラス＞インスタンス＞メソッド

メソッドと、クラス・インスタンスは畑違いだろ。


抽象度なら
クラス > オブジェクト > インスタンス


確かにメソッドも無形のものだが・・・・

>>74
あ、訂正していたか

>>75
インスタンスは存在するが、クラスは、存在方法が
異なる

>>48
そもそもその文章の中の「実体」という日本語が指す意味が俺には分からんですたい

うむむ

>>77
俺も理解に苦しんだ

クラスもメタクラスのインスタンスだったりする

インスタンス「化」してオブジェクトを作るってところで
インスタンス＞オブジェクト
って印象が付いたのかもな

Pythonスレに出てくるメタクラスの人って何者？

初心者でわからない単語ばかりです。
>>50 ベースでのトークは無理でしょうか？
ちなみに妹のマムコはインスタンスでいいんでしょうか？

>>56
それで考えると、
「ちんこ」はオブジェクト
「俺の」はメモリ

メモリの上にオブジェクトが乗っかってる状態がインスタンス。
つまりメモリの上に乗った「瞬間」にそれをオブジェクトとは呼ばなくなると言うことか。

みかんはオブジェクト、そのみかんがアルミ缶の上に乗った状態をアルミカン-EXと名付ける。
アルミ缶の上にあるのはたしかにみかんだが、もはやそのみかんとアルミ缶を別々のものとして
名付けることは無意味な事。それそのものがアルミカン-EXなのだ。

燃えてない火は無い

>>79
たとえば
int x = 1;
という変数があったとしよう。
これのxはJavaではオブジェクトではなくプリミティブ型の変数であるが、

仮にオブジェクトだとしてみようするｔ。
オブジェクトxのインスタンスは1ということになる。

x=2;としたら
xのインスタンスは2ということだ。

>>88
=メソッドが定義されているかによる

>>88

ちがうよｗ

intオブジェクトのインスタンスｘだよ。

Javaって変数がオブジェクトなの?

まさかｗ
プリミティブ変数。ここに限界がある。

int.classでプリミティブのクラス型はとれるけどな。
Integer.class != int.class、でもリフレクションのときは
Integerを放り込むあたりちょっとだけ破綻してる。

Wikipediaの記事はJAVAの例しか書いてないから
誤解が生まれるな。

>>92
Integer x = new Integer(1);とすればオブジェクト

今なら、Integer x = 1;
でもいい

右辺の 1 そのものはオブジェクトなの？

１も２もオブジェクト。

Cも変数のことオブジェクトって言うことがある。
英語の仕様書かなんかに書いてあった。

全てがオブジェクトでしょ。
クラスオブジェクトからインスタンスオブジェクトを作るって話で、Javascriptだとprototype指向でクラスとインスタンスの区別が無いからオブジェクトと呼ぶと。

そこらへんはSmalltalkとかRubyのが純粋だな

ほなってメモリの上にオブジェクトなんてないねんもん。

>>100
Ruby＊笑＊

>>96
これみて光が見えた初心者ですが、
この考え方は本当なんでしょうか？ネタなんでしょうか？

>>103
何の光だよ。
JAVAやりたいならここ覘いてるより本を読んだほうがいいよ！

オブジェクトで出来ること、出来ないこと
プリミティブ型で出来ること、出来ないこと

この４パターンを試してみればわかるんじゃまいか？

プリミティブ型はnullのない不変オブジェクト、というのがJavaの認識になってるな

>>100
rubyは関数がオブジェクトではないが、論理的一貫性よりそっちのほうがいいや。

確か四則演算はプリミティブ型しかできないから
てきとうに計算してみるとか。

でも一見オブジェクトで計算しているように見えちゃうから
やっぱりメモリーを考慮するレベルの処理をやってみないとわからんのとちがう？

Cで考えると
ローカル変数とかスタック領域を利用するのがプリミティブ型かなとか思うんだけど
オブジェクトやクラスはメモリのどのあたり使うんだろう。

テキスト領域にクラス、mallocで開放されるデータ領域にオブジェ…
あ、このスレによると、オブジェクトの段階ではメモリーに乗らないのか

>>95
じゃ、他の言語の例も追記してくれ

いまぱっとググってみたところ、インスタンスはヒープ領域に割り当てられるらしい

>>109
概念の問題

第1回　「オブジェクト，クラス，インスタンスの関係」
http://itpro.nikkeibp.co.jp/free/NIP/NIPCOLUMN/20021126/1/

クラスとインスタンスだけだったらどの言語も共通してるような？
「オブジェクト」という言葉が指してる内容が言語によって違うし
本質的に必要ない気がする・・

バズワード、みたいな？

名付けに困ったら取り合えずオブジェクトと呼んどけみたいな、あれそれこれどれに近い物。

「オブジェクト」は概念をあらわしているので必要。

で
結論でた？

>>103
本当。
後者は、Java SE 5から可能になった記法。
今まで x = new Integer(1);
しなければIntegerオブジェクトを生成できなかったところを
x = 1;と書いただけで


x = new Integer(1);と書いたのと同じ効果になり、コード量が若干短くなった。

シンタックスシュガー

>>106
ついでにいうと、メソッドも無い。
それに、参照型ではないし。

これはJavaに限った話であってC#はまた別でもっと複雑。

>>108
Javaでは
プリミティブ型やstatic変数はすべてスタック領域で処理される。
参照型であるオブジェクトはすべてヒープ領域で生成され、
時と場合に応じてスタック領域を参照する。

何で特定の言語実装の話になってるのｗ？
そういう観点で考えてはいかんだろｗ？

1.toString();

>>122
じゃあ、お主が助言してくれ。
皆、それぞれ、得意不得意言語ってものがあるんだろうから

>>96
それって変数xそのものがオブジェクトなの?
xが参照している先にあるモノがオブジェクトなんじゃないの?

何でインスタンス化とかわけわかんねー日本語作るかなー
実体化でいーじゃねーか
オブジェクトも物でいーじゃねーか
クラスがムズイな、どーせプログラムなんだし設計図でいーんじゃね？
設計図をもとに実体化した物を使って組み立てるのがオブジェクト指向、あーすっきり

>>126
クラス=鋳型 がいいとおもう。

…が、そうすると インスタンス=鋳物?

>>125
xそのものがオブジェクト。先に書いてあるものはインスタンスに近い

>>126
Instantiationという英語があるから。
それに対応する「インスタンス化」という日本語が必要になる。

C++畑の人の突っ込んだ意見も聞いてみたい

序盤で誰かが言ってたけど、インスタンスってのは相対的な表現だろ？
Hoge h1 = new Hoge();
だったら、h1は『オブジェクト』であり、『Hogeクラスのインスタンス』である。
と言える。
相対的であるのだから、『インスタンス』と単発で言っても、そこには暗黙的にインスタンス化をされたメタ的要素(クラスやメタクラス)が存在する。
『オブジェクト』は、単発で言っても、特にインスタンス化をされたメタ的要素を意識する必要がない。
俺は『○○のインスタンス』のように、必ずメタ的要素と組にして用いてるが。

>>127
インスタンスは鋳物でいいだろう。
だがその鋳物オブジェクトも時と場合により変化する。
変化すれば異なるインスタンスになる。

理解できるところまでの足場をかためたいんだけど、
スタック領域を直接利用するのはプリミティブ型のみでおk?

クラスやインスタンスやオブジェクトや色々あるけど、
そのへんのものはデータ領域の中のヒープ領域あたりでうごめいてて、
必要に応じてスタック領域のプリミティブ型を参照したりして利用する。
でもクラスやインスタンスやオブジェクトは、「原則として」直にスタック領域に
侵入することはない。

インスタンスが相対的な概念というのは
「状態」と「物」との相対的な関係の総称だからじゃないの？

車はオブジェクト
走っている車はインスタンス
ちんこはオブジェクト
俺のちんこはインスタンス

走っている車だろうが俺のちんこだろうが
車は車。ちんこはちんこ。

でも、「走っている」とか「俺の」とか、修飾的な状態が付随したとき、それをインスタンスと呼ぶと。

>>132
鋳物の容器A、Bがあって、Aには水が、Bには黄金水が入っているとかいう感じか。

抽象的←　クラス　オブジェクト　インスタンス　→具体的

　　　チンコクラス　チンコ　俺のチンコ
　　　車クラス　　　車　　　走ってる車

>>131
UMLだと、「オブジェクト図」「コラボレーション図」「シーケンス図」ってものがある。
そのときにオブジェクトを表すものが角が丸い箱や四角い箱で表現されるが

オブジェクト図では同じオブジェクトであっても中身が異なれば別の箱で表現する。
http://www.atmarkit.co.jp/im/carc/serial/object07/object07.html

こんな感じに
http://www.atmarkit.co.jp/im/carc/serial/renew_uml07/renew_uml07.html
http://www.atmarkit.co.jp/fjava/devs/renew_uml07/fig7_2.gif

クラスとオブジェクトの違いは大体みんな理解できているけど
オブジェクトとインスタンスはイメージ掴みにくいんだよ

以下各言語ごとに解説コード付きで説明よろしく

「燃えていない火」
インスタンス的にはありえないが
オブジェクト的にはありえる

「火」というものが「燃える」という状態と関係無しに定義できるならね。

>>139
ぬるぽ

>>133
> 理解できるところまでの足場をかためたいんだけど、
> スタック領域を直接利用するのはプリミティブ型のみでおk?

NO. クラスの中に含まれるstaticフィールドもスタック領域に確保される。
ゆえにSingletonの中身は必ずスタック領域に入る。
Class.forName()で呼び出されるJDBCドライバも同様。


ヒープの中のオブジェクトは、直接または間接的にスタック領域から指されている。


オブジェクトや配列はヒープ領域にしか確保されない。
つまりポインタ。

>>135
鋳型で作った鋳物は使っているうちに変化する。現実世界では特に。
DNAを持った受精卵から生まれた生き物は成長し、老化する。それと同じ。

この世に、剛体と呼ばれるものが存在すれば、インスタンスは一切変形しない。
だが、そんな理想の物体はこの世に存在しない。クラスというものも、実体としては存在し得ないイデアである。
オブジェクトはクラスと違って実在できるが、インスタンスという状態を持っていて、常に変化する。
誰かの写真を撮ったとき、その人のインスタンスの姿が写真となって映し出される。
その後、10年、20年経過してから取り直すと、異なるインスタンスを写真が見せてくれる。
二つの写真を比較するとインスタンスが異なることがわかる。


人間 : クラス
Aという名前の人間 : オブジェクト
Aという名前の人間が移っている写真 :Aという名前の人間のインスタンスを表示している

>>136
抽象、具体は、クラスの継承関係を表すときに使うのが相応しい。
よってちょっと違う。

>>138
つ[Wikipedia]

staticフィールドがスタック領域を使う理由はなんだろう…

static
「同じクラスから生成したオブジェクトでstaticを付けたフィールドは値が同一になる」
って書いてあるから、スタック領域で頻繁に値が更新されることを見込んでスタック領域に
割り当てたのかな…

カブト　イエバ　チンコデショ？

mainてメソッドだったのかー！
クラスかと思ってたああああああああああ

何が嘘で何が本当かということを真に試されるスレだなｗ

>>145
> staticフィールドがスタック領域を使う理由はなんだろう…
> static
> 「同じクラスから生成したオブジェクトでstaticを付けたフィールドは値が同一になる」
> って書いてあるから、スタック領域で頻繁に値が更新されることを見込んでスタック領域に
> 割り当てたのかな…

なんじゃそりゃ。staticフィールドとインスタンスフィールドとの違いわかってないだろ。
そんなことも解らないようじゃ、オマエサンは
Servletでstatic変数定義して銀行口座二重引き落としというとんでもないバグを作りそうだな。


ヒープに置く必要がないからスタックに置いてるだけだろうが。
インスタンスフィールドは仕様上どうしてもヒープ領域に置かないといけないから
仕方が無くそこに置いているだけ。
staticでいいならstaticに置くことでパフォーマンスを改善できる。

>>147
形を見ればメソッドだとわかるだろ

>>148
それはなんだ。
どういうことか気になってきたぞw

>>149
static修飾子をつけたフィールドがスタック領域
finalやその他の修飾子を付けたフィールドはスタック以外の領域

だと思ったの。

いっぺんメモリー離れて純粋なJAVAの勉強してみる

>>136
中小具象はともかく
下の2行は正しい！

　　こ　　の　　ス　　レ　　　レ　　ベ　　ル　　低　　す　　ぎ　　ｗ　　ｗ　　ｗ

どうぞ我々を置き去りにしてレベルの高い議論をやってください。
無理だろうけどねw

>>155
口先だけのお前にはレベルの高い議論は無理。
文句あるならWikipedia行進してみろやw

俺は>>155じゃないが…
まず、Smalltalk-72が35年前、Simula67なんて40年前にできてるのに、なんでオブジェクトの説明にデザインパターン>>141が出てくるんだ？
メモリだって磁気コアメモリの時代にヒープ？スタック？
スタックレジスタもないのにスタックと言われても…
しかも、この時代はオブジェクトなんて単語は使われてなかった。
「オブジェクト」という単語が論文に初めて書かれたのが1978年の1月。
だいたい、なんでオブジェクト指向の発明者でもない一般利用者がオブジェクトを定義するかね。
俺の定義は発明者のソースだけ。

1978年に書かれた論文
↓
http://portal.acm.org/citation.cfm?id=512762&jmp=references&dl=GUIDE&dl=ACM

>>158
40年前のものを引っ張り出されてコレが定義たといわれても・・・・
言葉の意味なんて時とともに変化していくモンしょｗ
いまオブジェクト指向の第一人者だって40年前は一般利用者。
発想が未だにコボルしかやったことの無いコボラーと同じｗ

>>158がそう思っているならいいんじゃない？
一人でもともとの定義はとかぶつぶつ言うタイプだろ

まあ由来を示すのは議論に有益なこともあるけど、
>>158のはだからどうした? 以外の感想は持てないなあ。
その由来が現在の定義にどう影響してくるかまるで書いてないじゃない。
「どうだおまえら知ってるか」程度の情報じゃあね。
ま、現在の状況がキャッチアップできてないんだろうけどもね。

>>100
「純粋」の意味は、誰のどんな「オブジェクト指向」に乗っかるかによると思う。
Smalltalkはともかく、いろんな言語のイイトコどりのRubyが純粋だなんてことはありえない。
Rubyなんかより、後述の後者においてならJavaのほうがよっぽど“純粋”だ。

一般には、「オブジェクト指向」（特に「〜プログラミング」において）で代表的なのは、
* アラン・ケイの「メッセージングによる表現や設計」
* ビヤーネ・ストラウストラップの「ユーザー定義型をクラスを使って実現する手法」

前者はいわゆる「オブジェクト同士がメッセージをやりとりして…」とかいうやつで、
後者はいわゆる「カプセル化、継承、ポリモーフィズム」に象徴される（メイヤーとかも原則こちら）。
両者は教科書レベルでもごっちゃにされているけれど、本来は出自も切り口も頓着する点も異なる。
「良質」のOOPLかどうかの言語間宗教戦争みたいなのも、どちらに軸足を置くかという違いに過ぎない。

158の言いたいのは、たぶん前者の「オブジェクト指向」における「オブジェクト」の要件。
つまり、オブジェクトとは、メッセージの「レシーバ」でなくてはならない…と。
後者の立場ではそんなのは関係なくて、再三出てきているようにクラスの「インスンタス」であればよい。

それと、後者の「オブジェクト指向」では、すべてがオブジェクトである必要はない。
むしろ、クラスにより定義した新しいユーザー定義型が、基本型と同様、安全かつ普遍的に使えることが重要。

クラスはイデア

チンコ マンコ＝クラス
　　　　↓クラスのインスタンス化
俺のチンコ 嫁のマンコ＝インスタンス

チンコ マンコ 俺のチンコ 嫁のマンコ お前のチンコ 幼女のマンコ ＝ オブジェクト

おなにー セクロス＝メソッド

クラスからオブジェクトをインスタンス化するっていうけど、
オブジェクトからインスタンスになる過程をインスタンス化みたいな言葉で
表現できればすっきりする。

むしろ日本語の方がこのへん得意なんじゃね？

クラス→(実体化)→オブジェクト
オブジェクト→(実態化)→インスタンス

実体化はnew演算子で明示的に理解できるけど、オブジェクト→インスタンスの過程はよくわからないよね。
車が「走る」状態は、時速何キロメートル以上の速度で移動している状態とかそのへん定義できないと。
「うさぎと亀は永久にゴールできない」とかの数学者の偏屈にマジレスできるレベルじゃないと理解することは難しい。

クラス＝オブジェクトについて

日本はかつてアメ車をクラスとして日本車を作った

クラス＝アメ車
オブジェクト＝日本車

現在は特アが日本車をクラスとして特ア車を作り始めている

クラス＝日本車
オブジェクト＝特ア車

つまり日本車はオブジェクトでもあり、クラスでもある。

また、自動車の起源はヨーロッパであるので、そういう意味ではアメ車はオブジェクトであり、
特ア車は将来アフリカやアジア諸国で参考にされた場合、クラスとなり得る可能性もある。

クラス＝オブジェクトと仮定する
またオブジェクトの別名がインスタンスであると仮定すると、本質的には

オブジェクト＝インスタンス

よって
クラス＝インスタンス　　　//


ん？

３年B組というクラスの、
出席番号１番というインスタンス。

こんなスレが立つのは、JavaやC++の市販本の説明が下手なためだ。
どの市販本もオブジェクトとクラスとインスタンスの違いを説明しているが、かなり適当だ。
そのうちわかるよ、みたいな感じだ。
確かに、そのうちわかってくるが、わからない人は何年もわからないまま放置されることもあるだろう。

初心者本はとりあえずオブジェクト＝インスタンスでやったほうがいいんじゃなかろうか。
数学で微分でも、微分の定義を初めから説明しても分かるはず無いし。
y=2x^2
y'=4x
とか、とりあえず練習問題の数こなしてその後に改めて定義を見ると
理解しやすいし。

クラス：設計図
インスタンス：製品

それらはオブジェクト（物体）と言えます、じゃいかんの？

上にもあるけど、これでいいだろ

クラス＝オブジェクトの仕様みたいの
オブジェクト＝クラスの実体化したもの（メモリー中にその実体のための個別の領域が割り当てられている）
インスタンス＝（メモリー中などに）存在しているオブジェクトのメンバの変数の状態までを考慮したもの

一般的には
オブジェクト＝インスタンス＝クラスの実体化したもの
で十分

>>158
> 俺は>>155じゃないが…
> まず、Smalltalk-72が35年前、Simula67なんて40年前にできてるのに、なんでオブジェクトの説明にデザインパターン>>141が出てくるんだ？
> メモリだって磁気コアメモリの時代にヒープ？スタック？
> スタックレジスタもないのにスタックと言われても…

古臭w

何時の時代の話だよw >>141のどこにデザインパターンが出ているんだw
Java基準で十分なんだよ。今はオブジェクト指向といえばJavaと言われている時代なんだから。
UMLの用語もJava用語を基準に策定されている。

>>166
ヒュンダイ(現代)や中国のパクリ車両みたいな糞車両を想像したじゃねえかw

静的なものか動的なものかで整理したほうがわかりやすくない？

静的なもの
クラス

動的なもの
(1) 今まさに動的なものに変わった瞬間　インスタンス
(2) とっくに動的してますが、なにか？　オブジェクト

Javaが基準ならオブジェクト＝インスタンスと考えていい

JavaというかUMLが基準なら。

UMLは標準の統一モデリング言語なんだから
UMLの基準に沿うべきで
プロトタイプベースオブジェクト指向の考え方は無視すべき

>>176-177
あえて言えば、JavaやUMLならオブジェクト＝クラスでしょう。
クラスベースでクラス＝非オブジェクトの考えなら、そのオブジェクト指向の土台が崩れるでしょう。
もし、考えは関係なく、「オブジェクト」の文字だけが重要なら、
ファーストクラスオブジェクトもオブジェクトになってしまうでしょう。
しかも、クラスのオブジェクトでしょう。
ちなみに、＠ITのファーストクラスオブジェクトの説明は、新説の誕生でしょう。

>>178
> >>176-177
> あえて言えば、JavaやUMLならオブジェクト＝クラスでしょう。
そんな大嘘はいかん。JavaやUMLにはそんなもんない。

クラスがスミス本体のデータが書かれているオブジェクトだとして、

ネオと戦う大量のスミスたちは元となったスミスのインスタンスという名のオブジェクト。

俺にしてみればオブジェクト＝クラスがJavaに無いと言いきる>>179がありえない。

実務レベルでいえば、「オブジェクト＝変数に格納されたもの」だよ。

Class clazz = Object.class
Object o = new Object();

「クラスは(is a)オブジェクトである」
「インスタンスは(is a)オブジェクトである」
てわけ。

他の奴らよりも何となくわかりやすい感じがするけど
もっとわかりやすくちんことまんこで例えてよ

ネオのクラスは スミスのインスタンスとして上書きされたが、
スミスのインスタンスとなったネオは、スミス本体のクラスにアクセスし、そのクラスを削除したことにより、
大量のスミスのインスタンスオブジェクトは マトリックスから姿を消した。

継承元の親をレイプしても
叔母とか従姉は死なないんじゃないの？
スミスっていきなり母叔母従姉のスーパープレイしやがったの？
うらやましすぎじゃね？

ナルト ＝ クラス ＝ クラスオブジェクト

↓

影分身の術

↓

インスタンス ナルト ＝ インスタンスオブジェクト

逆にオブジェクトとインスタンスが明確に区別されてる言語って何よ？

>>187
JAVAじゃね？ｗ

っかインスタンスオブジェクトって便利だよなぁ。
BASIC房な俺は配列変数を駆使しまくりんぐｗｗ

>>188
マジかよ裏ルート君

JAVAで理解できなければ救いようが無いって事かよ
ざけんじゃねえよ

＞＞インスタンスという名のオブジェクト
これが何を言ってるのか全く分からない by script系言語使い

＠IT：いまから始めるJava　第4回
ttp://www.atmarkit.co.jp/fjava/rensai2/javaent04/javaent04.html


>>「電気製品」クラスを継承して 〜（中略）〜 「カラーテレビ」クラスを作る

>>特にどの本というわけではないのですが、
>>どうしてこういう例え話が出てきてしまうのか、
>>私にはさっぱり分かりません。
>>クラスの概念を哲学用語か何かのように説明するの
>>はいいかげんやめにしてほしいものです。


いまから始めたので見ているサイトなんですが
すごい断言しているんですが
この考えでいいんでしょうか？

んなこた、自分で判断しろ

>>191
間違いじゃないからいいんじゃないの？
初学者は逆に言いきってる感じの文献参考にした方がとっつきやすいだろうし。
ただ、厳密な意味では違う場合もあるということを頭の片隅にいつも置いておくことは必要。
そういう可能性を無視して我が道を行きすぎると、頭の硬いプログラマーになる。

お薦めとして、初学の場合はサイトで勉強するより本で勉強するべき。
俺の経験上の話だけど、定着度が明らかに違う。

>>191
その後メモリの使い方で説明してんのな。余計わかんねーよタコｗｗｗｗｗｗｗ
初心者（オブジェクト指向って何？レベルの人）にはカラーテレビ云々の説明でおｋだと思う

>>191
そのサイトで分かりやすい人と、哲学用語でわかりやすい人といると思う。
でも多分そのサイトで分かりやすい人はオブジェクト指向自体向いていないと思う。

ttp://www.rupan.net/uploader/download/1168951504.jpg

ほれ。これでわからなかったらマトリックスみなさいｗｗ

メモリとの関係で理解しようとする人には良いサイトだと思う。
ただ初心者や純粋にJAVAだけの人にはわかりにくいというか、興味わかないだろうね

Neoのインスタンスオブジェクトはどこにあるんですか

スミスとネオはクラスじゃないなあ
俺もはじめはそういう類の間違いしてた。

>>192
そうなれるように努めます。

>>193
基本、初心者本で学んでますが、本ではほとんどTVの話でした。
それを全部ぶっ壊せというセンセーショナルな台詞に
ふと目線を奪われました。

>>195
・・・このサイトがわかりやすと思ってしまいました。

>>196
Smith&Neoと加えて前述のチンコの話が結構気に入りました。
ありがとうございます。

>>198
ネオはインスタンス作らないで クラスオブジェクトとして インスタンススミスと 戦ってます。

>>199
まじか。んじゃ実際なんなんだ？？

インスタンスラーメン

ネオもスミスも人だよな。
ネオとスミスの違いは基本的には属性の設定値だけ。

スミスの増殖は、インスタンスに対してcloneメソッド呼んでる感じ。

>>199
ごめん。今古本屋で３００円で買ったJAVAの本読んできた。
ネオとスミスはインターフェースで、 そのネオとスミスの【独立した操作】がクラスだな。

>>202
ｋｗｓｋ

>>201
ネオ、スミスの設計図＝DNAみたいなもの？が、クラスなんじゃねーの？
というか、人間とか、絶対プログラムできないもので喩えるのはよくない気がする。

>>204
操作があらたな未定義述語になってるけど？さらに状況を複雑にする気か？ｗ

おれのちんこのせっくすめそっどはすたてぃっくです

ちょい解釈まずってたからな。
これじゃマトリックスでたとえられんわｗ

>>203
だいたいわかりました。

＞「参照型とはエイリアス（alias：別名）のことだよ」

なるほど！！
と思えるのはUnix系OSかじってる人くらいだなw
CとメモリとUnix系OSの知識がそこそこあれば面白い

↑わりぃ名前欄ミスです。はいすいません。

>>1はツンデレだから>>208は偽物だな

>>205
オブジェクト指向の、「オブジェクト」ってのは常に
見る人目線で考えればいいんだよ。

極端な話、人間クラスつってもこれで十分（なときがある）

class Human {
public String name;
}

スミスはインターフェースだな

>>212
そういう、本来人間という名前を与えるべきでないものを、
その場限りの見方で、人間と呼んでしまうことが、学習者に対して
障害になってる気がする。
もっと、ちゃんと計算機能を持った計算機とか、
掲示板機能をもった掲示板とかで例を示してあげれば、
関数を理解するのとほぼ同じ感覚で理解できるようになるのでは？と思う・・

〜〜の設計図＝クラスっていう言葉は、すごく有害と感じる。
わかって無いのにわかったつもりになってしまうし、しかも肝心なところが全然的外れ。

やっぱりさ、メモリ（ry

クラスを拡張するのとインターフェイスでひっつけるのって違いあるの？
僕の肛門も拡張されそう。

>>214
＞本来人間という名前を与えるべきでない
ってのがオブジェクト指向的でない気がするんだけど。

そもそもインターフェースって言葉も意味不明なんだよ。
JAVAだとクラスの付属品みたいな印象だけど、
一般的なPC用語じゃ各種入出力装置やディスプレイだったり
かと思えばAPI的な事だったり、意味派生しすぎ。

PC業界って、基本ボキャ貧なのか？

>>217
インタフェースは、インタフェースを実装するクラスにとっては何の役にもたたないけど
そのクラスを外から使うやつが使いやすくなる。
つかオブジェクト指向全般にいえるのけど「〜〜する相手」を「扱いやすくする」技術といってよい。

＞インターフェースって言葉も意味不明
そんなことねーよものすげー厳密かつ明瞭だよ。
「２つをつなぐもの」

>>220
すごいわかりました。
ありがとう。

>>218
オブジェクト指向的って何？・・・

それぞれのクラスには本来与えるべき名前があると自分は思っていますが？
>>212
のHumanの例だったら、MyStringとかそういう名前以外はおかしいと思う。
なぜなら、Stringを一個記憶するだけのクラスは素のStringとほぼ同じだけの
機能しかもっていないから。
それをHumanと呼んでしまうのは、はっきり言って「人間は名前だけで決まる」
みたいなかなり無理のある比喩が入りすぎてる気がする。
比喩が入ってること自体は全然かまわないけど、初心者に最初に見せる例と
してはすごく不適切だと思う。

>>221
すごいわかりました。
ありがとう。

ttp://files.or.tp/up3296.jpg
ほいほいこれみれ。
スミスよりわかりやすいぞ。

インスタンス　インスタンス　インスタース　インタースース　インターフェイス？

>>225
（・∀・）ｲｲ!!

>>223
＞それぞれのクラスには本来与えるべき名前があると自分は思っていますが？
コレって、アーキテクチャつか実装よりのクラスの話なら同意なんだけど
ドメインレイヤのクラスつくってるときに、Stringを一個記憶するだけのクラスといっても
MyStringって名づけるのはおかしいよな？

階層名String

>>188
Javaだけとは限らない。C#などにもある。

staticに対してインスタンスという表現もある。

staticフィールド'(クラス変数)、インスタンスフィールド(インスタンスメンバ変数)。

staticメソッド(クラスメソッド)、インスタンスメソッド

>>189
UMLはJavaで理解することを前提に設計されているわけだが

>>191
オブジェクト指向の世界ではむかしからそうだ

>>196
ﾜﾛｽ

>>201
スミスとネオはオブジェクト

アバターや人間がクラス。

ネオをクラスにしたければ、シングルトンクラスになる。

>>203
cloneというか他人をpaste, overwriteしてるみたいな

>>219
デザインパターンの本を読めば解るし

ＵＭＬを勉強すればわかる

あなたに選ばれオーバーロード
あなたに染められオーバーライド

〜恋のオーバーライド〜
作詞・作曲　ム板の2chネラー

>>233
ちなみに インターフェースは 「人間」

私がオブジェクトになっても　本当に変わらない？

で
結論でたー？

情報統合思念体が言語を持たず直接的に有機生命体とコミュニケートするために造った
対有機生命体用ヒューマノイド・インターフェースには
主に、『長門有希』『朝倉涼子』『喜緑江美里』・・・等、多数のクラスが存在する。
別の時間平面上に存在する自分に対し、記憶を共有することが可能。ただし、情報統
合思念体にアクセス許可を申請し、許可を貰わないと行えない。ただし、長門有希は時
空改変以降、同期を行うことを自主的に禁止を行った。

>>240
インターフェースが『人間』なら。変わらない。

>>241
オブジェクト＝インスタンス

まだか・・・

>>243
それだとインスタンス指向になりはしないか？
それともあなたはJava＝UML＝オブジェクト指向の人？

>>245
ちがうよ。

>>245
243じゃないが 一般的にオブジェクトだけだと インスタンス オブジェクトを 差すらしい。

クラスオブジェクトもあるわけだが。

メタクラスといっとけ

インスタンスとオブジェクトの違いがはっきりわかっていないと困る場合ってほぼないよね
困る事例とかある？

>>247
分かった。
ありがとう。

普通文脈から判断して使い分けるからソウソウ困らん

>>247
オレは指さんな

>>252
じゃあ何を指すの？

オブジェクト＝インスタンスにおさめたい香具師はたくさんいるだろうなｗ

ほなって分ける必要無いし勉強するのめんどいんやもん

だってインスタンスオブジェクトなんて言葉ねーでしょ？

インスタンスクラスがあればインスタンスオブジェクトもあるか・・・・ｗ

インスタンスクラスのインスタンスはインスタンスインスタンスｗ

インスタンス の オブジェクト ｗｗｗｗ

オブジェクトは英語で言う不定冠詞「a」のついたモノを表し、
インスタンスは英語で言う定冠詞「the」のついたモノを表す。

といえば、いいのかな。どちらもクラスから実体化したモノだけども、
「ここにモノがあったとしよう」というときはオブジェクト、
「このモノが」というときはインスタンス。

てか日本語ではこの辺の使い分けをうまく表現できるのかな。
できないからややこしいんじゃないのかな。

メンバクラスってJava特有だっけ？

>>260
お
そんな感じだよね

表現できて、用途はなんなんだよ

オブジェクト　という言葉は設計時によく使うなー
テストやデバッグ時はインスタンスというなー

>>260
じゃぁ インスタンスは オブジェクトとして利用できないわけで？

最も設計時でも、動的側面を表現する時にはインスタンスといったりするなー

>>265
なにいってんのー？

Javascript勉強してみ
びっくりするから

>>249
確かに。実務で困る場面ってあるの？

>>269
中途半端にインスタンスとかオブジェクトとか混在して話されると
訳わかんなくなりそうになるから困るｗ

だいたい、水は水、お湯はお湯というだろ
水とお湯を混在したりしないだろ？
それと同じ

なら、インスタンスに定義されてるもろもろがオブジェクト？

共通点を探さず相違点を探しなさい

>>272
オブジェクトもインスタンスもクラスから実体化したモノではある。
違いはというと、

ただ漠然と頭にモノを思い浮かべているときは「オブジェクト」
「このモノは」とモノに指さしているときは「インスタンス」

実体化されたモノ一般を表現するときは「オブジェクト」
実際に実体化したモノを表すときは「インスタンス」

てな感じ。

>>274
なるほどな。
まぁ俺の解釈だと、

オブジェクト は 操作ができる対象 だと思ってる。
クラス単体だってそのまま操作できるから クラスも オブジェクト。
クラスから生成されたインスタンスだって
そのインスタンス単体を操作することができるから オブジェクト。

だから クラスオブジェクト。 インスタンスオブジェクト。 と言ったのだが。
確かにこの表現だとおかしいなｗ

>>274
それだったら、
an instanceと、the instanceで区別すればいいじゃん。
定冠詞がついた状況と、不定冠詞が付いた状況で別の単語だなんておかしい。

>>275
俺はインスタンスオブジェクトって単語は、インスタンス＝オブジェクトを略してると思ったからよく分かった。
同じようにクラスオブジェクトって単語も、クラス＝オブジェクトだと思ったからこれもよく分かった。
この「＝」は、オブジェクトとして考えられた物、って意味のイコールってことで。

昔、立ち読みした本にクラスもインスタンスもオブジェクトって書いてあった
だからおまえら全員間違い

>>276
そんなことおれに言われても…

このスレがあるようじゃ、別スレにあるようにオブジェクト設計が流行らないわけだわ。

>>275>>277
それだと、オブジェクトでないものには何があるの？

>>257
前者は正確にはstaticオブジェクトのことを指す

>>261
内部クラスは特有じゃない

>>268
JavaScript2.0が出たら勉強してみることにするよw
ハッキング言語は扱いが面倒だし。

>>278
いや、これなら正解。

インスタンス　⊆　オブジェクト

>>281
実際にはそんなものは存在しない。
オブジェクトとは、森羅万象を構成する物だから

プリミティブ型とかグローバル関数/変数という例外的な物が
言語によっては存在する。

>>285
この意地っ張りがｗ

>>281
オブジェクトの対義語ねぇ・・
インターフェースも指定しないモジュールをそのまま使う。

>>286
もし集合論とかやってれば分かると思うけど、真に全てを表すようなものに名前付けても無意味。

実際、すくなくとも、
クラス⊆オブジェクト
インスタンス⊆オブジェクト
なのであれば、実用上オブジェクトという言葉を使う場面はありえないと思う。

オブジェクト指向でない言語との対比として意味があるのだろう。
その言語で閉じた議論をするときは全てがオブジェクトと言ってしまっても構わない場合があるだろう。

モダン言語の最基底クラスがObjectであるってのがすべてさ。

オブジェクト指向とかかっこつけるからややこしいんだ
そもそもCとかでもオブジェクト指向っぽくコーディングはできるわけで
俗にいうオブジェクト指向言語は仕様を工夫して整理しやすくしただけだろ？

だから超整理法言語だ

>>288
> >>286

> クラス⊆オブジェクト
それは誤解を生む。現実世界では妥当だが。

>>291
どこがかっこつけだ。Cでオブジェクト指向だなんて非常に効率が悪い。

>>293
具体例を・・・

メッセージに応答できるもの（メソッドコール可能なもの）がオブジェクト。

インスタンスはクラスを実体化したもの。
クラスはインスタンスを作る鋳型。

言語によってはクラスもオブジェクトだがクラスがオブジェクトでない
言語もある。

　　こ　　の　　ス　　レ　　　レ　　ベ　　ル　　低　　す　　ぎ　　ｗ　　ｗ　　ｗ

クラスがオブジェクト・・・
という表現は混乱を招くから、そこはメタクラスといって区別しなさい

>>294
オブジェクト指向チックにする実装をしなければならん事が
だ
オブジェクト指向言語はソコを考える必要は無いからなぁ当然

>>294
とりあえず簡単に言うと
C言語だけでオブジェクト指向を実戦するには
いちいちコーディング規約を手動で守らせないと逝けないと言う
欠点があるだおる

>>296
じゃ、スレのレベル上げろ

>>295
ケイのオブジェクト指向に乗っかるならそうだが、オブジェクト指向はそれだけではない。
ストラウストラップやメイヤーのオブジェクト指向ではメッセージは関係ない邪魔なモノ。

結論: Objectという言葉は害悪。素直にInstanceやClassなどの代替表現を使っとけ。

#オブジェクトは概念だっての。
#言語としてオブジェクトそのものを実装してある言語なんてJavascript(ECMAScript 3)ぐらいしか知らね。
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/

>>302
どうしてそういう嘘を平気で書くのか？

「クラス」と「オブジェクト」は れっきとした言語機能だ。
これらは、コード　and/or　実行時のメモリ　に存在する。
インスタンスこそ（ある「オブジェクト」の位置づけをどう説明するかという）概念だろ。

「細胞」という「オブジェクト」があるとする

「DNA」がクラス

「たんぱく質」がインスタンス

このスレの議論の一つとして、メモリの上にオブジェクトは乗るのか？
それとも乗らないのか？って事についての統一的見解を出す方が良いと思うのだが。

メモリ上のオブジェクトは、ある意味「走っているオブジェクト」なんだから
インスタンスと呼ぶべきでしょ。

Object *object = new Object();

object->run();

>>305
なんじゃその「走っている」っつうのは…？

メモリ上にあろうが、あんたの頭んなかにあろうが、
走っていようが、止まっていようが、あるオブジェクトが、
何らかのクラスに属しているなら「インスタンス」だ。

それ以外のオブジェクトは（言語によってはそんなものは存在し得ないが）ただのオブジェクトだ。

オブジェクトがクラスに属するというのはどういうことですか？

>>308
人が乗っている車を「人が乗っている車」と呼んでみてはいかがでしょうか？
ということです。

もちろん人が乗っていても、乗っていなくても車は車です。
ただこのスレにおいては、人が乗っている(状態が付随する)車と人が乗っていない(状態が付随しない)車を
区別しないことからの混乱が生じているように思えるのです。
ですからあえてその辺りを明確にするべきではないでしょうか？という提案です。

クラスで「あらかじめ決めておいたこと」に従うかどうか、ということ。

ちなみに、ここでいう「あらかじめ決めておいたこと」とは、

ケイのオブジェクト指向なら「メッセージに対する振る舞い」だし、
ストラウストラップのオブジェクト指向なら「メンバ関数のコールの可不可や、
メンバ変数を持つかどうかや、それらに対するアクセスの可不可」。
どちらでもお好きな方で。

クラスベースの言語（普通のオブジェクト指向言語。Javaとか）ではオブジェクトはすべて、
なんらかのクラスのインスタンス。
JavaならgetClass()をコールすることで、そのオブジェクトが属するクラスを知ることができる。

そうでない言語（JavaScriptとか）にはクラスに属さないオブジェクト、つまり、インスタンスでない
オブジェクトも存在し得る。それだけの話。

オブジェクト＝バズワード説

インスタンス、クラスという言葉について誰も意見が相違していないのに対して、
オブジェクトという言葉について、どの２人の間でも意見が一致していないｗ

バズワードというのもあるけれど（たとえば「オブジェクトは“モノ”だ！」とかは典型例）、
歴史的にも、いろんな意味で使われてきているんだよ。まぎらわしいところでは、
Ｃ言語の設計者たちが使っている「第一級オブジェクト」ってのがある。これは
オブジェクト指向の「オブジェクト」とは（ほぼ）直交する概念。

言語にとらわれるから食い違いが起きる
プログラムと図で示せ

だから概念の問題だっての

>>314
いつ言葉の空間に計量を入れたのかと問いたい

>>305
すでに乗っている。
Javaではヒープメモリ上にオブジェクトが乗っている。
しかし、よく見ると、間接的にスタック領域を参照しているため
いくつものヒープといくつものスタック領域の組み合わせがオブジェクトとなる。

複雑なオブジェクト、たとえば集約関係(Aggregation)にあるオブジェクトほど、
たくさんのヒープを持つ。継承関係にあるクラスで下層の具象クラスはヒープの数も膨大。

>>312
しかしJavaScriptのようなプロトタイプベースオブジェクト指向言語は
UML(統一モデリング言語)とは合致しない。

>>313
UMLで統一されているのでバズワードにはならんよ。

>>315
言語に捕らわれてもJavaのような言語の捕らわれているなら
仕様や用語・用法がUMLと合致しているので食い違いは起きない。

>>319
だから無視しろと？　いつからUMLはそんなに偉くなったんだ？ｗ

UMLってインターフェース設計ぐらいにしか使えないと思ってたが。

>>310
いい提案ですなｗ
っていうか、ハルカ前からイッ取るんだけどなｗ

言語実装がどうとか逝ってる内は永遠に答えが出ないよ
なぜなら言語実装とは、オブジェクト指向を表現しようとした
結果だからねー
解釈は言語ごとに異なるし、言語からオブジェクト指向は紐とけん

言語実装を考えないオブジェクト指向ってなんなのさ？

オブジェクト指向があるからオブジェクト指向言語が生まれたわけだろ？
例えばJavaからオブジェクト指向が生まれたわけではない

言語実装を考えなければ全てのものがクラスになったりオブジェクトになったりインスタンスになったりする
そういう発想が出来なければオブジェクト指向は理解できないと思うなー

最近鼻炎に悩んでいます。
で、鼻炎をクラスにしてみました。
鼻炎の実態は鼻炎オブジェクト
いまオレの鼻を患わせているのは鼻炎インスタンス

晩御飯食べてお腹いっぱいクラス
「晩御飯食べてお腹いっぱいになった」の実態は、晩御飯食べてお腹いっぱいオブジェクト
オレのお腹の状態を持っているのは、晩御飯食べてお腹いっぱいインスタンス

状態を持ってるんじゃなくて、お腹の状態のバリエーションの1つか

んじゃコンピューター言語を考慮しない抽象論で

クラス…何かを生み出そうとするときに参考にする事象、設計図、鋳型
オブジェクト…クラスを元にして生み出された物、実体、存在

インスタンス化…事象から物を生み出す行為

インスタンス

y=2x

クラス:y
オブジェクト:2x


y = 2x_{x=2} = 4
y = 2x_{x=3} = 6

クラス:y
オブジェクト:2x_{x=2},2x_{x=3},4,6
インスタンス:4,6

事象はオブジェクトかなぁ
その事象が目の前で起こってる場合はインスタンスかなぁ

>>331
？

>>332
クラスからあるオブジェクトを生み出したとする。
もし、その生み出されたオブジェクトを参考にして、（設計図として、鋳型として）
あらたな物を生み出したとすると、そのオブジェクトはクラスの「役割」を果たしたとする。

つまり、結果論としてそのオブジェクトはクラスの「役割」を果たしたと言えるだろう。

何が言いたいかというと、オブジェクトやクラスやインスタンスは、その存在そのものを
定義するのではなくて、「その物、事象がどのような役割をはたしたか？」という役割の観測
でもって判断されるべきである。

人は貧乏ゆすりをする事があります。
この事象から、貧乏ゆすりクラスを導出しました。
で、今それをインスタンス化して貧乏ゆすりしています。

>>167
＝の使い方まちがってるぞ。
そこはクラスはオブジェクトを含んでいる程度じゃね？


>>168
学級というクラスの
3年B組というインスタンスじゃないか？

>>334
全くその通り
観測者の視点によって、クラスにもオブジェクトにもなる
が、インスタンスの観測点はクラスやオブジェクトより限定的だとおもうね

逆だったｗ
そこはオブジェクトはクラスを含んでいる程度じゃね？

だが、インスタンスがクラスやオブジェクトになる事をひていしてるわけじゃないよ

っていうより、ある視点から見た場合に、クラス、オブジェクト、インスタンスが限定されるってことかな

なんて馬鹿な話だ。
〜インスタンス.clone()メソッドでインスタンスのコピーが出来たら、
〜インスタンスがクラスになるとか言ってるの？

>>326
どうしてそういう見てきたような嘘を…。「オブジェクト指向」と名の付く概念の考案者である
ケイもストラウストラップもSmalltalkやC++の構築を通じて彼らの「オブジェクト指向」を培った。

かといって、SmalltalkやC++が彼らが行き着いた「オブジェクト指向」を完全にサポート
できているわけではないので（特に理想が高い前者は）、これら言語の実装や仕様から
彼らの目指したところを知ろうとするのは危険…だから同じ趣旨の最後の一言だけは正しい。

やはり提唱者が著わしたものを読み解くところから始めるのがスジだろうと思うがなぁ…。

そういう次元の話はしてないよ

>>342
ではそのSmallTalkやC++は何をベースに作ったの？

ただし、それらの言語を通じてより洗練させたって言う事に異論は無いよ

>>343のレスは>>341へのもの

ずばり大多数はよく分かってないって事だな。

それは正しい

>つまり、結果論としてそのオブジェクトはクラスの「役割」を果たしたと言えるだろう。
〜.clone()とどう違うのｗ

>>349
というより、そのclone()メソッドを持った物の視点でクラスやらオブジェクトやらインスタンスが
既に決まってるから、オブジェクト.clone()のリターンがクラスって事にはならない。

>>344
SIMULAという言語の「オブジェクト」と「クラス」を借りて、自分たちのアイデアを実現した。
考え方自体は、それぞれのオリジナル。つまり「クラス」や「オブジェクト」はオブジェクト指向より
前から存在していた。

ちんこの名前はちんこであるように
オブジェクト指向の名前はオブジェクト指向である
ちんこに深い意味がないのと同様に
オブジェクト指向にも深い意味はない

た　だ　の　ル　ー　ル

スレ読んでないけど、オブジェクト指向とか関係なく広い意味でメモリ上のデータの一区分を
オブジェクトって言うんじゃないの？
そういう意味ではC++だろうがなんだろうが、クラスもインスタンスもオブジェクトと呼べるし。

>>351
既存の言語使用がよりしろになってる事は違和感は無いけど
でも今までと違う発想がないとオブジェクト指向は思いつかないと思う。
現にC言語やCOBOLからC++やJavaに乗り換える時は、全く違う世界観を
受け入れなければならない事を強制されるからねぇ

×強制
○強要

プログラムするときにほとんどの言語でポインタを意識しなくてよくなったように
オブジェクトかインスタンスかを意識する必要はないんだよ

豆知識みたいなもんだろ、実務的に考えると

>>356
そうだけど、どうせならインスタンスに統一して欲しいなｗ

バカが暗黙のルール破ってバカなことしないために
制約をつけただけ
よって、世界観が変わるとかいってるやつはバカ

>>358
それは言語仕様の話だな

>>341
コピーしてもインスタンスにしかならんな

言語仕様の一つがオブジェクト指向だろ？

clone()といえば、ディープコピーとシャローコピーがある。
後者だと完全なコピーじゃないし、参照元の一部をコピーしただけだし

>>361
ﾌﾞﾌﾞ─────

>>353
そうすると、深いクローニングと浅いクローニングのことを考慮するときに問題が生ずる

>>362
だからそういう話じゃないって

>>353
プログラミング言語の垣根を無くして話すと、
ある意味「メモリ」そのものもオブジェクトだし、「データ」もオブジェクトだよね。

このスレでは、メモリの上にデータが乗っている状態をインスタンスとしようという
風潮が随所に見られるんだけど、それはそれであり。


「人が乗っている車」をインスタンスとしても、
「人」も「車」も、あるいは「人が乗ってる車」だってオブジェクトだし。
ただ、「乗っている」という付随状態が存在しているとみなして、
「人が乗っている車」をインスタンスと呼ぶと。


「人」を「データ」、「車」を「メモリ」にそのまま挿げ替えても通用する。
ある意味、上の文字の挿げ替えで意味が通用するモノなら、それは間違いでは無いでしょ。
「俺」と「チンコ」もちょっとした文章の体裁の修正で流用可能。


オブジェクト指向プログラミングのすごいところは、上の「ちょっとした文章の体裁の修正」が
不要なところがすごい。超すごい。かなり手間が省ける。
オブジェクト指向以外の言語の不都合さを理解してないと、この感動は味わえない。

>>354
それも、今なら、もう安心！

オブジェクト指向技術はUMLですべて統一されました！

>>54
率直に言って、>>29を含めるのは間違ってる。アンカーの仕方を勉強しろ。

>>363
じゃあ言語使用じゃないオブジェクト指向を教えてください

〜俺がチンコでチンコが俺で〜

作詞・作曲：ム板の2chネラー

>>368
ソコが気になったか─────ｗｗｗ

>>354
いや。だから、既存（SIMULA）の言語機能であった「オブジェクト」と「クラス」を使って、
彼らの「今までと違う発想」である「オブジェクト指向」を具現化してみせたのが
ケイ（Smalltalk）とストラウストラップ（C++）なんだってば。ｗ

>>369
っていうか
オブジェクト指向はどの角度から見ても言語仕様ではありません。
オブジェクト指向はプログラム設計をする際の考え方です。

>>372
それは百も承知だけど
そう言う事がいいたいわけではない

>>373
いや。それはケイやストラウストラップの「オブジェクト指向（プログラミング）」に
ヒントを得て、ブーチとかがこしらえた「オブジェクト指向設計」のことだから。ｗ
ちなみに、乱立したそうした考え方を統合してややこしくしたのがＵＭＬのベースになっている。

ちなみに私は設計する際に特定の言語使用を前提に設計はしていません。
実装言語がJavaだろうがC++だろうがなんだろうが、あるレベルまでは何の問題もありません。

そういえばRubyってさ、確か出来上がったオブジェクトに対して
さらにメソッドみたいなのを追加できなかったっけ
こういうのって今までのオブジェクト指向の用語で表せんの？

>>374
ん？　「クラス」と「オブジェクト」、それとインスタンスの関係を話しているんじゃないのか？

>>376が言ってるのはシステム設計におけるモジュール化っぽいことを
言っているような気がする
>>376的にはオブジェクト指向＝モジュール化なのか？

>>375
わかったわかった
結局はオブジェクト指向XXXXXXのXXXXXXの部分がないと
オブジェクト指向が表現できないといいたいんだろ？

いまだに>>367みたいな奴がいるとは残念。
デザパタ使わないとダメみたいな風潮も変だと気付かないと。

特定の言語を意識した設計なんてしたことないな
オブジェクト志向世代だからかもしれない

いや、Cのときだけ設計方針は変わるよ。

>>377
インスタンス化したあとクラスにメソッドを追加できる（ひいては、インスタンスから
それら追加したメソッドをコールできる）のは「クラスがオープンである」という。
インスタンスごとに追加するのは、そのまんま「インスタンス特異的なメソッド追加」。

>>379
クラスをモジュールとすればそうなる

だが役割の細分化といったほうがあってるかな

もうK&RのCでいいよ。
構造体もコピーできない奴で！

>>378
その関係を実社会からどうやって導き出すか？
ってところか？

オブジェクト指向プログラミングのすばらしさの例

講義の単位がレポートの提出でもらえる状況であったとしよう。
そのレポート、どのように作成するか？
賢明な学生ならお気付きだろうが、手っ取り早いのはグーグル先生に頼ることだ。

ただ、ちょっとした手間があることにお気付きだろうか？
それはコピペの文章をレポートにあう形に修正しなければならないことだ。

ここで、もしレポートをオブジェクト指向で処理するとどうなるか。

なんと、Web上の情報をそのままレポートにペタペタ張り付ければ、
それがすばらしいレポートになってしまっているのだ！！



ああすばらしいオブジェクト指向プログラミング

>>384
おお、なるほど
クラスがオープンってのはいわばメタクラスってことかな
ObjectiveCにも確かそんなのがあったような
インスタンス特異的なメソッド追加は、個人的には反則に思うｗ
それにしてもこのスレ伸びすぎ

車というと概念と実体の両方ある。

概念のほうはクラス。Staticメソッドを考えると設計図じゃない。
実体はインスタンス。
最初に出てきた車はオブジェクト。

モノじゃないものをモノで表現するのが難しいことに気づけ

>>389
だが、先生は大抵基底クラスの存在をWEBからみつける

>>391
この段階からStaticメソッドを考慮する理由はなんぞ？

>>390
メタクラスは、クラスのクラスだからオブジェクトとしてのクラスがコールできるメソッドを
定義する場所なのでちょっと違う。スレの流れ的には、このときクラスはメタクラスの
「インスタンス」であると言える。

インスタンス特異的メソッドは、指摘の通り、クラスベースの考え方には合わない。
プロトタイプベースの言語（JavaScript）とかLISP由来の考え方。

クラスに演算子を含んでる言語もあるよ。

ほいで？

>>385
ちょｗ
クラスとか言ってる時点で言語限定してんじゃねーかｗ

JAVAは全部クラスだけど、C++はクラスも使えて手続き型も使えるって事は、
とりあえずオブジェクト指向的手法でコピペレポート作っておいて、
その後手続き型的手法で微調整できるって、最強なんじゃね？

とC++を勉強してない俺は思う。

>>398
そういう意味じゃオブジェクト指向プログラミング言語であることは限定するｗ

モジュールって何？

どうしておまいらはこういうくだらない言葉遊びにはこんなに張り切るのか・・・。

>>401
テレビ分解して中身みてみたらわかる。

っか断言しとくけど、

ここのスレの大半の人

間 違 っ て ま す

入門書からオブジェクトとインスタンスの違いとかいうくだらない記述を削除すれば
万事丸く収まる気がする

>>404
間違ってるところを指摘しないで否定だけするのは間違ってると思います

>>403
絶対わからないと思います（＞＜）

モジュールは作業単位か動作単位に分解されたもの。

オブジェクト指向はテクニック
オブジェクトは概念
クラスとインスタンスはツール

ただそれだけのこと

あほな書き込みしてないでソース書け！
ちなみに俺はテストの終了街…

それよりさ、Mixinのほうがわけわからんのだが。
D言語のMixinとRubyのModuleが同じMixinとは到底思えないんだが。
インスタンスとオブジェクトでこれだけ知識を披露してくれるおまいらなら
きっと上手く説明してくれるよな？

>>408
なるほど

ところで・・・








>>1 よ、大漁だな。

ttp://www.kmonos.net/alang/d/mixin.html
>Mixin は、言語によって様々な意味を持っています。 D では、

つまり名前が同じで別物。

手続き型言語はモジュール化しても、例えばオーバーロード的な修正に手間取りそうな

>>415
オーバーロードが出来る手続き型の言語があっても
全然おかしくないと思うが？
っていうか、Java や C++ は手続き型の言語だし・・・

>>381
UMLを見捨てたら顧客の同意を得られないだろ

それになんでUMLにデザインパターンが必要なのか。
そもそも、ユースケース図やアクティビティ図にデザインパターンなんていらんだろ

>>399
それは大きな勘違い。
アルファベットの多い中国語のほうがアルファベットが少ない英語より
使いやすいと虚言をいってるようなもの

>>416
コボラーが使えばなんだって手続きかが言語になってしまう奇跡

>>406
否定しまくって疲れましたがなにか。

>>407
そうですかｗ
なんていうか、モジュールはテレビがテレビとして動くようになる
ための「しくみ」 ネジやら配線やらブラウン管でテレビは構成されてますが
プログラミングの場合だと画像を操作したりいろんな番組を表示させるような
プログラムを組んでテレビらしい形にするためのスクリプトそのもののことを
モジュールっていう。

>>408
カプセル化でよろしくないか。

>>416
どう言うのかな。
オブジェクト指向じゃない言語っていうのか、
システムをある程度理解してないと扱いきれない言語というのかな。

>>420
イメージわきました
どもですm(..)m

つまりモジュールを例えばネジにしぼって考えると、
モジュール化はネジの鋳型を作る事に相当するんですね。

一度作ってしまえばその鋳型を利用して効率良く作業ができると。
ただ、手続き型言語はその鋳型にちょっとした変更が生じたときに、
その大きなネジの鋳型機械そのものを改造する必要があるが、
オブジェクト指向だと、その鋳型の形の部分のみをちょちょっと変更することが容易にできると。

>>423
いろいろ破綻しているところがあるぞ。

例えばその伝でいくと、ネジそのものは何に当たるんだ？
オブジェクト？ んなバカな！

大体、鋳型機械って何よ？
それと、鋳型の形を変更するんじゃあ、
そもそも鋳型の意味がないだろうに。

違うだろ！騙すんじゃねーよ。
モジュールはテレビで言えばブラウン管やスピーカ、チューナーといった
動作単位の部品だよ。

>>423
ちょっとおしいｗ

モジュール化っていうのは別名 カプセル化 いわれてて

BASICのような複雑なスクリプトの中から 共通な点(同じ仕組みのスクリ) を見つけ出して
オブジェクトとして使えるようにすること。

>>425
まて！おちつけ！
テレビという物体そのもののこと言ってるから そんな細かいとこつっこまなくてもいいｗｗｗｗｗｗ

モジュールとは、Singleton のオブジェクト。

>>420はしったか初心者。

>>426
モジュール化とカプセル化 は全く別物。
ググレ。

>>429
初心者は走ってません。

>>430
わりぃ、データとスクリプト混合しちまった

>>430
>モジュール化とカプセル化 は全く別物。 
>ググレ。 
ググったけど、違いが分からんｗｗｗ

http://ja.wikipedia.org/wiki/%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB
>モジュールの特徴として「モジュール性」とカプセル化があり、それらによって複雑なプログラムを理解しやすくできる。

えっと。

カプセル化 が データとか 値をひとまとめにしたもので

モジュール化 が スクリプトの共通な部分をこう、抽象化。（ 抽象って便利な言葉だがわかりずらい。

http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

カプセル化はは手続きの隠蔽
モジュール化は機能分割

>>434
>モジュール化 が スクリプトの共通な部分をこう、抽象化

ハァ？
どうしてそこで「スクリプト」なんて言葉が出てくるんだ？

このスレ見てて複数の言語を勉強しておくべきだなって思った。

モジュール化とカプセル化を一緒にしてるともぐりのプログラマあつかいされるよ！

スクリプトをソースと解釈すれば、ほらすっきり

>>436
>手続きの隠蔽

「手続きの隠蔽」なんてされたら、手続きが使えないがなw

>>437
おまいはリファレンスに定義されてる言葉でしか説明できないと思ってるのか。

>>441
あほー
手続きの詳細はわからんけど、インターフェイスは知っている状態のことを隠蔽するというんだよ

JAVAでモジュールってあんまり聞かないってか、中間コードが生成されるだけで
モジュールっていうべき物はあるの？と思ったり、Cはカプセル化なんて概念そのものが
なさそうに見えたり。

>>444
C言語だってあるよｗ
でかい関数の処理の部分を別の関数に切り出したりすれば、切り出された部分の処理は元の関数からは
隠蔽されている事になる。
ただ、単純に切り出しただけだったらカプセル化とは言わないけどね

モジュールとはa.out

hoge.jar
hoge.exe
hoge.dll
hoge.lib
　　・
　　・
　　・

hogeって名前好きだよなｗ

−−−−−−−−−−−−−−−−−−−−−−−−−−
俺様用しおり
　 ∧＿∧
　（　・∀・）＜　今日はここまで読んだ
−−−−−−−−−−−−−−−−−−−−−−−−−−

お？
　　 ∩＿＿＿∩　　
　　 | ノ　　　　　 ヽ　
　　/　-=・=- -=・=|　

>>450
ぉ？

クラスとインスタンスの次はモジュールとカプセルかよｗｗｗｗ
おまえらおもしれーなｗｗｗｗ

俺は>>1が策士だとおもうｗｗｗｗ
わざとまちがえやがってどこまでツンデレなのｗｗ

>>452
俺定義だいっきらーいｗ＼(＾o＾)／
感覚で覚えるのが一番かと。

とりあえずおまいら。俺に

・インスタンス　 　→
・クラス　　　　　→
・オブジェクト　　→
・インターフェース→
・モジュール化　　→
・カプセル化　　　→

がなんだか教えてくれないか。

・インスタンス　 　→　hoge
・クラス　　　　　→ hoge
・オブジェクト　　→ hoge
・インターフェース→ hoge
・モジュール化　　→ hoge
・カプセル化　　　→ hoge

x=2なんじゃなくてy=xに2を代入したものなんだからね！

>>377
できますよ。

Rubyの場合はあるクラスCから新たにインスタンスiを作ると、
内部的にはCを派生したC'というクラスを作ってそのインスタンスを作ることになってます。

iにメソッドを追加(このメソッドを「特異メソッド」と言います)するというのは、
このC'というクラスにメソッドを追加することになります。

>>445
そうじゃないだろ。カプセル化したい部分を全部切り出して、
別のファイルに乗っけて内部的な処理や変数は全部staticにしておく。
で、少数のインタフェイス関数だけをextern関数にする。

これがカプセル化だろう。これだとインスタンスは一つしか持てないけどw

次回予告
　・関数型言語を極めし者表わる
　・真・Lisp括弧地獄
　・スクリプト言語の逆襲

の三本です
お楽しみにね

そもそも、UMLにはモジュールという用語は存在しないわけだが。
コンポーネントというべきだろう。
そうでなければ、クラスやパッケージという用語を使うべき。
UMLではそう規定している。

>>444
Javaにはモジュールという用語はない。
かわりにpackageという用語が使われる。

>>446
それはＵＭＬではモジュールともいわないし、パッケージともいわない、

コンポーネントと呼ぶ。

Javaもパッケージってあるよね

Windows系のでデカいユーティリティー入れたらコンポーネントのエラーが出て萎えて捨てた

>>458
Cのよくあるテクニックとして、ヘッダファイルに構造体の名前だけ宣言して
構造体の中身を本体ファイルの中に隠蔽して外部とのやりとりをポインタだけで
済ますようにすれば、マルチプルインスタンスな抽象データ型が表現出来るよ。

代数方程式をオブジェクト指向を使って解くにはどのようにすればよろしいでしょうか？

>>465
>ヘッダファイルに構造体の名前だけ宣言して構造体の中身を本体ファイルの中に

kwsk

>>467
不完全型で検索汁

えっ？

>>454
・クラス　　　　　→インスタンスを作るための雛型オブジェクト
・インスタンス　 　→クラスによって作るオブジェクト
・オブジェクト　　→操作できる物
・インターフェース→クラスやインスタンスの仕様
・モジュール化　　→複数のファイルや名前空間に分ける
・カプセル化　　　→内部関数を外から見えなくする

仕様って言葉は胡散臭くて嫌だ

ストラウストラップのオブジェクト指向（現在主流のオブジェクト指向。クラス指向）
・インスタンス　　→ ユーザー定義型に帰属するデータ。一般に「オブジェクト」のこと。
・クラス　　　　　→ ユーザー定義型の仕様と実装を定義するための言語機能。
・オブジェクト　　→ ユーザー定義型に帰属するデータ。
・インターフェース→ ユーザー定義型の仕様を定義するための言語機能。
・モジュール化　　→ ユーザー定義型の定義などを分割して扱いやすくすること。
・カプセル化　　　→ ユーザー定義型を定義すること。抽象データ型と（ほぼ）同義。

ケイのオブジェクト指向（原典だが今や影の薄い〜時に混乱の元になる〜オブジェクト指向。メッセージ指向）
・インスタンス　　→ クラス（メタ…を含む）に帰属することを強調したいときのオブジェクトの呼び名。
・クラス　　　　　→ 同じ振る舞いをするオブジェクト群を束ね、それらの振る舞いを定めるオブジェクト。
・オブジェクト　　→ メッセージの受け手。
・インターフェース→ 関係なし（しいて言えば、受けることができるメッセージの種類）。
・モジュール化　　→ 関係なし（しいて言えば、オブジェクトによる疎結合設計）。
・カプセル化　　　→ 関係なし（しいて言えば、状態や処理の保持・保護・隠蔽）。

↓ここでCLOS使いが颯爽と登場

CLOSのオブジェクト指向（他の斜め上をゆくちょっと変わったオブジェクト指向）
・インスタンス　　→　クラスにより定義されたユーザー定義型に帰属するデータ。
・クラス　　　　　→　この型に帰属するインスタンスが持つべき属性の種類を定める第一級オブジェクト。
・オブジェクト　　→　クラスから生じたインスタンス…だが、LISPではオブジェクト指向を離れて
　　　　　　　　　　　第一級オブジェクトのことを指す言葉として使う方が普通。
・インターフェース→　関係なし（しいて言えば、そのオブジェクトを引数に含む関数の種類）。
・モジュール化　　→　関係なし（しいて言えば、LISPでのパッケージ化と等価）。
・カプセル化　　　→　関係なし（しいて言えば、ユーザー定義型の定義）。

第一級オブジェクトとは、簡単には、関数の引数や戻り値にできるデータのこと。

>>466
まずはアルゴリズム本を読み行列クラスを作るか拾ってこい。
話はそれからだ。

>>467
多分、こういうコードのことだろ。ネットで公開されてるプログラムの
ソースコードを読んでると時々見かけるテクニックだ。
http://www.s34.co.jp/cpptechdoc/article/oop_in_c/index.html

インスタン

はぁはぁ

>>458
カプセル化の説明で「カプセル化」ｗ
っていうか、何でおマンはオレの言いたい事が理解できんのじゃ

クラス、インスタンス、オブジェクト。
何冊かの本を、何度かそのあたりの部分を繰返し読んでいるうちに
あっ、という感じで理解するときがきます。
載っているサンプルを何度か実際に打ち込んで実行するのも効果があります。
C言語のポインタ、C++の参照（Javaにもあるね）などと同じように、
「習うより慣れろ」の典型的なパターンです。

>>476
これができるのであればC++いらないような気がするんですが

馬鹿にクラス触らせるとオブジェクトがオブジェクトとして機能してないからな
馬鹿でかいツリーを作ってNULLじゃなければ実行、deleteみたいなこと連発してくれる。

フレームワークってあるじゃないですか、フレームワーク。
思うんですけど、Cで作らせるのが一番のフレームワークだと思うんです。

その心は？

余計な設計をさせないで済む

どんなところが？

メンバをワーク領域と思ってる奴を排除できる
手続き型だから糞いモジュール分割に巻き込まれにくい（＝リファクタリングしやすい）
開いて使って閉じるの流れを統一させやすい

これはなにを言っているのかさっぱりわからない
キミのかいだ仕様書とか読んでみたくてドキドキしてきた

>>486
要するに１つの関数にどかっと全部書いちゃうのがいいと・・・・；

なんでそうなる、真逆だろ

動的配置されたオブジェクトが飛び交うことが少なくなるだけでも
オブジェクト指向を禁止する価値がある。
名指ししてpublic staticメソッド以外禁止ってのでもいいな。

>>490
怖がりすぎ。

だからこそオブジェクト指向フレームワークが必要なのだよ
インターフェイスを実装してくれりゃいいだけの物にしときゃいいのじゃ

Javaだと馬鹿避けに既存のコンポーネントを見繕うことも簡単だが
C++だと途端に難解になるな、車輪の再発明が何回行われてるのか

Javaだって同じ
ようは使い手の問題

つーかもっとわかりやすく
まんことかでたとえてくんね？

それがむりならおまえらもう哲学板でやれよ

・インスタンス　 　→ オナホール
・クラス　　　　　→ 南極二号
・オブジェクト　　→ まんこ
・インターフェース→ コンドーム
・モジュール化　　→ あべさだ
・カプセル化　　　→ 包茎

　　こ　　の　　ス　　レ　　　レ　　ベ　　ル　　低　　す　　ぎ　　ｗ　　ｗ　　ｗ

個人レベルのリファクタリングならJUnit使ってTDMをやれば良い。

・インスタンス　 　→俺様のチンコ
・クラス　　　　　　→チンコっつー概念
・オブジェクト　　 →チンコ全般
・インターフェース→チンコとマンコの合体方法
・モジュール化 　 →ソープ行くか〜
・カプセル化　　　→○○円ぽっきり

たまにはプロトタイプの事も思い出してください

プロトタイプベースのオブジェクト指向っていうのは、ケイ（メッセージング）と
ストラウストラップ（抽象データ型のスーパーセット）だとどっちよりなのかな…
とたまに悩むんだけれども、どうにもはっきりしない。メッセージングをひたすら
強調するSELFやIoは別格として脇に追いやっておくとして、NewtonScriptや
JavaScriptなんかみていると、メッセージングっていう印象は薄い。というより皆無。
かといって「型」とかいうかっちりとしたものと相性がいいとはとうてい思えない。

そもそもSELFはケイのメッセージングパラダイムを突き詰めた結果、クラスも無用、
インスタンス変数とメソッドの区別もいらねー（スロットで統一）というシンプルさに
いきついたわけだけれども、その成果物である「フレームとスロット」による
オブジェクト表現（と、委譲ベース）という考え方だけあればよくて、メッセージングは
邪魔なモノ…として確立されたのが（今の）プロトタイプベースなのかしらん。

とか、500に言われてプロトタイプベースのことを思い出したのでつらつらと書いてみました。

>>501
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│
　　　 |:|: ..　　 :||　　　 .. |:|　　│
　　　　:|: ..　　 ||　　　 ..||　＜　>>501日本語でおｋ
　　　　 :＼　［_￣］　/::|　　　│
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿

>>502
>>501を日本語と思えないなら、PGやめた方がいいよ。マジで。
この程度の事を理解できないなんてエンジニアとしてレベルが低いにも程がある。

>>503
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│
　　　 |:|: ..　　 :||　　　 .. |:|　　│
　　　　:|: ..　　 ||　　　 ..||　＜　www
　　　　 :＼　［_￣］　/::|　　　│
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿

>>504
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│
　　　 |:|: ..　　 :||　　　 .. |:|　　│
　　　　:|: ..　　 ||　　　 ..||　＜　wwww
　　　　 :＼　［_￣］　/::|　　　│
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿

　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│
　　　 |:|: ..　　 :||　　　 .. |:|　　│
　　　　:|: ..　　 ||　　　 ..||　＜　メタクラスって知ってる？
　　　　 :＼　［_￣］　/::|　　　│
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿

>>502
ココ電さん、もうこの板にあなたの居場所は無いみたいですよ。。。

ClassのClassの親Class

>>504
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│
　　　 |:|: ..　　 :||　　　 .. |:|　　│
　　　　:|: ..　　 ||　　　 ..||　＜　メタタァなら…
　　　　 :＼　［_￣］　/::|　　　│
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿

ﾒﾒﾀｧじゃなくて?

>>501
まあ、要するに 「形而上」なんだろ。

>>511
オブジェクト指向のありようそのものというよりは
「どういう処理系が便利か？」ってところの工夫だと思う。
すなわち形而下。

>>512
http://pc10.2ch.net/test/read.cgi/prog/1167841734/472

>>513
ごめんいまいち言いたいことがわからなかった。。
でもまあどうでもいいや。

>>514
これ↓を言いたかっただけ。ま、あまり気にするなw
http://ja.wikipedia.org/wiki/%E4%B8%AD%E4%BA%8C%E7%97%85

>>515
あ、形而上ってのは煽りか。
わざわざすいませんね。

なんかどっかであったことあるようなヤツが紛れ込んだかな？
k.k

しーざーも>>515

まだ鉄にいるの？

ttp://blog9.fc2.com/2/2log/file/vlphp5172.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5173.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5174.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5175.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5176.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5177.jpg
ttp://blog9.fc2.com/2/2log/file/vlphp5178.jpg

急に静かになったな

試験にでも行ったか

>>517
k.kって？

>>520
一応ｵﾁがあってﾜﾛﾀ
個人的には最後人食い熊に食べられる瞬間の人間の画像が来ると思ってたんだけど・・・

つかもう疲れた

>>490
お前がマネージャだったらプロジェクト破綻するわい

>>502
ウルトラマンは、AAや絵にすると、なぜ間抜け面に見えるのだろう・・・

実写だと目がはっきり写っているからだな。。。恐らく。

>>526
昔、COBOLしかわからないからという理由でロボット制御を
COBOLで開発させたSEがいたんだが、それを思い出したよ。
おれは直接現場には関わらなかったけど、ひどいことになってた。

>>528
ＣＯＢＯＬでロボット制御をしようという発想がすごすぎるｗ
でも何とかすれば少しくらいはできるものなのかな？ｗ

>>520
最後のやつの後に居る奴がﾆﾀﾞｰに似ているのは気のせいか？

やはりﾁｮﾝという設定か？

オブジェクト、オブジェクト言ってるやつに限って仕事が遅いんだが。
かえって生産性低めてどーすんだよ。

正しく理解して使えば生産性が上がるのだが、凡人には無理なんだろうな。
このスレでこれだけ意味不明な議論してるのを見るとそう思う。

「オブジェクト指向で再利用性が高まる」とか言ってるやつに限って
 ライブラリによる再利用性とどう違うのかわかってないことが多いし。

>>501
あああ添削したい…

日本語勉強しようよ。

無用とか、、、

別にCOBOLで出来ない理由はないだろう
むしろ精度が必要とされる場面ではCOBOLの特徴が生かせるはずだ

簡単だよ、
名無しのごんべえさんが何か作業をする。
その作業がクラスの役割していたら、その人は「クラス君」、
オブジェクトの役割をしていたらその人は「オブジェクト君」と呼びましょうってだけ。

その人そのものに名前が付いてるんじゃなくて、その人がやった仕事を見て
その人の名前を決めましょうって事。

何も無い空間に、物体が生まれる。
その物体がインスタンスであり、オブジェクトである。
オブジェクトは必ずなにかの意味を持っている。
そしてオブジェクトが意義を果たし、その意義を失い消えるのを待つ。
次の瞬間インスタンスは消え、また何も無い空間に戻った。

オブジェクトと、インスタンスは同じものではないが、同居はありえる。
なぜなら、オブジェクトはインスタンスなくして実体化できないからだ。

ポインタ参照なんかで、このクラスのインスタンス空っぽだよっていったら何を指しているのかな？
ってことでしょ？

だからもっとわかりやすくちんことかまんこでたとえてくれよ

わかりやすいのと性的表現が一緒になってるのが違和感を感じるんだが。

そーだなー。
DNAってオブジェクトがあるわけだ、中には情報が入ってるが、実体を得ないと卵子と結合できない。
だから、精液というインスタンスを得て卵子にむかってくんだよ。
DNAは卵子と結合したあと、その卵子をどう扱うかはすでに知ってる。こういうのをメソッドっていう。
だから、プログラマの仕事はそのメソッドを構築してさらにまとめてオブジェクトを構築すること。

何書いてんだおれ。。。
しかも合ってるか自信ないし。むずかしい。。。

量子力学で説明すると、波動関数に演算子を作用させて固有値を得るってのがあるでしょ。
あれは波動関数に固有値が付随してるって考えるんじゃくて(そう考える人もいるけど)、波動関数に演算子を
作用させた結果その固有値が得られたって考えるわけですよ。つまり波動関数の正体については一概には言えないけど
、少なくともその演算子を作用させた結果ある固有値が得られるということはいえるじゃないですか。
つまりなんか詳しくはよくわからないけど、やってみたらこういう結果がでましたってのは
言えるわけですよ。つまりやってみたらオブジェクトでした。やってみたらクラスでした。みたいな。

ハードですな。

世の中ルールってあるでしょ。
それがオブジェクト。
実際に実行する人が、
インスタンス。

飛躍しすぎかな。。。

つまり三権分立ってやつだな！学校で習ったぜ！
あれ、でも執行権と適用権はわかったけど
立法の定立権はちんこまんこでいうとどのポジションなの？ヤオイ穴ぐらいの位置？
うは夢がひろがりんぐ

ぼーいずびーあんばらんすだよ

>>533
心配無用

で
ちんこは？

ちんこもまんこもインターフェース

という事は

　public class 男 extends 人間 implements ちんこ{
　
　}

　public class 女 extends 人間 implements まんこ{
　
　}

？

分かっていないようなので教えてあげよう。
インスタンスは実体
オブジェクトは概念

今過去レスを読んでみたが???
オブジェクト指向はみんなには難しいようだね。

安心しろ理解できてないのは君だけじゃない

で
まんこは？

オブジェクト指向はおまいらに必要ない！！！
そんなレベルの仕事こなしてるやつはここにはほとんどいない！

知識だけで鼻高くしてるやつらの集まりだなここは




次元が低い！！！！
根本から間違ってる！！！！
シロートが知ったかぶるな！！！！

それが２ｃｈクオリティ

今頃こっそりと来て次元が低いも何もないよw

クラス 餅のレシピ
インスタンス 餅
オブジェクト 「餅」という概念

オブジェクトはクラスとインスタンスにも共通しているから
この二つにとって抽象関係にある

つーかロバストネス分析、ロバストネス分析って
わかっていってんのかよハゲ

クラスをインスタンス化って言う言葉、違和感ないですか？
なんか定義が実体に化けるみたいで。
定義を元に実体を作るんだから
クラスからインスタンスを作成、みたいに表現するのが馴染みます。
まあ定着してるからインスタンス化でいいけど。

何言ってんだよオメー

クラスをインスタンス化
設計図を具現化

違和感無いかと

クラス≠設計図

どうやったら設計図という考えが？

クラス 餅の性質（ルール）について書いたもの。
付きたての餅は伸びる。ほっとくとカチカチになる。米で出来てる

インスタンス 餅
オブジェクト 「餅」という概念

ﾌﾞｯブー

クラス　餠の性質

インスタンス1　伸びる餠
インスタンス2　カチカチの餠
インスタンス3　米でできてる餠

オブジェクト　そんな餠


インスタンスとは餅オブジェクトのある状態、特徴に注目して
切り出したものではないだろうか。

『クラス』と『インスタンス』というモノ=オブジェクトがあって，
たとえば『人』がクラス(オブジェクト・クラス)，
『個々の人』がインスタンス(オブジェクト・インスタンス)

犬猫の話と何が違うの？

だからちんことまんこで（ｒｙ

『クラス』と『インスタンス』というモノ=オブジェクトがあって，
たとえば『犬』がクラス(オブジェクト・クラス)，
『個々の犬』がインスタンス(オブジェクト・インスタンス)


『クラス』と『インスタンス』というモノ=オブジェクトがあって，
たとえば『猫』がクラス(オブジェクト・クラス)，
『個々の猫』がインスタンス(オブジェクト・インスタンス)

↓ここの奴らにインスタントとインスタンスの違いを教えてやってくださいｗ
http://food8.2ch.net/test/read.cgi/nissin/1158545957/

抽象名詞がクラス、固有名詞がオブジャクト。
インスタンスは具体化かな

Boolというbool型をラップしたクラスがあってそれをインスタンス化したら
イスタンブール

『クラス』と『インスタンス』というモノ=オブジェクトがあって，
たとえば『哺乳類』がクラス(オブジェクト・クラス)，
それを継承した『人』,『犬』,『猫』もクラス(オブジェクト・クラス)，
『個々の人』,『個々の犬』,『個々の猫』がインスタンス(オブジェクト・インスタンス)

あと『個々の哺乳類』はおかしいので『哺乳類』を抽象クラスとする

クラスはクラスクラスをメモリ上に実体化したもの
インスタンスはクラスをメモリ上に実体化したもの

メモリ上に実体化する事をインスタンス化と呼ぶ

くらすくらす
ワロスワロスww

クラスが持つ属性に、具体的な値を入れたものがインスタンスだろ

現在のコンピュータ上では、
インスタンス(インスタンス変数とか)はヒープメモリ上に確保されて、
クラスは静的領域にロードされる。
メソッドは静的領域のを、各インスタンスが共有して使う。
スタックには、呼び出しとか、動的変数とかが記録される。
と思ってる。

クラスとの対比として「実体」を指す言葉がオブジェクト。
クラスの実現としての「実体」を指す言葉がインスタンス。

意味は違うが、結果的には両方とも「実体」を指す言葉だよ。

　　　　　　　　　 /　　/　 //　　　　　　　　　 ヽ
　　　 　　　　 ／ !/　/　/ ! ! |　ｌ　　 ! ｌ ヽ　 ヽ.!ヽ、
　　　　 　 　/:::::: |彡l　/ /| l　ｌ　ｌ、　 ! ｌ l l 　ヽ! ::::',
　　　　　　cｈ:::::: F l ! ! /‐トl､ ｌ　lヽ,.-ｌ‐トｌ ｌ ｌミ| :::ｎb
　　　　　　||Nヽ:: |l　!ｌlN,:==:Nヽヽヽ ≦kN! ! !ﾆl ジ/||
　　　　　　||| ` ‐f!!ヽヽｲ{:::::ﾘ`　 ヽｲ{:::::ﾘ〉lｲ ﾄ/＝'　||
　　　　　　　　　 N |ヽ　｀¨´ 　 　　　｀¨´ ﾘlｌ ﾘ　　　　　　　　　
　　 　 　 　　 　　.l ﾄ|　　 　　　、,. 　 　 　!_| |　　╋╋　　　　　　
　　　　 　 　 　 　 ! !ヽ　　　　 )-　　　　ノ　!lｌ　　 　┃　　　　　　
　　　　　　　　　　 ヽ 　＞-ｒ‐､　　 ,. イ　　 /.　┏┓　 　╋╋　　　　
　　　　　　　　　　　 　 ,.ｒﾆ!　　!¨´　|ﾆヽ.　　 　　 ┃ 　 　　┃　　　　
　　　　　　　　　　　／.:r'´ｌ　　l　　　ヽ::...＼　　　　　　　┏┓　　
　　　　　　　　 ,.．'´!:::::::!r'‐､,..l、　　 /::::::::/ヽ、　　　　　　 ┃　　
　　　　　 ,.．' ´　　 ｌ:::;.r'　　ﾉ} }_____/::::::::/　　 ｀ヽ、
　　　　 /　　　 　 　!ん､,.､/ { {　　/::::::::/　　 　　　 ヽ、
　　　　/　　| ! 　 　 Ｙ´二ヽ_|~　 /::::::::/　　　　　　 　 l
　　　 /　　 | ヽ 　　 {　--､`! 　 /::::::::/　　　　　　　　 |

>>576
ヒープ云々はクラスとインスタンスの違いに関して本質的には関係ない

C++厨にオブジェクト指向の理解は不可能

理解云々はともかくC++はCASEツールとの連携が難しすぐる…

クラス(オブジェクト・クラス) と インスタンス(オブジェクト・インスタンス)
はどちらもオブジェクト

データ抽象化についてですが

データ抽象化とは、要は「インタフェースでは見えないように実際のソースは隠蔽するということ」で、
その隠蔽するという作業がカプセル化と思えばいいのでしょうか？

データ抽象化、メンバ、カプセル化、隠蔽の関係を教えてください。

何で？ノートパッドでソースファイルを開いたらみんな見えちゃうじゃん。
見えない見えないとかって、本当はウソでしょ。

ノートパッドｽｹﾞｰ

　　　　社員
　　　　　△
　　┌─┼──┐
　　│　 │　　　│
　課長　係長　主任

ちんこインスタンスとマンコインスタンスを
フィールドに持つのがセックスオブジェクトだYO！

どうだ俎上に乗りに着たぞ

>>583
表現と実態の分離

>>583
「データ型」をからめて考えると整理をつけやすいかも。

「データ抽象化」というのは、扱いたいデータを新しい「型」として表現しようとする作業。
「メンバ」は、その「型」を成り立たせるために必要な内部情報や手続きなどの構成要素。
「カプセル化」は、データ抽象化の別の呼び名。ときとしてデータ抽象化＋隠蔽を意味することも。
「隠蔽」は、「型」のユーザーに対し、メンバ（や、ときとしてソース）へのアクセスを制限する行為やその結果。

データだけでなく操作も抽象化したい

リフレクションできる処理系だったら大抵操作も抽象化できるけど

操作の抽象化って、抽象メソッドを作ればいいんじゃないの？？

そういえば、デザインパターンって言葉最近聞かなくないか？
「そこはStrategyパターンで」とか言ってるやつ見かけなくなった気がする

そらそうだ。
相手の知らない（であろう）言葉を使うほど無神経な奴はそんなにいないよ。

一時期はデザパタデザパタで相当もてはやされてたと思うけどな
オブジェクト指向設計の精髄でありこれをカタログ化し名前をつけることで
コミュニケーションを円滑にするというふれこみだったんだから
古びることも使われなくなることも理論上はないはずなんだけどな

いかんせん、理解できる人が少なすぎたね。他人事じゃないけどｗ

うちの現場じゃ使ってるけど。

というか、オブジェクト指向自体が最近批判的に見直されている
現実世界のものをオブジェクトとして対応させる、というお題目は、
実際はプログラムが書くのはコンピュータの内部処理ばかりで
現実に対応するものはないからまるで役に立たないし、
共通の特徴があるものはベースクラスとしてそれを継承して派生させる、
なんてのは継承を使った瞬間そのクラスだけ見ても何をしてるのか分からず
プログラムの見通しが悪くなってバグの温床になるばかりだ

オブジェクト指向は一部の機能をうまく使えばうまく働くけど、
「オブジェクト指向」という思想に従ってお題目どおりに書いても何もうまくいかない

> 共通の特徴があるものはベースクラスとしてそれを継承して派生させる、
> なんてのは継承を使った瞬間そのクラスだけ見ても何をしてるのか分からず
> プログラムの見通しが悪くなってバグの温床になるばかりだ

実装を気にしなくていいようにするためのカプセル化では？
インターフェースに対してプログラミングをする、という言い方があるね。
つまり、親クラスの実装をそんなに頻繁に確かめるような設計は既に無理が在る。
内部は隠されたものとして使い、インターフェースを簡潔に作って利用する。

>>593
元々一部の人間が騒いでいただけ。冷ややかな目で見られていた事にやっと気付いたんじゃないの。

インターフェースと実装は別物だからな
親クラスから実装を継承して各子クラスの処理を書けば否応なく見通しは悪くなるが、
一つのクラスに親クラスの処理と全子クラスで使われる処理を書けば見通しはよくなる
あとはinterfaceだけ実装し、各子クラスはどの処理を使うかを選んで
委譲するだけのコードを書けばいい
外部から見たinterfaceの簡潔さと、内部の見通しの良さを両立できる

まあinterfaceはメソッドシグネチャを規定するだけだから
その用途なら関数オブジェクトとクロージャを使った方が簡潔に書ける
JavaやC++ではクロージャの導入が進んでいて
それが済んだらinterfaceは大部分の用途では用済みになる

>>601
で、要約すると何だって？

>>602
オブジェクト指向は死んだということだな
クロージャがあれば十分

>>601
>一つのクラスに親クラスの処理と全子クラスで使われる処理を書けば
そんなことしたら、そのクラスはどんどん肥大化していくだけで、
良い事ない。

それに、
一つのクラスに全部の実装が書かれてるより、ちゃんと役割ごとにクラス分けされて、
実装が分離されている方が、断然見通しはいいと思うけど？？

てか旧態依然としたエディタベースで開発していたらどうしたって見通し悪くなるよ。
Smalltalkみたいにオブジェクト階層を容易にたどっていけるブラウザの支援がないと。

いわゆる今時のエディタじゃないもので開発する場合に、追いにくいのは分かるよ。

でも、ちゃんと作ってれば（ドキュメント類とかも含めて）、そもそも追う必要がないわけだし。
追う必要がないなら、メソッドはあるべき場所にあればいいと思う。
それをあえて、一箇所にまとめるようなやり方は逆に見通しを悪くするんじゃないかなと。

>>606の名前間違った。604でしたｗ

もちろん階層を追いやすいIDEなりなんなりを使うことは前提だ
それでも、関連する処理が実際に一画面に収まっているかどうかは
見易さにものすごく影響するわけだ
たとえば
ttp://www.removingalldoubt.com/PermaLink.aspx/bece3be7-04a1-4130-b1ac-0b88c94e7708
これなんかを見て欲しいのだけど
これはC#の、一クラスを複数のソースファイルに分割して記述する機能を使って、
クラスごと、ではなく複数の子クラスの一つのメソッドをまとめて記述している
関連する処理が一つにまとまってるから、明らかにこっちの方が見やすい

内部処理は内部処理なので、密接に関わりあうのが普通で
内部処理を複数のクラスに分割し、簡潔なインターフェースで
内部と外部に分けるというのは普通は出来ない
そうやって無理にカプセル化すれば、内部の処理が見えないことがデメリットになり、
わかりにくく拡張しにくいソースになってしまう
関連する内部処理は一箇所にまとめて、カプセル化せずに丸見えにするのが基本だ

そうやって無理にカプセル化しようとすることが、オブジェクト指向の一番の弊害だと
俺は思うね

つまり内部処理用メソッドも外から呼べる方がよいと?

外部からは簡潔なインターフェース
内部処理はカプセル化されていない複数のクラスの共同作業として実装し
関連する記述は出来るだけ一箇所にまとめる

「カプセル化」を通常と異なる意味で使ってないか?

>>611
どういうこっちゃ？
カプセル化は、外部から呼ぶもの(public)と
内部処理(private)を分けて、外部からのインターフェースを
簡潔に使いやすくする

外部からは内部処理を気にしなくて済むので、実装を入れ替えることも
出来るようになる、といったことだと思ってるけど

>>608
関連する内部処理は一箇所に置いた方がいいというのは、むしろ同じ考えｗ
俺は、>>601の言う、実装は１つのクラスにを持たせるっていうのに、賛成できないだけ。
こういう、なんでも屋的クラスを作って、いろんなことをそのクラスにやらせると、
いずれそのクラスは関連しないメソッドでいっぱいになって、逆に見通し悪くする。
ってことを言いたかった。

んで、ちょっと質問なんだが
俺はC#はよく分からないんだけど、クラスのソースファイルを分割するって、日常的に使うもの？
既存のイケてないソースに対しての、とりあえずの対処とかじゃなくて？

>>613
日常的に使う人もいるし、あまり使わない人もいる

一番基本的な使い方は、ツールによって生成されるソースと
自分で書くソースを分けて、コンパイル時に結合するというもの
Visual StudioのGUIデザイナがそういうソースを吐くからみんなそれを使っている

>>608のようにクラス階層をぶった切って、
関連する処理をまとめるなんていうのはあまりされてないと思う。
これから広まるかもしれないけど

いけてないソースに対してとりあえず対処するのに、どう使うのか分からないけど
あまり使えないんじゃないかな

>>614
あーなるほど
GUI周りとかのツールが吐く部分と、自前実装の分離か。それは便利そうだね。

あと、イケてないソースへの対処というのは、可読性最悪の既存ソースに対して、ソースを分割して見やすくするとか、そういうのを考えてた。

ソースの分割は便利そうだけど、その場その場でちゃんとルール決めておかないと、無秩序に分割されて悲惨な事態を招きそうw