トップページ⇒tech
1001コメント377KB

OOP

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2010/09/10(金) 19:44:50
OOPをネタに罵ったり罵られたりするスレ

0809デフォルトの名無しさん2010/10/15(金) 21:26:48
箇条書きよりはマインドマップの方がわかりやすいってマインドマップの本に書いてあった
0810デフォルトの名無しさん2010/10/15(金) 21:31:37
>>808
まさかの同窓。。
とりあえず、あまり母校の名に泥を塗るような言動は止してくれ、頼むから。
0811デフォルトの名無しさん2010/10/16(土) 04:29:02
>>807
> 処理ナンバーで一括管理してる
管理できなくなってるから困ってるんじゃねーの？
0812デフォルトの名無しさん2010/10/16(土) 18:33:13
俺はそうとは読まなかったが。

とにかく、箇条書きは構造がシンプルだから、後々の応用が利いて良いんだよ。
その証拠にRDBも成功してるじゃん。Oracleとか自社の検定まで作って、ウハウハ。箇条書きすげぇって。
オブジェクト指向型のDBも有るけど、全然人気出なかったし。そんなもんだよ。

俺ら、もう良く知ってるわけよ。
テキストファイルで書いといてgrepしても良し、CSVで書いてエクセルで読み込んでも良し、
エクセルだったら、オートフィルタや関数やVBAも使えるし、あー便利便利。
ただ、かっこ悪い気がするっていう。

でも本当はかっこいいんだよ、箇条書き。
LinuxBoot時の山のようなinitには感動すら覚える。
0813デフォルトの名無しさん2010/10/16(土) 19:59:52
>>812
そのための多態とファクトリーパターンだろ、死ねよ。
0814デフォルトの名無しさん2010/10/16(土) 23:08:36
× 箇条書きは構造がシンプルだから、後々の応用が利いて良い
○ 箇条書きは構造がシンプルだから、バカでも理解できて良い

いや、わりと重要なことだけどな。世の中のみんなが天才ではないし。
0815デフォルトの名無しさん2010/10/16(土) 23:16:09
OOP的な階層構造って、わかってる人が設計した物をわかってる人が読まない限りはスパゲッティにみえちゃうもんだからな
0816デフォルトの名無しさん2010/10/16(土) 23:25:30
プログラマ以外でも書ける部分を箇条書きにしとけばいいって話しだろ
プログラマはOOP覚えろよ
0817デフォルトの名無しさん2010/10/16(土) 23:54:57
なんか裸の王様っぽくなってきました
0818デフォルトの名無しさん2010/10/16(土) 23:59:45
多態つかわないのに継承したり、
get/setだらけで実質ほとんどpublicフィールドになってたり
やたらややこしい事前条件を暗黙的に要求してきたり
何やってくれるのか全く想像できないメソッド名つけたり
やたらたくさんの機能を備えたクラスつくったり

そんなんするからOOPの可読性が悪いんじゃないかと勘違いする奴がでる
0819デフォルトの名無しさん2010/10/17(日) 00:14:58
言語が許してるのが悪い
0820デフォルトの名無しさん2010/10/17(日) 00:19:33
どう考えても使う奴の問題
0821デフォルトの名無しさん2010/10/17(日) 00:25:22
>>817
まーわざと箇条書きとOOPを比較して、OOP派の人に無理に箇条書きを否定させる流れに持っていったからな。
そこは、「OOPも良いけど、箇条書きもいいね」って言えれば良かったのに、
それが出来ないのがOOP脳と言うかなんと言うか。。
2流なんだよ。俺が1流ってわけでもないがな。
0822デフォルトの名無しさん2010/10/17(日) 00:27:14
あんまりそう言い出せる空気でもないだろここ
0823デフォルトの名無しさん2010/10/17(日) 00:36:55
そもそも箇条書きで済むところと多態で済む所が同じとは限らん
0824デフォルトの名無しさん2010/10/17(日) 00:49:33
そうなんだけど、そこはあえて比較させて、箇条書きを叩かせる方向へ持っていったのよ。
俺の悪知恵。

だけど、箇条書きって大概が箇条書きの箇条書きで2次元だから、
マトリックスになって、組み合わせが使えて、大概のことは出来るぞ。
A　○　×
B　○　○
C　×　○
こんな感じでさ。
プログラムで言ったら配列に相当して、
その強力さとシンプルさと道具としての奥深さは、皆理解しているところだろ？
これ否定するとか、天に向かって唾吐くようなものだわな。
あえて吐かさせといて言うのもなんだが。
0825デフォルトの名無しさん2010/10/17(日) 00:52:51
あーごめん2次元って表現はおかしい罠。
0826デフォルトの名無しさん2010/10/17(日) 00:57:47
箇条書きのスレ作って、そっちでやれ。
0827デフォルトの名無しさん2010/10/17(日) 00:59:40
箇条書きって言うからイモいけどcsv, tsvとかいうとそうでもない
まぁcsvがいいか多態がいいかは状況によるよ
0828デフォルトの名無しさん2010/10/17(日) 03:14:29
>>827
CSVやTSVじゃ構造化したデータを表現できねーだろ。
DBのテーブルならそんなんでもいいがな。
0829デフォルトの名無しさん2010/10/17(日) 11:14:59
>>816
箇条書きで手に負えるような単純なもん作ってるうちはそれでいいが、
現代のプログラムはそれじゃおっつかない。だからOOPが必要、ってこったな。

例の彼はプログラマではないみたいだし、OOPが必要になるほど複雑度の高い
プログラムを書いたことがないんだろうな。
ワンライナー書いて「俺って天才ハッカーｗｗｗ」とか勘違いしてるタイプと想像。

あまり誰も言わんが、ワンライナーを賞賛する文化って、教育上有害だと思うんだよな。
ああいうのは、非実用的で実戦で使うのは有害な（だからこそ面白い）お遊びなんだ、
っていうのをもっと喧伝した方がいいと思う。
0830デフォルトの名無しさん2010/10/17(日) 12:05:27
>>829
もちろん使い方次第だけど、ワンライナーが有害だとは思わないな。
書き捨てのスクリプト以外でワンライナー使うのは駄目。
0831デフォルトの名無しさん2010/10/17(日) 12:46:47
是々非々じゃないレスはまず煽り
0832デフォルトの名無しさん2010/10/17(日) 12:55:40
人によって理解力が違うんだから、ソースコードの意味を表すメタ情報が必要だと思うの
コードと仕様書から自動的にドキュメントを生成するのってない？
仕様はもちろんZ言語です
0833デフォルトの名無しさん2010/10/17(日) 14:29:12
>>832
ScalaのSpecsみたいのとかはどうだ。テストケース＝仕様書。
0834デフォルトの名無しさん2010/10/17(日) 14:54:43
おお、specsいいね
0835デフォルトの名無しさん2010/10/17(日) 15:01:11
多態の良さは型switchを無くせることと、既存コードに手を加えずに拡張できる事であって
箇条書き云々とは全く関係ないと思うんだが
0836デフォルトの名無しさん2010/10/17(日) 15:09:27
switchがなくせることがいいこと？
0837デフォルトの名無しさん2010/10/17(日) 16:30:56
switchが不要になるのは結果として、だな。
0838デフォルトの名無しさん2010/10/17(日) 16:43:46
処理対象が増えたら、全ての型switchに処理を追加してかなきゃいけない
継承すればそれが無くなる
0839デフォルトの名無しさん2010/10/17(日) 22:48:20
>>838
継承じゃなくて多態だろ？
0840デフォルトの名無しさん2010/10/17(日) 22:56:08
多態は形容であって、switchの分岐を増やすことでswitchで扱える型と処理の多様性を関係付ける行為は継承なんでは
おっぱお
0841デフォルトの名無しさん2010/10/17(日) 23:22:59
継承は、親オブジェクトから性質を受け継ぐことを述べているに過ぎないだろ。
switchを消せるのは、同じインタフェースに対して別々のオブジェクトを作れることの恩恵に過ぎない。
0842デフォルトの名無しさん2010/10/17(日) 23:23:25
いつもの人だけど、俺より日本語がヤバイってもうダメ。
0843デフォルトの名無しさん2010/10/17(日) 23:58:30
一番いい日本語を頼む
0844デフォルトの名無しさん2010/10/18(月) 00:06:15
そんな日本語で大丈夫か？
0845デフォルトの名無しさん2010/10/18(月) 19:15:18
大丈夫だ、問題ない
0846デフォルトの名無しさん2010/10/19(火) 18:30:09
>>843-845
こんなとこでやるなよw
気がつくまで時間かかるわ
0847デフォルトの名無しさん2010/10/21(木) 12:39:10
ある日
俺「バカオヤジが片付けむちゃくちゃだから新しい棚買おうよ」
母「そうね、明日買いにいきましょう」
明日
俺「オヤジ　車貸してくれ」
父「おぅ、あそこの電気がつかんが・・・ちょっと電気の球とってこい」
俺「・・・」
父「ここの球がなぁ、前からつかん」
俺「・・・（無言で立ち去り部屋で布団に入りヌクヌクする）」
遠くから
父「あいたたたたた・・・ピー（糖尿病の血糖値を測る測定器の音）」
３０分後
母「お父さんが低糖になるからごはんあげてやって」
俺「・・・（メシをつぐ）」
父「（メシをうけとって）おい、電気買ってこいよ（ムシャクチャ）」
母「・・・」
俺「・・・」
俺「いつ棚買いに行く？（いつになったらこいつ死んでくれるだろう・・・）」
0848デフォルトの名無しさん2010/10/21(木) 23:03:56
俺には難しすぎて意味がわからないが、
車持ってないお前が糞でFA？
0849デフォルトの名無しさん2010/10/22(金) 16:17:45
兄が糞でＦＡのようだ
0850デフォルトの名無しさん2010/10/25(月) 05:22:38
ツンデレですね！
デレ期はまだですか！
0851デフォルトの名無しさん2010/10/25(月) 06:06:15
いいえ今日は月曜日です
0852デフォルトの名無しさん2010/10/25(月) 06:13:31
俺を娘に変えると、とたんに・・・
0853デフォルトの名無しさん2010/10/26(火) 11:16:16
ヤンキーデレのほうのヤンデレが連想された
ふしぎ！
0854デフォルトの名無しさん2010/10/26(火) 23:22:25
でも良く考えたら、お前ら永遠の命って欲しいか？
死ぬことも出来ないってのもなかなか大変そうだ。
OOPや取り巻きのプログラマたちもそう思ったのだろう。
儚さ、刹那主義。滅びの美学。
縦割り構造。利権主義。お役所仕事。たらい回し。
とても日本的で良いじゃないか。

C言語は良すぎてダメだね。永遠に残るし。
0855デフォルトの名無しさん2010/10/27(水) 13:56:02
すまん、永遠の命欲しい
0856デフォルトの名無しさん2010/10/27(水) 15:37:26
コンストラクタでどこまで処理をするのが望ましいでしょうか？
クラスの機能を最低限満たせばよいですかね
0857デフォルトの名無しさん2010/10/27(水) 16:39:31
そのクラスを使用できる状態に出来る最低限の初期化かねえ。
細かい設定はほかに持つのがすきかな。

でもコンストラクタで全て終わらせるのもそれはそれですきだけどな。

どういうのがいいのかねえ。
0858デフォルトの名無しさん2010/10/27(水) 18:12:59
クラスの一通りの機能が使える状態にするところまで、かな。
生成したら基本的には、もう使える状態であるべきだと思う。

細かい設定もコンストラクタの引数でやるのが理想ではあるなあ。
作ったらもうほとんど弄る必要がなくて、役割上、本当に途中変更が必要な属性以外は
読み取りしかできないような感じにして、どうしても変更したいならオブジェクト作り直し。

…とはいえ、そういうワケにもいかんって場合もやっぱある。
その線引きは難しいところ。

でも最低限「生成しただけじゃ使い物にならない」ってのは避けたいかな。
出来れば生成しただけで一応使えるように、そうでなくても
生成→有効化、の2手順（有効にする前にやっておくべきことがあるクラスの場合）で一応使えるようにしておきたい。
0859デフォルトの名無しさん2010/10/27(水) 18:20:24
何処で見たか忘れたけど、コンストラクタ内ではいろいろ処理を行わないことみないなやつ。
生成コストがどうのとか例外がどうのとかそんなないようだったきがするんだけど・・・。

こういう考えだと生成と各種変数の初期化くらい？
その後用途別の初期化メソッドを呼ぶのかね。
0860デフォルトの名無しさん2010/10/27(水) 19:29:16
ファクトリ関数にすればいいんじゃね？
0861デフォルトの名無しさん2010/10/27(水) 20:09:30
staticなメソッドで、目的別の生成用メソッドを持つってかんじ？
コンストラクタはprivateで隠蔽なのかな？
0862デフォルトの名無しさん2010/10/27(水) 20:21:25
856です
ありがとうございました。

0863デフォルトの名無しさん2010/10/27(水) 20:44:06
>>862バーローｗｗｗ
0864デフォルトの名無しさん2010/10/27(水) 22:36:22
>>861
一部の言語では複数名称のコンストラクタを持てるから(Delphiとかそうだった希ガス)
そういう言語では単に各種用途のコンストラクタを用意する、になるのかな？
0865デフォルトの名無しさん2010/10/28(木) 00:42:20
ほらもう、コンストラクタで何処までするか、こんなことに悩まなきゃならんなんて、時間の無駄だよなぁ。
コンストラクタって名前がダメなんだろうな、なにか特別な感じがして。
こんなのただの初期化用関数なんだから、深く考えるなよ。
init( &hoge );　だったら誰も悩まないのにな。
インスタンス確保したら勝手に初期化されてる、ってのは一見便利そうに感じるんだけど、
実際には引数を渡さなきゃならなかったり、完全に全自動ってわけにはいかないんだよな。
なんつーか、中途半端。別に初期化用関数方式でも構わないっちゃ構わない現状。
そのくせ言語レベルで組み込まれている仕組みだから、なにか活用しなきゃいけない気がして困る。
その点デストラクタは有用だな。とはいっても、GC無い言語だと意味半減だけど。
まーGCある言語だと、デストラクタ自体の意味が別の意味で半減して、これまたなんとも。
個人的にはコンストラクタもデストラクタも無いほうが良いと思っていて、
無くても問題ないように言語使用を練り直す方向が正しいと思ってる。
オブジェクト自身がコンストラクタやデストラクタを持ってるってのはガンだと思うから、
どこか別のところへ持ってくなり、なんらか別のトリックを用意するなり。
0866デフォルトの名無しさん2010/10/28(木) 00:54:39
そんで、C++だと、暗黙の型変換までコンストラクタで賄うだろ。
初期化の仕組みで変換もするって、もうおかしいだろ。
そんで困って、コンストラクタでの暗黙の型変換を禁止するへんな予約語が追加されたんだっけか。
言語レベルで変な仕組み導入しまくって後で困ってるっていうね。
標準のIOストリームもそうだけどさ。色々やって、結局printf万歳だもんな。
バカの考え休むに似たりってか。あーC言語は平和だなぁ。
0867デフォルトの名無しさん2010/10/28(木) 00:59:27
つーかコンストラクタってそんなに活用されてないよね。
大体はファクトリーパターンとか使うんだろ？
もうなんなんだろうね。
そもそも初期化ってのはそれなりに複合的な処理なんだよ。あっちゃこっちゃが相互作用で影響してくる。
そんな処理が単一のオブジェクトのしたにぶら下がってること事態おかしいっちゃおかしい。
だから、結局大したことできないっつーね。
0868デフォルトの名無しさん2010/10/28(木) 01:26:55
どこまでって明らかにオブジェクトの初期化までだろ
0869デフォルトの名無しさん2010/10/28(木) 03:03:59
あれの自作言語ではnew AddExpr(new IntExpr(4), new MulExpr(new IntExpr(4), new IntExpr(12)))
相当のことやると漏れるようにできてんのか。なる。
0870デフォルトの名無しさん2010/10/28(木) 08:31:10
>>865
init( &hoge ); だと init() の管理は誰がやるんだ。
0871デフォルトの名無しさん2010/10/28(木) 11:24:06
>>865
GCある言語だとデストラクタの扱いは微妙なんじゃなかったか
最近はusingやwithみたいに特定のスコープを抜けたときに処理するという仕様が多かったような
0872デフォルトの名無しさん2010/10/28(木) 11:38:53
C#で「デストラクタ」と呼んでるものはファイナライザ
明示的ないしスコープから抜けた時に明に呼ばれるものがデストラクタで
参照が無くなってる場合に暗に呼ばれるものがファイナライザ
0873デフォルトの名無しさん2010/10/28(木) 12:01:32
そうなるとDisposeは単なる事後処理メソッドの規約みたいなものでいいかいな？
0874デフォルトの名無しさん2010/10/28(木) 13:15:01
「オブジェクト自身がコンストラクタを持っている」という時点でなんか勘違いしてるだろ
0875デフォルトの名無しさん2010/10/28(木) 13:22:57
確かに。読む気しなかったがコンストラクタ持ってるのはクラスだよな。
プロトタイプベースでもオブジェクト自身はコンストラクタでは…ないよな？
0876デフォルトの名無しさん2010/10/28(木) 13:24:23
オブジェクトが持ってるのは半分程度だな。

thisが使えない初期化リストは…オブジェクトのものと言い難いかもしれない。
いや、初期化リストはコンストラクタと呼ばないのかもしれない。
俺は俺が何をいってるのか、わからないのかもしれない。
0877デフォルトの名無しさん2010/10/30(土) 18:31:12
いよいよ「OOPには2012年までのカレンダーしかない」が現実味を帯びてきたな。
って、今日はオカルトキャラで行こうかと思ったけど、無理だったいつもの人。

オブジェクト指向・・・オブジェクト・・・・オブジェクトって何？
二通り思い浮かぶ。
1．オブジェクト=モノ
だけど、物って言っちゃうと、アホっぽいというか。物指向って即物的というか。
それを素晴らしいアイデアのように言われても。なぁ。
2．オブジェクト=対象
対象って言うからには、何かの対象なわけで、じゃあ、オブジェクトは何の対象なの？って言われれば、
オブジェクトは処理の対象なわけで。
英語の文法を考えてもわかるけど、述語もなしに、対象だけポツンっと出てくることって無い訳で。
あくまで、処理側から目線で、自分の処理の対象はアレですって意味合いだから。
だから、オブジェクトがメソッド持ってて、自分のメンバメソッドの処理の対象は自分だから、
自分は自分のメソッドの対象で、すなわち自分は対象＝オブジェクトですってのは
何かふに落ちない。
自分は自分自身の持つ機能の対象だから、自分は対象です。ほらなんか変だ。

どっかでおかしいんだよね、OOP。
そのおかしさをずっと引きづってる。ウソが雪だるま式。掛け違えたボタン。
0878デフォルトの名無しさん2010/10/30(土) 18:42:32
だからなんで論文一本も挙げずに自論をグダグダ言っちゃうわけ？
色々足りてないんでねーのもぅ
0879デフォルトの名無しさん2010/10/30(土) 18:58:14
ドSだから。
0880デフォルトの名無しさん2010/10/30(土) 20:04:58
といいますと、ＯＯＰに関する論文がござるようでぜひともそのＵＲＬを貼っていただけたらと思う次第でございます
0881デフォルトの名無しさん2010/10/30(土) 22:56:19
>>877
オブジェクトひとつで完結するわけじゃないんだから
処理を呼び出される対象でいいじゃん
0882デフォルトの名無しさん2010/10/31(日) 02:26:15
>>881
だったらそれは、C言語だよ。
0883デフォルトの名無しさん2010/10/31(日) 09:37:34
対象を最初に書くからオブジェクト指向、って言い方も聞いたことあるな
0884デフォルトの名無しさん2010/10/31(日) 12:18:44
アホっぽくて良いね
0885デフォルトの名無しさん2010/10/31(日) 12:28:47
過去からの経験の蓄積を元にした、現在のオブジェクト指向の実践が既にあるのに、
いまさら「オブジェクト」っていう言葉の定義を云々して何がしたいんだ？
0886デフォルトの名無しさん2010/10/31(日) 12:43:03
いまさら、という言葉をチョイスする時点で。
0887デフォルトの名無しさん2010/10/31(日) 12:57:10
OOPの進化(bugfix)は未だ衰えずということだ
0888デフォルトの名無しさん2010/10/31(日) 13:14:52
このさい何がオブジェクトかなんてどうでも良くって
ちゃんとカプセル化したら依存関係が整理できて再利用しやすくなるという事実のみが大事
0889デフォルトの名無しさん2010/10/31(日) 13:28:31
>>888
同意。とにかく、整理は全てのプログラマの恩恵となる。
KISSの次はOOP。
0890デフォルトの名無しさん2010/10/31(日) 13:31:18
じゃあカプセル化って何？ってなる
依存関係が整理できて再利用しやすくする事そのものがカプセル化ですか？
0891デフォルトの名無しさん2010/10/31(日) 13:35:31
カプセル化は内部状態を公開しないこと
依存関係の切り離しそれそのもの
0892デフォルトの名無しさん2010/10/31(日) 14:45:12
内部状態を公開しないことと、
依存関係の切り離しは何の関係も無いだろ。
たしかに内部状態と外は切り離されるが、その代わりメソッドが依存するだろ。
0893デフォルトの名無しさん2010/10/31(日) 14:50:32
それから、カプセル化とOOPは関係ないと思うんだよね。
だって、C言語でも普通にするでしょ、カプセル化。
ハンドルとかで対象物を抽象化するわけな。
だけど、対象物を抽象化したからって、オブジェクト指向ってわけでは無いよな。
0894デフォルトの名無しさん2010/10/31(日) 14:52:52
その理屈で行くと多態もOOPと関係ないな
Cや関数型言語でも多態できるしな
0895デフォルトの名無しさん2010/10/31(日) 14:53:40
OOPってやっぱオブジェクトやクラスがメソッド抱えててってイメージがある。
だけど、マルチメソッドになると、メソッドはグローバル空間に行っちゃう。
だからより一層OOPって何なのって話になる。本当は無いんじゃないか？そんなもの初めから。
0896デフォルトの名無しさん2010/10/31(日) 14:56:26
>>894
実際関係ないと思うよ。
だってマルチメソッドだと、クラスやオブジェクトがメソッド抱えてるって感じじゃないし。
要は動的オーバーロードだし。
0897デフォルトの名無しさん2010/10/31(日) 15:00:40
だからオブジェクトが何かなんてこのさいどうでも良いと教えてやったのになんでまたそこに戻るんだ。
そんな曖昧な物いくら考えても有益なことなんて一つも出ないぞ。
0898デフォルトの名無しさん2010/10/31(日) 15:02:04
いや、OOPがまるで実体の無いペテンだってことが解るじゃん。
0899デフォルトの名無しさん2010/10/31(日) 15:02:41
>>892
内部状態は全て自分のメソッドからのみ変更される。
これで依存関係が切れてなかったらそれは単なる設計ミス
内部状態が内部状態になってない。
0900デフォルトの名無しさん2010/10/31(日) 15:06:23
だから、そのメソッドが外部と依存するだろ。
依存関係が切り離されてるんじゃなくて、
実装とインターフェースが切り離されてるだけだ。
0901デフォルトの名無しさん2010/10/31(日) 15:08:18
そして、実装とインターフェースが切り離されていることと、再利用性は何の関係も無い。
0902デフォルトの名無しさん2010/10/31(日) 15:12:48
自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。

外部状態がどうなってるかを気にせず、
「この内部状態の時にこのメソッドが呼ばれたらこの内部状態に変わる」
という一貫した普遍性を維持するためのカプセル化だし
これを依存関係が切れてると言う。
0903デフォルトの名無しさん2010/10/31(日) 15:19:05
何言ってるんだ？
自分のメソッドと、自分以外の他オブジェクトは、
たとえカプセル化しても、メソッドを通じて依存しあってることには変わりない。

>自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。
逆逆。
実装とインターフェースを分離することで、自分のメソッド(というかインターフェース)と内部状態(というか実装)を
依存「しない」ようにするのがOOPだろJK。

>これを依存関係が切れてると言う。(ｷﾘｯ
聞いたこともない。OOPを支持する人って、やっぱこのレベルなんだな。
0904デフォルトの名無しさん2010/10/31(日) 15:22:42
>>903
依存しあってる？
使う側は使われる側の挙動に依存してるかもしれんが
使われる側は使う側の事情なんて何も気にせず、与えられた機能を実行するだけだぞ。

ライブラリの挙動がアプリの実装に依存するわけ無いだろ馬鹿か
0905デフォルトの名無しさん2010/10/31(日) 15:22:57
カプセル化して内部の整合性を取ることを、依存関係が切れてるって表現するの、
本当に聞いたことがない。悪いが。
0906デフォルトの名無しさん2010/10/31(日) 15:24:48
まあ確かに依存しあってるって表現はまずかったな。依存しているが正解。
0907デフォルトの名無しさん2010/10/31(日) 15:32:12
つまり、内部状態をもつということはそれ以外の外部の状態は気にしなくてよくなるわけだ。
気にしなくてよくなるから、そのクラスの実装に関して依存関係はない。
で、その内部状態はカプセル化によって実現している。
0908デフォルトの名無しさん2010/10/31(日) 15:41:19
内部状態を持つ(というか、内部状態をプライベートにして外から見えなくする)ことは、
外から内部の実装を気にしなくても良くなる、というだけで、
内部から外の状態を気にしなくても良いと言うことにはならない。

なんか全て反対言うよな。頭おかしい。
レス数が900を超えています。1000を超えると表示できなくなるよ。