OOP 2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/11/10(水) 22:51:25OOPってよくわかんないよね
http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0268デフォルトの名無しさん
2010/11/23(火) 19:13:55構造体と関数だと手順になる。
260 >外からは初期化関数呼べば実装はどうあれ初期化できる
の「「外から」が手順になってしまう。
オブジェクトは作成時からデータが初期化されているから
いつでも「オブジェクト」ならメッセージパッシング出来ると思う。
0269デフォルトの名無しさん
2010/11/23(火) 19:15:070270デフォルトの名無しさん
2010/11/23(火) 19:18:50オブジェクト指向に出てくる言葉の中でこれが一番わからん。
単なる関数呼び出しとの違いはなんなの？
0271デフォルトの名無しさん
2010/11/23(火) 19:25:08意味が分からん
初期化関数というのは、コンストラクタと等価だぞ？
初期化関数を呼ぶ前はオブジェクトがなくて、関数がオブジェクトをこしらえて、
それを返す
fopen()を考えて欲しい
0272デフォルトの名無しさん
2010/11/23(火) 19:27:33Stack stack;
stack.push(x);
のように書く
Cのような言語では関数名の衝突を避けなければならないので、
通常もっと長い名前が必要になる
stack_t stack = create_stack();
stack_push(stack, x);
のような感じになるだろう
ここで典型的なclass指向のOO言語のclassが、少なくとも
適度な名前空間としての機能を果たしていることが分かる
表記の違いではあるが、名前の衝突を気にせず短く書けていいですね、というわけだ
0273272
2010/11/23(火) 19:28:47関数呼び出しについては、型のパターンマッチをコンパイラが行ってくれるので、
非OO的に記述する場合にも、長い名前を使う必要は無い、つまり
stack_t stack = create_stack();
push(stack, x);
のようなインタフェースであっても問題はない
「コンストラクタ関数」だけはパターンマッチは効かないが、
操作する関数については、どこかにある
void push(stack_t stack, int x);
のような関数を、コンパイラが探してくれるわけだ
push()という（短い）名前は勿論衝突するかもしれないが、
引数の型が違えば別の関数として扱われるので、問題は無い
よって、オーバーローディングを持つ静的型言語であれば、
クラスの提供する名前空間が実は必要が無いことがわかる
0274デフォルトの名無しさん
2010/11/23(火) 19:29:08望ましいモジュール化・抽象化の表現を推奨するのがOOPであって、
Cではできない革新的な何かを目指すものじゃないんじゃないかな
0275272
2010/11/23(火) 19:30:04「全ての引数について」ディスパッチが行われているという点では
レシーバのみに適用される動的ディスパッチ（C++系のOO言語で
言われるところの「ポリモーフィズム」）よりも優れているとさえ言える
このパターンマッチを実行時に拡張すれば、全ての引数についてのディスパッチが
可能であることは容易に理解できる
実行時型情報をサポートする言語であれば、特に実装上の問題も無いだろう
関数探索はハッシュテーブルのルックアップのような形を
取らざるを得ないだろうから、効率面ではvtblに劣ると考えられるが
特定の関数呼び出しにおいて実行時ディスパッチを行うかどうかを
何らかの方法で指定可能であれば、特に大きな問題は無いように思える
0276272
2010/11/23(火) 19:31:03俺はスレの住人ではないのでいい加減だがｗ
こんなもんで合ってるのかな
0277272
2010/11/23(火) 19:40:27C++のISA継承とvtblによる「ポリモーフィズム」とこの方法の違いは、
C++の「ポリモーフィズム」は探索に失敗することはない、すなわち
呼び出せる関数が存在することが保証されている点にある
この点について適切な解決策を出せないのなら、静的型言語でありながら、
動的型言語のように実行時エラーが連発するという結果に終わる
一方動的型言語ならどうかというと、その種の引数には型を指定しないのだから
この種の「引数型によるディスパッチ」がそもそも不適当になる
最後に、現状のC++流儀のOO言語が、IDE（主に補完機能）と非常に
相性が良いことは知っておく必要があるだろう（C++自身は別だが）
0278デフォルトの名無しさん
2010/11/23(火) 20:01:22コンストラクタはクラスの機能だから
「オブジェクト」間の呼び出しは手続きにはならないと思う。
OOPだとクラスとオブジェクトが分かれているけど
関数だとその区別がないから駄目だと思う。
0279デフォルトの名無しさん
2010/11/23(火) 20:19:58データの整合性を保っていろんなメッセージに対応できるようにしておくべき、って話ならわかる
モジュールの理想方針としては妥当だろう
でも「クラスとオブジェクトが分かれてるけど関数だと区別がないから駄目」云々ってのは
日本語として意味がよくわからん
0280デフォルトの名無しさん
2010/11/23(火) 20:33:47もはや何を言いたいのやらさっぱりわからんな、話がどんどん横道に逸れているし
だからカプセル化はCでも出来るんだってば
構造体と関数を使う場合であっても、
内部で使う構造体定義をヘッダに書いて外に見せなきゃいいだけ
そうすりゃ中身を弄りようがないから
構造体の定義は.cに書く、あるいは複数のソースで使うのなら、
internalな、外には見せないヘッダに記述する
fopen()だのCreateDIBitmap()だのと
コンストラクタによるオブジェクト生成で、本質的に何が違うと言うの、
同じだろ？
データの中身を見せないのなら、その一貫性も外に見せる関数によって
保てばよい、そこで考えればよいということになる
C++との本質的な違いはコンストラクタではなくて、
デストラクタを自動で呼び出してくれるかどうかと、
opaqueな（外には見せない）型の場合はオブジェクトをスタックに配置できない
ことぐらいだよ
0281デフォルトの名無しさん
2010/11/23(火) 20:47:18個人的には>>280寄りの意見。
OOPの考え方そのものは言語から切り離せるもので、
不完全だったりプログラマが気をつけることが増えるにせよ、
非OOPLでも実装は出来る。
ただ>>266とはちょっと違って、スタイルが似てるからって、
「オブジェクトたるか？」どうか考慮してないモジュールは
オブジェクトじゃないと思う。
0282デフォルトの名無しさん
2010/11/23(火) 21:31:27関数fopen()と関数fread()の場合は、
fread()呼び出し時にファイルオープン済みであることを保証できません。
fopen()を呼んでからfread()を呼ぶという手順を知っている必要があります。
メソッドfopen()とメソッドfread()の場合はコンストラクタ内でfopen()を呼べば、
メソッドfread()呼び出し時にファイルオープン済みである事を保証できます。
デストラクタ自動呼び出しでユーザのfclose()呼び出しが不要になるのは利点ですが、
コンストラクタ強制呼び出しでユーザのfopen()呼び出しが不要になるのもまた利点です。
0283デフォルトの名無しさん
2010/11/23(火) 21:40:28↑を言うやつは、アセンブラでやれ。何でも出来る。
0284デフォルトの名無しさん
2010/11/23(火) 21:44:010285デフォルトの名無しさん
2010/11/23(火) 21:47:41オブジェクトを扱っている時点でそのオブジェクトはデータの整合性が取れているのが分かる。
でも関数なら初期化前か後か分からないと言いたいだけなんだが。
>>280
>だからカプセル化はCでも出来るんだってば
カプセル化は出来ると思う。カプセル化自身がOOP特有の機能じゃないから。
もとの話は構造体と関数でOOっぽいスタイルと言う話だったから
カプセル化がOO特有だと思っていないから意識してなかった。
だから構造体と関数でオブジェクトに似ていると考えた場合の違いを書いている。
カプセル化の話だったのか！ すまない勘違いしていた。
0286デフォルトの名無しさん
2010/11/23(火) 21:51:23外に見せる用の構造体と、内部用の構造体を用意して、両者を同期するって言ってる？
0287デフォルトの名無しさん
2010/11/23(火) 21:59:58不完全な構造体宣言だけ書いて全部ポインタ経由で操作するってことじゃね
スタック変数とかは作れないけど、
必ずhoge* hoge_create()みたいな関数経由でオブジェクトを作らせれば初期化前の状態は見えない
0288デフォルトの名無しさん
2010/11/23(火) 22:01:38さらに、それを効率よくコードに落とす手段がOOP及びOOPLだ、という簡単な話が何故ここまでこじれるのか。
0289デフォルトの名無しさん
2010/11/23(火) 22:01:57逆に、俺はCLOSのようなマルチメソッドの世界は、
総称プログラミングであってオブジェクト指向ではないと思う。
stream.write(text);と書けば、streamとtextは対等ではなく、streamが主語、textが動詞に見えてくる。
そして、概念的にはstreamは別プロセスで動いていたりしてもかまわない。
そういうのが狭義のオブジェクト指向だと思う。
0290デフォルトの名無しさん
2010/11/23(火) 22:03:30> 不完全な構造体宣言だけ書いて全部ポインタ経由で操作するってことじゃね
C言語ってそんなことできるんだっけ？
どっちみち、そこまでするなら素直にOOPL使えばいいじゃん、という話ではあるが。
0291デフォルトの名無しさん
2010/11/23(火) 22:06:280292デフォルトの名無しさん
2010/11/23(火) 22:07:49出来るに決まっているだろう
不完全型が扱えないのなら、
struct node {
struct node *next;
};
もコンパイルが出来ない
というのはさておき、別にvoid*でもいいんだよ、外に見せるのは
0293デフォルトの名無しさん
2010/11/23(火) 22:08:400294デフォルトの名無しさん
2010/11/23(火) 22:09:44どうやるのかコード例見せて。
0295デフォルトの名無しさん
2010/11/23(火) 22:10:25コンストラクタ関数であるfopen()を呼ばずにそれを使うということは、
コンストラクトしていないオブジェクトに何かしようとしているのと同じだ
C++で言えば、
istream *stream;
stream->read();
とか書くようなもんだ
こう書けるし、コンパイルは通るぞ？
C++でも
0296デフォルトの名無しさん
2010/11/23(火) 22:13:49初期化してない変数（≠インスタンス）のメンバ関数を呼ぶのは単純にバグと言いませんか。
0297デフォルトの名無しさん
2010/11/23(火) 22:15:12FILE*オブジェクトが得られていないのに、それを使った操作を行おうとするのも
単純にバグだろ
0298デフォルトの名無しさん
2010/11/23(火) 22:16:34これが分からない奴がこんだけいるというのがもう凄いな
オープンソースの世界はLinuxのカーネルと言わんでもCのコードだらけだが
ちらっとでも読んだことも無い奴がこんなにいるのか
0299デフォルトの名無しさん
2010/11/23(火) 22:19:300300デフォルトの名無しさん
2010/11/23(火) 22:27:05または、まだ広まっていない時代だから。非OOPでいろいろなノウハウが当然ある。
そのノウハウで、今もCで書けと言うのか？ 好きにしろ、俺はやらん。
0301デフォルトの名無しさん
2010/11/23(火) 22:30:07腹の中で「OOPL使わせろよ…」って思ってるんだから
struct hoge_;
typedef struct hoge_ *hoge;
hoge *hoge_create(void);
void hoge_hello(hoge*, FILE*);
void hoge_destroy(hoge*);
0302デフォルトの名無しさん
2010/11/23(火) 22:43:50そうそう
でもイディオムだのノウハウだのというが、C++も一緒だよ
>>301のやりかたではhogeモジュールが実際に扱っているデータ構造が
完全に外に見えないから、データ構造の変更に強い
それをdata abstractionと言う
C++で同等のものが欲しければ、普通に書いていてはダメで
pimplのようなイディオムが結局は必要になる
それでもコンパイラを越えたABI互換性がひどく脆弱で無いに等しいのが
C++だけれども
0303デフォルトの名無しさん
2010/11/23(火) 22:50:13PythonやRubyのような現在のオブジェクト指向スクリプト言語の
インタプリタもたいがいはCで書かれてるんだぞ
0304デフォルトの名無しさん
2010/11/23(火) 22:51:07ヘッダに書くのは構造体の定義じゃなくて宣言と違うか？
とりあえず>>301には定義は出て来てない。
0305デフォルトの名無しさん
2010/11/23(火) 22:52:30誰へのレス？
0306デフォルトの名無しさん
2010/11/23(火) 23:02:36あー、理解した。
しかし、「OOPLでやれよ」だな。
>>300
カーネルみたいな速度が最重要な世界では、C言語の出番はある。
ただ、全てのプログラムで速度が最重要ではなく、
むしろ可読性や柔軟性の方が重要な場面の方が多い、というだけの話だな。
0307デフォルトの名無しさん
2010/11/23(火) 23:05:15>>298
0308デフォルトの名無しさん
2010/11/23(火) 23:11:05もしかして>>301が出した親切な例の意味が分かってない？
>>301においては、struct hoge_の型の定義が書かれていないので、
「不完全型」になっている
Cでは不完全型のポインタを扱うことは出来るので、型の定義を知らなくとも
上の3つの関数を扱う分には何も問題はなく、コンパイルは通る
勿論内容が分からないからメンバにアクセスはできない
struct hoge_型の変数を普通にスタック上に配置することもできない（サイズが
不明だから）
よって、このインタフェースを提供している実装側は、実際にはその
ポインタが指す構造体の定義を、外に見せない形で別に持っているわけだ
0309308
2010/11/23(火) 23:14:35複数のソース(.c)から参照する必要がある場合は、それは当然ヘッダに置かれるのが
普通だ
が、ユーザにも見えるヘッダに定義を書いた場合には、ユーザにデータが
見えてしまうことになる
(stdioのFILEはそうだ）
>>301の例では、ユーザに見えるヘッダには定義は書かないことで
データを隠蔽しているわけだ
0310デフォルトの名無しさん
2010/11/23(火) 23:42:40>内部で使う構造体定義をヘッダに書いて外に見せなきゃいいだけ
の意味が分からんかっただけ。
ちなみに今も分かってない。
まぁ別にどうでもよさげだな。
0311デフォルトの名無しさん
2010/11/24(水) 00:03:13正：(ヘッダに書いて外に見せる) をしない
誤：(ヘッダに書く) をして (外に見せない)
0312デフォルトの名無しさん
2010/11/24(水) 00:27:01俺の名作文>>267が流れるじゃねーか。
マルチメソッドはOOP的じゃないって言ってる人が居たが、俺もそう思う。
単一のクラスやオブジェクトにメソッドがぶら下がらない時点で、
オブジェクト中心って感じじゃないもんな。単なる型スイッチだもん。
マルチメソッドはハッシュ引くことになるとか意見があったが、
そうしなくて済むコード例は前上げたよな。コンパイラががんばればいいよ。
そんでも、デストラクタぐらいは有ってもいいと思うぜ。
いちいちrelease_hogeするの面倒だしな。
コンストラクタは要らないな。
暗黙の型変換とかの話が出てくるし。
これはオーバーロードと相性が悪いんだよ。
そこはC++はミスったね。案の定変な予約語で誤魔化したし。
コンストラクタは普通の関数でも問題ない。init_hogeとかでいいよな。
あと、関数のスタイルは何をどの順に呼び出していいかわからないって池沼が居たけど、
それ、OOPでも一緒だろ。なんせ、手続き型言語なんだからなw
こんなアホの相手してやるお前ら親切だな。俺は無視だぜ。
0313デフォルトの名無しさん
2010/11/24(水) 00:40:48関数型や論理型のようなパラダイムを知らず、OOに幻想を抱いているタイプの
人なんだろう
まだいたのねって感じはするけど
0314デフォルトの名無しさん
2010/11/24(水) 01:19:04関数型は副作用がなくて機能が関数で完結するからいいんだよ。
なんでいまさら手続き型の機能単位をデカくしようとするのか教えてくれ。
一人で小規模に作るんなら書き散らせる方が便利だろうが、
仕事でやるには堅く書けるのが大事なんだ。
結合で出る問題を減らすにはモジュールがきっちり分かれてる必要があるの。
なんでいまさらそんなサポートの少ないショボい言語が要るの？
OOPにゃこだわりはないけど、プログラムの機能を分割する機能をよこせ。
0315デフォルトの名無しさん
2010/11/24(水) 01:19:42> 関数のスタイルは何をどの順に呼び出していいかわからない
× 分からない
○ 制約を付けられない
0316デフォルトの名無しさん
2010/11/24(水) 01:23:34完全同意。
> 関数型は副作用がなくて機能が関数で完結するからいいんだよ。
つまり、副作用がある前提で書くなら、機能の整理を支援する何らかの仕組みが必要なわけだね。
そして、その方法のうちの一つがOOパラダイム。ここテストに出るよー。
0317デフォルトの名無しさん
2010/11/24(水) 02:33:14何言ってるのかちょっと解らないんだけど、
カプセル化の話なら、マルチメソッドでも出来るぞ。もちろんCでも。
void func( obj1_t *obj1, obj2_t *obj2 )
{
set_value( obj2, get_value( obj1 ) );
}
ほら、何の問題も無いだろ？
0318デフォルトの名無しさん
2010/11/24(水) 02:45:24マルチメソッドだと、この二つの引数の型を元に、funcの呼び出し先を型switchすることさえも出来るってだけなんだが。
C++やJavaの単一ディスパッチみたく、第一引数のみに基づいて型switch可能って、なにやら変だろ？
何で第一引数だけ特別なのかと。
C++にしろJavaにしろ、オーバーロードは全ての引数の型に基づいて決定されるのにな！
動的多態は第一引数の型のみってのは変だろ？
そんなに第一引数のみでやるのが便利なんだったら、オーバーロードも第一引数に基づいてのみ決定する仕様にすりゃいいのに。
まー不便だわな。
今現在、単一ディスパッチが主流なのは、単に、実行コストとコンパイラの実装コストが高いから。
基底クラス使って多態するのも同様の理由。
ただそれだけ。利便性とかは関係ないのさ。
まー当時はメモリもCPU時間も貴重だったからな。
今だったら、マルチメソッド+ダックタイピングが良いわな。
あとはどう速く実行するか。ハッシュとかは嫌だからね。
0319デフォルトの名無しさん
2010/11/24(水) 02:56:10第一引数でのみ多態するってことは、メソッドは第一引数に依存するから、
メソッドそのものが第一引数ありきになちゃって、やがては、第一引数中心で考える、
所謂オブジェクト指向になっちゃったんだ。
とにかく、C++やJavaでは、そういう第一引数志向なコードしか走らないんだから、
そういう風に書くしかないので、そういう風に物事を考える癖がついて、OO脳になる訳だな。
これは恐ろしいことだね。
日本語もその毛色があるね。
目的語の後に述語がくる並びだから、物を大事にする文化が育った。
というか、元々物を大切にする気質だったから、目的語→述語の並びになったのかもしれんが。卵と鶏だな。
英語なんかは逆だよね。だから機能主義。わかりやすいよねー。
0320デフォルトの名無しさん
2010/11/24(水) 04:35:50オブジェクトが能動的なのが良くて受動的なら関数呼び出しと同じだから悪いなんて
考え方自体おかしい。各オブジェクトが勝手に判断して能動的に動かれたりいたら
ますます何やってるかわからなくなる。
各オブジェクトの動作まで完璧に把握してないと危なくて使えない。
各オブジェクトが勝手に動き回った結果、相互作用で生じた不具合なんて想像すらできない。
そんなのデバッグすんの無理だから。
0321デフォルトの名無しさん
2010/11/24(水) 04:51:27人それぞれ解釈のしかたによっていろんな書き方ができる。いろんなレベルで書ける。
C++ならCと同じようにも書けるし、混在した形にも書ける。C++の機能だけをフル活用した書き方もできる。
自分が納得したレベルで、自分が書きやすい形で書いてればいいんだろうな。
いろいろ書いてれば、そのうち経験値が上がっていって自然にコーディングレベルも上がってくるんだろうと思った。
0322デフォルトの名無しさん
2010/11/24(水) 06:33:350323デフォルトの名無しさん
2010/11/24(水) 08:12:21機能単位を「安全に」外部へ公開するための手段がインタフェース。
そして、機能分割を適切に行うための手法がオブジェクト指向分析／設計であり、
それをコードに落とすときに、インタフェース等の枠組みを使って適切に制約を
加えながらプログラミングするスタイルがオブジェクト指向プログラミングであり、
それを容易に行えるようにプログラマを支援する仕組みを持った言語が、オブジェクト指向言語。
0324デフォルトの名無しさん
2010/11/24(水) 08:18:31その結果として辿り着くのはオブジェクト指向ではないかもしれないが、
少なくとも、Itsumono言語でないのは確かだな。
モジュールを肥大化させる方向性は明白に誤りであり、経験値がある人間がまず避けるやり方。
0325デフォルトの名無しさん
2010/11/24(水) 10:10:23間違えてないと思うけど、ちょい言い過ぎ。
クラスベースの話だろ。
0326デフォルトの名無しさん
2010/11/24(水) 14:10:42メソッドでないメッセージはあり得るのですか？
0327デフォルトの名無しさん
2010/11/24(水) 14:15:34オブジェクト指向のオブジェクトが「能動的だ」とか言ってる奴に
つっこんでるだけで、誰も能動的でないのが悪いとは言っていないよ
まあ、お前がErlangのような言語やπ計算のようなモデルについて
全く無知なのはよくわかった
自己紹介乙
>>326
アクターモデル
0328デフォルトの名無しさん
2010/11/24(水) 19:44:56プロトタイプベースはよく分かんないけど、「クラスベースほどの厳しい制約は必要ない」
という立場なのかな、と今思った。
0329デフォルトの名無しさん
2010/11/24(水) 19:51:11Software is Beautiful：第4回 オブジェクト指向の本質
http://gihyo.jp/lifestyle/serial/01/software_is_beautiful/0004
0330デフォルトの名無しさん
2010/11/24(水) 20:19:32タイトルはそのものズバリなんだが
なんか内容薄いね、この記事
0331デフォルトの名無しさん
2010/11/24(水) 20:24:23いやだから、設計論は何でも適用できるから、OOPとは区別しないと。
OOは設計論かもしれないけどな。
0332デフォルトの名無しさん
2010/11/24(水) 20:57:33OOD無くしてOOP無し
0333デフォルトの名無しさん
2010/11/24(水) 21:14:12だから、デザイン（設計）だったらOOもOODでなくてもいいだろ。
と言われて終わりだろ。普通のデザインとOODの違いを明確にいえるのか？
0334デフォルトの名無しさん
2010/11/24(水) 21:18:27プロトタイプベースやメッセージングにマッチするOODの手法って
見たことないけど例えば何がある？
さしあたりクラス図が出てこない手法を教えて欲しい。
0335デフォルトの名無しさん
2010/11/24(水) 22:25:30そもそも普通のデザインとは？
0336デフォルトの名無しさん
2010/11/24(水) 22:52:161. モデルを定義する数式をでっちあげる
2. 数式が解を持つことを証明する(特殊解でも可)
3. 数式の各項を分解する
4. 分解した各項に対して 2, 3 を適用する
5. 十分小さな単位まで分解できたら, 使用する言語のシンタックスに置き換える
0337デフォルトの名無しさん
2010/11/25(木) 00:11:14それは何の魔術の儀式？
0338デフォルトの名無しさん
2010/11/25(木) 02:44:140339デフォルトの名無しさん
2010/11/25(木) 06:28:260340デフォルトの名無しさん
2010/11/25(木) 08:06:41どの要素技術がオブジェクト指向的か、なんて議論にはほとんど意味はない。
記事にもあるように、オブジェクト指向の代表的な要素技術と看做されている「継承」が、
最近は「不必要に用いるべきでない」とされるのも、「疎結合」を目指す、という方向性とズレるから。
0341デフォルトの名無しさん
2010/11/25(木) 08:34:170342デフォルトの名無しさん
2010/11/25(木) 08:46:26>>329 の記事を読むと1970年代のモジュラープログラミングとどこが違うの？という
疑問が生まれるな。マイヤーズ/国友らの著作。彼らは「〜を〜する」の『機能主義』
だとは思うけれど。
0343282
2010/11/25(木) 10:02:41>あと、関数のスタイルは何をどの順に呼び出していいかわからないって池沼が居たけど、
>それ、OOPでも一緒だろ。なんせ、手続き型言語なんだからなw
>こんなアホの相手してやるお前ら親切だな。俺は無視だぜ。
コンストラクタの目的という基本的な事を説明した人達は全員池沼でアホですか？
>>315を具体的に説明しているのをあなたが理解できなかっただけですよ。
0344デフォルトの名無しさん
2010/11/25(木) 10:03:07構造化プログラミングもモジューラプログラミングもオブジェクト指向も
目的は大規模なプログラムを作る事で、方法が違うだけです。
>>329の記事は目的の話しかしてないのだから区別できないのは当然でしょう。
「目指すもの、という意味では>>329でFA」に同意します。
0345デフォルトの名無しさん
2010/11/25(木) 10:05:000346デフォルトの名無しさん
2010/11/25(木) 10:19:59「オブジェクト指向の本質」というタイトルと内容が一致していないのは確かですね。
このタイトルからはこれがあればオブジェクト指向だという内容を期待しますが、
実際には「本質」でなく大前提である「目的」しか書かれてないですから。
0347デフォルトの名無しさん
2010/11/25(木) 10:30:39いや目指すものはその通りだろ。
「OOとは、の記事」としてOOの特色が取り上げられてないないから
表題に対して内容が薄っぺらいだけで、
OOPの実利的な面は、結合度と凝集度の延長線上にある。
0348デフォルトの名無しさん
2010/11/25(木) 11:44:45コンストラクタが何か特別で素晴らしいものだと思ってるのは
残念ながらお前だけじゃね？
Stroustrupは何かそれを素晴らしいものだとして宣伝したかもしれないが、
より高い抽象度から見れば、それはただの生成「関数」と同じ物なんだよ
Lispのconsはコンストラクタの略でもある
CLOSやJavaScriptなど、世の中には色んなオブジェクトシステムがあり
関数型のクロージャは概ねオブジェクトと等価だ
抽象化の方法論も色々なんだから、もっと視野を広げるこった
C++の系統の言語でも、オブジェクト生成をより抽象化したければ
ファクトリ「関数」を用いることになるしな
0349デフォルトの名無しさん
2010/11/25(木) 11:56:02open/close principleとかを念頭に言ってるんだと思うが
少なくともC++に関して言えば、それを非常に重視しているようには見えないな
たとえprivateメンバであっても追加や変更を行えば、それを使用してる側に
影響を与えてしまう
脆弱なスーパークラス問題って奴な
勿論それを解決する方法はあるが、Cと一緒で、要は言語レベルでは問題は
何も解決されていないわけだ
Javaの系統も同様で、インタフェース、ファクトリ、実装クラス、を
「自分で」作って分離しなければ結合性を弱められない仕組みになっている
0350デフォルトの名無しさん
2010/11/25(木) 14:28:06どちらも相手の意見を最初の文で捏造してから架空の意見に反論しています。
ストローマン
http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%88%E3%83%AD%E3%83%BC%E3%83%9E%E3%83%B3
>ストローマン（英語:straw-man）は、
>議論において対抗する者の意見を正しく引用しなかったり、
>歪められた内容に基づいて反論するという誤った論法、
>あるいはその歪められた架空の意見そのものを指す。
>藁人形論法ともいう。
0351デフォルトの名無しさん
2010/11/25(木) 20:18:50OOPLはオブジェクト指向開発を容易に実現するための道具に過ぎないんだから、
言語処理系のレベルで全てが提供されている必要はないと思うが。。
道具は組み合わせたっていいんだよ。むしろその方が拡張性は上がる。
0352デフォルトの名無しさん
2010/11/25(木) 20:42:34私は>>349ではないけれど、プログラミング言語を道具という感覚には
ついて行けない。言葉と思考は一体のものだな。先行して「目的」が
あるというところが何かあやしい。
0353デフォルトの名無しさん
2010/11/25(木) 20:52:52道具云々はともかく、目的もなく作業したって意味がないじゃない。
0354デフォルトの名無しさん
2010/11/25(木) 21:03:11疑問に思った事は
「OOPではスパゲティコードで作らないことが必須」なのか？
もちろんスパゲティコードにしない方がいいが
OOPにはそんな制約はないし
メソッドのコードをスパゲティコードで作ってもOOPは実現出来る。
OOPを誤解している人の多くは、いままでの経験上の延長線で
OOPを考えている人が多いと思う。
（情報隠蔽（カプセル化）こそがOOPだと主張する人とか）
OOPは構造化とは別次元の考えでパラダイムシフトだと思うけど。
0355デフォルトの名無しさん
2010/11/25(木) 21:10:30すまん、もう少し主張を整理してもらえる？
0356デフォルトの名無しさん
2010/11/25(木) 21:26:390357デフォルトの名無しさん
2010/11/25(木) 21:34:54「コード間の依存関係」が高まることの結果として生まれるのが、
メンテナンス不能のコード、即ち「スパゲッティコード」であり、それを防ぐには、
依存関係の低い状態である「疎結合」を保たなければならない。
オブジェクト指向の様々なコンセプトは、その意味では特別なものではないし、
逆に、それらのコンセプトの裏にある「本質」を無視して書かれたプログラムは、
たとえオブジェクト指向言語で書いたとしてスパゲッティになる。
という内容でしょ、あの記事は。
0358デフォルトの名無しさん
2010/11/25(木) 21:48:29特別な意味じゃないのは「疎結合」という目的のほうだろ
0359デフォルトの名無しさん
2010/11/25(木) 21:55:13フィールドへのアクセスは、かならずアクセサを通す。
引数に取るのは、intやdoubleなどの基本型のみ。
この二つを守れば、どうやったって疎結合になるよ。
OOPだからどうだってんじゃ無くて、C言語レベルの話でしょ。
0360デフォルトの名無しさん
2010/11/25(木) 21:57:08また、どんな言語を使おうが機能的・データ的に「祖結合」が有用なのは
変わらないわけで。
それを用いてOOPの何たるかを語る事自体が意味がない。
結局の所一時期のOOブームで、まるで銀の弾丸のように説明して
分野を広げすぎた事にOOの問題を感じる。
OOPLによる、OOPはいいものだけどな。
0361デフォルトの名無しさん
2010/11/25(木) 21:58:15分かり難いか、すまない。
簡単に書くと、「メソッドでGOTO文を使っても良い」ということ。
構造化では禁止されているけどOOPではそんな制約はないし
GOTO文を使ってもOOPは実現出来る。
そもそもGOTO文を「使う使わない」とかとは観点が違うと思う。
0362デフォルトの名無しさん
2010/11/25(木) 21:59:38いや、クラスで囲ったとしても、機能的に簡単にスパゲッティはできる。
0363デフォルトの名無しさん
2010/11/25(木) 22:06:49相手のフィールドの存在を意識しなければならないというのは密結合の度合いが強めな証拠
0364デフォルトの名無しさん
2010/11/25(木) 22:15:26だから、ここで最初の結論に戻る。
「オブジェクト指向設計無くしてオブジェクト指向プログラミング無し」
オブジェクト指向言語という有用な道具を生かすには、相応の設計が必要だってこと。
0365デフォルトの名無しさん
2010/11/25(木) 22:21:18フィールドなのかメソッド(アクセサ)なのかコードを見ただけだとパッと見はわからない
しかしIntellisense使うときにでるアイコンでばれる。残念
0366デフォルトの名無しさん
2010/11/25(木) 22:26:18「コード間の依存関係」を整理する、という目的に対して、
オブジェクト指向がどんなメリットを提供しているかを考えるべきだろう。
少なくとも、言語の文法レベルの話をしてもあまり意味がないだろう、というのが俺の意見。
例えば、オブジェクト指向に、なぜ依存性注入(DI)のような手法が登場したかを説明できない。
私見では、疎結合に保ちたい状態の操作を、オブジェクトの提供する「サービス」として
見せるあたりがキモだと思うけど。
0367デフォルトの名無しさん
2010/11/26(金) 03:05:04疎とか密とかは方針としてわからなくはないけど、実際のプログラム開発では気にしない。
たとえばよくあるWebプログラムで言うと、サーバーサイドスクリプトをA、データベースをBオブジェクトを作り、
相互に必要なメッセージをやりとりして、結果をクライアントに応答するように書くけど、
A,B間でメッセージのやりとりをする部分をわざわざ疎にしようとか密にしようとかは考えない。
なぜならどういう機能をどれだけ盛り込むかは要求仕様で決まるから。
疎にするために機能を削るというのは非現実的。何しろお客の要求なんだから。
A,B間で連携して処理する作業が多ければA,B間の関係は自然に密になってしまう。
これが良くないからと言って疎にできるんだろうか？
無理じゃね？
■ このスレッドは過去ログ倉庫に格納されています