OOP
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/10(金) 19:44:500357デフォルトの名無しさん
2010/09/20(月) 20:19:11オブジェクト指向と言ったら継承っしょみたいなノリで継承が多用されてる
しかし、一口に継承と言っても
実装の継承: コードの使い回しを目的にした継承
概念の継承: 多態性を利用する目的の継承（インターフェース継承）
の二つの継承があり、この二つが混同されることによって厄介な問題が起きる。
ちなみに、C++はprivate継承といって、実装だけの継承も出来るのだけど、
boost::operatorsみたいな特殊なパターンを除いては、コンポジションが推奨されてるみたい。
0358デフォルトの名無しさん
2010/09/20(月) 20:43:48ズレてるってか多分俺が理解できてない。
>なぜ継承元の構造をそこまで意識しないといけない？
今のところ、凄くやっつけ仕事を言ってるに見えてるから。
システム全体として引き継ぎ易い構造になるの？
0359デフォルトの名無しさん
2010/09/20(月) 21:30:24言語や開発環境でいろいろなケースがあると思うけど、俺が考えつくのは
ライブラリや開発環境が比較的代わりやすい場合は
コンポジションの方が影響を受け難い。
コンポジションは別クラスに実装するから、相手のフィールドやメソッドを直接操作出来ない。
これは欠点でもあるし、影響を受け難い利点にもなる。
継承の場合、スーパークラスが修正されると影響が出るから安定したクラスを親にしないと。
言語はjavaとか？
>>358
>今のところ、凄くやっつけ仕事を言ってるに見えてるから。
差分プログラミングの例だから、そこまで考えていない。
和暦を入力パラメータにもつメソッドに
新元号が追加される単純な話だから。
0360デフォルトの名無しさん
2010/09/20(月) 21:50:40契約プログラミング的な考え方を非常に大雑把に言えば、
「あるインタフェースを持つオブジェクトがユーザに対して見せる機能は、
常に一貫していなければならない」と言えると思う。
差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
むしろ相反する場合の方が多いのではないか、というのが俺の意見。
もちろん、両者が一致する範囲内での話なら特に問題はないと思う。
0361デフォルトの名無しさん
2010/09/20(月) 21:58:500362デフォルトの名無しさん
2010/09/20(月) 22:46:19なるほど、そう言うことが言いたかったのか。
>差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
>という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
>むしろ相反する場合の方が多いのではないか、というのが俺の意見。
俺の意見は、差分プログラミングは基本包含になるから継承しても事前/事後条件は守られる。
俺の浅いEiffelの知識でも大丈夫だったと思うが。
ただ機能削除や別機能なら言う通りだと思う。
0363デフォルトの名無しさん
2010/09/20(月) 23:05:34肝心の、「オブジェクトがメソッドを持つべきかどうか」に関しては何も考えない、というか、それが当たり前と思ってるのな。
OOPのグダグダは全部そこから始まってるといっても過言ではないのに。
そこ無視して小手先のフォローに走る。OOPらしいっちゃらしいが。
0364デフォルトの名無しさん
2010/09/20(月) 23:33:15やるなら多態だけにして、あとはできるだけ合成しろって事でしょ。
0365デフォルトの名無しさん
2010/09/20(月) 23:37:10少しはこのスレの住人を説得してみろよ
0366デフォルトの名無しさん
2010/09/21(火) 00:39:54OOPだとモジュール構成の最小単位がオブジェクトで、
オブジェクト同士が協調しる手段としてメソッドがあるんたから、
オブジェクトはメソッドを持ってて当たり前だと思うけど。
「OOPはよろしくない」って話？
0367デフォルトの名無しさん
2010/09/21(火) 00:46:01多重ディスパッチのことを言ってるんじゃね
>>363
個人的には「オブジェクトがメソッドを持つべきか」は正直どうでもいいなあ
それが多重ディスパッチとかのことなのであればの話だが…
最低限多態さえ出来れば手段は何でもいいと思うよ
カプセル化や継承も、あったら便利だな程度の認識だわ俺は
0368デフォルトの名無しさん
2010/09/21(火) 19:39:54そんな話し書店に行けばいくらでも読める。
俺は実践から学んだ人の考えを知りたい。
お前は図書館でもいってろ。
0369デフォルトの名無しさん
2010/09/21(火) 19:58:41やっぱり不特定多数の人が集まるところでは、経験から来る話を一番に聞きたいね。
0370デフォルトの名無しさん
2010/09/21(火) 20:29:290371デフォルトの名無しさん
2010/09/21(火) 20:42:46最近調べ物をしててこれを知ったんだけど
publicやprivateなどの可視性は事前条件とは無関係なんだろうか？
C++ではvirtualなメンバ関数はprivate推奨のNVIイディオムとかあるし
それとは別にis-a関係はLSPにとって十分でないことを知り
調べるほどに、継承を使える自信が無くなって行く
0372デフォルトの名無しさん
2010/09/21(火) 21:09:310373デフォルトの名無しさん
2010/09/21(火) 21:19:00それはさておき、クラスのprivateな状態をメソッドの事前条件にするのは良くない。
呼び出し側がチェック不能だから。
0374371
2010/09/21(火) 21:31:29>publicやprivateなどの可視性
この認識はそもそも誤りだった。
publicやprivateはアクセス権(accessibility)のコントロールであり、
可視性(visibility)とは別の概念
>>373
というわけで、その主張は俺の勘違いと同じ誤りを含む
検証可能なソースとしては
C++の仕様書をvisibilityで検索すると1箇所(+索引)しかヒットせず
そこにはaccessibilityとvisibilityは違うと書いてある
となると、アクセス権と事前条件の話は独立、と考えるのが正しいのかな
上の記事はどちらかというと疑って読んでたんだけど
上のtwitterの人はまじプロいな
なんたるPitfall
0375デフォルトの名無しさん
2010/09/21(火) 21:56:34そのプログラムは常に正しい動きをするって事なんじゃないのかな
そんなにややこしいかねLSPって
0376デフォルトの名無しさん
2010/09/22(水) 03:52:21SettingDialog sd = new SettingDialog();
sd.bModal = false; //エラー
Dialog tmp = sd; //エラー
tmp.width = 0;
とできる。
しかしDialogクラスのコンストラクタでdialogManagerか何か、クラスの外にDialogクラスのポインタ/参照
として渡されている可能性を考えると完璧とはいえない。
0377356
2010/09/22(水) 04:14:15(*)AbstractDialogクラスを実装したDialogクラスがあって
こいつの実装を利用して(一部の振舞いは変更して)MyDialogクラス作りたい
MyDialogもAbstractDialogインタフェースを実装すればこのインタフェースを想定する他のクラスと組み合わせることができる
じゃあとりあえずpublic継承してメソッドオーバーライド使うのが目的の達成は一番楽だよね
Qtもこういうプログラミングを想定しているようだし
これをMyDialogクラスがDialogクラスのインスタンスをprivateメンバに持つような形の包含にしちゃうと
一々MyDialogクラスの定義でAbstractDialogインタフェースのメソッドの定義を、
振舞いがDialogクラスのそれと全く同じでも書かなくちゃならない
void fuga() { m_dialog.fuga(); }
とかね
MyDialogクラスをAbstractDialogクラスのインタフェースを使って参照等で扱う、または直接扱う場合なら問題なさそうだけど
MyDialogクラスをDialogクラスの参照経由で扱うとかならちょっと嫌な臭いがする気がする
これが>>357のいう混同なのかな？
0378デフォルトの名無しさん
2010/09/22(水) 05:31:340379デフォルトの名無しさん
2010/09/22(水) 07:21:52実装の継承系統を分けた方良いんでない
DialogImplみたいな別クラスをAbstractDialogに所有させる。
違う挙動が欲しければImplの方をいじる。
0380デフォルトの名無しさん
2010/09/24(金) 21:39:31・カプセル化
まず構造化と比べオブジェクト指向はどう違うか？
0381デフォルトの名無しさん
2010/09/24(金) 22:59:25お し ま い
0382デフォルトの名無しさん
2010/09/24(金) 23:10:28馬鹿？ お前自身が終わっているぞｗ
0383デフォルトの名無しさん
2010/09/24(金) 23:49:240384デフォルトの名無しさん
2010/09/25(土) 00:05:41要素へのアクセスを「確実に」共通化できる、ってとこじゃないだろうか
構造体だと、どこか1つでも直接アクセスしたら共通化が外れちゃうからね
その恩恵は多人数開発だけじゃない、個人での開発でもある
例えば、あるフィールドをpublicでの直接アクセスから
private+アクセサメソッドに切り替えたくなった時とかね
フィールド代入をメソッド扱いにできる言語なら、利用側はそのままで
宣言／定義の書き換えだけで済むし
そうでない言語でも、フィールドをprivateにしたことで
利用側でアクセサメソッドを通してない部分はコンパイル時に炙り出される
0385356
2010/09/25(土) 00:11:52見せない化
意識させない化
0386デフォルトの名無しさん
2010/09/25(土) 00:13:26議論する必要ないだろ
お し ま い
0387デフォルトの名無しさん
2010/09/25(土) 00:23:320388デフォルトの名無しさん
2010/09/25(土) 00:30:240389デフォルトの名無しさん
2010/09/25(土) 00:44:090390デフォルトの名無しさん
2010/09/25(土) 00:47:150391デフォルトの名無しさん
2010/09/25(土) 00:51:12継承なんて言ってしまえばただの便利機能だし。
カプセル化は便利とは真逆の、アクセスを制限してしまう不便機能だが
そんなものがなぜプログラムに必要で重宝されるのか、もうちょっと真剣に理解したほうが良い。
0392デフォルトの名無しさん
2010/09/25(土) 00:51:210393デフォルトの名無しさん
2010/09/25(土) 01:01:59単にグループ化を指してる人と
オブジェクトのインターフェースを作る事を重要視してる人と
データを隠蔽する事を重要視している人が居るから
0394デフォルトの名無しさん
2010/09/25(土) 01:06:10全部大事なんだよ。
プログラムの宿敵はスパゲッティだ。
全部それを避けるための手法だ。
0395デフォルトの名無しさん
2010/09/25(土) 01:21:00せいぜい要所に型switch入れるぐらいの変更で済むが
カプセル化が無くなると大変酷いことになる。
0396デフォルトの名無しさん
2010/09/25(土) 01:50:48せいぜいクラスを構造体に替えたりアクセサを関数に変えるくらいの変更で済むが
多態が無くなると大変酷いことになる。
0397デフォルトの名無しさん
2010/09/25(土) 02:07:460398デフォルトの名無しさん
2010/09/25(土) 02:13:00要所に型switchで代用できるレベルならいいけど、そうとも限らないからな。
次点でカプセル化だな、使い方が解りやすい割に幅広く、便利機能って言葉がぴったり。
無くてもなんとかなるっちゃなるんだが、あって欲しい機能ではある。
継承はたまーに欲しいんだが、普段は多態の一手段でしかないのがなあ。
他の手段で代用できるのなら要らないことも多い。
でも、大きめのライブラリを作る場合にはちょっと欲しいかな。
0399デフォルトの名無しさん
2010/09/25(土) 03:55:490400デフォルトの名無しさん
2010/09/25(土) 04:17:040401デフォルトの名無しさん
2010/09/25(土) 08:09:370402デフォルトの名無しさん
2010/09/25(土) 08:24:58使う側も使われる側も相手を意識しないオブジェクトではグローバルに定義されている。
しかしグローバル変数の弊害が、オブジェクト指向ではあまり聞かれない。
構造化のスコープとオブジェクト指向のカプセル化は考え方の違いがある。
0403デフォルトの名無しさん
2010/09/25(土) 08:30:030404デフォルトの名無しさん
2010/09/25(土) 09:27:37クラスとオブジェクトの区別もつかない奴がいるとは
0405デフォルトの名無しさん
2010/09/25(土) 09:35:180406デフォルトの名無しさん
2010/09/25(土) 10:16:56設計の本質は依存関係の整理であって、継承関係の構築じゃない。
0407デフォルトの名無しさん
2010/09/25(土) 10:25:33あれはOOPやりはじめの熱病みたいなもんかな。
0408デフォルトの名無しさん
2010/09/25(土) 11:41:18何を「処理系」と言っているのか理解出来ないが
オブジェクト指向はデータに処理が付く、その基本観点が抜けている。
>>384
言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。
>>386
仮に「本質的なもんじゃない」としよう（本当にそうなのかもしれないが）
だが、オブジェクト指向では必要なものだ。なぜ必要なのか議論してもいいと思うが。
>>390
カプセル化の定義を聞きたい。
>>393
なるほど、カプセル化の結果から考える人はそうなるな。
ここではカプセル化の本質から考えるのがいいと思う。
>>394
勘違いしている「スパゲッティ」は制御文の話だ。データの話ではない。
>>395,396
>カプセル化が無くなると大変酷いことになる。
>多態が無くなると大変酷いことになる。
具体的に？
マシン語や構造化の時代でもカプセル化・多態性が無くても
それなりの手法はあって「大変酷い」事にはなっていなかったが。
>>406
>設計の本質は依存関係の整理であって、継承関係の構築じゃない。
具体的に？ 俺はオブジェクト指向設計の本質は再利用だと思うが。
0409デフォルトの名無しさん
2010/09/25(土) 12:18:55今のWindowsアプリをマシン語で書けって言われて大変酷い事にならない奴がいたら天才
プログラムの規模が昔のままで良いんなら別にOOPもなくて良い
そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない
0410デフォルトの名無しさん
2010/09/25(土) 12:26:05>言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
>なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。
OOPの機能とカプセル化の相性が良かったからでしょ。
カプセル化ってのはデータと処理を一括りにすることなワケで
データと処理を分割している非OOPLでそれをやるのは、新たな要素を追加しなきゃならんが
そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。
0411デフォルトの名無しさん
2010/09/25(土) 14:13:06論点がずれている。どう「大変酷い」になるか聞いている。
アセンブラでも構造化でも大規模開発はあって、綺麗なソースも存在した。
君が言う通り「天才」なのかもしれんが．．．
>そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない
オブジェクト指向で再利用を否定できるのは、まだまだオブジェクト指向の理解が足りないから。
>>410
>カプセル化ってのはデータと処理を一括りにすることなワケ
カプセル化をそう考えるのか、俺はカプセル化＝情報隠蔽と考えるから
「データと処理を一括りにする」はカプセル化とは考えていない。
つまり、publicのみにフィールド・メソッドが書かれている場合
カプセル化は適応されていないと考える。
>そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。
一括りにするだけなら、publicやprivateなど要らない。
オブジェクト指向はpublicやprivateなどの新しい概念を導入している。
0412デフォルトの名無しさん
2010/09/25(土) 14:34:50どう大変酷くなるか、なんて考えなくてもわかるもんでは？
誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
そのあたりを何のツールも使わずに完璧に整理できるならOOPLなど要らないと言ってる。
そしてそれができる奴は天才だし、どんな言語でどんな開発規模でもうまくやってのけるだろう。
OOPにおける再利用は依存関係をうまく整理した上で得られた副次的な物に過ぎない。
逆に言えば、依存関係がうまく整理できたならOOPなど関係なく再利用性の高いコードになる。
「オブジェクト志向」がいったい何を志向しているのかといったら
それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。
0413デフォルトの名無しさん
2010/09/25(土) 14:45:54そしてこれからもオレオレOOP
0414デフォルトの名無しさん
2010/09/25(土) 16:14:09情報隠蔽は「データと処理を一括りにすること」で生まれる二次的な効果じゃね？
データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
情報の隠蔽もなされるワケで。
0415デフォルトの名無しさん
2010/09/25(土) 16:42:21acm のが一番古いっぽいんだが今大学いない一般人なのでむりです
0416デフォルトの名無しさん
2010/09/25(土) 17:49:15CLOS あたりは クラス は メソッド を抱えていないが…
0417デフォルトの名無しさん
2010/09/25(土) 18:56:54CLOSの話にもっていきたい人がいるみたいだけど、
多分それ、正解。でもバカどもは食いつかないだろうな。
OOPのObjみたく、自分で情報を遮断して殻に閉じこもってるから。
だから、議論は成り立たないから、天下り的に一言で未来を予言してみせるしかない。
モノに執着した考え方は破滅を招く。
オブジェクト指向？ﾉﾝﾉﾝ
関係指向、関数指向、機能指向、メッセージング指向。
他との関係から導かれる個性こそが、それの性質そのもの。
単体では個性は確立し得ない。
マルチメソッドの無いOOPは全部甘い罠だ。つれてかれるぞ。
0418デフォルトの名無しさん
2010/09/25(土) 19:01:180419デフォルトの名無しさん
2010/09/25(土) 19:12:28いっつも雰囲気でぼんやりした話しかしないからかなり信用できない
0420デフォルトの名無しさん
2010/09/25(土) 19:15:390421デフォルトの名無しさん
2010/09/25(土) 21:31:41多重継承とかほとんどいらないし
0422デフォルトの名無しさん
2010/09/25(土) 21:43:230423デフォルトの名無しさん
2010/09/25(土) 22:20:360424デフォルトの名無しさん
2010/09/25(土) 23:23:39public : void Parent(ITree* pITree_ ) = 0;
public : void Add(ITree* pITree_ ) = 0;
public : void Remove( ITree* pITree_ ) = 0;
};
class Tree : public ITree {
public : void Parent(ITree* pITree_ ){...}
public : void Add(ITree* pITree_ ){...}
public : void Remove( ITree* pITree_ ){...}
};
class XXTree : public ITree {
private : Tree tree;
public : void Parent(ITree* pITree_ ){ tree.Parent( pITree_ ); }
public : void Add(ITree* pITree_ ){ tree.Add( pITree_ ); }
public : void Remove( ITree* pITree_ ){ tree.Remove( pITree_ ); }
private : XX xx;
public : xx GetXX(){...}
public : void SetXX( XX xx_ ){ xx = xx_; }
}
0425デフォルトの名無しさん
2010/09/25(土) 23:24:32クラスとメソッドって形ではないけど
データ型によって実際の処理が変わるのだから、データと処理はセットになってると言えないか？
0426デフォルトの名無しさん
2010/09/25(土) 23:24:32●ツリーの操作はITreeで定義
●Treeにて上記インターフェースを実装
●深い継承はしたくない
XXTreeという具体的なデータを持つノードを作成したい。
この場合上記のようにXXTreeを作成すればよいか、
またはTreeを継承して作成したほうが良いのか。
冒頭のXXTreeのつくりの場合、ITreeはTreeとXXTreeで、
別々ではあるが2回継承されている。
包含されるTreeはインターフェースを継承すべきか。
使用目的が明示的になるの継承したほうが良いのか。
パフォーマンスのために継承はしないほうが良いのか。
具体的なデータを持つノードはXX以外にも多数あり、
またそれらはXMLのように互いを子要素として持つこともありえる。
皆様のご意見をいただきたく思います。
0427デフォルトの名無しさん
2010/09/25(土) 23:27:140428デフォルトの名無しさん
2010/09/25(土) 23:34:390429デフォルトの名無しさん
2010/09/25(土) 23:47:00ツリー構造を管理するデータと、それ以外のデータが、同じ場所にあるのは、
のちの混乱の元にならないだろうか？
ちゃんと分けた方がいいかと。
0430424
2010/09/26(日) 00:06:18レスありがとうございます。
いまいちそこまで考えが至りません。
もしよろしければもう少し具体的にお願いできますでしょうか・・・。
0431429
2010/09/26(日) 00:21:591.ユーザーに提供するデータだけを保持するクラス。
2.1のクラスのインスタンスを集めて、ツリー構造にするクラス。
に、分けるかな。
1はシンプルにして、多様性をだしやすく、
2には色々めんどい事を任せる。
こうしておけば、1は簡単に拡張が出来るし、
後でハッシュ構造に変えたくなった時は、2を取り替えるだけで済む。
0432デフォルトの名無しさん
2010/09/26(日) 00:36:35Tree単体で使うこともあるの？
そうでないならITreeの役割をTreeに移してしまえばいいと思う
また、XXTreeがTreeの子でない、というのは直感的でない
名前だけみたら、TreeがXXTreeの派生クラスだと勘違いする
ITreeはインタフェースなんだから、XXTreeはTree/ITreeを両方継承しても問題無いけど
上の例だと、そもそもTree/XXTree独自のメソッドがないから
クラス階層をわける意義が感じられない
それからvirtualは付けなくて良いんだっけ
最初Javaか何かかと思ったけどC++だよね？
0433デフォルトの名無しさん
2010/09/26(日) 00:44:41とりあえずLISPで検証できる
0434デフォルトの名無しさん
2010/09/26(日) 00:54:480435デフォルトの名無しさん
2010/09/26(日) 01:02:500436デフォルトの名無しさん
2010/09/26(日) 01:03:04データ構造を定義する前にまず何をすんの？から始めないと
それが決まらんうちはXMLでもS式でもVariantでもDBでも使っとけばいいよ
0437デフォルトの名無しさん
2010/09/26(日) 01:06:22最初から設定された問題の中で話をすればいいのに。
0438デフォルトの名無しさん
2010/09/26(日) 01:15:55>>426はもうやりたい事は決まってるでしょ。
ツリー構造を使う必要があったり、データの多様性を出そうとしたりしてるし。
0439デフォルトの名無しさん
2010/09/26(日) 01:35:31構造を眺めるだけですか
0440デフォルトの名無しさん
2010/09/26(日) 01:40:080441デフォルトの名無しさん
2010/09/26(日) 02:27:270442デフォルトの名無しさん
2010/09/26(日) 09:03:05なるほど、カプセル化を「物事の整理の仕方」と考えているのか。
何件か質問させてもらう。
>誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
「誰がどのメモリ領域いじってるのか」と「誰がどのメソッド（Setter）いじってるのか」での違いは？
構造化でもサブルーチン・ローカル変数など制限できるがオブジェクト指向と何が違う？
>「オブジェクト志向」がいったい何を志向しているのかといったら
>それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。
「オブジェクト志向」=「物事の整理の仕方」=「プセル化」と考えているようだが
それは概念か、それとも方法諭か 実装もかみしているのか？
>>414
>データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
>情報の隠蔽もなされるワケで。
その「特定の処理を通させる」は何の目的の為に行なうのか？、具体的に書いてくれ。
俺の考えでは「フィールドの情報隠蔽の為に、”特定の処理を通させ”るカプセル化を適用している」のよう考える。
「データと処理を一括りにすること」は手段だと考えるが、目的と考えているのか？そのメリットは？
まっ、メリットを書いてもらうとそれが目的だとなるが。
0443デフォルトの名無しさん
2010/09/26(日) 09:42:25このメソッドを呼ぶときは事前にあっちのメソッドが呼ばれてないといけないとか
誰それがこういう状態を構築してなきゃ、このメソッドは成功しないとか
引数にはこれを生成して渡さなきゃいけないとか
この変数はこいつもいじってるから勝手に触っちゃダメとか
そういう膨大な依存関係が出来上がるだろう
これは開発規模が大きくなれば指数関数的に複雑になっていく。
ドキュメントちゃんと書けば済むじゃんと言われればそうだが
こういう依存関係に依存したバグが一旦出てしまったら捜索は厄介になりがちだ。
もちろん天才なら構造化だけの整理手法でもかなり対応できるとおもう。
でも、コードをオブジェクト単位でまとめると、さらに関係が整理しやすくなる、と。
0444デフォルトの名無しさん
2010/09/26(日) 10:45:05ぼやけたイメージしか出てこないみたいだから
MVCのMの範囲とかで考えた方がいいよ
何のためにそんなことするのか
0445デフォルトの名無しさん
2010/09/26(日) 13:00:12そんな事したらもっとぼやけるっていう。
てかカプセル化って、モジュール化をもっと使いやすくしたものなんだけどな。
0446デフォルトの名無しさん
2010/09/26(日) 13:01:59俺はどちらかというと、「依存関係の整理を支援するために、OOP言語の機能がある」
という>>443の説明の方が説得的だな。>>436とは違う意味だが、何をするのかが
決まらなければ、最適な言語機能を論ずることもできない。
もちろん、これは歴史的にどうだったかとか、アラン・ケイの意見がどうかというのとは
別の話な。
0447デフォルトの名無しさん
2010/09/26(日) 13:13:56だからこそこのネタで盛り上ることができるわけだが
0448デフォルトの名無しさん
2010/09/26(日) 13:27:570449デフォルトの名無しさん
2010/09/26(日) 13:29:15正確な定義はなくても、目的はモジュール化なのは確実だから、まだマシだよね。
0450デフォルトの名無しさん
2010/09/26(日) 13:29:48データにメソッドをくっつけたもの派？(Booch,Thomas M. Connolly, Wm. Paul Rogers)
Encapsulation is not information hiding
ttp://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html?page=9
アクセス権派？(John C. Mitchell,Pierce, Benjamin)
メリット
どっかいじっても他の場所に影響がないか小さい領域にとどまる
よくわからない依存関係を、インタフェースなどに明示し、実装から分離
他にもAbstract Data TypeやModuleにも同様の考え方がある。
どのタイプも、数学的には存在型というコンセプトがベース
0451デフォルトの名無しさん
2010/09/26(日) 13:31:390452デフォルトの名無しさん
2010/09/26(日) 13:35:32でもこれはコンピュータサイエンスでの定義でOOPには限らないもののよう
the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior;
encapsulation serves to separate the contractual interface of an abstraction and its implementation.
0453デフォルトの名無しさん
2010/09/26(日) 13:39:010454デフォルトの名無しさん
2010/09/26(日) 13:52:010455デフォルトの名無しさん
2010/09/26(日) 14:09:04代わりにメソッドを用意し、内部的不整合な設定を起こさないようにするという理解。
例えば
・0〜2までが設定可能なときにそれ以外の値が渡されたときに回避または例外発生
・２つの内部状態が連動して変化する関係の場合にメソッドが整合性を保って処理する
みたいに
特に２番目がないと使う側が考えることが増える。
アクセス制限もコードを読む上で無視できる目印になる。
0456デフォルトの名無しさん
2010/09/26(日) 14:12:03■ このスレッドは過去ログ倉庫に格納されています