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

オブジェクト指向は戦場では必要なし⑧

レス数が1000を超えています。これ以上書き込みはできません。
0001あたたたたNGNG
　オブジェクト指向はより自然なモデルに即したものではあるが、
クラスを理解する労力が大きく、目的まで達成するのに時間がかか
る。他人のソースを見るにも複雑でときほぐしにくい。ちゃんと
整備されたドキュメントがなければ粗大ゴミソース。またオブジェ
クト指向が○○に優れているとかいう話も、あくまでちゃんと設計
され、ちゃんと実装されたクラスがあるという前提での話。実際は
世の中にはそれほど有能なSEやPGなどいません。
　よってオブジェクト指向は戦場では使いものになりません。

前前前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/
前前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013266554/
前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013875413/
前前前前スレ http://pc3.2ch.net/test/read.cgi/tech/1021468476/
前前前スレ http://pc3.2ch.net/test/read.cgi/tech/1027983898/
前前スレ http://pc3.2ch.net/test/read.cgi/tech/1029297075/
前スレ http://pc3.2ch.net/test/read.cgi/tech/1030029357/

　オブジェクト指向が誕生して30年以上の年月が経ちますが、
未だにオブジェクト指向は広く使われていません。それはオブジェクト
指向開発が理想を追っているだけの机上の空論に過ぎないからです。
　ある10年前のオブジェクト指向の本には、オブジェクト指向は
今後爆発的に普及してゆくだろうということが書かれていましたが、
結果は言うまでもなく無残なものです。おそらくきっとあと10年経っても状況
は大きく変わることは無いでしょう。相変わらず構造化言語は便利なのでこれ
からも半永久的にに使われてゆき、また開発効率が高い新しいツールや
開発方法が登場して複雑なオブジェクト指向は消えてゆくでしょう。
　オブジェクト指向よ、さようなら。
0002デフォルトの名無しさんNGNG
>>1
いい加減にしろ!
0003デフォルトの名無しさんNGNG
構造化でもデザパタみたいなことはできるしね。
0004>>3NGNG
>>3
0005デフォルトの名無しさんNGNG
OOは便利だが、
「OO厨は戦場では必要ない」に１票
あいつらはプログラムを知らない新人以上に邪魔
0006デフォルトの名無しさんNGNG
とりあえず, スレタイに機種依存文字使うなよ, と. そんな奴にOOがどうのこうのと言われたくない.
0007海坊主NGNG
>>6
ﾌﾟ
0008デフォルトの名無しさんNGNG
>>6
>1はプログラマじゃないもん。
0009デフォルトの名無しさんNGNG
じゃ結論出すよ。

OOは最高。

*** the end ***
0010デフォルトの名無しさんNGNG
そんなに急いで結論を出す必要はない。

*** reopening ***
0011デフォルトの名無しさんNGNG
>>10
転送量の無駄。
お前みたいなｳﾞｧｰｶのお陰で閉鎖しかけた。
首吊れカス。
0012デフォルトの名無しさんNGNG
OOは便利だが
「OOは最高。」
などとRuby厨と変わらんことを言う奴も邪魔。
戦場どころか人として必要なし
0013デフォルトの名無しさんNGNG
>>11
転送量だって(藁
0014デフォルトの名無しさんNGNG
> 転送量の無駄。
オマエモナー
0015学生NGNG
このスレッド凄い。。。さすがですね。。。
2チャンネルってこんなに低レベルだったのか
0016デフォルトの名無しさんNGNG
>>15
ここは低レベルなやつを隔離するための場所だからだよ。
おかげで他のスレはちょっとはマシになる.
0017デフォルトの名無しさんNGNG
>>15
> 2チャンネルってこんなに低レベルだったのか
ハイレベルだと思ってたのか？
0018デフォルトの名無しさんNGNG
Ａ君、必死だな。
0019デフォルトの名無しさんNGNG
OO厨にもアンチを納得させられる
ほどの奴がいないという罠。
0020デフォルトの名無しさんNGNG
よくわからないのあげ
0021デフォルトの名無しさんNGNG
public static void main(String [] hoge);
0022デフォルトの名無しさんNGNG
逝ってよしの>>1は、戦場で逝ってﾖｼ
0023デフォルトの名無しさんNGNG
ポリモーフィズムって結局呼び出し部分を一緒の名前に
してるだけじゃん。
0024デフォルトの名無しさんNGNG
しまったsage
0025デフォルトの名無しさんNGNG
>>23
つか、OOそのものって別に小難しいもんじゃないよ。
わかっちまえば楽だよ。
0026デフォルトの名無しさんNGNG
オブジェクト指向自体は糞だろ。
多重継承しようが、クラスフラッドかまそうが、
オブジェクト指向はオブジェクト指向だ。
だから、糞。
オブジェクト指向だけではあまりにも欠点が多すぎるので、
デザパタとやらを持ち出して来るんだろう？違うか？OO厨さんよ。
0027デフォルトの名無しさんNGNG
オブジェクト指向がどーたら言う奴は消防。
0028デフォルトの名無しさんNGNG
OOはデザパタつかっても他人に伝えることが難しいし、
そのためのドキュメントもそろえないとダメだし、
そんな体制で凌いでも無駄だと思う。
0029デフォルトの名無しさんNGNG
「そんな体制」てのが、ｻﾊﾟｰﾘ見えませんが、何指して言ってるの？
0030デフォルトの名無しさんNGNG
>>29
OO厨に具体的なことを突っ込まないように（ｗ
0031デフォルトの名無しさんNGNG
>>1 って結局、専門用語小耳に挟んで業界人気取る痛い厨じゃん
0032デフォルトの名無しさんNGNG
まだやってんの？
0033デフォルトの名無しさんNGNG
>>23
それがなんの役に立つのか見当がつかないなら、それはアンタの
脳みそに知識が足りないからです(ﾜﾗ
0034デフォルトの名無しさんNGNG
今日はサンドバッグ>>1さん、現れないのかな(ﾄﾞｷﾄﾞｷ
0035デフォルトの名無しさんNGNG
>>33
機能追加したときに変える場所が少なくてすむからですか？？
先に考えとけよ。
0036デフォルトの名無しさんNGNG
>>35
アホが自供しました（ﾜﾗ
0037デフォルトの名無しさんNGNG
>>36
おまえはｱﾎ
0038デフォルトの名無しさんNGNG
久しぶりに、真性厨房のなんのひねりもない情報量0ツッコミをみました。
頭が悪いんだから、ヘンにプライド持ってても不幸だよ。人格改造したほ
うが君の為ですよ（ﾜﾗ
0039デフォルトの名無しさんNGNG
まーだやっていたーのかー
0040逝って良しの１NGNG
スレの雰囲気がどんどん変わるなあ・・・張るか。

　　　　　　☆
　. ∧∧　　/　：。
　 (*ﾟーﾟ)　ρ　 ‥
σ(　　 )　　　　・` 。・ ； ’ 、∴ ﾟ ，・・` 。・ ： ’ ∵、‘｡‥ ﾟ ，・・` 。∴ ､’．
　 υυ　　　　　、’　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・ﾟ
　　　　　　　　　 ・　　　　　　オブジェクト指向厨って不思議！！　　　　 ‘．
　　　　　　　　　。：　　　　　作：ファンシー乙女　　　　　　　　　　　　　　　 ；
　　　 　 　 　 　 …　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　`。
　　　　　　　　　 ；　　ＯＯ厨って不思議！能も無いのにいばってばかり 。 ‘
　　　　　　　　　∵　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　‘．
　　　　　　　　　 ･ 　　その自信は何を拠り所にしてるのかしら？ 　 ,‘．
　　　　　　　　　`。　　　　　　　　　　　　　　　　　　　　　　　　　　　　 。
　　　　　　　　　‘． ＯＯ厨って不思議！説明せずにけなしてばかり。　‘．
　　　　　　　　　。：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ；
　　　　　　　　　…　　その妄言の発想はどこから来るのかしら？　　　 `。
　　　　　　　　　｀ ;　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾟ ・
　　　　　　　　　｀ ;　　再利用、フレームワークと壊れたラジオのようね　　 ：・
　　　　　　　　　 ’。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ‥
　　　　　　　　　 ‘・∴ 。’∵ 、 ; ｡…． ・ ” ，・` 。・ ； ’ 、∴

0041デフォルトの名無しさんNGNG
結局、安置OO厨が能無しだから、スレの雰囲気悪くなってるんでしょ(ﾆﾔﾆﾔ
0042デフォルトの名無しさんNGNG
>>41
（　´,_ゝ`） ﾌﾟｯ
0043デフォルトの名無しさんNGNG
川俣晶が言ってたことは漏れ的には同意できる。
struct aclass{
char* id_;
int value_;

char* id() { return id_; }
int value() { return value_; }
};
で下のような関数は要らないって奴。id_とvalue_を外からは代入せずに
読むだけと決めておけばaclass内部で実装変更があってから初めて
char* id(), int value()を書けばいい。修正個所はコンパイラが検出してくれる。

再利用しないコードでOOする理由は保守性ってことになるが
上のような例やデザパタにあるような複雑な仕組み
を入れたりすると調整や辻褄合わせでコードが巨大になってしまい
余計に保守性が下がる気がするのは漏れだけだろうか？
0044デフォルトの名無しさんNGNG
川俣晶ﾀﾝって誰？
んで、>>43が問題にしてるのは、
人間がアクセサ (get*(),set*(value)とか、上の例のid(),value())
書く事による保守性の低下？

AspectJの人は、
「アクセサ・メソッドをいちいち書かなけりゃならないのって、
　コンピュータやコンパイラーが低性能/低機能だった時代の名残」
って逝ってたっけ。


0045デフォルトの名無しさんNGNG
struct?
0046デフォルトの名無しさんNGNG
>>45
struct {...}＝class {public: ...}
0047デフォルトの名無しさんNGNG
>>46
言語は何？
少なくともCやC++じゃないし。
004847NGNG
おっと、C++だ。
C++って構造体に関数を定義できるんだったな・・・
0049デフォルトの名無しさんNGNG
>>45 >>47
あまり使われないﾊﾞｯﾁｲ文法らしいことがﾜｶﾀﾖ
0050デフォルトの名無しさんNGNG
>>49
Cではよく使うんだけどね(^_^;)
classのあるC++で構造体使う人いるのかな？既存のものは別として、新しく自分で定義するってこと。
0051デフォルトの名無しさんNGNG
つーか・・・・
あんたら何にも知らずに議論してるんだな・・・
0052デフォルトの名無しさんNGNG
>>51
つーか・・・・
あんた何の目的も持たずに非難しているんだな・・・
005346NGNG
いちおう補足。

俺がC++を勉強していた頃の知識によると：
・Cの構造体の概念は、C++ではクラスの概念に吸収された。
・structによるクラス定義では、デフォルトでメンバにpublic属性がつく。
・classによるクラス定義では、デフォルトでメンバにprivate属性がつく。

その後Javaに移行しちゃったので、新しい標準でどうにかなってても知らないYO
0054デフォルトの名無しさんNGNG
かなり昔からこの手の類のスレ有るけど、


オブジェクト指向『開発』『分析』『設計』はまだまだ未発達だが
「オブジェクト指向『言語』は成功している」


この事実を無視した発言が多すぎる気がするのだ
言語うんぬんの論争は無意味だ。
0055デフォルトの名無しさんNGNG
> 「オブジェクト指向『言語』は成功している」
成功って何？
普及していること？使いやすいこと？信者を洗脳しやすいこと？
0056デフォルトの名無しさんNGNG
＞54　
　わけわからん
0057デフォルトの名無しさんNGNG
>>54ではないが。

OOPLはいっぱいあるが、
設計に関していえば、デザパタを入れていいのかわからんけども、
やっと出てきたところでしょうが。
UMLだってようやく普及してきたのかなぁというぐらいのもんだろう？
あぁん？
0058デフォルトの名無しさんNGNG
>>55-56
むしろ、おまえらがわけわからん
とりあえずゲーデル嫁。
0059デフォルトの名無しさんNGNG
OO厨は知ってる単語しか並べない。暗記しかできないから
思考能力がないのでまともな議論ができません
よってOOのプロパガンダ行えるがOOを使うことはできない

OOを使うにはOO厨は必要なし
0060デフォルトの名無しさんNGNG
おまいらに聞きたいが､OOが糞だってならそれに代わるナイスな開発手法ってどんなのがある？
煽りでなく｡漏れは趣味でプログラム組んでるだけのヘタレなんでよく知らんのです｡
0061デフォルトの名無しさんNGNG
>>43
>再利用しないコードでOOする理由は保守性ってことになるが
>上のような例やデザパタにあるような複雑な仕組み
>を入れたりすると調整や辻褄合わせでコードが巨大になってしまい
>余計に保守性が下がる気がするのは漏れだけだろうか？

いや、漏れもそう思う。
で、XPの "シンプルデザイン" はその問題に対する答えの1つだと思う。

http://w3.dreams.ne.jp/~pb1871/xpractices.htm

の "Do the simplest thing that could possibly work" が参考になるかも。
0062 NGNG
つかprivateなデータフィールドを
アクセサで包めなんて誰が言ったよ？
0063デフォルトの名無しさんNGNG
>>60
趣味でプログラム組んでるだけのヘタレにはOOがお似合い
君にはOOで十分
0064デフォルトの名無しさんNGNG
>>62
マイクロソフトはそんなレベルの低いことはいいません。
0065デフォルトの名無しさんNGNG
＞privateなデータフィールドをアクセサで
無効なデータの設定を防ぐため、

くらいしか思いつかない。
0066デフォルトの名無しさんNGNG
OOはプログラマを信用してないから糞。
同様にC++以外の言語はプログラマを信用していないので糞。
よって俺糞。
006754NGNG
＃あぁ、漏れの書き込みのせいでスレが荒れる・・・ｗ

まぁお前らOOPLを批判するヒマがあったら
もっとOO開発手法の批判をしたほうが有意義ですよ！
ってこった。

…漏れも開発には疎い厨房だがｗ
0068デフォルトの名無しさんNGNG
>66
>よって俺糞。
ﾜﾛﾀ
0069 NGNG
今時アクセサネタかよ
get/set抽象化したプロパティ知らんの？
0070デフォルトの名無しさんNGNG
つまりVB最高ということですね？
007160NGNG
ヽ(`Д´)ﾉ
0072デフォルトの名無しさんNGNG
VB.NETは最高だよな。
0073プロの逝って良しの１NGNG
論理的にいくぞ！

１）全ての企業は利益を出すことが第一目標である。
２）すなわち、企業においてはソフトウエア技術は財の生産効率をいかに高めるか
　　だけがその評価の指標となりうる。
３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
　　その生産性に有意の差は認められない。
　　むしろ低下する場合が多く報告されている。
４）真の技術革新によって従来の成熟した技術から転換が起こるには
　　数倍～１０倍程度の明瞭な生産性の差がみられるのが一般的である。
５）従来技術からオブジェクト指向への転換によって生ずる資源の破棄コスト
　　や導入コストを回収できるだけの生産性の向上など、どこからも報告されていない。
６）結論として、企業としてのオブジェクト指向への転換は全く持ってナンセンス
　　と言うのが、現在私の得ている情報から得た結論である。
　　
0074デフォルトの名無しさんNGNG
>>26

OOPとはオブジェクトを組み合わせてプログラムを組むこと。
デザパタはオブジェクトを組み合わせるという当たり前のことをしてるだけ。
それにデザパタはどれもわずか数個のオブジェクトの組み合わせ。

数個のオブジェクトの組み合わせの何が複雑なんだ？
数個のオブジェクトの組み合わせで何か特別なことができるって
本気で信じてるのか？
0075プロの逝って良しの１NGNG
おいお～い。せっかく気合入れて書いたのに放置かよ。
0076デフォルトの名無しさんNGNG
＞３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
＞　　その生産性に有意の差は認められない。
具体的なソースきぼーん。
DQNが導入して駄目でした、みたいなアレなソースはのぞいてね（ｗ

＞５）従来技術からオブジェクト指向への転換によって生ずる資源の破棄コスト
＞　　や導入コストを回収できるだけの生産性の向上など、どこからも報告されていない。
大手ベンダは軒並みOOを導入していますが何か？
0077プロの逝って良しの１NGNG
ホントはね、ぼくちんもオブジェクト指向への転換ってものをしたいのよ。
でも今のぼくちんにはあまりにも難しくてさ、それで悔しくて、つい...。
0078 NGNG
OOの唯一の欠点はイニシャルコスト(つまり厨房の調教コスト)が意外に高いということだ。
このコストを負担できない人間・組織は旧来の開発手法を選択せざるを得ない。
0079デフォルトの名無しさんNGNG
きちがいすれきょうもげんきだなー

その有り余る時間をわけてくれ
008054NGNG
>>73
いったい何に対して言ってるのか見えてこない。
まさかOOPLがわからないのか！？

OOPLを習得することすらできないならPGやらない方がいいぞ.

ていうかアンチOOなﾔｼは
OOの何がいけないというのか明確じゃないよな。
「OOPLを理解できないオヤジ共」的な煽りは案外的を得ているのかも。
0081プロの逝って良しの１NGNG
ＯＯ側には論客が居ないな。
吹きこまれた嘘情報を全く検証せず権威主義で受け入れてるだけの
自らものを考えられない様なのばっかしだ。

0082デフォルトの名無しさんNGNG
1) オブジェクト指向の究極の理想。
　　↓
2) 必要なコードはすべてクラスライブラリとしてそろっている。
　　↓
3) あとは選んで混ぜるだけ。
　　↓
4) アプリケーションツクールに改名。
　　↓
5) でも誰がその究極のクラスライブラリ作るの？
　　↓
6) 一から作るのはめんどくせー
　　↓
7) 楽できる便利な方法ないかなぁ？
　　↓
8) goto 1)
0083 NGNG
5), 6)にビジネスチャンスを見出せない奴は一生コーダやってろ
0084プロの逝って良しの１NGNG
ーーーーーーーーーーそんなもの売りつけるなーーーーーーーーーーー
0085デフォルトの名無しさんNGNG
>>81
そう思いたい事という理由で全く検証せず
自分の脳内世界を世の中の標準だと思っているあなたは何なんですか？
008674NGNG
ちょっとだけ訂正

OOPとはオブジェクトを組み合わせてプログラムを組むこと。
デザパタはオブジェクトを組み合わせるという当たり前のことをしてるだけ。
それにデザパタはどれもわずか数個のオブジェクトの組み合わせにすぎない。

数個のオブジェクトの組み合わせの何が複雑なんだ？
数個のオブジェクトの組み合わせが複雑だとアンチは本気で思ってるのか？
0087デフォルトの名無しさんNGNG
抽象思考が苦手な人は OO 向いてないね。
デザパタもしかり。
008843NGNG
>>74
デザパタで複雑になると言ったのは失言。パターンで認識することに
よって複雑なコードでも「ああ、あのパターンか」と分類ができて
分かりやすくなるから保守面でも有用だね。
008988NGNG
ただ、いいたいのはOOによって意味のないコードが増えてないか？ということ。
あるプログラマが書ける（把握・管理できる）コード量は決まってると言うけど
漏れ的には本質以外のコードが増えて、それを浪費したくないんだよね。
0090デフォルトの名無しさんNGNG
>>89
で、本質以外のコードって、具体的にどんなの？
0091デフォルトの名無しさんNGNG
プロトタイピングなＯＯだったら、実働一週間残業なしで、一万行位書きますが、何か？
0092デフォルトの名無しさんNGNG
とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。
0093デフォルトの名無しさんNGNG
そもそもOOってーのは、分析・設計部分が肝であって・・・
88は明らかに勘違いしてると思うんだが。
0094デフォルトの名無しさんNGNG
つーか、デザインパターンはOO特有のものでも何でもないことぐらい
GoFの読者には常識だと思うが。
0095デフォルトの名無しさんNGNG
> 業界談義、愚痴はプログラマ板へどうぞ。
ということなので、このスレはプログラマ板が
ふさわしいとおもうが。
0096デフォルトの名無しさんNGNG
>>95
自治厨ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!!!
それはともかく、議論の進み方は半分ネタのようでもあり、
マ板のほうがふさわしいと感じることもある。
0097デフォルトの名無しさんNGNG
>>86
> 数個のオブジェクトの組み合わせの何が複雑なんだ？
> 数個のオブジェクトの組み合わせが複雑だとアンチは本気で思ってるのか？
従来の言語でも数個の関数を組み合わせればカプセル化、多態など
OOPLと似たようなことがでますが、複雑で面倒なので私は使いません。

同様に数個のオブジェクトを組み合わせないと概念を表現できないOOPLは
そろそろ言語としての限界が見えてきたと思ってます。
限界がみえたからこそデザインパターンで誤魔化しているのでしょう。
009895NGNG
>>96
おっと、 自治厨と呼ばれちゃったよ(自治厨って何だろう？)
というより、このスレってマ板の方が盛り上がるんじゃない？
あの板はネタスレ限定だし。
0099デフォルトの名無しさんNGNG
>>98

オブジェクト指向を使わない理由を考えるスレ
http://pc.2ch.net/test/read.cgi/prog/1030649831/


この状況を見て判らない？　盛り上がらないと思うよ。
0100デフォルトの名無しさんNGNG
>>97
>同様に数個のオブジェクトを組み合わせないと概念を表現できないOOPLは
>そろそろ言語としての限界が見えてきたと思ってます。

オブジェクト指向では、複数のオブジェクトを組み合わせて概念を表現する。
手続き指向では、複数の関数と複数のデータ構造の組み合わせで概念を表現する。

私にはどちらも同じに見えますが。
0101100NGNG
ﾔｯﾀ!!
100ｹﾞﾄ
0102デフォルトの名無しさんNGNG
そうか？　構造化的に仕事をする場合は、先にデータの流れを調べて
データ構造を作ってから手続きを構築してゆく。

つまり、複数を組み合わせてるように見えて、巨大な一つのクラスを
作ってるようなもの

それが尺にあう場合はそれが一番判り易く効率的だけどね
0103デフォルトの名無しさんNGNG
>>97がどんなプログラミングしてるのか見てみたい
0104デフォルトの名無しさんNGNG
＞そもそもOOってーのは、分析・設計部分が肝であって・・・

ウソを書くな
010554=104NGNG
>>81
無視してよろしいか？
オブジェクト指向プログラミングが普及するに至った
理論的背景、歴史的背景両方とも筋が通ったものだ。
自分で調べてくれ。

>>104の発言はちょっと言い過ぎたかも・ｽﾏｿ
しかし分析・設計はまだまだぁゃιぃ部分が多いぞ。
010697NGNG
>>100
> 私にはどちらも同じに見えますが。
その通りです。限界が見えたからこそ新しい手法が考えられたのです
ポストOOPLが出現し、OOPLは古い開発手法になるときも来るでしょう。
0107デフォルトの名無しさんNGNG
>>106
根本的に他のデザパタやらツールやらに頼らざるを得ないOO開発は欠陥。
0108みなしごハッチNGNG
スズメバチ駆除　ビ－バスタ－ズ
　http://ww41.tiki.ne.jp./~mikihiro9649/
0109デフォルトの名無しさんNGNG
色んなモノを組み合わせて目的を達成できるなら,それでもイイじゃん.
0110デフォルトの名無しさんNGNG
>>107
>根本的に他のデザパタやらツールやらに頼らざるを得ない
うーん、ちょっと違うんだよな。
デザパタを使うのは、その方が楽だから。ツールを使うのは、その方が便利だから。
無ければ無いで自分で作る。
0111100NGNG
>>102
>そうか？　構造化的に仕事をする場合は、先にデータの流れを調べて
>データ構造を作ってから手続きを構築してゆく。
>
>つまり、複数を組み合わせてるように見えて、巨大な一つのクラスを
>作ってるようなもの

複数の要素を組み合わせてシステムを作成するという意味ではオブジェクト指向も手続き指向も同じだよね、ということを言いたかっただけなので、細かいところは聞き流していただけると幸いです(^^;
0112デフォルトの名無しさんNGNG
オブジェクト指向の場合、オブジェクト以下とオブジェクトの扱いが違う点が違うように思うのだが？
0113100NGNG
>>106

>>111 の繰り返しになりますが、
複数の要素を組み合わせてシステムを作成するという意味ではオブジェクト指向も手続き指向も同じ。
つまり、パラダイムに依存しない問題ではないかと。

それがオブジェクト指向の限界となるとは考えづらいです。
0114100NGNG
GoFが 「継承」をデザインパターンに含めるかどうか悩んだ、という話をどこかで読んだ覚えがあるんだけど。
誰か、ｿｰｽｷﾎﾞﾝﾇ。

そんぐらい特別なものじゃない、ってこった＞デザインパターン
011597NGNG
>>113
複数の要素を組み合わせてシステムを作成することが
パラダイムに依存しない問題だからこそ、限界があるのです。

手続き指向では継承や多態は可能ですが、作成者にかなりのスキルと時間を要求します
OOPLではその概念を直接表現できるため、OOPLを使った方が作成時間も速く、
バグの少ないプログラムを作ることができます。
これは手続き指向の限界と私は考えます。

もし、デザインパターンの概念を直接表現できる言語ができ、
その言語を使った方が作成時間も速く、バグの少ないプログラムを作ることができた場合、
これはOOPLの限界と私は考えます。
0116デフォルトの名無しさんNGNG
>> 115
デザインパターンって「手続き指向」やオブジェクト指向と並列に並ぶパラダ
イムか？

あと「直接表現できる」っていうのはそういうパラダイムが言語仕様に含まれ
ているってことだと思うけど、そういう言語がそうでない言語に比べて優れて
いるっていうのは漏れはかなり怪しいと思ってる。
0117_NGNG
デザインパターンってOOの機能に依存してると思うけど・・・
0118デフォルトの名無しさんNGNG
>>117
あほはCでもデザパタできますなんて抜けぬけというけどな。
0119116NGNG
デザインパターンがOOの機能に依存してないなんていってないけど
0120デフォルトの名無しさんNGNG
デザインパターンなんて線形リストとか２分木とかハッシュとかの
延長線上のものだろ。
まあ、ハッシュとか自分でコーディングできないバカもいるんだろうけど。

とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。
0121デフォルトの名無しさんNGNG
かきあげ
0122デフォルトの名無しさんNGNG
手続き型言語においては、ある属性の持ち主が明確でない場合が多い。
したがって特に急ぎ仕事の場合、場つなぎ的ご都合主義的コードが増加する。
結果保守が難しくなる。ってのはどうなの
0123デフォルトの名無しさんNGNG
構造化設計も出来ないくせに、なにがOOだ。
直感で設計する奴は死んでくれ。
0124デフォルトの名無しさんNGNG
だからＯＯなんじゃん・・・アンタ思いっきりマヌケ
0125デフォルトの名無しさんNGNG
まあOOをカダイヒョウカしてる奴が理解できなくてアンチOOになるわけよ。
わかってる奴にとっては別に特別な手法ではないし。
まあICONIXとかuse-caseの問題点に突っ込むならまだマシだが、あれって
「OOを理解」してないと無理だろうし
0126デフォルトの名無しさんNGNG
>>122
うーん、そういう属性はヘッダで晒さなければいいから。
インスタンスが複数ない場合は手続き型言語でやっても一緒でしょ。
0127デフォルトの名無しさんNGNG
実際の話、クラスが使えない言語なんか難しくて使えない。
goto文使うぐらい難しい。
0128デフォルトの名無しさんNGNG
そりゃ無理すりゃどの言語でも可能ではあるかもしれませんが非効率的です。
そもそもあなたの言ってる事自体ＯＯの考え方では？
0129デフォルトの名無しさんNGNG
オブジェクト指向データベースとか馬鹿だよなぁ。
全然話題にものぼらないね。（ｗ
オブジェクト指向をカダイヒョウカした馬鹿が、
データベースにも適用するぜ！と
意気込んだはいいものの、
たいした成果もあげられてないよね。（嘲笑禿藁
0130デフォルトの名無しさんNGNG
まあ自然な考え方だからな・・・終了？
0131デフォルトの名無しさんNGNG
あ、でも継承は糞だね。
0132デフォルトの名無しさんNGNG
俺はできるだけ使わないようにしてる。
0133100NGNG
>>129
インピーダンスミスマッチも知らないあなたの方が馬鹿
0134デフォルトの名無しさんNGNG
久しぶりみみたら・・・「手続き指向」とか得体の知れない言葉がでてるな。
あと、「手続き型言語」という言葉の用法がすごく変。
この流行、何があったの？
0135100NGNG
>>115
ごめんなさい。よくわからなくなりました。

よろしければ、なぜ「数個のオブジェクトを組み合わせないと概念を表現できない」ことがオブジェクト指向言語の限界なのかをお聞かせ願えませんか?
0136デフォルトの名無しさんNGNG
構造化は安価である。導入コストはなきに等しい。
OOの導入コストは以外に高く、罠も多い。

これが全て。
0137100NGNG
>>134
変かな＞手続き指向
ぐぐったら結構出てくるので、得体が知れない程ではないと思うんだけど。
0138デフォルトの名無しさんNGNG
>>136
×以外に高く
○意外に高く
0139プロの逝って良しの１NGNG
昔のテーブルマナーで、ライス食べる時フォークの背にナイフで乗せて食うのが
あったでしょ？

論理的に考えれば、【西洋人はライス食わないし、フォークの背は変だ】
インチキ料理評論家が流行らせたんだとすぐわかっただろうにね。

オブジェクト指向もあと１０年もすれば「フォークの背」と同じだと
みんな気付くと思う。

【メンテも実装も短いコードほど効率が高い】
実に単純な理屈だ。
これが今納得できない人が居るとしたら、それは権威主義で目が曇っているからに
他ならない。
0140デフォルトの名無しさんNGNG
フォークの背は不便だけどオブジェクト指向は便利だよ。
0141デフォルトの名無しさんNGNG
俺はOO厨だが、OOに変わる概念がずっと現れないとは思わない。
たしかにOOをきちんと理解するのは難しいところもある。
だが、その新しい概念が構造化より優しいとは限らないと思う。
つまり、OOが理解できた人間にその新しい概念は理解できても、
構造化しか理解できなかった奴に理解できるとは限らない。
そういう奴はその時代の2ch的サイトで
「○○指向は戦場では必要なし」
とかとんちんかんなスレ立ててるんだと思うよ。
0142 NGNG
OOPLは今も緩やかにではあるけど進歩し続けてるよ。
モダンな言語はデザインパターンを無理なく
ライブラリとして記述できるような柔軟性を持った文法に仕上がってる感じがする。
0143デフォルトの名無しさんNGNG
ポリモフィズムはテスト用のスタブをつくるためにあるかのような
気がしてきてる俺はテスト熱中症？
0144デフォルトの名無しさんNGNG
構造化のころも KJ 法やジャクソン法があったわけだが。
構造化はそういった分析設計技法を含めずに語られて、
OO では含めて語られているような感じがする。
0145デフォルトの名無しさんNGNG
前スレからコピペ

> デザパタは数個のオブジェクトの組み合わせに過ぎない。
> デザパタが理解できないのは構造化で
> 数個の関数の組み合わせが理解できないって言ってるのと同じ(藁
0146デフォルトの名無しさんNGNG
「OOは優れた考え方である。したがってOOPLも優れている。」
これは正しいですか？
0147デフォルトの名無しさんNGNG
＞西洋人はライス食わないし

アメリカが何故米国と呼ばれてるか少しは考えよう。
今時海外旅行経験者なんてざらなんだし・・・
つーかおまえって何をやっても駄目なタイプ？
0148デフォルトの名無しさんNGNG
OOだって得意分野と不得意分野があるわけだ。OO不要とか言ってる奴
はおそらく数値演算屋とかと、めっさ小さいトイプログラムしか書か
ないやつ（或いは書けない無能者）のどっちかじゃないかと
0149デフォルトの名無しさんNGNG
たしかにちっこいくだらんプロジェクトなら非OOのほうが設計が簡素な分
早いかもしれんが、保守っつーかいろんな実験すること考えたら。。。
つーか数値演算屋だってOOつかってるっつーか、そもそも元祖のSimula自
体が。。。
0150デフォルトの名無しさんNGNG
とりあえずsageようぜ。
0151デフォルトの名無しさんNGNG
>147
MAJIRESですか?
0152デフォルトの名無しさんNGNG
>>147は米国産米穀の喰いすぎ
0153デフォルトの名無しさんNGNG
>>147
お前も少しは考えよう。休むに似たり、かも知らんが。
0154デフォルトの名無しさんNGNG
>>147
> アメリカが何故米国と呼ばれてるか少しは考えよう。
おまえは本当に考えたことがあるのかと小一時間(略
昔は漢字で「亜米利加」と表記されて、最初の文字の
「亜」じゃ混乱するので(亜細亜とかあるもんな)
2番目の文字の「米」を使って米国と表記してるだけなんだけど。
0155プロの逝って良しの１NGNG
>>147
すばらしい漢字と歴史の知識だ！（藁
亜はアルゼンチンかどっかだろう。
0156デフォルトの名無しさんNGNG
>西洋人はライス食わないし
スペインのパエリアなんかは米料理だよね。
食わないわけじゃないよな。

147は馬鹿だけど。
0157デフォルトの名無しさんNGNG
>>147 えーっと、とりあえず…アフォ！
0158デフォルトの名無しさんNGNG
>>154
あと、「米利堅」ってのもあるな。
147はアフォだけど。
0159デフォルトの名無しさんNGNG
>>147のようながアフォOO厨は逝って由
0160デフォルトの名無しさんNGNG
>>147
> アメリカが何故米国と呼ばれてるか少しは考えよう。
知識が間違っていて、それを自信満々で広めるのは迷惑
OO厨はこんな奴ばっかなので駆除しているのに
やつらはゴキブリや蛆と同じでいつも湧いて出てくる。
0161デフォルトの名無しさんNGNG
>>160
たとえば 160 の様にってか？
0162デフォルトの名無しさんNGNG
147 は希代の釣り師だな。
0163ｱﾝﾁﾓﾄﾞｷNGNG
>>135
「すべてに通用する一つのオブジェクト」があればいいのさ
0164100NGNG
>>163
アンチパターン "The Blob"の典型的な症状っすね。

http://www.antipatterns.com/briefing/sld024.htm
0165デフォルトの名無しさんNGNG
>>147
あのさあ、イギリス国旗に、でっかく『米』の字が描いてあるのを知らないのか?


当然、日本の国旗が日の丸弁当なのは知ってるよね。
0166デフォルトの名無しさんNGNG
>>165
パラオ共和国の国旗がタマゴ弁当だということは
知っていますが、何か？。
0167デフォルトの名無しさんNGNG
インドの国旗はカレー
0168デフォルトの名無しさんNGNG
オブジェクト指向は必要ではない。
なくても問題ない。
必要と思うなら使え。
思わないなら使う必要なし。
それだけだろ？
0169デフォルトの名無しさんNGNG
>>168
それだとスレが伸びないじゃん。
0170デフォルトの名無しさんNGNG
これをコピペすればアンチは反論できません。

デザインパターンなんて線形リストとか２分木とかハッシュとかの
延長線上のものだろ。
まあ、ハッシュとか自分でコーディングできないバカもいるんだろうけど。

とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。

0171デフォルトの名無しさんNGNG
>>170
安置が批判してるのはOOとかOOAとかOODとか
OO至上主義とかであって、
OOPL批判はしてねぇだろ。
つうかC++にしてCより悪くなることなんて何もないでしょ．
0172デフォルトの名無しさんNGNG
>>171
だから前スレから何度も言われてるだろ。
OOPLとOOA、OODが区別できない馬鹿は放っておけ。
その手の馬鹿にレスし始めるとスレが無限にループする。
0173デフォルトの名無しさんNGNG
OOA、OODができないと
OOPLが使いこなせない罠。
そういうﾔｼはきっと、C++の良さもわからないんじゃね？

おまえらvirtual使ってますか？
0174 NGNG
>おまえらvirtual使ってますか？
今すぐこのスレから出て行け！！
0175デフォルトの名無しさんNGNG
同意
0176デフォルトの名無しさんNGNG
>>132
カプセル化→非OOでも常識
継承→糞
となるとOO廚の心のよりどころは多態だけだね(w
0177デフォルトの名無しさんNGNG
>>170
漏れはC++のクラス機能が嫌いで使ってないんだけど(struct+関数でやってる）
カプセル化ではこっちの方が強力だよ。
例えばC++のクラスは宣言時にprivateな属性もそこに書かなければならないけど
その属性がstructなりclassなら、その定義までヘッダに晒さなくてはならない。

他にもクラスオブジェクト、インターフェース
動的継承や多重継承なども(継承嫌いだから使わないけど)好きに表現できる。
object->fun(1)をfun(object, 1)としなければならないのが難点だが。。。

C++の不要な機能、それはclass宣言文(w
0178プロの逝って良しの１NGNG
OOPL批判ならＪＡＶＡは関数ポインタ無いから糞だし。
0179デフォルトの名無しさんNGNG
ふぅ。

C++最高と。
0180デフォルトの名無しさんNGNG
VC++マンセー と。
0181デフォルトの名無しさんNGNG
>>177
STLの味がわからないガキなんだな。かわいそうに。
食わず嫌いは井の中の蛙なんで、無害だけど、
自分の知らないことまで大きな声で否定するのは厨房と思われ。
0182デフォルトの名無しさんNGNG
>>181
放っておいてあげましょうよ。
かわいそうだよ。
0183 NGNG
>例えばC++のクラスは宣言時にprivateな属性もそこに書かなければならないけど
>その属性がstructなりclassなら、その定義までヘッダに晒さなくてはならない。
なんというか「旧世代」を感じさせるレスですな。
0184プロの逝って良しの１NGNG
ゲッターセッターはやっぱ要らないね。
0185 NGNG
もちろんいるよ。
まぁプロパティの無いJavaは糞だが。
0186デフォルトの名無しさんNGNG
>>184
情報隠蔽の意味を知らない厨房。
0187デフォルトの名無しさんNGNG
>>177
激しく嘲った
0188一言NGNG
戦場で必要なものこそOOPなんだよ。ボケとんなハゲ
0189結城苗NGNG
>>172
OOA,OODとOOPLの区別ってよりも。
データ構造とクラス間相互作用の区別がついてないって感じ。
0190プロの逝って良しの１NGNG
つうか戦場ってシステム系の」ことだろ？
0191デフォルトの名無しさんNGNG
>>177
好き嫌いで語ってる時点で厨房っと…。
まともな PG ならただの好き嫌いに筋の通った理論をつけて
ごり押しする能力がある筈。
0192177NGNG
今日もたくさん釣れました(藁
0193デフォルトの名無しさんNGNG
>>192
釣れた、と言ってる時点で厨房っと…。
0194デフォルトの名無しさんNGNG
>>190
制御分野でも。
「リアルタイムＵＭＬ」って言う本よんだけど、
チンタラした制御でない限り、今のCPUでは実行不可能。
0195デフォルトの名無しさんNGNG
>>194
それはCPUが悪い・・・。
このご時世仕方ないかもしれないが。
制御系はやった事ないんで知らないが、まあ大変そうだな。
頑張って構造化プログラムしてやって下さいな。

ＯＯＰは小手先の技術じゃないんで、資産と人材が集まるまで
大変だとは思うＹＯ。
色んな会社を見て回るのが良いのかも･･･。

俺的にマジレスでした。
0196100NGNG
>>178
>OOPL批判ならＪＡＶＡは関数ポインタ無いから糞だし。

関数ポインタっていうか、メソッドがファーストクラスのオブジェクトだったら便利なのは同意。
けど、無いから糞って程じゃないと思う。
ちょっと複雑になるけど、以下のようにすれば望む機能は得られるわけだし。

* interfaceの宣言
public interface Comparer {
public int invoke(Object a, Object b);
}

*inner-classのインスタンス化
Comparer c = new Comparer() {
public int invoke(Object a, Object b)
{
return this.stringCompare(a,b);
}
};

* intefaceからの呼び出し
int comparisonValue = c.invoke(a,b);

(*)このコードは
http://member.nifty.ne.jp/masarl/article/nifty-logs/inner-vs-delegate.html
からお借りしました。
0197デフォルトの名無しさんNGNG
>>192
敗北から何を学ぶかが大事です。
あまり気を落とさないで下さいね(^^)
0198デフォルトの名無しさんNGNG
>>194
高級言語なんかで制御できるかよ。
構造化？ヴァカ逝ってんじゃねーよ。

なーんて時代もあったねえ。
0199デフォルトの名無しさんNGNG
C++の仮想基底を叩く人いないのか
0200デフォルトの名無しさんNGNG
>>196
それはCでも多態できるって言ってるのと同レベルだと思うよ.
関数ポインタ使えないのとコレクションが型安全じゃないのは
糞といわれてもしょうがないくらいに欠点
0201デフォルトの名無しさんNGNG
>>200
は？コレクションが型安全じゃないって…
君、型安全ってどういう意味で言ってる？

そもそも、>>196はポリモーフィズムの基本なんだけど。
それをCで多態できるのと同レベルって…
0202デフォルトの名無しさんNGNG
Javaって結局総称サポートしてないの？
駄目駄目じゃん。
0203デフォルトの名無しさんNGNG
>>201
いちいちキャストしなくちゃコレクションの中身使えないでしょ。
そして実行時までキャストミスには気づかない。
まあキャストするクラス書けばいいけど、
そりゃ結局CでOOPできるといってるのと同じレベルの話だ

面倒なコーディングすれば「Cでも多態やクラスみたいなことできる」
って騒いでるアンチと同レベルって言いたかったんだよ
0204デフォルトの名無しさんNGNG
>>203
特定のクラス用のcollectionクラスつくるのと
CでOOPできるのとが同じレベルに見えるのか…

すっげー不思議な奴だな。
特定のクラス用のcollectionクラスつくるぐらい、
開発環境工夫すれば自動的にできる話だろ。
アフォらし
0205デフォルトの名無しさんNGNG
>>204
だ・か・ら

>開発環境工夫すれば
CでOOPするのも
>自動的にできる話
なんだって
0206デフォルトの名無しさんNGNG
>>205
Cで開発環境に手を入れてOOPするには文法を拡張しなきゃいかんでしょ。
それこそC++みたいにね。
collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。

というわけで、全然レベルが違うよ。
0207デフォルトの名無しさんNGNG
俺の脳内のイメージの話で恐縮だが、
オブジェクト指向を知らなかった時代の「プログラム」に対する認識は
すごく二次元的で平面的だった。
今は三次元的なモノに感じる。

２次元世界から３次元世界へ移行するのには
確かに労力ずいぶんかかったけど、
やっぱり表現力は爆発的に増えたよ。

そして普通なら複雑度も爆発的に増えるはずなんだろうけど、
GoF パターン等が、その複雑度の爆発を抑えて、むしろ以前よりも
複雑度は下がっている。

負け犬アンチは２次元世界から３次元世界を理解しようとして
悩んでしまった人や、
表現力の爆発に伴う複雑度の爆発を抑えるテクニックを知らなかった人達なような気がする。
0208デフォルトの名無しさんNGNG
>>207　知らないというより、「判ったからダマットレ」と言いたいの

確かに勉強不足の奴もプロジェクトにもいるが、会議はそいつの
勉強の為の場じゃないし、ましてや君の知識を披露する演台でもない。

やるなら一人でやれ。俺も一人でやってるんだから会議では黙ってろ
0209デフォルトの名無しさんNGNG
>>208 判ったからダマットレ？　ｹﾞﾗｹﾞﾗ
『負け犬アンチ』って言葉に敏感に反応する奴がなに言ってんだか。
そもそもあんたがひとりでやってんのは友達いないからでしょ？

と煽ってはいけませんよみなさん
0210デフォルトの名無しさんNGNG
プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。
0211デフォルトの名無しさんNGNG
>>209
典型的な鬱症状患者だな
0212デフォルトの名無しさんNGNG
　　　　　　　　ほら、またきちがいすれがあがっているよ
　　　　　　　　　　　　　　　　 　 　 　 ,!ヽ
　　　　　 　 　 　 　 　 　 ,!ヽ、　　　 ,!　 ヽ
　　　　　　　　　　　 _,..ィ´￣｀)-‐‐‐''　　　ヽ
　　　　　　　　　 　 /　　´｀)'´　 　 _　　　　 !、
　　またかよ…　/　　i-‐'´　　　,　｀　　　　 `!
　　 lヽ、　　/　 Y　 　 ,!　ヽ-‐‐/　 　 　 　 　 l　
.　　l　＞‐'´｀ 　 l　　 ﾉ 　　ヽ_/　　　 　 　 　 ﾉ
　 ,ﾉ　　　 　o 　 ヽ　　l　　　　　　　　　　　 _,ｲ
　i'.o　 r┐ 　 　　 ヽ、 ヽ､_　　　　　　,..-=ﾆ_
　l　　 ,!-l､　　 　　 ﾉヽ､,　　　　　　　　　　 ヽ
　ヽ　　　　　　　 _,.ｨ'. 　,!　　　　　　　 　､ 　　`!、
　　`ｰ-､_　 　 く´　 　 l　　　　　　　　　 ヽ 　 　l
　　　　　,!　　 　`!　　 l　　　 　 　 　 　 　 ヽ､__ﾉ
　　　　 l　　 `!　 `!　　!　　　　　　　 　 　 　 l
　 　 　 l　 l.　l　 ,　l　　ヽ、 ､_　,ｨ　　　　　 ノ
　　　　 l､_,!　 し'　 l　　　l　　 `l　　　　　　l
0213デフォルトの名無しさんNGNG
>>208
誰に逝ってるのか知らんが、お前、疲れてるぞ。ちったー休めや。
なーに、会社のほうは大丈夫。みんながちゃんと君の分もがんばってくれるよ。

つーか、いないほうが生産性があがるみたいだし。
0214プロの逝って良しの１NGNG
>>207
そんなのはＣ時代に自分で発想していて当たり前。
0215デフォルトの名無しさんNGNG
Cでもできる厨
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!
0216プロの逝って良しの１NGNG
十年以上前のテクニックを最新技術だと思って得意になってるばかりか
「自分は進んでいて、ＯＯ知らない奴は遅れている」
などと勘違いも甚だしい奴が多過ぎる。
しかも、俺から見れば時代遅れのテクニックを押し付けてくるし、
「本当の最新のやり方はこうだ」
と俺が教えてやっても、逆に時代遅れと受け取るし、
雑誌や本に書いてあることなんて、大抵１０年は遅れている事ばかりなんだよ。
本当にＯＯ厨には困ったもんだ。
0217デフォルトの名無しさんNGNG
>>216
１０年前なら話が合ったかﾓﾅｰ
0218デフォルトの名無しさんNGNG
「本当の最新のやり方」キボンヌ
0219デフォルトの名無しさんNGNG
ネタに決まってるだろ
プロの逝って良しの１が技術的に具体的かつ正確な
レス付けたの見たことない。
0220プロの逝って良しの１NGNG
それは商売の邪魔になるから教えられない。
過去スレにヒントとか書いてあるが。
0221プロの逝って良しの１NGNG
目が曇っている者には目の前のものも見えない。
0222デフォルトの名無しさんNGNG
「技術的に具体的かつ正確なレス」きぼー＞＞風呂の逝ってﾖｼ
0223プロの逝って良しの１NGNG
じゃあちょっとだけ。
継承の組み合わせで大量にクラスが増えそうな場合、
継承を使わずに、全ての要素を重ね合わせた基本クラスを用意し、
注文によって必要な機能を持った任意のオブジェクトの生成を行う。
0224デフォルトの名無しさんNGNG
>>206
>Cで開発環境に手を入れてOOPするには文法を拡張しなきゃいかんでしょ。
なじぇ？
Cの文法の中でできるよって主張してる奴がこのスレや前スレにたくさんいる。
そしてそれは事実だ。ただめんどくさいだけ。

君の思考回路は彼らと同程度だろ

0225デフォルトの名無しさんNGNG
>>223
委譲、Compositionってあたりだね
0226デフォルトの名無しさんNGNG
Facadeと言いたいのかな
0227デフォルトの名無しさんNGNG
>>223
（　ﾟдﾟ）ﾎﾟｶｰﾝ
0228プロの逝って良しの１NGNG
デザパタ＝ノストラダムスの大予言
0229デフォルトの名無しさんNGNG
俺だったら、
OOPLの初期から確立していたFacadeを
自分の独自発見のようにいちいち言う奴とは
仕事したくはねぇーな。

共通概念として整理して名前つけて広報する事って、
意外と重要な仕事なんだよね。
0230デフォルトの名無しさんNGNG
知的所有権の共同保有とか相互使用協定と同じく、
技術の健全な発展のためには、欠くべからざる仕事だと思う。

皆が「俺が独自に発見した概念で、
　　　あんたの糞概念とは桁がちがうんだー」
とかいいだしたら、相互理解も共同作業も成り立たなくなっちまう。
0231デフォルトの名無しさんNGNG
それじゃ、真に有用と思われる新規概念を構築しちまった人は、
どう振舞えばいいの？
0232プロの逝って良しの１NGNG
全然ちげーよ。ヴァカ！

＊「本当の最新のやり方はこうだ」と俺が教えてやっても、逆に時代遅れと受け取るし、＊

な？言ったとおりだろ？
0233デフォルトの名無しさんNGNG
１０年前なら、話が合ったのにねー。残念だね。
0234プロの逝って良しの１NGNG
デザパタなんか勉強すんなよ。
目が曇って最前線に立てなくなるよ。
（システム系は除外）
0235デフォルトの名無しさんNGNG
>>232
は、漏れの過去の「10年前は…」発言を見て
厨が作ったﾈﾀｷｬﾗなんで、質が低くてスマン。
0236デフォルトの名無しさんNGNG
確かに、最前線の雇われｺｰﾀﾞには不用な概念かもな。
変に設計いじって欲しくないしぃ、
人の仕事で勝手に試行錯誤してほしくないしぃ
0237デフォルトの名無しさんNGNG
最近はOOPしないほうが難しくないか？

VBだってヘジがOOにしたし
0238デフォルトの名無しさんNGNG
おれは２０３の言ってること理解できたよ。
どの言語を使っても似たようなことはできる。
ただし、用意に記述できたり、できなかったりする。

だから、>>196のようなやり方をしてまでする方法は
CでOOPするのと同じなんだろう。

ただ、関数ポインタがないからJAVAがくそって言うのは理解できない。
C++をつかってて関数ポインタを使いたくなった事はないんだけど、
どういう時に使うと便利なの？
0239デフォルトの名無しさんNGNG
>>238 DLL作ったり使う時
0240プロの逝って良しの１NGNG
携帯に収めたい時。
ＯＳ作りたいとき
インタプリタ作るとき
コールバック使いたい時
0241デフォルトの名無しさんNGNG
>>240
　コールバックはオブジェクトインスタンス(ポインタ)を渡してもいいじゃないか
0242プロの逝って良しの１NGNG
分散オブジェクトしたい時
簡易スレッド作りたいとき
コードの動的生成やりたい時
プラグインやりたい時
言語解析機作るとき
0243デフォルトの名無しさんNGNG
>>224
話の流れ全然読めてますか？
>>205のCでOOPするのに自動化できるってに対するツッコミから来てるんですよ。
最初からCの文法でOOPしてたら自動化も何もないですね。
自動化するのであれば、Cの文法を拡張しなければ、どうしようもないと思いますが。
0244デフォルトの名無しさんNGNG
>>242
…virtual関数じゃだめなのか？
つうか、本当にOOPわかってんのあんた？
0245デフォルトの名無しさんNGNG
>>238
は？まさに動的束縛の典型例というか、一番単純な部分だと思うんだけど。
0246プロの逝って良しの１NGNG
>>241
よくわからん。

良く不便だなと思うのは通信でのエラー処理だな。
元が同じエラーでも現在のアプリ側の状態によってエラーの種類が
かなり予測不能に増える。
0247デフォルトの名無しさんNGNG
>>223
そんなものはとっくに常識になってますが。
万能チューリングマシンって聞いたことない？
0248デフォルトの名無しさんNGNG
オブジェクト指向も結局は手続き型じゃないの？
0249デフォルトの名無しさんNGNG
関数型ベースのオブジェクト指向言語もあるけど。
OCamlとか
0250デフォルトの名無しさんNGNG
>>246
へっぽこ
0251デフォルトの名無しさんNGNG
>>248
>>249に加えて、論理型オブジェクト指向言語もある。
0252デフォルトの名無しさんNGNG
>>246
　それならコールバックより例外の方がより適切では？
　それともエラーが発生したらとりあえずコールバックして誰かに処理してもらう事にしてるの？
　回復可能ならreturn して貰って　でなければ例外投げて貰うとか？
0253プロの逝って良しの１NGNG
>>247
昔delphiスレを潰した方ですか？
0254デフォルトの名無しさんNGNG
>>246
なんだ、実装技術低いだけｼﾞｬﾝ(ﾜﾗ
0255デフォルトの名無しさんNGNG
>>246
C++なのに戻り値で0か-1返して、受けた側でIF ELSE分岐してる
馬鹿がｺｺにもいたか…うちの会社にもいるんだよ…肩書きｴﾗｰｲ奴に…
0256100NGNG
>>200
もともと言語でサポートされていない Cでの多態。
メソッドが一個だけの Strategyパターンとしてサポートされている Javaでの関数ポインタ。
両者を同じものとして扱うのは乱暴杉。
0257プロの逝って良しの１NGNG
>>254
アフォ
0258プロの逝って良しの１NGNG
>>255
Javaだっつうのに！
0259デフォルトの名無しさんNGNG
>>243
最初にクラスもどきを作るのに自動化されたジェネレータを一発起動。
出来上がったソースはCの文法どおり。
これで立派な自動化だけど?

>>206の
>collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。
これだって同じ意味でしょ？
最初に造るときだけ自動化してあとのメンテはJavaの文法どおり。

もしのちのちのメンテまで自動化しようとしたらJavaも文法拡張するしかない。
例えば IntegerVector,StringVector とか造ったあとに DebugVector
というデバックプリントはくVector造ったら継承しなおせないでしょ

話の流れを読めていないのは君だと思うが
0260!254NGNG
>>257
少なくとも実力の伴っていないお前よりはマシだ。
0261デフォルトの名無しさんNGNG
>>258
どうせ同じはなしだろ、馬鹿。
0262100NGNG
>>202
いずれサポートされると思われ＞総称
http://jcp.org/jsr/detail/014.jsp
0263デフォルトの名無しさんNGNG
>>256
あほですか？
関数ポインタはまさに「多態」をサポートするために
Cに組み込まれていますが？
0264254=EJBエンジン設計技術者NGNG
>>258
Javaならリフレクションでメタプログラミングできる方法が
コアAPIにあるんだぞ？それで関数ポインタが必要なんていってる
やつは、C++でそれをいう奴の1000倍馬鹿だと思うが…
0265プロの逝って良しの１NGNG
OO厨＝二周遅れのなのに先頭を走ってると勘違いしているランナー
0266デフォルトの名無しさんNGNG
通信でのエラー処理は時間シーケンスが絡むから確かに普通に実装してたら閉口するな

俺はどうやってるかというと簡単なスクリプトを作ってその行番号でエラー処理したり
それほどでもない場合は

static no=0;
switch(no++)
{
case 0: ...
case 1: ...
case 2: ...
no:=0;
}

みたいな感じで書いて エラーが起きた時はこのnoと組み合わせて判断させたりしてるな
0267プロの逝って良しの１NGNG
>>246
不便なだけ
0268デフォルトの名無しさんNGNG
>>266
エラーオブジェクトのクラス自身にディスパッチロジックおいといて、
それをコールすればええだけﾔﾝ…
0269デフォルトの名無しさんNGNG
>>267
おまえ、社会人じゃないだろ。
0270プロの逝って良しの１NGNG
>>268
言ってる事が良く判らんが
エラー処理はオブジェクトに依存しない。手続きに依存する。
0271デフォルトの名無しさんNGNG
int a = 10;

if ( 9 < a < 10)
printf("9 < a < 10");
else
printf("!(9 < a < 10");

これを実行したら, 9 < a < 10 と表示されました。
これはコンパイラのバグでしょうか？
0272デフォルトの名無しさんNGNG
>>270
手続きをオブジェクトでラッピングするんだよ。
状態が関わるダブルディスパッチなら、その方が管理が楽。

うちの上司並の馬鹿だな（ﾜﾗ
0273100NGNG
256 GET!!!
小さくガッツポーズ。
0274プロの逝って良しの１NGNG
>>272
相変わらず意味が判らんな
エラー処理が１００種類有る場合には１００個クラス作るのか？
それとも処理の中に状態フラグいじるルーチンをいちいち置いて
switch-case１００個並べるのか？
0275デフォルトの名無しさんNGNG
9<aが1を返してそれと10を比べているだけだと思うが。。。>>271
0276デフォルトの名無しさんNGNG
>>274
関数100本書くほうが賢いか？
0277プロの逝って良しの１NGNG
>>276
はあ？
異なるエラー処理が１００種類生じる場合の話だぞ
それとも「通信エラー」と表示してアプリ終了させるだけのヘタレプログラム
でも作ってるのか？
0278プロの逝って良しの１NGNG
>>276
はい、賢いです。
0279100NGNG
>>263
そうですね。
構造体の中の関数ポインタの値を置き換えることで多態を表現できますね。
0280100NGNG
>>73
>３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
>　　その生産性に有意の差は認められない。
>　　むしろ低下する場合が多く報告されている。
>４）真の技術革新によって従来の成熟した技術から転換が起こるには
>　　数倍～１０倍程度の明瞭な生産性の差がみられるのが一般的である。

ｿｰｽｷﾎﾞﾝﾇ。
0281デフォルトの名無しさんNGNG
このスレにいるやつって職業プログラマ？？
アフォな議論してるとしか思えん。
0282プロの逝って良しの１NGNG
http://www.njk.co.jp/otg/Drop/Drop_v20/part2/chapter5.html

コンポーネントを組み合わせながらシステムを構築することで、生産性の向上を
＞図り、再利用性を高めるというのは、オブジェクト指向の理想であり、
＞オブジェクト指向技術採用時の大きなメリットと言われている。
＞しかしながら、オブジェクト指向開発の評価として
＞「再利用可能なコンポーネントは作成できなかった」、
＞「従来よりも生産性は落ちたようだ」などといった愚痴をよく耳にする。

＞オブジェクト指向は、５年後、１０年後の企業のあり方を前提とした長期的な
＞ビジネスプロセスのリエンジニアリングが必要とされる。
0283100NGNG
>>281
ｱﾌｫ上等。
ばっちこい!!
0284プロの逝って良しの１NGNG
元のＨＰはサイトごと無くなっているが、紹介記事。

http://slashdot.jp/article.pl?sid=01/09/22/109245&mode=thread&threshold=
オープンソースプロジェクトの成功率

C++を採用したプロジェクト→20.8%
JAVAを採用したプロジェクト→20.6%
Cを採用したプロジェクト→45.13%
0285デフォルトの名無しさんNGNG
ねたりさいくるっすか
0286プロの逝って良しの１NGNG
４）は列挙に疲れるから歴史の本でも読んでくれ。
0287デフォルトの名無しさんNGNG
>>281
ネタで書き込んでる奴が大半。
0288デフォルトの名無しさんNGNG
OOってのはまだまだ枯れた技術ではない。
構造化は既に枯れた技術。

OOと構造化の差はここにある。
OOが構造化を含むというのは当然。
枯れた技術に負い目を感じているからである。
0289デフォルトの名無しさんNGNG
>C++を採用したプロジェクト→20.8%
>JAVAを採用したプロジェクト→20.6%
>Cを採用したプロジェクト→45.13%
Cよりもはるかに歴史が浅いC++やJavaがすでに20%以上もの成功率を誇っているっていう
好意的な解釈はできないのかな？俺はこの記事を見た時、単純にそう思ったんだけど。

# っていうかオープンソースプロジェクトの「成功」って何を基準にするんだろう。
0290デフォルトの名無しさんNGNG
>>284
誰だか知らないが、そんなところで厨房なんて言葉を使うなよ。恥ずかしい・・・・
0291プロの逝って良しの１NGNG
>>290がショックで気がふれてしまいました。
ご冥福をお祈りします。
0292デフォルトの名無しさんNGNG
>>284
どこに使ってるんだ？
0293290じゃないがNGNG
リンク先の
>Javaで始めようとする人に厨房が多いのか。
この事だと思われ
0294デフォルトの名無しさんNGNG
>>289
オープンソースプロジェクトに参加する人間は
C ハッカーな UNIX 野郎が多いということか。
0295デフォルトの名無しさんNGNG
>>288
うましか
0296プロの逝って良しの１NGNG
ああ、下の方に掲示板があったのに・・・。
ごめんなさい。
0297100NGNG
こんなの発見。

オブジェクト指向の生産性評価に関する一考察
http://homepage.mac.com/nanameneko/job/papers/ITCproductivity.pdf
0298デフォルトの名無しさんNGNG
うううう
＞Delphi 0.042
我が愛しのDelphiがこんなところに……

(同じRAD系の)VisualBasicより上だから少しはましですけどね．


Del厨ってどこでもVBを目の敵にするのね。
ところで、あそこは2ちゃんねらーの巣窟なのかしら。
0299デフォルトの名無しさんNGNG
ちゃんと’すくつ’っていわなきゃだめだよ
0300デフォルトの名無しさんNGNG
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。

0301デフォルトの名無しさんNGNG
くそすれ３００げとおめ
0302デフォルトの名無しさんNGNG
>>297
その PDF の中に書いてある怪獣の絵
とても可愛いっ！！
0303デフォルトの名無しさんNGNG
そもそも、このスレ　マ板のネタだろ！
0304100NGNG
>>282
もうちょっと定量的な評価が欲しいっすね。
いや、漏れは何も出せてないので大きなことは言えんのですが。
0305100NGNG
>>303
だね。
0306プロの逝って良しの１NGNG
そのＰＤＦねえ・・・
ソフトウエア部品の流通には根本的な問題がある。
事前にその部品の製品の品質を確かめる事が出来ないという点である。
「買ってみるまでは何が出てくるか判りません」
じゃ、くじ引きみたいなもんだな。
マイカルだな。
0307デフォルトの名無しさんNGNG
>>306
しかしネタキャラ演じるのうまいね、あんた。
0308デフォルトの名無しさんNGNG
>>277
＞100種類のエラー
分　類　し　ろ　!!

言語以前の問題。
ｱﾌｫですかアンタ？

＃と。ここで多態が役立つのでわ。
0309デフォルトの名無しさんNGNG
>>259
だから、
> 最初にクラスもどきを作るのに自動化されたジェネレータを一発起動。
> 出来上がったソースはCの文法どおり。
> これで立派な自動化だけど?

ジェネレータに食わせるソースはCじゃねーだろうが。
どこ読んでんだ、こんヴォケは。

> >collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。
> これだって同じ意味でしょ？
> 最初に造るときだけ自動化してあとのメンテはJavaの文法どおり。

全然違うだろうが。collectionクラスを自動生成したけりゃ、
基底のcollectionクラスと要素にしたいクラスのソースがあれば十分だろ。
なんでこの程度の事にここまで説明しなきゃならないんだ？
ほんと白痴相手は疲れる。
0310デフォルトの名無しさんNGNG
>>309
君、早朝からテンション高いな。
0311309NGNG
>>310
君の所じゃどうか知らんが、俺の所じゃもう午後ですが、何か？
0312デフォルトの名無しさんNGNG
>>310
ワラタ
0313デフォルトの名無しさんNGNG
>>310-311
藁た。
>>310君、早朝からマヌケだね。
0314デフォルトの名無しさんNGNG
>>274
普通に考えて、エラーを例外オブジェクトに格納して throw する
以下、適当にでっちあげたソース.

//ﾀﾞｳｿ
void download(string inUrl , string inSaveFilename) throw()
{
　UrlParse url(inUrl); //URLをパースする. 失敗時例外 UrlParseException

　Socket soc;
　soc.Connection( url ); //ホストに接続 失敗時例外 UrlParseException

　SaveMemory bufer;
　HttpRequestMaker req(url); //リクエスト作成
　soc.Send(req); //リクエスト送信 失敗時例外 UrlParseException
　soc.Reserve(memory,inSaveFilename); //結果を保存 失敗時例外 UrlParseException

　//後処理は全部デストラクタががんばってくれるのでやらねーよ
　//OO万歳!
　return;
}
0315デフォルトの名無しさんNGNG
×　soc.Reserve(memory,inSaveFilename); //結果を保存 失敗時例外 UrlParseException
○　soc.Reserve(bufer,inSaveFilename); //結果を保存 失敗時例外 UrlParseException

すまん、ぴたてん見ながら書いていたら間違ったYO。
んぢゃ、寝るので反論かいといてくれ。
0316314NGNG
む、さらに間違っていたのでいっそのこと書き直す。
レス汚しｽｽﾏｿ.
//ﾀﾞｳｿ
void download(string inUrl , string inSaveFilename) throw()
{
　UrlParse url(inUrl); //URLをパースする. 失敗時例外 UrlParseException

　Socket soc;
　soc.Connection( url ); //ホストに接続 失敗時例外 ResolveException,ConnectException

　HttpRequestMaker req(url); //リクエスト作成
　soc.Send(req); //リクエスト送信 失敗時例外 IOReadException
　soc.Reserve(inSaveFilename); //結果を保存 失敗時例外 IOWriteException

　//後処理は全部デストラクタががんばってくれるのでやらねーよ
　//OO万歳!
　return;
}

ついでに使い方を書くと
try
{
　download("http://www.2ch.net/" , "2ch.html");
}
catch(Exception e) //すべての例外は Exception から派生している
{
　//俺は printf が好きなのでこれを使う　文句ありますか?
　printf("エラーﾆﾀﾞ!謝罪しる\n%s\n" , e.getMessage() );
}
0317デフォルトの名無しさんNGNG
>>274
JavaやC#のように、クラス毎にどの例外が発生するか具体的に明示してあるほうが
多種の例外をハンドリングするのに適していると思うが。
0318デフォルトの名無しさんNGNG
>>314-316
だから、それは使う方だろ？　使う方が楽なのは皆が認めるよ。

ここではソレを作る方の話をしてるんじゃないの？

0319デフォルトの名無しさんNGNG
>>318
いや、作るにしても、ちゃんと互いに責任関係を明確にできるほうがいいでしょ？
「俺はこの例外投げるから、ちゃんと処理しろよ」と言える事のメリットは大きい。
特に複数人で開発するのならね。

人数が増えれば増えるほどこれができない言語との差が広がっていくよ。
他のメンバーがつくったオブジェクトがどんな例外を投げるかわからないんじゃ、恐くて使えないでしょ。
0320デフォルトの名無しさんNGNG
ここにきてる奴はクラス使ってﾏﾝｾｰ厨ばかりです。（ｗ
0321デフォルトの名無しさんNGNG
C#だと結局追える範囲が限定されるしな。MSに規定される量が多すぎる。
0322デフォルトの名無しさんNGNG
>>318
はあ？例外をやたら投げるだけなら誰でもできるでしょ。
0323デフォルトの名無しさんNGNG
俺が考えるには、オブジェクト指向は再利用価値のある部分のみ、もしくは
すでにパターンかされ尽くされた部分に使うべきであると思うなぁ。
関数の場合はそれだけで仕様は終わるがクラスとなるとクラスひとつが仕様
になるような気がする。
0324322NGNG
>>318
そうそう、とりあえず>>274は例外を処理する側の話だよねえ。

274 ：プロの逝って良しの１ ：02/09/07 16:36
>>272
相変わらず意味が判らんな
エラー処理が１００種類有る場合には１００個クラス作るのか？
それとも処理の中に状態フラグいじるルーチンをいちいち置いて
switch-case１００個並べるのか？
0325デフォルトの名無しさんNGNG
>>263
それは多態というよりはメソッドの動的束縛なのでは？
本来は、多態ってのはある型の変数や関数に多種の型の値を適用できることで、
parametric polymorphismとかinclusion polymorphismとかad-hoc polymorphismなどがある。
それをOOPLに持ち込むとメソッドの動的束縛につながっていくということで。
メソッドの動的束縛以外の多態の効用としては、
関数型言語の高階関数などは多くの場合多態だし、
Cの算術演算子もad-hoc polymorphismで多態だよ。
0326デフォルトの名無しさんNGNG
人海戦術。全部switchでかく。これ最強。
0327(祭)NGNG
>>324
無名インナークラスつこたらあかんの？
0328プロの逝って良しの１NGNG
>>327
きたねーソースになるな。
よめね―じゃん。
0329デフォルトの名無しさんNGNG
>>328
ひょっとして関数のネストを許す言語もお嫌いで？
0330デフォルトの名無しさんNGNG
>>328
100個も関数作る方がよっぽど汚いかと。
あと無名クラスも書き方次第で読みやすくかけるよ。

>>329
関数のネストを許す言語ってあるの？ gccの独自拡張で関数ネストできるのは知ってるけど。
0331プロの逝って良しの１NGNG
>>330
アフォか！
処理と例外処理をそばに並べておけるから可読性高いの！
「この例外処理はなんだっけ」っていちいち他のファイル開けにいくのか？
0332デフォルトの名無しさんNGNG
>>330
Perl
0333デフォルトの名無しさんNGNG
>>332
ぉ、本当だ。でもこれって用途あるのか…？謎。

>>331
誰が他のファイルに書くっつったよ。同じファイルに書けばいいだろう？
とりあえず、お前要らないから黙ってろよ。
0334デフォルトの名無しさんNGNG
>>330
Modula-2(当然Modula-3も)とかpythonとか…それぞれ細かい制約がつくけど。
0335デフォルトの名無しさんNGNG
>処理と例外処理をそばに並べておけるから可読性高いの！
駄目だこりゃ
0336あたたたたNGNG
オブ戦スレもここまで成長しましたか。
うれしいですね^-^
0337デフォルトの名無しさんNGNG
ここで出た例外ってどこでcatchされるんだっけ・・・
と悩むようなら設計がヤバイ。
0338デフォルトの名無しさんNGNG
>>333
private methodが1つのmethodからしか呼ばれてないようなのは結構あるでしょ？
そういうのはnested procedureで十分だよね。
0339デフォルトの名無しさんNGNG
>>337
逆に、本来はどこでcatchされても意味が通るような設計/実装を心掛けるべし、と思われ。
その意味でも>>331は論外。
0340プロの逝って良しの１NGNG
ダメプログラマー必死だな（藁
0341プロの逝って良しの１NGNG
いいか、お互いに関連の高い変数や関数はなるべく近くに置く。
一画面に入るようにするのがベスト。
同じファイルなんてのは失格。
0342デフォルトの名無しさんNGNG
>>340
必死なのはお前だろ(藁

>>334,338
ふむ、参考になったっす。たしかにprivate method並べるよりはイイかもしれん。
0343プロの逝って良しの１NGNG
>>339は通信やったことなさそうなんで論外
0344デフォルトの名無しさんNGNG
>>343
>本来はどこでcatchされても意味が通るような設計/実装を心掛けるべし
通信するプログラムでもこういう設計/実装は可能。アンタこそ実務やったことあるの？
0345プロの逝って良しの１NGNG
「意味が通る」の意味が不明だが、
例えば、アプリケーション層でキャッチした下位層からの通信例外は
アプリケーション層の状態や手続きによって千差万別の処理が必要になるのだがね。
0346デフォルトの名無しさんNGNG
意思の疎通がまったく取れていない模様
0347プロの逝って良しの１NGNG
じゃあ二周遅れの君達に最先端技術の一端をちょっとだけ教えて上げよう。
「最良のコードは上から下へと乱れなく読める手続き型である」
0348デフォルトの名無しさんNGNG
>>347
激しく同意！！
モジュール分割なんて流れを阻害するだけだし
オブジェクトが自立的に動くなんて論外だ。
0349314NGNG
おまえ等おはようございます。

>318
実装のやり方? おまえは俺様の擬似コードをみても実装方法が
ひらめかねーのかよ。おまえ本当にプロか?
オブジェクト指向は、
設計が決まってしまえばあとは実装を詰め込んでいくだけだろう。
ついでに使い方のテストもできているんだからな。

>328
おまえが昔書いたソースよりはマシ

>331
例外にもそれをスローするクラスから連想できるような
わかりやすい名前を付けるべき。

>341
よし、俺はもうソースを一部だが公開したぞ。
次はそのおまえのすばらしい非OOのエラー関数が100個ある
プログラムを公開してみろよ。まってるにょ。

>341
そうかそうか、ぢゃあ、宿題のプログラムは
激しく見やすくなるね。早く公開してほしいにゅ。
0350デフォルトの名無しさんNGNG
>>347-348
多分君たちは、プログラマ止めた方が幸せになれると思うよ。
0351デフォルトの名無しさんNGNG
>>331
バカ発言の極致ですな。
一種類のエラー発生元からの一種類のエラー種別ごとに、いっこの
処理ブロックを、発生もとの近くに羅列してるんだね。
こんな奴が「俺は最先端の技術者」と思っていて職場じゃ通用して
るのか…そりゃ日本の開発会社は低レベルっていわれるわなあ…

で、ネタですよね？まじでいってんの？
0352314NGNG
>>347
すげー、エラー処理とかで戻ることもないのか。
それに複数のファイルに、プログラムを分けたりしない人ですか?
ますます、宿題のプログラムが楽しくなってきた。
0353デフォルトの名無しさんNGNG
>>347
じゃあ関数なんて使えないね・・・・
0354プロの逝って良しの１NGNG
>>350
いやいや、なにも昔流のコードを主張している訳ではないのだよ。
メッセージ機構やらなんやらをバックグラウンドに隠蔽した
ニュータイプの手続き型。
0355デフォルトの名無しさんNGNG
>メッセージ機構やらなんやらをバックグラウンドに隠蔽した
>ニュータイプの手続き型。

ニュータイプキタ━━━━（゜∀゜）━━━━!!!!!
師匠!
そのニュータイプの手続き型というものを是非伝授してください。
おながいします。

0356プロの逝って良しの１NGNG
>>331
あーう、良く読んでくれ。
上位層では一個の例外から複数の場合の処理が発生する。
それはオブジェクトによって固定ではなく、それまでの処理に依存する。
つうことだ。
同じルーチンを走っていても違う処理が必要になったりする。
それまでの処理の履歴に依存すると言う事だ。
0357デフォルトの名無しさんNGNG
お前ら釣られすぎ。
言っとくけど奴は絶対コードなんて出さないよ。
0358デフォルトの名無しさんNGNG
>>357
ネタ雑談スレで何を言う。
0359プロの逝って良しの１NGNG
>>355
なんとなく語り口がシャアっぽくなってるが俺。

これだけ情報あれば充分だろ。
0360デフォルトの名無しさんNGNG
360げとずざー
0361プロの逝って良しの１NGNG
コード出して欲しいのか？
んー、人のを探して見る。
0362デフォルトの名無しさんNGNG
>>358
> ネタ雑談スレで
マ板に逝ってくれないかなぁ...。
0363356 NGNG
>356
フラグを例外を使ってとばすの?
それこそ、例外オブジェクトに解析に必要なフラグやメッセージをバインドして
飛ばしたほうが見やすくなると思うがな。

try
{
　throw FlgException(500 , "僕の肛門も閉鎖されそうです");
}
catch(FlgException e)
{
　printf("エラー %d: %s", e.getErrorCode() , e.getMessage() );
}

別に全部の例外を呼び出されたメソッドに投げ返す必要はない。
普通は自分のクラスの中で処理して、もうだめぽな状態になったら
例外を投げる。
0364314NGNG
>>363
大変失礼、間違えた 314 です。
プロの逝って良しの１を語ってしまったスマソ。
決してｼﾞｻｸｼﾞｴｰﾝではないので。。。
0365314NGNG
>>359
わかんねーよ。
ニュータイプって何だよ。おまえはただのガンオタか?
シャア専用板へ(・∀・) ｶｴﾚ!!

説明しろとはいわないが、
どっか参考になるURLぐらいは教えてくれよ。
0366デフォルトの名無しさんNGNG
わかったよ。

プロ逝＝末端のスクリプト書き

汎用的ライブラリの書き方の話をしても通じないわけだ。
そりゃあ末端で複雑な事をして汎用性を高めてもしかたがないわな。

0367プロの逝って良しの１NGNG
（java）

FileInputStream fis = new FileInputStream("filename");
int b = fis.read(); //←ココ
fis.close(); //←ココも多分

良い例がみつからないが、これなんかどうだ？
イベントや割りこみを隠蔽して見事に手続き型にしちゃってるぞ。
実はイベント駆動なんかウザくてやってらんねーつうのが
ライブラリ作成者の本心だろうな

知恵のある人は一を聞いて十を知る。
私は一を示した。
0368デフォルトの名無しさんNGNG
よって
//// 終了 ////
0369デフォルトの名無しさんNGNG
>>367
なんで入出力をイベントドリブンにしなきゃいかんのよ。
使い分けろって言ってるの。

# こいつ、十を言っても一すら分からんボケだな。
0370プロの逝って良しの１NGNG
愚かな。
十年後くらいには再手続き型化がブームになっているであろう。
0371デフォルトの名無しさんNGNG
>>370
はいはい、そーですね。おめでてー頭だな。
0372100NGNG
>>367
>FileInputStream fis = new FileInputStream("filename");
>int b = fis.read(); //←ココ
>fis.close(); //←ココも多分

FileInputStreamオブジェクトのメソッドをコールしてるよね。
このコードはバリバリのオブジェクト指向だと思われ。

オブジェクト指向、手続き指向をなにか勘違いしておられませんか?
0373100NGNG
>>354
>いやいや、なにも昔流のコードを主張している訳ではないのだよ。
>メッセージ機構やらなんやらをバックグラウンドに隠蔽した
>ニュータイプの手続き型。

ニュータイプの手続き型かどうかはわかんないけど、要は Composed Methodと同じことを言いたいんだよね、きっと。
それ自体は正しい方向性だと思う。

http://c2.com/cgi/wiki?ComposedMethod
0374100NGNG
>>325
おー、325さんカコイイ。
そのへんに関する良い文書がありましたら教えていただけませんか?
0375314NGNG
>>367
それが手続き型?
めちゃ、オブジェクト指向ぢゃん。
　　　　　　　　　　　　　　　　　　　　　　＿＿＿＿　　　　､ミ川川川彡
　　　　　　　　　　　　　　　　　　　　／:::::::::::::::::::::::::""'''-ミ　　　　　　　彡
　　　　　　　　　　　　　　　　　　　//, -‐―､:::::::::::::::::::::三　　ギ 　そ 　三
　　　　　　　　　　　　＿＿_　 　 巛/　　　　＼::::::::::::::::三.　　ャ 　れ 　三
　　　　　　　　＿-=三三三ミミ､.//!　　　　 　 ｌ､:::::::::::::三　　グ 　は 　三
　　　　　=＝三＝￣　　　　　　《|ll|ﾆヽ　l∠三,,`＼＼::三　　で 　 　 　 三
　　　　　　　 /　 　 　 　 　 　 　 |||"''》 ''"└┴‐`　`ヽ三 　　言　 ひ 　三
　　　　 　 　 !　　　　　　　 　 　 　| /　　　　　　　　　 三 　　っ　　ょ 　三
　　　　　　　|‐-､:::､∠三"`　　　　| ヽ=　　　　　U　 　三.　　て 　 っ 　三
　　　　　　　|"''》 ''"└┴` 　 　 　 | ゝ―-　　　　　 　 三　　る　　と　 三
　　　　　　　| /　　　　　　　　　　　ヽ　""　 　 　 　 ,.　三 　 の 　 し　 三
　　　　　 　 | ヽ= 　 ､　　　　U　　　 lヽ､＿__,,,...-‐''" 　三 　 か　 て　 三
.　　　　　 　 | ゝ―-'′　 　 　 　 　 | 　|::::::::::::＿,,,...-‐'"三　 !?　　　　三
　 　 　 　 　 ヽ　""　 　 　 　 ,.　 　 | |￣￣￣　　　　　　彡　　　　　　ミ
　　　　　　　　ヽ､＿__,,,...-‐''"　 ,,..-'''~　　　　　　　 　 　　 彡川川川ミ
　　　　　　　　　　厂|　　厂‐'''~　　　　　　〇
　　　　　　　　|￣＼|　／

それに、例外は飛ぶし、おまえが文句つけた俺の書いたソースと同じようなもんだろ。
そもそも、例外がいやとか上から下へ流れていないとダメだというやつが java なんて使うなよ(w

0376デフォルトの名無しさんNGNG
恐怖：OOのテクニックを全て構造化プログラミングにマッピングして理解する奴
0377プロの逝って良しの１NGNG
あのコードをオブジェクト指向と言っている奴はネタかと思ったが
二人も居るのか(藁
0378314NGNG
>>377
お前、本当に哀れだな。
最初から勉強しなおして強くイ㌔
0379デフォルトの名無しさんNGNG
あのコードがオブジェクト指向？？
なるほど。オブジェクト指向ﾏﾝｾｰする気持ちもわかるな（ｗ
いやぁ爆笑だよ。OO厨諸君
0380314NGNG
>>379
> あのコードがオブジェクト指向？？
そんぢゃあ、さっきこのコードを
お前が言うオブジェクト指向で書いてみろよ。

いやぁ爆笑だよ。アンチOO厨諸君
0381デフォルトの名無しさんNGNG
必死だなぁ。OO厨よ。落ち着けよ。な。な。
0382デフォルトの名無しさんNGNG
OOを目的語先行と定義すれば、ForthもOOかな
0383デフォルトの名無しさんNGNG
class aho{
private:
int aho;
int kuso;
int baka:
public :
aho(){
printf("アンチOO厨逝って良し")
}
}
main(){
object d=new aho()
d.aho;
return aho;
}
0384314NGNG
>>380
おいおい、さっきのコードとは、>>367 のコードだぞ。
ついに頭まで悪くなったか?
事件起こして人様にめーわく書ける前に、早めに鉄格子のある病院に入院しる!
0385デフォルトの名無しさんNGNG
すごいオチがついたな。
「8時だよ全員集合」だったら音楽が鳴って舞台が回転し始める。
0386プロの逝って良しの１NGNG
>>380
public class TestClass implements java.io.Serializable {
...
}

TestClass test;
ObjectInputStream in = new ObjectInputStream( new FileInputStream("hoge"));
test = (TestClass)in.readObject();
0387デフォルトの名無しさんNGNG
イベント＝割り込みと誤解している痛い厨がいるすれはここですか？
0388314NGNG
>>386
それはただオブジェクトをオブジェクトでラップしただけだろう。

>test = (TestClass)in.readObject();
しかも、せっかくラップしたのに、とりだしてどうする?
なんか意味でもあるのか?

しかしこれが OO だとすれば、キミがアンチOOになるのもよくわかるよ。
とりあえず、いますぐ PG の道は挫折することだな。
0389デフォルトの名無しさんNGNG
ていうかなんで1は立て逃げなのよ？
能無し？
0390プロの逝って良しの１NGNG
哀れなりＯＯ厨
0391デフォルトの名無しさんNGNG
>>390
∧　∧　( ｵﾏｴｶﾞﾅｰ )
(・ω・) ノ
o(U_U)っ
0392デフォルトの名無しさんNGNG
class Status{
　String getHandlerName(){/*implementation*/}
　//...some status manage codes
}

interface ErrorHandler{public void handle(Exception e);}
class ErrorHandlerImpl1{public void handle(Exception e){/*Implementation*/}}
class ErrorHandlerImpl2{/*same*/}
class ErrorHandlerImpl3{/*same*/}
//...

public class ErrorHandlerFactory{
　public static ErrorHandler getHandler(State state){
　　return Class.forName(state.getHandlerName()).newInstance();
　}　　　
}

Usage:
try{
//some implementation
}
catch(Exception e){
ErrorHandlerFactory.getHandler(getStatus()).handle(e);
}

Javaで、エラー処理を実行時に動的変更(実行中の処理ロジック追加も許す)する
なら、例えばこんなかんじかな？いちいちnewするの無駄とか、そういう重箱すみ
突っ込みについてはカンベン。わかってっから。
0393プロの逝って良しの１NGNG
１）上位層に依存した下位層作ってるし
２）問題になってたのは投げるエラーの種類をどうするかじゃなくてエラー処理

0394(祭)NGNG
無名インナークラス
0395 ◆k/Ubp.Kg NGNG
>>394
俺もそうするのが一番スマートだと思う。何がどう汚いソースになるのか小(略。
0396プロの逝って良しの１NGNG
一画面に収まらないじゃん。ｲﾔﾝｲﾔﾝ
0397(祭)NGNG
>>396
使った事ないでしょ？
0398プロの逝って良しの１NGNG
インナークラススレッドで使ったっきり使ってないな。
0399デフォルトの名無しさんNGNG
OOのおかげで、抽象的なプログラミングができて、
より高い世界（知ってる人だけわかる世界）へあがることができる。
実際の作業にあまり役立たなかったとしても、
うまく使えば効率を上げられるはず、と思えたり、
プログラミングにおける地道な作業があまり好きではなく
学際的な雰囲気が好きな人には、
OOを勉強する事が心の支えになってるわけ。
0400プロの逝って良しの１NGNG
だって気持ち悪い名前のクラスファイルが出来るし・・・。
0401 ◆k/Ubp.Kg NGNG
…もう呆れて何も言えない…。
0402デフォルトの名無しさんNGNG
いいぞいいぞ！プロの逝って良しの１！！
この調子で蹴散らせ！馬鹿なOO厨を！
あっはははははははー。
必死なOO厨よ。貴様らは戦場では必要なしだ。
あはっはははははー。
0403314NGNG
>>プロの逝って良しの１
318に対する反論はまだ?

とりあえず、ワるきゅーレ始まるんで実況してくるから
俺が(；´Д`)ﾊｧﾊｧしている間にでも反論を書いておいてくれよ!
0404無名NGNG
　
0405314NGNG
む、また間違ってしまった。
>×318に対する反論はまだ?
>○388に対する反論はまだ?

んぢゃ、よろしこ。
0406デフォルトの名無しさんNGNG
(´Д｀)逝って良しって何人いるの？
0407 ◆k/Ubp.Kg NGNG
>>406
過去ログを読む限り、どんどん世代交替が行われてるっぽいね。ちょっと前の逝って良しの１と、
今回のプロの逝って良しの１は、そん中でもレベルがかなり低い。まー過去ログ読んでみなよ。
面白いぜ。
0408プロの逝って良しの１NGNG
マジで答えなきゃならんのか？

＞それはただオブジェクトをオブジェクトでラップしただけだろう。

これが間違い。
どこをどう読んだらそうなるのかおしえてﾎｽｲ
それからオブジェクトシリアライゼーションくらいＯＯ厨ならしっておいて欲しい。

>>406
一人。たまに偽物あり。>>77とか。

>>407
一人だっつうの！
0409無名インナークラスNGNG
本当に激しくレベルが低いのか、確信的釣り師なのか？＞プロの逝って良しの1
0410デフォルトの名無しさんNGNG
っていうか、 >>367 のコードだけみて
「これはオブジェクト指向的か？」っていう質問に
Yes でも No でも答えを出せる時点で思い込み厨だろ。

InputStream is = new FileInputStream("filename");
int b = is.read();
is.close();

これなら多少 OO 的だけどな。
0411デフォルトの名無しさんNGNG
プロの"逝って良し"なわけね。確信犯なのね。
おかげで、いつになく盛り上がったよ。

良くそんな頭の悪い文章、恥ずかしげもなく自信満々
な文体でかけるね。えらい。
0412プロの逝って良しの１NGNG
┐(；´へ｀)┌　
0413デフォルトの名無しさんNGNG
>>412
Javaつかってるなら、JDKのコアAPIライブラリを、便利で綺麗で
らくちんだと感じたことは、ないのかな？
0414デフォルトの名無しさんNGNG
>410
read() がストリームのメソッドであることがOO的
ファイルハンドルとかファイル名（ﾌﾟ を指定してないし
0415プロの逝って良しの１NGNG
>>413
問題が違いますが何か？

綺麗とは思わないし。
0416314NGNG
>>408
おー、すまんすまん。
javaは素人なもんでトンチンカンなことをいっているな。
今調べて鬱になったよ。ごめんな、素人で。

ぢゃあ、それを踏まえた上で。。。
>>367 が 非OO で
>>386 が OOだとしたら、
ファイルから read メソッドで値を読み込むのが 非OOで
シリアライズで取得するのが OO ?

たしかにオブジェクトをシリアライズしているわけで OO であるとは
間違いないのだが、それはちょっと違うんぢゃない?
0417ＯＯ派 ◆roi4uMcE NGNG
ＯＯ派はなんのためにレスしてるの？
0418410NGNG
>>414
たしかにメソッドを使うのはオブジェクト指向だけど、
それだけじゃ「シンタックスシュガーだ！Cでもできる」派に負けてしまうよ。
(この例(>>367のコードね)だとCでもできる派の意見も、もっともだと言える)
0419デフォルトの名無しさんNGNG
>>417
頑固馬鹿の代表者みたいなスレ主が、リクエストにどんなレスポンスを
返すのかを調査し、それをもって自社の馬鹿年寄との対話を行う上での
自衛策を構築する際の参考にするため。
0420ＯＯ派 ◆roi4uMcE NGNG
>>419
アンチと年齢は関係ないと思うけど…
0421デフォルトの名無しさんNGNG
>>347

遅レスすまねえが一言いわせろ。

>「最良のコードは上から下へと乱れなく読める手続き型である」

あんたメソッド使用を禁止したうちの化石チックプロジェクトリーダーですか？
0422ＯＯ派 ◆roi4uMcE NGNG
あげてしまった(鬱
0423デフォルトの名無しさんNGNG
>>410
まあ、おちけつ。

まず、>>367は例外処理をどうスマートに解決するかという例題として出されたものだろ？
ところが>>367は例外がstream経由でthrowされることはあっても、>>367のソースではcatchされてない。
streamオブジェクト内でcatchしていることはあっても、な。

とすると、FileInputStreamで外に出てくる可能性がある例外を宣言している点ぐらいしか
>>367のソースと例外処理の接点はない。
したがって、FileInputStreamの例外の宣言やFileInputStream自体の実装はOO的かどうかという事になる。
するとやはり、FileInputStreamはOO的に実装されていると見るのが自然じゃないのか？

それともFileInputStreamはOO的ではないと言うのか？
0424あるoo派 ◆L3/G8//E NGNG
つまりは模擬戦なわけだ。
戦場では必要なしと言ってしまう馬鹿者を戦場でやっつけるためのね。
0425デフォルトの名無しさんNGNG
OO使いたければ、使うがよし。
使いたくなければ、使わんでよし。

500km離れた地点へ行くのに、車や、高速バスなどで行くのが
普通だろうが、
原付でもよいのだ。自転車でも。
原付で行けば、交通費1000円だ。
問題はどこに重きを置くかによるだけで、
どーしようが、勝手にしろ。
0426デフォルトの名無しさんNGNG
見てるとこのスレのアンチOO厨は
かなりのOO信者であるように見受けられるね。
0427ＯＯ派 ◆roi4uMcE NGNG
>>425
そう思う。
0428デフォルトの名無しさんNGNG
>>425
全然関係ないけど...
> 原付で行けば、交通費1000円だ。
微妙に正しい値なんだけど、経験者 ?
0429デフォルトの名無しさんNGNG
ばれたか（ﾜﾗ
0430デフォルトの名無しさんNGNG
つまり日本の端から端まで行くのって結構安いのね。
0431デフォルトの名無しさんNGNG
>>430
でも時間がかかればかかるほど宿泊費や食費が増えるし・・・・
0432プロの逝って良しの１NGNG
>>421
いや、俺は機能が独立してればメソッド化すべきだと思うね。
俺のソース３－４行のメソッド多いし。
0433プロの逝って良しの１NGNG
>>423
いや>>354,355に対するレスです。
0434プロの逝って良しの１NGNG
話の流れを書くと
ＯＯはともかくＯＯＰＬはいいじゃん
　　　↓
ＪＡＶＡはポインタ無いから糞
　　　↓
ポインタ無いと何が困るの
　　　↓
・・・とか・・とか・・・コールバックとか・・・どか
　　　↓
インターフェースで出来るじゃん
　　　↓
0435プロの逝って良しの１NGNG
履歴に依存する場合は出来ない
　　　　　↓
話が飛んでイベント機構の隠蔽とニュータイプ手続き型の話に
　　　　　↓
イベントが隠蔽されたコードの例>>367
　　　　　↓
思いっきりオブジェクト指向じゃん>>372,375
　　　　　↓
（話が変わってるが）いやオブジェクト指向ではない
　　　　　↓
じゃオブジェクト指向にしたコードをみせてよ
　　　　　　↓
で、>>386　　　　　
0436ＯＯ派 ◆roi4uMcE NGNG
いつまで続くんだろう…
0437デフォルトの名無しさんNGNG
>>434,435
殊勝ﾀﾞﾅｧ
0438デフォルトの名無しさんNGNG
>>435
じゃあ>>367がオブジェクト指向でなくて>>386がオブジェクト指向だという理由は？
0439プロの逝って良しの１NGNG
前者は単なるデータを扱い、後者はオブジェクトを扱っている
0440プロの逝って良しの１NGNG
とーとろじー
0441プロの逝って良しの１NGNG
みたいに聞こえるかもしれんが・・・
0442ＯＯ派 ◆roi4uMcE NGNG
なんでsageてるの？
0443プロの逝って良しの１NGNG
別の説明

前者は外部のプログラムがデータの出し入れを行うが
後者はオブジェクト自身がデータの出し入れを行う機構を備えているとみなされる。
0444デフォルトの名無しさんNGNG
ageるとバカが来るから
ギコナントカとか
0445プロの逝って良しの１NGNG
さっきの２連レスでsage設定してただけ。
0446ＯＯ派 ◆roi4uMcE NGNG
偽物かと思った。
0447デフォルトの名無しさんNGNG
>>1は、これ読んで、もっと煽り方を勉強汁

【デベロッパー: 日本語が読めず、テストファーストが嫌いなプログラマ】
http://slashdot.jp/article.pl?sid=02/09/08/0734254&mode=thread

0448プロの逝って良しの１NGNG
スネークマン・ショーのパロディーですか？
0449デフォルトの名無しさんNGNG
ネタだと分るように書いてあるのにマジレスするのはバカだけど
わざとマジギレ反応をして盛り上げるのも宴会テクですよ
0450ＯＯ派 ◆roi4uMcE NGNG
>>425の言う通り自分が好きな言語を使うということで終了。
0451デフォルトの名無しさんNGNG
>>443
> 後者はオブジェクト自身がデータの出し入れを行う機構を備えているとみなされる。

惜しい。
「オブジェクト自身が他のオブジェクト(シリアライザ)を使って自身をデータオブジェクト化することができ、
かつ、その後他のオブジェクトが元のオブジェクトを復元することができる。」

そのオブジェクト自身はシリアライズに参加してはいるがシリアライズしている主体ではないことに注意ね。
0452デフォルトの名無しさんNGNG
つーか、じゃあ>>443に聞くけどさ、

Javaのように整数がobject typeじゃない言語ならば>>443のように言えなくもないけど、
Smalltalkのように整数のオブジェクトな言語ならばどうなるんだろうね？
読み取るのが整数だろうが文字列だろうがバイト列だろうが、
みんなオブジェクトなんですが。
0453デフォルトの名無しさんNGNG
　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜ OO厨のWeb掲示板まだかよ？
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻

0454デフォルトの名無しさんNGNG
ﾟДﾟノ 掲示板のひとつやふたつ早くOOで作ってみろよ。ｺﾞﾙｱ！
0455デフォルトの名無しさんNGNG
Javaならいくらでもあるだろ
ゴーグルくらいすれよ
http://www.hellohiro.com/jspbbs.htm
http://hosting.yoko.ne.jp/servlet/SampBBS01
http://hosting.yoko.ne.jp/jsp/SampBBS.jsp
http://www.asahi-net.or.jp/~jz6h-ymmt/servlet/sv20011202.htm
0456デフォルトの名無しさんNGNG
>>455
自分で作ることは避けるんだな（藁
再利用性に優れている、仕様変更に強いことを
証明してもらおうと思ったのだが。
0457デフォルトの名無しさんNGNG
>>456
OO厨の同士へ
　アンチの術中にはまらないように！
0458デフォルトの名無しさんNGNG
>>454は他人のコードをパクるしか能がないPerl廚とみた。
0459デフォルトの名無しさんNGNG
> >>454は他人のコードをパクるしか能がないPerl廚とみた。
ﾟДﾟノ そういう>>458はパクッても完成させられないC#厨と見た。

0460デフォルトの名無しさんNGNG
ご自慢御のＰｅｒｌ掲示板はどこ？>>459
0461デフォルトの名無しさんNGNG
>>455
ソース見たけど、ここのOO厨って
オブジェクト指向設計って何か分かってるのかな？
0462デフォルトの名無しさんNGNG
>>461
クラスを使うってことでしょ？(^0^=)
0463デフォルトの名無しさんNGNG
ぜひとも貴殿にご高閲賜りたい>>461
0464デフォルトの名無しさんNGNG
>>455

OO信者が紹介してくれたページの掲示板のソースだが・・・
も少しオブジェクト指向設計らしいのはないのか？
つーかおまいらが作れよ。ﾟДﾟノ

> public void do(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> PrintWriter out = response.getWriter();
> out.println("<html>");
> out.println("<head>");
> out.println("<title>掲示板</title>");
> out.println("</head>");
> out.println("<body>");
> out.println("<h1>掲示板 No.1</h1>");
> out.println("<form method=post>");
> out.println("<table>");
> out.println("<tr><th>名前</th><td><input type=text name=\"userName\"></td></tr>");
> out.println("<tr><th>題名</th><td><input type=text name=\"subject\"></td></tr>");
> out.println("<tr><th>内容</th><td><textarea name=\"content\" rows=5></textarea></td></tr>");
> out.println("</table>");
> out.println("<br>");
> out.println("<input type=submit value=\"投稿\">");
> out.println("<input type=reset value=\"クリア\">");
> out.println("</form>");
>
（略）
> out.println("</body>");
> out.println("</html>");
> }

0465デフォルトの名無しさんNGNG
>>464
なんか実は結構詳しいみたいね。
OO知らないとケナすにも取り付くしまがないしね。
アンチ巨人が必死に巨人戦見るような物か？
0466デフォルトの名無しさんNGNG
ﾟДﾟノ こんなページもあるぞ、ｺﾞﾙｧ
判断はおまいらにまかせる。

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
0467マ板でがいしゅつNGNG
有名なネタじゃん
0468デフォルトの名無しさんNGNG
>>465
というか構造化プログラム以前の糞ソースじゃねーか。
OO厨ってプログラムの善し悪しも分からないのにOOを語ってんのかよ。

この前日本でワールドカップがあった時、解説者とか言う肩書きで
サッカーのルールも知らん奴がのさばったことがあった。

OO厨もそれと同じ、OOどころかソースの善し悪しも分からないのに
OOという流行に踊らされるピエロ。

サッカーやOOは嫌いではない、というかOO自体は有効な技術だと思っている。
しかし、ソースの善し悪しも分からないOO厨は必要なし。
0469 ◆k/Ubp.Kg NGNG
キチンとOO使えている人は綺麗な設計・実装できるし, OO以外でもそれなりのコード書けると思うんだけど….

# 俺? ﾍﾀﾚなんでもう非OOPLは触れませんです,ハイ.
0470デフォルトの名無しさんNGNG
>>469
能書きはいいから早く作られよ（作れるんだったらな）
0471100NGNG
>>464
掲示板の作者に代わって反論。

1. HTMLの出力が汚く見えるのは当然。ﾂｯｺﾑ方がおかしい。
2. この掲示板の規模のアプリならこのくらいの設計は妥当。ﾑﾀﾞにOOするより断然いい。
3. 464のコードから、以下の行を省いてるのに作為を感じる。
> if (msgList != null) {
>for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> BbsMsg msg = (BbsMsg)it.next();
> out.println("<hr>");
> out.println("<table>");
> out.println("<tr><th>名前</th><td>" + msg.getUserName() + "</td></tr>");
> out.println("<tr><th>題名</th><td>" + msg.getSubject() + "</td></tr>");
> out.println("<tr><th>内容</th><td>" + msg.getContent() + "</td></tr>");
> out.println("</table>");
> }
> }

まあ、OOな掲示板を出せと言われてこれらの掲示板を示した 455も不用意といえば不用意。
0472デフォルトの名無しさんNGNG
>>471
分かったから早く作れ。
0473デフォルトの名無しさんNGNG
>>472
まず仕様を決めたほうがいいのでは？
0474デフォルトの名無しさんNGNG
>>471
武士の情けじゃないのか？
ところで、１件目が出力されないのって仕様？
>for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> BbsMsg msg = (BbsMsg)it.next();

普通こうだろ？
for (Iterator it = msgList.iterator(); it.hasNext();it.next()) {
BbsMsg msg = (BbsMsg)it;

１件目を出したくないならListIteratorを使って
for( ListIterator it = msgList.listIterator(1); it.hasNext();it.next()) {
BbsMsg msg = (BbsMsg)it;

ま、１件目を特別視したいってことは設計が間違っている可能性が高い。
0475100NGNG
じゃあ、472が非OOの掲示板を書いてよ。
OOに書き換えてみるからさ。
0476デフォルトの名無しさんNGNG
>>475
>>455にJavaで書かれた非OOの掲示板がイッパイあるけど、それでは不満なの？

# 前もこんな流れがあったな
0477デフォルトの名無しさんNGNG
>>475
漏れは↓の掲示板を使ってるから
http://www.rescue.ne.jp/cgi/minibbs-ic/
とりあえずは、これと同等の機能をOOで実現してくらはい。
趣旨はOOは本当に再利用性、仕様変更に強いかの検証です。
本当に作ってくれるのなら、おながいします。
0478100NGNG
>>476
>455にJavaで書かれた非OOの掲示板がイッパイあるけど、それでは不満なの？

うん。
455で示されているやつは書きかえる気しないけど、472が書いたやつなら書きかえる気がする。
0479デフォルトの名無しさんNGNG
オブジェクト恥垢
0480100NGNG
>>474
> >for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> > BbsMsg msg = (BbsMsg)it.next();
>
> 普通こうだろ？
> for (Iterator it = msgList.iterator(); it.hasNext();it.next()) {
> BbsMsg msg = (BbsMsg)it;

漏れはこうする事が多いです。
いろいろやり方があるのね。

Iterator it = msgList.iterator();
while (it.hasNext()) {
BbsMsg msg = (BbsMsg)it.next();
...
}


> ま、１件目を特別視したいってことは設計が間違っている可能性が高い。

禿胴。
0481100NGNG
>>479
ﾜﾗﾀ
0482デフォルトの名無しさんNGNG
オブジェクト指向は戦場では必要なし！とか言っている椰子のおかげで仕事場が
戦場になる説はキシュツですか？
0483デフォルトの名無しさんNGNG
>>477

【OO厨によるオブジェクト指向設計のWeb掲示板開発が決定！】

　　∧＿∧　　ﾄﾞｷﾄﾞｷ
　 （ ；´∀｀）　ちんこ勃ってきた。
　 人　Y /
　(　ヽ し
　（＿）＿）
0484デフォルトの名無しさんNGNG
>>480
１件目が出力されないのって仕様？
１件目から出したい場合どうするの？
> Iterator it = msgList.iterator();
> while (it.hasNext()) {
> BbsMsg msg = (BbsMsg)it.next();
> ...
> }
0485デフォルトの名無しさんNGNG
>>477　

そ　れ　は　お　ま　え　が　作　っ　た　の　か　？
0486100NGNG
>>477
>>>475
> 漏れは↓の掲示板を使ってるから
> http://www.rescue.ne.jp/cgi/minibbs-ic/
> とりあえずは、これと同等の機能をOOで実現してくらはい。
> 趣旨はOOは本当に再利用性、仕様変更に強いかの検証です。
> 本当に作ってくれるのなら、おながいします。

ぐげっ、perlっすね?
5行以上の perlのソースはクラクラしてくるんだよね。
一応目は通してみますが。

472が書いたソースなら perlでもがんばってみるけどさ。
0487デフォルトの名無しさんNGNG
つーかここで聞かないで作者にきけよおまいら、、、
0488デフォルトの名無しさんNGNG
>>483
　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜ これでやっとこのスレも新しい段階に入れるな。ｶﾞﾝｶﾞﾚ
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻
0489デフォルトの名無しさんNGNG
レガシー野郎の夢の宴age
0490デフォルトの名無しさんNGNG
おまゑら戦場とやらで撃ち合って市に絶えなさい
ガンガレ
0491デフォルトの名無しさんNGNG
かなり久しぶりに書き込むが、ここは
perlしか書けない厨房
Cしか書けない老兵
がタッグ組んでるのか?

前者は微笑ましい無害な連中で 後者は職場では非常に有害な連中だと
個人的は思っているが、まぁそれはおいといてだ。後者の連中は、厨房
ドモと組むことに恥ずかしさを感じないのか?

一 応 ベ テ ラ ン だ ろ ? お 前 ら 。


0492100NGNG
>>484
471のコードはちゃんと1件目から出力されますね。
ちゃんとコード読まずに発言してました。
ごめんなさいごめんなさい。

・・・逝ってきます。
0493デフォルトの名無しさんNGNG
>>491
じゃあそいつらの相手は
・Javaでプログラムを書くことをOOと勘違いしてる奴
・OOで掲示板を書くと豪語しながらforとwhileの使い分けも知らない奴
だな。壮絶な試合になりそうだ
0494491NGNG
>>493
OOD是非はともかくとしてだ(重要)。

そういうOO厨(と言うんですか?)でも、老兵よりマシ。

老兵は "OOPLを使えば堅牢なコードを書くことが可能である" っていう、
そのうち小学生でも実体験で理解しそうな事すら認めようとしないからな。

0495デフォルトの名無しさんNGNG
>>486
> ぐげっ、perlっすね?
> 5行以上の perlのソースはクラクラしてくるんだよね。
> 一応目は通してみますが。
> 472が書いたソースなら perlでもがんばってみるけどさ。

漏れはPerlも使えるけどさ、この掲示板は使ってるだけで
漏れが書いた奴じゃないよ。
また結果的に同じ機能を実現してもらえればいいし。
言語は>>100はJava使いのようだからJavaでいいよ。
0496100NGNG
>>493
>・OOで掲示板を書くと豪語しながらforとwhileの使い分けも知らない奴

480から、どうやって「for と whileの使い分けも知らない奴」という結論を導いたかをお聞かせ願えませんか?
0497491NGNG
>>493 の立場は何だ? Haskell大好き とかなら少し尊敬する。
0498デフォルトの名無しさんNGNG
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　辞めるなら今のうちですよっ
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　>>100　 ／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　そ、そうだよなっ
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　 　 　￣　　　=======　　＼
0499デフォルトの名無しさんNGNG
>>497
厨房同士の馴れあいスレなんだからHaskellとか言っちゃダメダメ。

0500デフォルトの名無しさんNGNG
>>494
×：OOPLを使えば堅牢なコードを書くことが可能である
○：ある一定規模以上のプロジェクトでは
　　OOPLを正しく使えば堅牢なコードを書くことも可能である
0501デフォルトの名無しさんNGNG


>>100 が 敵 前 逃 亡 す る に 10000ｸﾗｽ
0502デフォルトの名無しさんNGNG
> 10000ｸﾗｽ
禿げワラ
0503デフォルトの名無しさんNGNG
>>500
走り書きでもOOPLのほうが堅牢だろ。
0504500NGNG
むずかしいこと何も考えなくていいんだから。
数十行のC++ (with STL)はperlみたいな感じだなぁ。
0505デフォルトの名無しさんNGNG
504の名前の500は503の間違いネ。
0506100NGNG
>>495

495=472?

おれひとりでコード書くのはなんだか悔しいんだよね。心狭いんで。

perlで良いので 472が書いてくれれば、モチベーションが高められるんだけど。
>>475の発言は >>472の反応してのことだしさ。
0507デフォルトの名無しさんNGNG
504の気分をちゃんと理解できる奴がいないに1票

0508100NGNG
>>501
正直、言わなきゃ良かったなと思わなくもないです。
0509デフォルトの名無しさんNGNG
おいおい。おめーらこんなことで争ってるんじゃねぇよ。
VB厨もVB.NETでオブジェクトばりばりやってんだぜ？
VB厨ですらオブジェクト指向やってんのに、
今時構造化かよ。つーかおまえら構造化ちゃんと
できんの？
制御文使うだけで構造化できてるなんて思うなよ。
構造体をちゃんと定義して使え。これ重要だ。
それができて初めてオブジェクト指向へステップアップ
できんのさ。まぁ、OO厨には荷が重いかな。
0510504NGNG
>>509
もちろんネタだよな?
0511デフォルトの名無しさんNGNG
>>510
ネタのつもりじゃないけど？
図星だった？悪いねぇ。（ｗ
0512504NGNG
どのへんがどう図星なの?
0513デフォルトの名無しさんNGNG
構造体をちゃんと考えて作ってっか？ってこった。
ちゃんと考えとかないと、ロジックも冗長なものが
できあがってしまう可能性があるわけだが。
それができないのに、OOなんてできないよ？
クラスライブラリ使ってOOﾊﾞﾘﾊﾞﾘだぜ。ってなら
それでいいけど。（ｗ
0514504NGNG
組み込み以外ではもう随分Cは使っていませんね。
0515デフォルトの名無しさんNGNG
おまえもう発言しない方がいいかもよ>>504=503
OOPLをオブジェクト指向ライブラリとか思ってるだろ（ﾊｹﾞﾜﾗ
0516504NGNG
>>514
日本語でお願いします
0517504NGNG
515、か。
よくまちがえるな。
0518デフォルトの名無しさんNGNG
オブジェクト指向ライブラリって何だよ（藁

0519デフォルトの名無しさんNGNG
走り書きでもOOPLのほうが堅牢だろ。

おまえのこの発言のことを言ってんだよ。
0520493NGNG
>>496
> 「for と whileの使い分けも知らない奴」
for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、
その証拠にwhile文で書いて間違えてる

>>497
OO厨が嫌い。OOについては勉強中なので保留。
0521504NGNG
>>519
なるほど、よくわかった。謝罪する。

0522デフォルトの名無しさんNGNG
>>519は>>500についてはどう考えてるの?
0523デフォルトの名無しさんNGNG
>>506
>おれひとりでコード書くのはなんだか悔しいんだよね。心狭いんで。

目的は本当にOOは再利用性と仕様変更に強いかの検証なので、
申し訳ですがオブジェクト指向派の>>100がひとりで作ってください。
>>100以外の人でも可です。
0524デフォルトの名無しさんNGNG
>>522
一言で言うと、
当たり前。

構造化に置き換えてもなんらおかしいことはないだろ？

「正しく使えば」
これは逃げ。
0525522NGNG
え、よくわかんないんだけど、519はOO好きなの嫌いなのどっち?
0526デフォルトの名無しさんNGNG
>>525
両方だ。
0527100NGNG
>>523
> 目的は本当にOOは再利用性と仕様変更に強いかの検証なので、
> 申し訳ですがオブジェクト指向派の>>100がひとりで作ってください。
> >>100以外の人でも可です。

検証したいのは、「オブジェクト指向が手続き指向に比べて再利用性と仕様変更に強いこと」でしょう。
やっぱり欲しいでしょう。

っていうか、おれは 472に作って欲しいだけなのです。
粘着ｳｻﾞ、と言われるでしょうが。
0528デフォルトの名無しさんNGNG
>521
やたらヨワいな(w
0529ループNGNG
>>500
スクリプト言語以外で走り書きしろって言われた場合に現実的な選択肢としてC,C++,C#,Javaを考えると、503であってる気もする。519の指摘の通り、OOPLだからという理由ではないよ。
文字列が使える、typesafeなコンテナがある、というあたりのしょーもない理由ね。それでも俺はCでそういうこまごましたコード書くとよく間違えるね。厨房だし。

0530デフォルトの名無しさんNGNG
>>524
> 構造化に置き換えてもなんらおかしいことはないだろ？
どんな手法にしても正しく使わないと危険
そしてOOは構造化以上に正しく使うことが難しい技術

特にC++の場合は演算子の振る舞いを変えることができるので、
最悪の使い方を行えばグローバル変数乱用以上の打撃を与えることも可能
0531デフォルトの名無しさんNGNG
どこで拾ったテンプレートですか?漏れにも教えて。>>530
0532デフォルトの名無しさんNGNG
どした？今日のOO派のレベルは著しく低いぞ。
今度は教えて君か？
0533デフォルトの名無しさんNGNG
>>532
ネタじゃない？
0534デフォルトの名無しさんNGNG
>>530
日経BPあたりの文系の記者でも書けそうではある
0535デフォルトの名無しさんNGNG
ttp://www.h5.dion.ne.jp/~ikeruze/nae/sis1.htm
0536デフォルトの名無しさんNGNG
>>527

申し訳ないですが少なくとも漏れを頼らんでください。
おながいすます。
0537デフォルトの名無しさんNGNG
なんで誰も'掲示板くらいperlで'、って言わないんだ？OOだろうが何だろうが適材適所だろ。
掲示板でOOの良さ(?)を行かそうと思ったら/.みたいな大がかりなモン作らないと分からん。
仮にできあがっても>>367関連の話しと代わらんぜ。
0538デフォルトの名無しさんNGNG
/.のシステムってそんな大掛かりか？
にしてはずいぶん使いにくいよ。
0539デフォルトの名無しさんNGNG
>>537
大言壮語はいいから、早く作ってくれぃ。
0540デフォルトの名無しさんNGNG
> なんで誰も'掲示板くらいperlで'、って言わないんだ？
537がperlで掲示板を作るみたいです。
0541100NGNG
>>520
> for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、

for文で Iteratorの初期化を行うと分かりやすいケースは、Iteratorの初期化と Iterationが隣接している場合のみ、それ以外は while文を使用する方が簡潔だと思う(オレはね)。
で、あるときは for文、あるときは while文となると、コードの一貫性がなくて読みづらいよね。
だからオレは常に whileを用いている。
これがおれの「forとwhileの使い分け」。

> その証拠にwhile文で書いて間違えてる

どこが間違ってるかもう少し詳しく教えていただけませんか?
以下のサンプルコードで指摘していただけると助かります。

// Omaemona.java
import java.util.*;
public class Omaemona {
static Iterator getIterator() {
String[] strings = { "o","m","a","e","m","o","n","a" };
return Arrays.asList(strings).iterator();
}
static void printIterator(Iterator itr) {
while (itr.hasNext()) {
System.out.print(itr.next());
}
}
public static void main(String[] args) {
Iterator itr = getIterator();
printIterator(itr);
}
}
0542デフォルトの名無しさんNGNG
自分で作らないクセに人には作れっていうんだな。
0543デフォルトの名無しさんNGNG
だってただの煽りだもん
0544デフォルトの名無しさんNGNG
　　　∧∧＿__　　http://www.muuz.ne.jp/hosting/　　
　／(*ﾟーﾟ)　／＼ 月額200円コバルト激安レンタルサーバーホスティング
／|￣∪∪￣|＼／　150MB大容量。電子メール最大20個作成可能
　　　　　　　　　　　サブドメイン、独自ドメインOK CGI/SSI/PHP/ASP/JSP利用可能 　
0545100NGNG
>>536
ﾗｼﾞｬ。粘着ｺﾞﾒｿﾈ。
0546デフォルトの名無しさんNGNG
Ruby最高ォォォォォォッ！！！！！！！！！！！！！！
0547デフォルトの名無しさんNGNG
あぁ。このスレ好きだ。
この殺伐とした馴れ合いが。
あぁ愛してるよ。ﾁｭｯ!
0548プロの逝って良しの１NGNG
>OOPLを使えば堅牢なコードを書くことが可能である

そうか・・・・

int　a[1];
for( int i=0;i<2;i++ ) a[i]=0;


0549デフォルトの名無しさんNGNG
>>548
(ﾟДﾟ)ﾊｧ?

JavaならArrayIndexOutOfBoundsExceptionがスローされるし、
C++ならオーバーヘッドを気にしないならoperator[]()をオーバーロードして
safe array使えますが何か？OO関係ねーよ、ボケ。
0550デフォルトの名無しさんNGNG
>OOPLを使えば堅牢なコードを書くことが可能である
を
>OOPLを使えば全てのコードが自動的に堅牢になる
と勝手に読み替える莫迦
0551デフォルトの名無しさんNGNG
おいおい。やめろ。
もう既に俺が突っ込んで、
発言主も謝っているだろう？
無理に続けようとせずともよい（ｗ
0552デフォルトの名無しさんNGNG
おいおい、このスレは粘着で成り立ってるんだろうが。
もっとベトつけよお前ら。
0553デフォルトの名無しさんNGNG
蒸し返してきたのは逝って良しの１だろ。
0554プロの逝って良しの１NGNG
非ＯＯＰＬでも可能だから意味無くなっちゃうじゃん。
意味の無い解釈と意味のある解釈と二通りあったら
普通は意味の有る解釈をするがねー。
0555プロの逝って良しの１NGNG
ああ、終わってたのか。ｺﾞﾒｿ
0556デフォルトの名無しさんNGNG
>>552
わかった

552とオブジェクト指向は戦場では必要なし
0557デフォルトの名無しさんNGNG
まったくぅ。血の気が多い奴ばっかでやんなっちゃう。ﾜﾗ
0558デフォルトの名無しさんNGNG
あまり逝って良しにかまうなよ。
彼はここが余りに気になって仕事中から帰宅してまで
しょぼついた目で画面に貼り付いて
右腕の痛みをこらえつつ際限なくリロードし続けてるだぞ。

才能のないコーダが集中力と健康を失ったときどうなるかを
ちょっとは考えてやってくれないか。
0559デフォルトの名無しさんNGNG
んー。ならあげんなよ。
0560デフォルトの名無しさんNGNG
>>559
>しょぼついた目で画面に貼り付いて
ちょっとでもスレ探すのを楽にしてあげようという>>558の計らいだよ。
0561493NGNG
>>541
> for文で Iteratorの初期化を行うと分かりやすいケースは、Iteratorの初期化と
> Iterationが隣接している場合のみ、それ以外は while文を使用する方が簡潔
だと思う(オレはね)。
つまり、>>480のケースでは（以下再掲）
> Iterator it = msgList.iterator();
> while (it.hasNext()) {
> BbsMsg msg = (BbsMsg)it.next();
> ...
> }
for文の方がよいと認めるということか？
forで初期化した方が変数名のスコープが小さくなるという利点も考えとけよ。

> 以下のサンプルコードで指摘していただけると助かります。
public static void main(String[] args) {
Iterator itr = getIterator();
printIterator(itr);
printIterator(itr);
}
printIterator()って何回も呼べない仕様なの？
前で呼んでないかどうか調べないといけない不便なメソッドだな。

printIterator()中で何か中間オブジェクトを初期化させる必要がないかい？
そうすると上記の再掲コードと同じようなことにならないかい？
0562デフォルトの名無しさんNGNG
552は将来大物になる、もしくはもう大物だ。
そんな気がするんだ。
漏れが保証するよ。
0563プロの逝って良しの１NGNG
どうでもいいけど、だっせえデザインのイテレーターだな。
0564デフォルトの名無しさんNGNG
>>561
全面的に同意。
0565プロの逝って良しの１NGNG
なんか今日は外が駄スレの嵐だな。
0566100NGNG
>>561
まず最初に、そちらの質問にお答えします。

(Q1) 480のケースでは for文の方がよいと認めるということか？
(A1) 認めます。
ですが私は whileを使います。理由は 541で述べた通りです。
「forで初期化した方が変数名のスコープが小さくなるという利点」よりも 541の方が私の中では優先度が高いです。
もう一度言いますが、私は「forと whileを使い分けて」います。
それを「for と whileの使い分けも知らない奴」とあなたが思い込むのは自由ですが。

541のコードで
(Q2) printIterator()って何回も呼べない仕様なの？
(Q3) printIterator()中で何か中間オブジェクトを初期化させる必要がないかい？
(Q4) そうすると上記の再掲コードと同じようなことにならないかい？

(A2) printIterator()は何度も呼べます。ただし itrを初期化せずにもう一度 printIteratorを呼ぶのは Iteratorの使い方としては間違いです。
JCF(http://java.sun.com/docs/books/tutorial/collections/index.html)と、デザインパターンの Iteratorパターンを読んでみてください。
簡単に言えば Q2でやりたがっている事は以下のコードと同じようなことです。

int itr = 0;
String[] array = {"A", "B", "C"};
for (; itr < array.length; itr++) {
System.out.println(array[itr]);
}
for (; itr < array.length; itr++) {
System.out.println(array[itr]);
}

(A3) 必要ありません。中間オブジェクトは必要ありません。
(A4) なりません。
0567デフォルトの名無しさんNGNG
いつものことさ・・・
0568100NGNG
>>561
次にこちらから質問です。

496で
>480から、どうやって「for と whileの使い分けも知らない奴」という結論を導いたかをお聞かせ願えませんか?

とお願いしたところ

520で
>for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、
>その証拠にwhile文で書いて間違えてる

という回答をいただきました。
その回答に対して

541で
>> その証拠にwhile文で書いて間違えてる
>
>どこが間違ってるかもう少し詳しく教えていただけませんか?
>以下のサンプルコードで指摘していただけると助かります。

と 541のコードの中で while文のどこが間違えているかをお聞きしたところ
561の回答をいただきました。

が、この中では「while文のどこが間違えているか」の回答はいただけませんでした。

もう一度お伺いします。
541のコードの中で while文のどこが間違えているのですか?
0569100NGNG
>>563
>どうでもいいけど、だっせえデザインのイテレーターだな。

どうださいかをご指摘いただければ幸いです。偽者さん。
0570 ◆k/Ubp.Kg NGNG
>printIterator()って何回も呼べない仕様なの？
>前で呼んでないかどうか調べないといけない不便なメソッドだな。
おれは>>563ではないが、少なくともこの仕様はダサいと感じた。簡便性のために複数回コールできるように設計すべきかと。
0571プロの逝って良しの１NGNG
next()だけで充分。
hasNext()は余計。
0572100NGNG
>>570
566ではお答えになりませんでしょうか?
0573 ◆k/Ubp.Kg NGNG
>>571
じゃーどうするの？next()がnull返したら次の要素はないってコトにするの？
Iterator#next()がnullを返す事もあり得るんだから、hasNext()は必要。
0574 ◆k/Ubp.Kg NGNG
>>572
いや理屈は分かるけど、実用的ではないと思われ。
>簡便性のために複数回コールできるように設計すべきかと。
が俺の意見っす。
# 好みの問題だ、と言われればそれまでだけど。
0575100NGNG
>>571
>next()だけで充分。
> hasNext()は余計。

next()だけだと、どんなコードになるか教えていただけませんか?
0576プロの逝って良しの１NGNG
while( true ){
　　if( it.next()== null ) break;
・・・
}
0577 ◆k/Ubp.Kg NGNG
>>576
>>573
0578プロの逝って良しの１NGNG
while( true ){
　　if( ( a=it.next())== null ) break;
・・・
}
0579デフォルトの名無しさんNGNG
どっちでもいい事を
おまえは間違ってる、俺が正しい的な言い切りをするところがプロ１のすばらしい所だよね。
0580 ◆k/Ubp.Kg NGNG
>>578
（　ﾟдﾟ）ﾎﾟｶｰﾝ
それだと答えになってないでしょう？
0581デフォルトの名無しさんNGNG
ねえ、もしかしてすげーくだらねえ議論？
0582プロの逝って良しの１NGNG
nullは扱わない。
これ最強。
0583 ◆k/Ubp.Kg NGNG
>>581
その通りだと今、激しく痛感した…。
0584デフォルトの名無しさんNGNG
>>582
君の大嫌いなデザパタにそういうのあるねえ。プ
0585100NGNG
>>576
>while( true ){
> 　　if( it.next()== null ) break;
> ・・・
> }

だから JCFのドキュメント読んでって言ってるのに（ ´Д⊂ヽ

http://java.sun.com/j2se/1.4/docs/api/java/util/Iterator.html

これ以上要素が無い時に next()を呼んだ場合、NoSuchElementException例外が発生します。
よって、上記のコードは期待した通りには動きません。
0586100NGNG
>>574
ごめんなさい。
今日は疲れました。
また後日お答えさせていただきます。
0587デフォルトの名無しさんNGNG
今回の逝って良しの１のレベルの低さは半端でないねヽ(´▽｀)ﾉ
>>571-582のやり取りは禿しくﾜﾗﾀ
0588デフォルトの名無しさんNGNG
↑なんだかその仕様もクソっぽいね。
Javaerは大変だな。
デザパタにNullパターンって無かったっけ？
0589デフォルトの名無しさんNGNG
あ、↑は>>585のリンク先のことね。
0590デフォルトの名無しさんNGNG
>>プロの逝って良しの１
メンバ関数に見立てたファンクタによる動的継承についてどう思われますか？
0591100NGNG
>>590
ここで発言が止まっちゃうと、明日の朝が楽しくないので何か書いてもいい?
0592100NGNG
>>588
>↑なんだかその仕様もクソっぽいね。
> Javaerは大変だな。

だんだん慣れてきます。
毒されてるのかもしれません。＞漏れ

> デザパタにNullパターンって無かったっけ？

ありますね。
UnitTestする時によく使ってます。
スタブとして NullObjectを使うです。
すげー便利です。
0593 ◆k/Ubp.Kg NGNG
>>591
イイんでないの？確かにココで止まると面白くない。

>>588,592
Iteratorの仕様はアレゲだよね。Java使いでも結構賛否両論あってもいいような気がするんだけど、
意外と反論の声が上がらない。
0594デフォルトの名無しさんNGNG
まあ、言葉にするのもなんですが。

OOの真意の一つは、
自分はしょぼくないと思っているプログラマが色々と内容を
いじって欲しくないから閉じ込めたいって所だと思います。

ようは、世の中がほんとにできるプログラマの集団だったら
どんな言語も問題ないわけで。

真にOOを分かってる人々のプログラムは目からうろこが落ちそう。
なんでもいっしょか。
0595デフォルトの名無しさんNGNG
＞で、あるときは for文、あるときは while文となると、
＞コードの一貫性がなくて読みづらいよね。
＞だからオレは常に whileを用いている。
＞これがおれの「forとwhileの使い分け」。

つか、
「繰り返しを実現するには、構造化された方法(whileとか)と、
されていない方法(gotoとか)があるけど、構造化されないのは
読みづらいから、いっつも構造化構文の方をつかってるよ」
ってのは、
「構造化構文 と 非構造化構文を使い分けている」
と言えるのか？
なんつーか、「道は０人の男がいます」的違和感を覚えるﾅｧ
0596100NGNG
>>590
調査なし、資料なしで書くので間違い、ﾂｯｺﾐどころ満載かと思いますが。

JavaScriptの継承はこのタイプだったよね。
たしか Rubyもこの形式をサポートしていたはず。
使ったことはありませんが、新しくクラスを作らずにオブジェクトの振る舞いを変えれるのは便利そうだなと思います。
その場限りの、ちょっとした振る舞いの違いのために新しいクラスを作成するってことって結構あるよね (ねーか)。

クラスベースでない(プロトタイプベース?)オブジェクト指向言語ではこの形式が標準なのでしょうか?
0597100NGNG
>>595
>＞で、あるときは for文、あるときは while文となると、
> ＞コードの一貫性がなくて読みづらいよね。
> ＞だからオレは常に whileを用いている。
> ＞これがおれの「forとwhileの使い分け」。
>
> つか、
> 「繰り返しを実現するには、構造化された方法(whileとか)と、
> されていない方法(gotoとか)があるけど、構造化されないのは
> 読みづらいから、いっつも構造化構文の方をつかってるよ」
> ってのは、
> 「構造化構文 と 非構造化構文を使い分けている」
> と言えるのか？
> なんつーか、「道は０人の男がいます」的違和感を覚えるﾅｧ

むむ、forを全然使ってないくせに「forと whileの使い分け」で forが出てくるのがおかしい、ってことでしょうか?


関係ないけど、「つか、」て G某さんに似てる。
気のせい?
0598デフォルトの名無しさんNGNG
for (;;)
ってソースを見ると萎えるんですが。スレ違いですね。
0599デフォルトの名無しさんNGNG
「googleとyahoo？使い分けてるよ。
yahooは検索結果が糞だから使わないけどネ」
「'ゐ'は現代仮名遣いでは全然使いませんね。'い'だけ使います。
よって、私は'い' と 'ゐ' を使い分けてます。 」
ﾊｧ?使い分けてねーだろ、と思わない？

if( 1 ) use(A);
else if ( 0 ) use(Z);
を条件分岐と主張された気分。

「A,B,Cを使い分ける」って「A,B,Cを使っていて、条件により
A,B,Cのうち適切な物が選ばれる」ってことじゃないん？
0600デフォルトの名無しさんNGNG
>>598
ミクロな最適化テクの代表例みたいなもんだな。

まあ、今時のコンパイラならwhile (1)もfor(;;)に置き替えてくれるだろうけど、
昔は「while (1)は1を評価して条件分岐する分、遅い」と信じられていたし、
実際そうなるccが多かった。
0601デフォルトの名無しさんNGNG
>>595
俺は100じゃあないけど、
構造化された制御構造とgotoによる制御構造の違いを理解した上で
構造化された制御構造を採っているのであれば、
それは使いわけていると言えるんじゃない？
0602デフォルトの名無しさんNGNG
なんがほんとミクロなどうでもいい話になってるな・・・

結局プログラミング技法なんてのは制限にすぎない
制限する事によって効率的になる部分と、そうじゃな
い部分や制限内で実現不能になる部分が生まれる。

しかし、制限された世界しか知らなければ、それが世界
だと思っていまう。

　オブジェクト指向も、その世界を知らない事も、その
世界に漬かりすぎてしまう事もどちらも不幸な事だ。
0603デフォルトの名無しさんNGNG
>>602
ハゲ堂。つーわけで、終了ね。
0604デフォルトの名無しさんNGNG
どちらの世界もどっぷりはまった上でOOは糞と思ってますが？
0605デフォルトの名無しさんNGNG
>>604
くせー奴。肥だめにでもはまってたんだろ。
0606デフォルトの名無しさんNGNG
>>604
ハマったけどツカったことはないんですね
0607デフォルトの名無しさんNGNG
>>100
Perlでオブジェクト指向掲示板はいつごろ出来るのかな？
0608100NGNG
>>607
607が perlで掲示板を作ってからだよ。
あと、perlでOOは正直ｷﾂｲ。
0609デフォルトの名無しさんNGNG
そんな人のためにRubyがあると何度言えば分かるんだ。
0610100NGNG
>>609
漏れ Ruby好き。
Rubyのイテレータ(もう、そう言わないっけ?)はすばらしい。
あと、Smalltalkも内部イテレータなので萌える。

# ruby
array=["o","m","a","e","m","o","n","a"]
array.each { |item|
puts item
}

"smalltalk"
#('o' 'm' 'a' 'e' 'm' 'o' 'n' 'a') do: [:item|
Transcript show: item; cr
]

やっぱり、外部イテレータよりも内部イテレータの方が楽でいいよね。
0611デフォルトの名無しさんNGNG
過猶不及如
0612100NGNG
>>602
達人プログラマに「毎年少なくとも1つの新しいプログラミング言語を学習せよ」とありましたね。
ある言語の制限に慣らされた頭をリセットするには、とても有効な手段だと思います。

http://www.pragmaticprogrammer.com/loty/ の機械翻訳。
>毎年少なくとも1つの新しい[プログラミング]言語を学習してください。
>異なる言語は、異なる方法で同じ問題を解決します。
>いくつかの異なるアプローチの学習によって、あなたの思考を広げて
>慣習に差し込まれることを回避することを支援することができます。

ちなみに漏れは、毎年少なくとも1つの新しいプログラミング言語に挫折しています。
0613デフォルトの名無しさんNGNG
>>610
Rubyはよく知らないけど、Smalltalkの場合にはstreamによる外部イタレータもあるね。
| stream |
stream ← 'omaemona' readStream.
[ stream atEnd not] whileTrue: [Transcript nextPut: stream next]

元が配列でなくても、例えばファイルなら
| stream |
stream ← 'file.name' asFilename readStream.
[ stream atEnd not] whileTrue: [Transcript nextPut: stream next].
stream close
とか。
内部イタレータだけでできる事は限られてくるから、
外部イタレータも必要に応じてちゃんと用意しといたほうがいい。
0614偽者の１NGNG
発音は中間だからアレだが、書き言葉だとイタレータってのはちょっと抵抗があったり。
0615100NGNG
>>613
なるほど、streamは外部イテレータとしても使えちゃうんですね。感動ｼｽﾏﾀ。

> 内部イタレータだけでできる事は限られてくるから、
> 外部イタレータも必要に応じてちゃんと用意しといたほうがいい。

ふむふむ、勉強になります。
0616デフォルトの名無しさんNGNG
>>607
Perlじゃなくてもいいって言ってるじゃん。
0617デフォルトの名無しさんNGNG
#!/usr/bin/perl
@array = ("o","m","a","e","m","o","n","a");
foreach $item ( @array ) {
print "$item";
}

で、これってイテレータなの？イテレータって何？
0618デフォルトの名無しさんNGNG
繰返子
0619デフォルトの名無しさんNGNG
>>618
ﾜﾗﾀ
0620デフォルトの名無しさんNGNG
イッテモータ
0621プロの逝って良しの１NGNG
逝テレーター 次々に持ってくる奴
0622デフォルトの名無しさんNGNG
スレッドセーフなイテレータは、
イテレータ呼び出しの度に、毎回一から数えなおしている罠
0623100NGNG
>>617
> で、これってイテレータなの？イテレータって何？

617は内部イテレータっすね。

イテレータの明確な定義を見つけられなかったのですが、私は以下のように認識しています。

イテレータとは「繰り返し処理」を行うフレームワーク。
で、繰り返し処理を行う場合に
- フレームワークの利用者側で「繰り返し処理」の制御を行うのが外部イテレータ
- フレームワーク側で「繰り返し処理」の制御を行うのが内部イテレータ

繰り返し処理に「フレームワーク」という言葉も大袈裟な気もしたのですが、他に良い言葉が思いつきませんでした。
間違っていたらご指摘ください＞識者
0624デフォルトの名無しさんNGNG
>>612
さすがにC++知ってる人が
JAVAとかC#やると３時間くらいで、理解できてしまうというか、
それくらい同じというか。（DELも）
まあ、RUBYもPERLもオートマトン知ってれば、３時間で理解できるし・・・
LISPなんかはもっと早く理解できるよね。
でもprologは、使い道で悩みそうだね。
prologを他の言語から使うのはいいと思うけど、
prolog単体だとしょぼいね。
0625デフォルトの名無しさんNGNG
LOGO厨の俺でも3日でJavaを理解できたぞ
0626デフォルトの名無しさんNGNG
気のせい
0627デフォルトの名無しさんNGNG
なんでオートマトンがでてくんの？
クロージャとかそういう話？
0628プロの逝って良しの１NGNG
オートマトンだとおお！！！
…(((;ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0629プロの逝って良しの１NGNG
オートマトンと言えば・・・・Delphiスレを潰し、ギコ猫を2CHから
追い出したアイツ・・・・
0630デフォルトの名無しさんNGNG
Javaを理解するってなんだか曖昧だなぁ
0631デフォルトの名無しさんNGNG
>>629
えいとおーとぅーのことか？
0632デフォルトの名無しさんNGNG
オートマトン知ってれば、正規表現も習ってるだろ。
オートマトンなんて、まともな大学入ったら
１年か２年の時に習うよ。
0633デフォルトの名無しさんNGNG
じゃぁそこらの大学生に聞いてみ。
オートマトンって何ですか？って。
さーて何人答えられるやら・・・（ｗ
0634デフォルトの名無しさんNGNG
>>624
なっつかさぁ、マージャンできる奴が7ブリッジのルール覚えたからって
すぐに強くなるわけじゃないだろ。
基本は同じだけど､やっぱ違うところはある。まさに同じ問題に別のアプローチで
挑んでいるわけよ。

俺はその言語の「こころ」がわかるようになるには相応の時間がかかると思うよ。
0635プロの逝って良しの１NGNG
少年サンデーの読者は皆知ってたりする。
0636デフォルトの名無しさんNGNG
つーか、言語仕様を理解することとその言語を使えることには
大きな隔たりがあるということを>>624に教えてやってくだせえ。
さらに、それぞれの言語が仮定しているアーキテクチャで
効率的なプログラムを書けるということもまた別の事だってこともね。
0637デフォルトの名無しさんNGNG
>>634
考えてみればわかると思うけど、
言語って、制御構文＋αなの。
制御構文は、
if/else,while(),breakくらいしかない。

αはOOPLなら継承とポリもーフィズムの実現方法
RUBYとかPERLなら、言語に組み込まれたデータ構造とそのアクセスの仕方
くらいでしょ？
0638デフォルトの名無しさんNGNG
>>637
晒しあげていいでつか？
0639俺は東大NGNG
>>633
うちの大学の情報系の奴に聞いてみてください。
0640デフォルトの名無しさんNGNG
オートマトンについて学べるページってないすかね？
0641デフォルトの名無しさんNGNG
ちょっと違うけど、なんとなくわかると思うので
http://web.sfc.keio.ac.jp/~n96229sh/Research/page1.htm
0642デフォルトの名無しさんNGNG
>>641
おおっ。ありがとうございます。
0643デフォルトの名無しさんNGNG
つーか、セルラオートマトンはまだ工夫すれば面白そうな部分が残ってるけどね、
ただのオートマトンじゃ面白くもなんともねえなあ。
0644デフォルトの名無しさんNGNG
>>643
そりゃそうだけど、コンパイラは使ってる
0645デフォルトの名無しさんNGNG
>>634
×：まあ、RUBYもPERLもオートマトン知ってれば、３時間で理解できるし・・・
○：まあ、RUBYもPERLもBNF知ってれば、３時間で「文法だけ」は理解できるし・・・

普通言語を作る場合って、BNF書いてyacc & lex使うもんだけどな
yaccではオートマトンを使って実装されてるけど、そんなものは
yaccを実装する場合ぐらいしか必要ない。

また、文法を理解しても言語を覚えたことにはならない。
自然言語には言葉があり、プログラム言語にも関数がある。
言語特有の言い回し、慣用句があり、プログラム言語にもある。
君って英語の文法理解したただけで英語を話せるの？

# 英語だと英語でジョークを飛ばせれば、英語を使えると言っていいみたいだけど、
# プログラム言語だと何ができれば使えると言っていいんだろう？
0646デフォルトの名無しさんNGNG
>>623
> 617は内部イテレータっすね。
イテレータということは同意だね。

> イテレータとは「繰り返し処理」を行うフレームワーク。
個人的には
イテレータとは「コレクション（要素の集合を抽象化したもの）」を
操作する手続きを抽象化したものと定義したいな。

ということでOOPLでなくともイテレータは存在する。
0647100NGNG
>>574
ちょっと質問です。
「複数回コールできるように設計すべき」ってのは、printメソッドの引数に Iteratorを使わない方がいいんでない?、ってことでしょうか?

こんな感じで。

// Omaemona2.java
import java.util.*;
public class Omaemona2 {
static List getList() {
String[] strings = { "o","m","a","e","m","o","n","a" };
return Arrays.asList(strings);
}
static void print(List list) {
Iterator itr = list.iterator();
while (itr.hasNext()) {
System.out.print(itr.next());
}
}
public static void main(String[] args) {
List list = getList();
print(list); // うひょー
print(list); // 何回でも呼べちゃう
print(list); // まじすか?
}
}
0648100NGNG
>>646
そっちの方がしっくりきますね。
0649プロの逝って良しの１NGNG
粘着オートマトン馬鹿は去りましたか？…((;ﾟДﾟ)))ﾌﾞﾙﾌﾞﾙ
0650デフォルトの名無しさんNGNG
つーか「オートマトン」という言葉を使いたかっただけかと・・
0651 ◆k/Ubp.Kg NGNG
>>647
うん、だいたいそんな感じ。>>647が書いてるけど、
>イテレータとは「コレクション（要素の集合を抽象化したもの）」を
>操作する手続きを抽象化したものと定義したいな。
…ってコトなんで、引数としてIteratorを渡すのはなるべく避けたいな。俺ならそうする。

あと、くだらん突っ込みをするならprint(List)よりもprint(Collection)の方が良いかと思われ。
どのコレクションに対しても一意の方法でアクセスできるのがIteratorの利点だから、Listだけに
束縛するのは勿体無い。その用例ならIterator使わなくてもList.get(int)で代用できるんだから。
# もちろん、Listにあるメソッドをフルに使うっていうのなら話は別だけど。
0652デフォルトの名無しさんNGNG
>>651
>どのコレクションに対しても一意の方法でアクセスできるのがIteratorの利点だから
それ違うと思うよ・・
0653プロの逝って良しの１NGNG
イテレーターとは必要なデータを自動的に順番に取り出してくれる仕組みのことです。
カウンタやループ処理のことではありません。
0654デフォルトの名無しさんNGNG
>>651
genericのと混同してるっぽいね。
あれはたまたま。（名前を一緒にしてるのは偶然ではないが）
「一意の方法でアクセス」をイテレータが保証してるってわけでは無いよ。
0655 ◆k/Ubp.Kg NGNG
あうースマソ、勘違いっす。
0656デフォルトの名無しさんNGNG
>言語特有の言い回し、慣用句があり、プログラム言語にもある。
具体例教えて。

>○：まあ、RUBYもPERLもBNF知ってれば、３時間で「文法だけ」は理解できるし・・・
もう一回書き込み読んでね。
正規表現とかが、言語に組み込まれてるPLについての話ね。
もちろん使わなければ、JAVA等と同じだけど。
0657デフォルトの名無しさんNGNG
↑え、、、続けるの？（ｗ
0658プロの逝って良しの１NGNG
呼んじゃダメ―！！！
奴が来たらこの当たり一帯が火の海に・・・
…(((;ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0659 ◆k/Ubp.Kg NGNG
>>656
>>645
そのネタ、もう終わりじゃないの？
0660デフォルトの名無しさんNGNG
>>1って何様でしょうか？
0661プロの逝って良しの１NGNG
俺はあいたたた氏とは別人です。
0662（自称プロ）の逝って良しの１NGNG
改名しますた。
0663デフォルトの名無しさんNGNG
仮想関数なんて言葉も使ったけど、
virtualを日本語化しただけなんだよね。
仮想関数って何？とか思ったら、
継承先で実装しなきゃならんのよね。
もう馬鹿かと思ったよ。
純粋仮想関数なんてもう愚の骨頂だよね。
これ最初に見たときは名前の付け方が
意味不明すぎて笑えたよね。
0664デフォルトの名無しさんNGNG
で、だからなに？
0665デフォルトの名無しさんNGNG
>>664

あなたに言ったわけではありませんので。
何も答えなくていいですよ（ｗ
0666デフォルトの名無しさんNGNG
独り言は余所でやってほしいなぁ。
0667デフォルトの名無しさんNGNG
>>666
じゃあ他所でやってくださいね。
0668100NGNG
>>663
釣られてみるけど、仮想関数と純粋仮想関数がゴッチャになってると思われ。
「仮想関数って～継承先で実装しなきゃならんのよね。 」のあたり。

純粋仮想関数とかのネーミングが分かりづらいのは同意。
0669デフォルトの名無しさんNGNG
あーつまらんな。次のネタどうぞ。
0670デフォルトの名無しさんNGNG
>仮想関数って何？とか思ったら、
>継承先で実装しなきゃならんのよね。

もう馬鹿かと思ったよ。
0671デフォルトの名無しさんNGNG
あっと。間違えてたじゃん。
C++なんて最近全然やってないからなぁ。
糞言語には付き合ってられないのよねぇ。
0672デフォルトの名無しさんNGNG
>>669
つまらんつまらんと不平を言うよりも、
進んでオモロイネタを言いましょう。
0673デフォルトの名無しさんNGNG
>>672
うむ、確かにそうだな。ちょっと考えてみる…。
けど、面白いネタって天然やから面白いんじゃねーか？
0674プロの逝って良しの１NGNG
C#厨が「仕事がねえ～」って上の方で騒いでますな。
0675デフォルトの名無しさんNGNG
>>662
（自称プロ）の逝って良しの１ よりは
(自称プロの)逝って良しの１ のほうが
"自称プロの" interfaceへのnarrowing type conversionみたいでカコイイぞ！
0676デフォルトの名無しさんNGNG
>>646
つーか、関数型言語なんかの高階関数つかったイテレータって美しいよな。
ひさしぶりにMLやHaskelで遊びたくなってきた。OCamlでも使ってみるか。
0677100NGNG
>>672
それ聞いたことある。朝のラジオでやってるよね。
ttp://www.tomoshibi.or.jp/top.html
0678100NGNG
>>574
> いや理屈は分かるけど、実用的ではないと思われ。
> >簡便性のために複数回コールできるように設計すべきかと。
> が俺の意見っす。
> # 好みの問題だ、と言われればそれまでだけど。

メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、Collectionより Iteratorの方が汎用性が高いですよね。
で、Iteratorを使用すべきか否かは、簡便性と汎用性のどちらに重きを置いているかによるわけで、一概にどちらが良いとは言えないと思うんですよ。

ちなみに 541のコードは簡便性も汎用性も求めていない、ただ Iteratorのサンプルを示すためのコードなので
「複数回呼べないのでださい」
と言われてもリンダ困っちゃう。

ここまで書いておいて、こう言うのもなんですが、普段はメソッドの引数には Iteratorはおろか Collectionも使いません。
そのまま ArrayListとか書くことが多いですね。
先を見越して汎用的にするよりも、必要になってから汎用的になるようにリファクタリングした方が楽なんですよね、個人的には。
# けど、Collectionぐらいは使った方がいいかな?
0679100NGNG
652から 655まで話についていけてないです。
STLの Iteratorとか調べればついていけますか?
0680デフォルトの名無しさんNGNG
>>675
((自称プロ)の)逝って良しの１
の方が汎用性が高い。
0681デフォルトの名無しさんNGNG
>>678
>メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、
Listの方が指定された位置に要素を追加できたりするので、汎用性ではListの方が高い。

> Collectionより Iteratorの方が汎用性が高いですよね。
いいえ、CollectionとIteratorは別物です。

Collectionは要素の集合の抽象化であり、Iteratorは操作の抽象化です。
print()に渡すものは「要素の集合」でしょうか「操作」でしょうか？

> そのまま ArrayListとか書くことが多いですね。
ArrayListはCollectionのサブクラスだよね？
つまり、君はprint()には「要素の集合」を渡すべきだと思っているはず。
0682100NGNG
>>646
> イテレータとは「コレクション（要素の集合を抽象化したもの）」を
> 操作する手続きを抽象化したものと定義したいな。

今ごろ気付いたのですが。
ここの「操作」、実は「走査」だったりしないですか>646
0683100NGNG
>>681
> >メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、
> Listの方が指定された位置に要素を追加できたりするので、汎用性ではListの方が高い。
> > Collectionより Iteratorの方が汎用性が高いですよね。
> いいえ、CollectionとIteratorは別物です。

678は書き方まずいっすね。
↓これならどう?

printList よりも printCollection の方がメソッドの汎用性が高い。
また、printCollection よりも printIterator の方がメソッドの汎用性が高い。
なぜなら Collection クラスは iterator()メソッドにより Iterator を生成可能なことを保証しているから。

void printList(List l) { ... }
void printCollection(Collection c) { ... }
void printIterator(Iterator i) { ... }

List list = getList();
Collection collection = getCollection();
Iterator itelator = getIterator();
// list
printList(list); // ○
printList(collection); // ×
printList(iterator); // ×
// collection
printCollection(list); // ○
printCollection(collection); // ○
printCollection(iterator); // ×
// iterator
printIterator(list.iterator()); // ○
printIterator(collection.iterator()); // ○
printIterator(iterator); // ○
0684デフォルトの名無しさんNGNG
// iterator
printIterator(list); // ×
printIterator(collection); // ×
printIterator(iterator); // ○

0685100NGNG
>>681
> Collectionは要素の集合の抽象化であり、Iteratorは操作の抽象化です。
> print()に渡すものは「要素の集合」でしょうか「操作」でしょうか？

Collectionが「要素の集合を抽象化したもの」は OKなんだけど、
Iteratorが「操作を抽象化したもの」ってのは違うんじゃないかなと思います。

実際に、646では

>イテレータとは「コレクション（要素の集合を抽象化したもの）」を
>操作する手続きを抽象化したものと定義したいな。

とありますし、GoF本の Iterator パターンの「構成要素」(P277)には

>Iterator クラス
>- 要素にアクセスしたり操作したりするためのインターフェースを
>定義する。

とあります。
0686デフォルトの名無しさんNGNG
>また、printCollection よりも printIterator の方がメソッドの汎用性が高い。
なんの話をしてるのか良くわからんけど、
IteratorとCollectionは別物なんだから
汎用性とかの問題じゃないと思うぞ。
そもそもインターフェースに汎用性もくそも無いだろ。
あるなら、比較する基準、つまりどのように汎用性を計量するのかを
教えてくれ。
0687686NGNG
なんか誤解を含みそうな表現をしてしまったけど、
インターフェースはJAVAでいうinterfaceね。
0688100NGNG
>>684
http://java.sun.com/j2se/1.4/docs/api/java/util/Collection.html#iterator()
0689100NGNG
>>681

> > そのまま ArrayListとか書くことが多いですね。
> ArrayListはCollectionのサブクラスだよね？
> つまり、君はprint()には「要素の集合」を渡すべきだと思っているはず。

いえ、思ってません。

print() メソッドで Iterator のメソッドしか使用しないのであれば、
Iterator を渡すべきだとと思っています。
# めんどくさいから必要になるまではやらないけど。

541の print()メソッドが必要としているのは
「要素の集合を走査するためのインターフェース」であって、
「要素の集合」ではないよね。
なぜ「要素の集合」を渡す必要があるの?
0690デフォルトの名無しさんNGNG
>>689
なぜageた？
0691100NGNG
>>686
> IteratorとCollectionは別物なんだから
> 汎用性とかの問題じゃないと思うぞ。

Iteratorは Collectionからクラスからコレクション走査のための
責務を委譲されている。
文法的に別物かもしれないけど、意味的には Collectionは Iterator を
内包していると考えるのはヘンですか?


> そもそもインターフェースに汎用性もくそも無いだろ。
> あるなら、比較する基準、つまりどのように汎用性を計量するのかを
> 教えてくれ。

ごめん。
インターフェースの汎用性じゃなく、メソッドの汎用性なんです。

比較基準は 683のコードじゃだめかな?
0692100NGNG
>>690
ｽﾏｿ。sage忘れです。
0693デフォルトの名無しさんNGNG
>>685
> Iteratorが「操作を抽象化したもの」ってのは違うんじゃないかなと思います。
GoF本を持っているならばIteratorパターンは「振る舞い」に関するパターン
ということは分かるはずだ。

そして、オブジェクトの木構造を提供するCompositeパターンを
単純にし、オブジェクトの集合を提供するのがCollection

その「構造」をアクセスしたり操作したりするための「振る舞い」を
提供するのがIterator

よって、CollectionとIteratorには深い関係は存在するが全くの別物
0694プロの逝って良しの１NGNG
>>680
お！　
イテレーターはgetNext()一本にすべきという私の考えの支持者ﾊｹｰﾝ
0695デフォルトの名無しさんNGNG
イテレータなんぞ知らなくても
ちゃーんとプログラムは作れます。
残念ですね。OO厨のみなさま
0696プロの逝って良しの１NGNG
イテレーターはＯＯじゃないし・・・
0697100NGNG
>>693
> そして、オブジェクトの木構造を提供するCompositeパターンを
> 単純にし、オブジェクトの集合を提供するのがCollection

うーん。
ちょっとイメージが湧きません。

Composite パターンの構成要素として
- Component クラス
- Leaf クラス
- Composite クラス
とかがありますよね。
Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?
0698デフォルトの名無しさんNGNG
イテレータパターンだよ。ﾊﾞｶﾁﾝ
0699プロの逝って良しの１NGNG
デザパタ＝ＯＯ論でつか？
アフォでつか？
0700デフォルトの名無しさんNGNG
氏らねｰよ。ﾊﾞｶﾁﾝ
0701デフォルトの名無しさんNGNG
ふう。

デザパタ有用っと。
0702デフォルトの名無しさんNGNG
ちんぽも有用だよ！忘れないで！
0703デフォルトの名無しさんNGNG
>>699
その点については完全に同意するよ。
デザパタ自体が建築からの借り物なのを忘れてどーすんだよ。
0704デフォルトの名無しさんNGNG
OOそのものではないが、
OOPL周辺でよく出てくる概念ってあるよね。

C++だと
・コレクション
・ストリーム
・マルチスレッド
とか、Javaだとそれに加えて
・デザパタ
・イテレータ
等々が加わる、と。

そーゆーのって結局、
OOよりもっと基本的なプログラミング上の概念や、
あるいはそれまでプログラミング言語のサポートが足りなかった概念を、
Objectとしてモデリング/カプセル化する事で、
扱いやすくなった(かもしれない)って例なんだろーね。

つう意味で、上記リストへの概念追加をきぼん

0705100NGNG
>>685

ｺﾞﾒｿ、訂正。
操作じゃなくて、走査です。

>Iterator クラス
>- 要素にアクセスしたり操作したりするためのインターフェースを
>定義する。

Iterator クラス
- 要素にアクセスしたり走査したりするためのインターフェースを
定義する。
0706デフォルトの名無しさんNGNG
>>697
> Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?
あえて言えばComponentクラスしか無いクラスかな？

というか、JavaでIteratorパターンを構成する要素が
- Aggregate → Collection
- Iterator　→ Iterator
といった方がわかりやすいか？

またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない
AggregateのCreateIterator()中でFirst()相当の処理も行い、
Iteratorのnext()中でNext(),CurrentItem()相当の処理を行い、
hasNext()でIsDone()相当の処理を行っている。

これには激しく違和感を感じるし、そんなにメソッドをケチりたかったら
Cみたいにwhile((c = getc(fp)) != EOF)と書けるように
while((obj = itr.getNext()) != itr.IsDone())と書けるようにすればいい
プロの逝って良しの１が大喜びするぞ。
0707100NGNG
>>706
>>> そして、オブジェクトの木構造を提供するCompositeパターンを
>>> 単純にし、オブジェクトの集合を提供するのがCollection
>>
>> うーん。
>> ちょっとイメージが湧きません。
>>
>> Composite パターンの構成要素として
>> - Component クラス
>> - Leaf クラス
>> - Composite クラス
>> とかがありますよね。
>> Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?
>
> あえて言えばComponentクラスしか無いクラスかな？

???
0708100NGNG
>>706
> またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
> メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない

まあ、そのまま使わなきゃダメってわけじゃないですからね＞デザインパターン
常識的な変更の範囲内だと思います。


> またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
> メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない
> AggregateのCreateIterator()中でFirst()相当の処理も行い、
> Iteratorのnext()中でNext(),CurrentItem()相当の処理を行い、
> hasNext()でIsDone()相当の処理を行っている。

確かに next() は少し微妙な気はします(少しね)。
けど、コンパイラの本とか読んでるとよく登場するので、
Javaの Iteratorだけが特殊だというわけじゃないみたいです。


> これには激しく違和感を感じるし、そんなにメソッドをケチりたかったら
> Cみたいにwhile((c = getc(fp)) != EOF)と書けるように
> while((obj = itr.getNext()) != itr.IsDone())と書けるようにすればいい
> プロの逝って良しの１が大喜びするぞ。

getcと違って next()ではどんな値でも来得るので(もちろん -1(*)や nullも)
EOFに相当する値を定義できないですよね。
なので、hasNext()のは必須でしょう。

(*) new Integer(-1)
0709プロの逝って良しの１NGNG
＞Objectとしてモデリング/カプセル化する事で、
＞扱いやすくなった(かもしれない)って例なんだろーね。

「ライブラリのコードを並べてるだけ」をカッコ良く言うとそうなるのか（ｗ
0710デフォルトの名無しさんNGNG
アホどもがいつまでも同じ話題で盛りあがってるな。
0711デフォルトの名無しさんNGNG
>>100=アホの代名詞
0712デフォルトの名無しさんNGNG
>>711
使えない奴は放っておいて俺たちのような使える奴だけで話しすすめようぜ
0713プロの逝って良しの１NGNG
光あるところ影がある。
まことの栄光の陰に数知れぬＯＯの姿があった。
だが人よ、名を問う無かれ。
闇に生まれ闇に消えるそれがＯＯの運命（さだめ）なのだ。
0714デフォルトの名無しさんNGNG
>>713
ＯＯのところはいろんな言葉があてはまりますね(w
もちろんOOだってことはわかってますが　テンプレートかな
0715デフォルトの名無しさんNGNG
OO：ObjectOrientedの中傷クラス
0716デフォルトの名無しさんNGNG
うちの部署では構造化チップででOOを実現している。
0717デフォルトの名無しさんNGNG
プロの逝って良しの1が入ると議論が破綻するな
0718100NGNG
>>711
どのへんがアホかご指摘願えませんか。
0719デフォルトの名無しさんNGNG
ほんとに構造化だけでやってる奴このスレにいるのか？
0720デフォルトの名無しさんNGNG
>>719 OOPLは使うけど構造化の精神を貫いております
0721デフォルトの名無しさんNGNG
このスレの住民はレベルが低い奴しかいないな。
参加するのは止めとこう。
0722100NGNG
>>721
レベルが低いからいいんだよ。
中にはｷﾗﾘと光る発言もあるしさ(漏れのではない)。
0723デフォルトの名無しさんNGNG
よいしょ。

Object Compositionっと。
0724プロの逝って良しの１NGNG
下がり過ぎあげ

>>719
ＯＯマンセー派の大部分がそうですが何か？
0725デフォルトの名無しさんNGNG
>>719
キミはどんな小さなアプリでもクラス設計から始めないと気が済まないのかい？
0726デフォルトの名無しさんNGNG
>>721
2度と来んなよ。
0727プロの逝って良しの１NGNG
Classクラスのオブジェクトはクラスなのかオブジェクトなのか・・・
0728デフォルトの名無しさんNGNG
初心者さんが沢山いる様で・・
0729デフォルトの名無しさんNGNG
初心者しかいませんが何か？
0730デフォルトの名無しさんNGNG
>>727
アホですね。
0731デフォルトの名無しさんNGNG
>>725
まぬけ
0732デフォルトの名無しさんNGNG
>>727
言語や環境によるが、Classクラスを提供しているようなOO言語/環境であれば
そのインスタンスもオブジェクトだが、それがどうかしたのか？
そもそも、この手のメタタワーなモデルはOOよりもLISPのほうが歴史が長いのだが。
0733デフォルトの名無しさんNGNG
メタレベルとオブジェクトレベルっていう議論を
回避するために型理論ってあるんじゃないの？
0734デフォルトの名無しさんNGNG
つーか、Smalltalkの階層構造では、下図のよーにぜーんぶオブジェクト

　Object
｜　　　↓
｜　　　　MetaClass
｜　　　　　　↓
｜　　　　各クラス
↓(instance)↓(super)
各インスタンス
0735デフォルトの名無しさんNGNG
>>732
LispでReflectionてな話って、どのあたりでしぉうか？
Lisp3 とか？
0736734NGNG
スマソ、間違えた

　Object
｜　　　　↓(instance)
｜　　　　　MetaClass
｜　　(super)↓↑(instance)
｜　　　　　Class
｜　　　　　　↓(instance)
｜　　　　　各クラス
↓(instance)　↓(super)
　各インスタンス

てな感じで、Metaclass階層をinstance of と super で循環定義してるんだっけ？
0737デフォルトの名無しさんNGNG
>>736
へえ、smalltalkってそうなってるんだ。
それだとC++からのアナロジーで考えることを当然のこととしてると
分かりにくいね。こんどsmalltalkを勉強してみます。
0738デフォルトの名無しさんNGNG
>>735
とりあえずevalがLispで実装されてればメタサイクリックじゃないか？

>>737
Smalltalkでのクラスはインスタンス変数やインスタンスメソッドを持っている部分と
クラスインスタンス変数(C++のstaticメンバに相当)やクラスメソッドを持っている部分に
わかれていて、それぞれ別のオブジェクトになっている。
ここを見誤ると混乱する。
たとえばObjectクラスのインスタンス担当部分はObjectで
クラスメソッドなどを持っている部分はObject classというオブジェクト。

また、Smalltalkではオブジェクトにclassというメッセージを送ると、
そのオブジェクトのクラスインスタンスを返してくれる。

1 class → SmallInteger : Objectのサブクラス
SmallInteger class → SmallInteger class : Classのサブクラス
SmallInteger class class → Metaclass
Metaclass class → Metaclass class : Classのサブクラス
Metaclass class class → Metaclass
下2つでループになってる。

なお、ClassとMetaclassは共にBehaviorのサブクラスで、
BehaviorはObjectのサブクラスになっている。

Object class → Object class : Classのサブクラスであり、また、Objectのサブクラスでもある。
0739デフォルトの名無しさんNGNG
VB.NET使って、継承やらオーバーロード、オーバーライド、
クラスライブラリやら使えるが、
当然VBAでは使えん。鬱だ。
0740734NGNG
うーん、Behaviorクラス忘れてましたぁー。
あと、Metaclass や Classにもclassありますよねぇー。
＃所で、上記の式で Classそのものが出てこないのはどしてでしょうか？superしないとだめ？

＃いずれにせよ、>>734 も >>736 も、ｶﾅｰﾘ恥ずかしい図面だ。
＃↓super は、 ↑superか↓subclassのまてぃがいだし、
＃Class と Objectの峻別忘れてMetaclass語ってるし。
0741734NGNG
>>738の情報をまとめると、こんな感じかな。
(ﾒｯｾｰｼﾞclassでｲﾝｽﾀﾝｽ関係━、ﾒｯｾｰｼﾞsuperでｻﾌﾞｸﾗｽ関係─を追っかけるとして)

　　　　　　　　　　　ｻﾌﾞｸﾗｽ
　　　　　　　─────→
　　　Object←━━━━━Object class
　　　　││　ｲﾝｽﾀﾝｽ　　　　 ↑ｻﾌﾞｸﾗｽ
　　　　││　　　　　　　　　　 │　　ｻﾌﾞｸﾗｽ　　　　　　　　　　　　　　　　ｻﾌﾞｸﾗｽ
　　　　│└─────────→Behavior　　　　　　　　Class class━━→Metaclass class
　　　　│　　　　　　　　　　　　│┏│━━━│━━━━━━━┛　　　　　　　　 ┃↑ｲﾝｽﾀﾝｽ
　　　　│　　　　　　　　　　　　│┃│　　　　 │┏━━━━━━━━━━━━━┛┃　
　　　　│　　　　　　　　　　　　│┃│　　　　 │┃┏━━━━━━━━━━━━━┛
　　　　│　　　　　　　　　　　　│↓↓ｻﾌﾞｸﾗｽ↓↓┃ｲﾝｽﾀﾝｽ
　　　　│　　　　　　　　　　　　Class　　　　Metaclass
　　　　│ｻﾌﾞｸﾗｽ　　　　　　　　　│　　　　　　┃
　　　　↓　　　　　ｲﾝｽﾀﾝｽ　　　　↓ｻﾌﾞｸﾗｽ　↓ｲﾝｽﾀﾝｽ
　　SmallInteger←━━━━━SmallInteger class
　　　　┃※ｲﾝｽﾀﾝｽ定義　　　　　　　　※ｸﾗｽ定義
　　　　┃
　　　　↓ｲﾝｽﾀﾝｽ
　　　　1
0742734NGNG
ところで、Smalltalk80って、多重継承なしだから、
「２種類のｸﾗｽのｻﾌﾞｸﾗｽ」(例:Object class)っつう事は、
どっちかのｸﾗｽはもう一方のｻﾌﾞｸﾗｽなんだよね？
つう意味で、上記の図面はまだ誤りがある。

Smalltalk80の原理原則
「全てがオブジェクトであり、
　全てのオブジェクトはクラスのインスタンスであり、
　全てのクラスはClassのサブクラスである」
は美しいけど、
それを実装すると上の図みたいに複雑になるわけで、
Smalltalk80作った人々はこの複雑さをどう捉えたんだろうね？
0743デフォルトの名無しさんNGNG
>>734
解説どうもありがとう。
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-4_1.html
ここなどと照らし合わせて勉強してみます。

0744デフォルトの名無しさんNGNG
class と super の二元論で全てを記述しようとしたのが、
構造の複雑さの原因じゃないかな？

んで、flavorとかinterface追加してみたり(flavor, Objective C)、
classとsuper以外の、多種多様なObject間相互作用を考えたり(デザパタ)、
classオブジェクトを無くしてみたり(C++)、
プロトタイピング・ベースのOOPL作ってみたり(Self,Squeak Morph,JavaScript???)
したんでしょ
0745デフォルトの名無しさんNGNG
言い方逆かもね。

classとsuperで、シンプルな世界を実装したらsmalltalk80になりますた。
概念が未整理で、実装基盤も不充分な現実世界で、OOしようとしたら、
classとsuperで寄木細工の閉じた世界作ってる暇がないんで、拡張しよう。

ってな感じ
0746OO マンセNGNG
ふう。

ここはStratege patternで組んでと。
0747デフォルトの名無しさんNGNG
>741が複雑？
どこが？
0748デフォルトの名無しさんNGNG
>>741が複雑？
>どこが？

こんな事言いながらOO厨は保守でｋないコード量産するんだよな。
0749デフォルトの名無しさんNGNG
>>747
循環定義でオナニーしてしまうくせがあるよな＜学者さん
0750デフォルトの名無しさんNGNG
>>747
　>>744-745という事だよ。
0751デフォルトの名無しさんNGNG
ちなみに>>741は、
その昔オブジェクト指向LISP(Dylanの人のヤツ)を、
Smalltalk風OOPLに拡張した時の階層に近くて、
当時も今もBehaviorやClassDescriptorの機能をよく知らなかったりする(藁

誰か解説きぼん
0752デフォルトの名無しさんNGNG
メタクラスは関数型言語のカリー化のオブジェクト版って事よ。
0753デフォルトの名無しさんNGNG
意味が全く分かりません。

皿仕上げても（・∀・）ｲｲ？
0754デフォルトの名無しさんNGNG
>>752
全然違うだろ。
0755デフォルトの名無しさんNGNG
>>752
全くその通り。
0756スレ違いNGNG
わざわざカリー化しなきゃならないのはダサイ言語。
0757デフォルトの名無しさんNGNG
理解できてないﾔｼ(＝アンチFP)がたくさんいる。
0758デフォルトの名無しさんNGNG
久しぶりにghc入れてHaskellの勉強でも再開しようかな・・・
0759デフォルトの名無しさんNGNG
>>752
酔っ払った勢いで、無理矢理介錯してやる。











只今考え厨
0760デフォルトの名無しさんNGNG
例えば、高階関数＝状態の畳み込み、と考えて、
meta instance ＝ class
class instance ＝ object
-------------------------
meta instance instance = object
みたいなのを考えてるのｶﾅｰ
0761デフォルトの名無しさんNGNG
カリー関数→...関数→最終的な出力(オブジェクト)
メタクラス→...クラス→インスタンス(オブジェクト)
ってことでしょ？
0762デフォルトの名無しさんNGNG
instanceはclassの逆関数だけど、追加の引数(class定義やobject定義)が必要な罠
0763コボラNGNG
何逝ってんのかサッパリ………？？？
0764デフォルトの名無しさんNGNG
初心者＆厨房の追い出しには成功したな
0765デフォルトの名無しさんNGNG
ただいま厨房によるパトロール中・・・
0766デフォルトの名無しさんNGNG
はーい
厨房が通りますよ
道を空けてね
0767プロの逝って良しの１NGNG
クラス型オブジェクト指向はその基礎に重大な矛盾を孕んでいることが判明
と理解して良いですか？
0768デフォルトの名無しさんNGNG
>>767
何言ってんの？
0769デフォルトの名無しさんNGNG
>>768
日本語読めないんですか？
0770デフォルトの名無しさんNGNG
>>769
読めるよ
0771デフォルトの名無しさんNGNG
つーか、>>767だけじゃ会話になってないと思われ。
独り言ですか？
0772デフォルトの名無しさんNGNG
>>767
では"重大な矛盾"とやらを具体的におながいします。
0773プロの逝って良しの１NGNG
Class クラスがクラスだかインスタンスだか判らない点
0774デフォルトの名無しさんNGNG
>>773
Classクラスはクラスでしょ。Object#getClassで返ってくるのは
Classクラスのインスタンス。

どこがわからない? もしかしてメタクラスって理解できない?
0775デフォルトの名無しさんNGNG
メタクラスもクラスもインスタンスも流動的で、
特に区別されないところがキモだと思うんだが。
これは使ってみないとわからないか。
0776デフォルトの名無しさんNGNG
>Class クラスがクラスだかインスタンスだか判らない点
いや、クラスだって分かってるじゃん…「Classクラス」って言ってるんだから。
俺はこの発言の意図の方がよっぽど分からん。
0777デフォルトの名無しさんNGNG
>>773
Metaclassのインスタンスはクラスでありかつインスタンスでもある。
すなわちClassクラスはクラスでありかつインスタンスでもある。
何の不思議もないけど。

結局、メタ循環から木構造に落す時にどれを根として扱うかということでしょ。
Object → Class(のサブクラスであり、かつObjectのサブクラス) → Metaclass(Objectのサブクラス)
という循環をObjectを中心に見るか、それともClassを中心に見るかという問題で、
Objectを根にすればSmalltalk的な「何でもオブジェクト」な言語になるし、
Classを根にしてObject以下の階層と分離すればC++的な「クラスはオブジェクトじゃない」ような言語になる。
あるいはObjectを根にしてMetaclass以下を省略すればPythonのような「クラスもオブジェクトだが、クラスのクラスは存在しない」言語になる。

それぞれ長所も短所もあるわけだけど、Smalltalk的な「何でもオブジェクト」が複雑とは思えん。
むしろ、「これはオブジェクトだが、これはオブジェクトではない」のほうが複雑だと思うが。
0778777NGNG
>>773
ところで、Classクラスっていうけど、どの言語でのClassクラスの話なんだ？

SmalltalkのClassクラスであれば、Classという名前のオブジェクトなのか、それともClassという名前クラスなのか。
Classという名前のオブジェクトであれば、それはクラスでありかつClass classのインスタンスだ。
Classという名前のクラスであれば、それはクラスでありかつMetaclassのインスタンスだ。
0779デフォルトの名無しさんNGNG
Smalltalk80だと、grobalにClassというクラスがあるんで、Classというオブジェクトは存在し得ない。
0780777NGNG
>>779
Smalltalk-80だと、
globalにClassというクラスがあり、
そのインスタンスメソッドなどを管理したりインスタンス生成をおこなう
Classというオブジェクトが存在します。
0781デフォルトの名無しさんNGNG
あれ、dictionaryの空間分かれてるんだっけ？Class dictionary？

0782734NGNG
>>743の図面が判りやすいんで、AAこぴぺ

http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/img/metaHiera9.gif

　　　　　　　　　　　　　　┌───┐　　　　　　　　 meta┏━━━━━┓
　　　　　　　　　　　　　　│Object├…………………→┃Object class┃
　　　　　　　　　　　　　　└─△─┘　　　　　　　　　　　 ┗━━△━━┛
　　　　　　　　　　　　　　┌─┴──┐　　　　　　　 meta┏━━┷━━━┓
　　　　　　　　　　　　　　│ Behavior├………………→┃Behavior class┃
　　　　　　　　　　　　　　└─△──┘　　　　　　　　　　 ┗━━△━━━┛
　　　　　　　　　　　┌───┴────┐　 meta┏━━━━┷━━━━━┓
　　　　　　　　　　　│ ClassDescription ├……→┃ClassDescription class ┃
　　　　　　　　　　　└───△────┘　　　　 ┗━━━━△━━━━━┛
　　　　　　　　　　　　　　　　　│　　　　　　　　　　　┌────┴──────────────-┐
　　　　　　　　　　　　　　　　　├────────|─────────┐　　　　　　　　　　　　　　 │
　　　　　　　　　　　　　　┌─┴─┐　meta┏━━┷━━┓　　　 ┌──┴──┐ meta┏━━━┷━━━┓
　　　　　　　　　　　　　　│ Class ├……→┃Class class┃　　　 │ Metaclass ├……→┃Metaclass class┃
　　　　　　　　　　　　　　└─△─┘　　　　┗━━━━━┛　　　 └─────┘　　　　 ┗━━━━━━━┛
　　　　　　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　↑meta↑meta
┌────┐　meta┏━━┷━━━┓　　　　　　　　　　　　　　　　 ：　　　　：
│ Object　├……→┃Object class　┠……………………………┘　　　　：
└─△──┘　　　　┗━━△━━━┛　　　　　　　　　　　　　　　　　　　　 　：
┌─┴──┐　meta┏━━┷━━━┓　　　　　　　　　　　　　　　　　　　　　 ：
│Account ├…･･→┃Account class┠……………………………………･┘
└────┘　　　　┗━━━━━━┛

0783プロの逝って良しの１NGNG
sinu
0784777NGNG
>>781
Smalltalk-80では"Class"というクラスは
"Class"と"Class class"という2つのオブジェクトによって実装されているという話。

だから、Smalltalk-80のクラスライブラリにはClassというクラスが存在すると同時に
Classという大域変数とそれによって差されるClassというオブジェクトも存在する。
そしてそのClassという大域変数で差されるオブジェクトと、
大域変数では差されていないが"Class class"というメッセージ式で得られるオブジェクトが、
クラスライブラリ上の"Class"という名前のクラスを構成している。
0785デフォルトの名無しさんNGNG
上記図面で Account, Object, Class の各Objectは、
それぞれ Account class, Object class, Class classの各クラスのSingleton であり、
インスタンス・オブジェクト作成はサブクラス任せにするFactoryMethodパターンでもある
と言えそうですね。
0786デフォルトの名無しさんNGNG
さて、と。

次の問題は、クラス・ベースのOOPLのやり方を、
実行時にクラス・オブジェクトを持たないOOPLで
いかに実現するか、ですね。
0787プロの逝って良しの１NGNG
落ちが無いし・・・
0788デフォルトの名無しさんNGNG
え？
0789デフォルトの名無しさんNGNG
もしかしていまとなってはスモールトークユーザーってRubyよりすくない？
0790デフォルトの名無しさんNGNG
ふう。

ここはSingleton㌧っと。
0791デフォルトの名無しさんNGNG
日本でSmalltalkの需要なんてまずないのでは。
研究関係はよく知らないけど。

でもこの前ジョブズがSmalltalkのサブセット子供に教えてたよ。
0792デフォルトの名無しさんNGNG
Smalltalkerから言わせるとC++やJavaのオブジェクト指向は糞ですか？
0793デフォルトの名無しさんNGNG
いと懐かしきかな純準論争。
0794デフォルトの名無しさんNGNG
>>768
クラス・ベースOOPLと、クラス・オブジェクト無しOOPLのマッピングかよ！
ＯＯって、マッピングが多いなぁー
＃オブジェクト・リレーショナル・マッピングとか、
＃ＭＤＡでも標準マッピングの嵐らしいし…

OOPLあらため、マッピング指向言語って呼んでも（・∀・）ｨｨ？
0795デフォルトの名無しさんNGNG
誰か、型理論とZFC集合論のマッピングをしてくれんかのぅ。
0796デフォルトの名無しさんNGNG
>>791
ジョブスは変態です。
他にも小さい子に悪戯にLispを教えるのです。
0797デフォルトの名無しさんNGNG
教えるんじゃなくて喋ってるだけだろ。ただの自己満足じゃん。
0798デフォルトの名無しさんNGNG
ZのツールでGPLライセンスのものはありますか？
0799デフォルトの名無しさんNGNG
ハァ？
0800デフォルトの名無しさんNGNG
　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　800げっとぉぉぉ～♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは～っ、800ｹﾞｯﾄ～！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 ～～　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;
0801デフォルトの名無しさんNGNG
　　　　　　　　　　　　 ＿ _　　　　 / ）
　　　　　　　　　　 〃┏━━ 、／ フ
　　　　　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　やった～♪
　　　　　　　　(＼／|」~　　~|」／)
　　　　　　　 ヽ／, ｲ/￣￣　i／）
　　　　　　　＜／ヽ| 　 　　　i／
　　　　　　 (_ノ　 　レ'⌒i 　 |
　　　　　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 　　　　(＿|＝|).､　 ＼
　　　　　 　　　　　　_|(　 | 　>　　）））
　　　　　　　　　　／ Ｏし'Y==_／
　 　 　　　　　 　/ ＼ | ／ii／
　 　　　　～～　|l─-0-─||
　 　　　　　　　　!　　ﾍへ !!ﾍ　 プチｯ
　　　　　　　 r'´⌒⌒ ヽ彳# ７
　　　　　　⊂(（(ﾊ)）⊂〃＿〃つ ﾆﾊｶﾞｫｸﾞｹﾞﾎﾞｯ
0802デフォルトの名無しさんNGNG
>>794
ねえ、君、クラスベースOOPLってどういう意味で言ってるの？
普通はクラスがオブジェクトであろうがなかろうがクラスという概念があればクラスベースOOPLなんだが。
例えばC++も普通はクラスベースOOPLと呼ばれる。
0803デフォルトの名無しさんNGNG
文法レベルでの直截的なサポートがない場合でも
クラスという概念を使ったコーディングが可能と言い張れば
クラスベースOOPLなの？
0804デフォルトの名無しさんNGNG
ごめん、クラス・オブジェクトを持つOOPLと読み替えてくれ。
0805794=804NGNG
↑は>>794の訂正。言葉使いが適当でスマソ。

ところで、数日前から議論が初級Smalltalkみたいな所で頓挫してるのはﾅｾﾞ？
0806794=804NGNG
ﾔﾊﾟｰﾘ２ちゃんでは、言葉尻を捕らえた不毛な議論しかできないのｶﾅｰ？
0807786NGNG
ぁーあ。

次の課題は、クラス・オブジェクトを持たないOOPLのメリット/デメリット
の検討、ですね。

その次の問題は、クラス・オブジェクトを持つOOPLのやり方を、
実行時にクラス・オブジェクトを持たないOOPLで
いかに実現するか、ですね。

そのまた次の課題は、クラス・ベースでないOOPLのメリット/デメリット
の検討、ですね。

って感じで、12時間位でちゃっちゃと進まないのかな
0808デフォルトの名無しさんNGNG
>>807
＞の検討、ですね。
はぁ？課題？
検討？
ここ何処だか知ってる？
0809デフォルトの名無しさんNGNG
最近電波な人多いね
08101NGNG
オブジェクト恥垢初チン者が、入門書の中身をえらそーに講義してるスレッド。
0811デフォルトの名無しさんNGNG
>>809
君ほどじゃないよ。理系のど真ん中で、電波電波って、恥ずかしいったらありゃしない
0812デフォルトの名無しさんNGNG
ﾌﾟﾛﾌｪｯｿﾅﾙな人は、>>807のテーマでもあくびが出る罠
0813デフォルトの名無しさんNGNG
>>812
3点
0814デフォルトの名無しさんNGNG
>>807
OOPLにおいてクラスが1st class objectでない事の
メリット: 実行時メモリの節約
デメリット: クラスを変数やパラメータとして渡せない

クラスが1st class objectでないOOPLにおいてクラスを1st class objectとして扱う方法
プロトタイプ・パターンを使う

クラスベースでないOOPLの
メリット: 比較的簡単に多種の振舞いを持つオブジェクトを実行時に生成できる
デメリット: method dictionaryのオーバーヘッドが(時間、空間共に)大きくなりやすい
0815814NGNG
おっと、
> クラスが1st class objectでないOOPLにおいてクラスを1st class objectとして扱う方法
> プロトタイプ・パターンを使う

ここはプロトタイプ・パターンを使ってもいいんだけど、
1st class objectでないFooクラスに対応してFooClassクラスを作って、
そのsingletonをFooクラスに対応させてもいいな。
0816デフォルトの名無しさんNGNG
プロトタイプ・パターン、ですか？

　http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/gof/prototype.html

慎重に検討した事がない解ですたので、
ちょっと考えさせて下さいです。
0817デフォルトの名無しさんNGNG
>>1->>816
おまいら、わかったからさ、はやくOOでOS作れよ
0818デフォルトの名無しさんNGNG
>>817
すでにLinux、WindowsがOOで作られてるじゃん。
0819デフォルトの名無しさんNGNG
>>818
ネタにもなんねー
0820デフォルトの名無しさんNGNG
　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　820げっとぉぉぉ～♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは～っ、820ｹﾞｯﾄ～！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 ～～　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;
0821デフォルトの名無しさんNGNG
抽象クラスなんぞ必要ない。
インターフェイスで十分。
それがわからんOO厨の多いこと多いこと。
0822デフォルトの名無しさんNGNG
なぜ？>>821
0823デフォルトの名無しさんNGNG
　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　823げっとぉぉぉ～♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは～っ、823ｹﾞｯﾄ～！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 ～～　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;

0824816NGNG
816です。>>816の行間、伝わったかなぁー？
0825デフォルトの名無しさんNGNG
　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　825げっとぉぉぉ～♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは～っ、825ｹﾞｯﾄ～！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 ～～　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;
0826デフォルトの名無しさんNGNG
>>821
> 抽象クラスなんぞ必要ない。
> インターフェイスで十分。
抽象クラスがあったほうが楽にできるケースもある。
そんなことを言うんだったら
「swich文など必要ない。if-elseで十分。」とも言える。

>>822
（821が）坊やだからさ。
0827デフォルトの名無しさんNGNG
>>821
面倒だから、お相手しません。悪しからず
0828デフォルトの名無しさんNGNG
>>827
すでに相手しちゃってるじゃん(藁
0829デフォルトの名無しさんNGNG
(実装)継承に頼るのはよくないぞ。>OO厨。
確かに実装継承はコードを書く手間も省けるし、
インターフェイスも同時に継承できる。
しかし、OOのポリモーフィズムやらは
インターフェイスの継承によって
実現していることを忘れるなよ。
俺の愛の忠告を受け取れ>>OO厨
0830デフォルトの名無しさんNGNG
（´-｀） .｡oＯ（誰も相手してないのに、どうしてそう熱く騙れるんだろう…）
0831デフォルトの名無しさんNGNG
インターフェースの向こう側にAOPがありそうだと直感してしまった今日この頃♪
0832デフォルトの名無しさんNGNG
>>831
> インターフェースの向こう側にAOPがありそうだ
Cloneable, Runnable, Serializableなどの～able系インタフェース
AOPを使えばこれらが一掃されそうな予感がする

はっきり言って、～able系インタフェースは動詞を無理矢理名詞化して
クラスらしく見せかけているような胡散臭さを感じる。
0833デフォルトの名無しさんNGNG
ＡＯＰ：アナルおまんこプレイですか？
0834デフォルトの名無しさんNGNG
>>832
捻りすぎでよくわかりませんでした。

つか、>>831で言いたかったのは、概略次のような事。
インターフェース：既存のオブジェクトの型の一部分のみを取り出して、
　　　　　　　　　継承(型の包含関係)を柔軟に実現するためのもの。
AOP:　　　　　　　既存のオブジェクトの機能の一部を取り出したり、
　　　　　　　　　あるいは既存のオブジェクトに一部機能を追加して、
　　　　　　　　　クラス(やインターフェースｗ)とは違う切り口で、
　　　　　　　　　実装(ソースコード)を再構成するためのもの。
として。
AOPが既存オブジェクトから部分的に切り出したり追加したりする機能というのは、
インターフェースが既存オブジェクトから切り出す部分型と、結構似ているのではないか、と。
すると、実装を切り捨て、型の包含関係のみを議論するインターフェースよりも、
実装方法やソースコードを前提に、型の再構成をするAOPの方が、より有用なのではないか、と。

＃OOA/OODだと、概念モデルがインターフェースに相当するわけだけど、
＃ここでは実装ﾏﾝｾｰで、実装の観点からのみインターフェースを見てますです。
＃でも、AOPって実装がある程度進んだ段階で有用な手法みたいだから、
＃インターフェース：上流工程で概念モデルと実装を結び付ける手段
＃アスペクト：　　　下流工程で実装を整理する手段
＃みたいな感じで、現時点では対象的なのかな～。(AOAとかAODとか出てきたりして(w))
0835デフォルトの名無しさんNGNG
>>833
交互なの？
0836デフォルトの名無しさんNGNG
ふう。


ここはTemplate Methodパターンを使って、と。
0837デフォルトの名無しさんNGNG
>>835
やる前にちゃんと洗浄する。
Ａ→Ｏ→Ａ→Ｏ→Ａ→Ｏ
0838デフォルトの名無しさんNGNG
>>836
テンプレート使ってるだけだろ？
0839デフォルトの名無しさんNGNG
>>834
AOPのメリットはわかったけど、
デメリットは何なの？

OOもメリットがある反面、デメリットがあるわけだけど
そんなのはわかってるものと信じて話を進める事にする。
0840デフォルトの名無しさんNGNG
それがわかってないOO厨ばっかりだからこそ、
このスレがあるんじゃん。大丈夫？>>839
0841デフォルトの名無しさんNGNG
>>839
バカ(840)は気にするな。
0842デフォルトの名無しさんNGNG
>>839
バカ(841)は気にするな。
0843デフォルトの名無しさんNGNG
実は俺、クラシックファンぶってるけどマジでアニメファンです。
アニメージュ毎月買って読んでます。
部屋のミケランジェロの絵の裏には
カードキャプターさくらのポスターが貼ってあります。
「モーツァルト歌劇」のラベル貼ってあるビデオの中身は
全部カードキャプターさくらです。
人にはモーツァルトファンってことにしてあります。
でもモーツァルトなんかより、カードキャプターさくらの
主題歌聴いてる方が落ち着くんです。
クラシック界はこの先どうなっていくのかを
クラシック友だちと真剣に語り合ったりしてますが、
本当はさくらたんの個々のアニメの回の出来について
真剣に議論したいんです。
コミケにも毎回行ってＣＧ集も売ってます。
　　　真面目ぶってるけど、さくらたんと知世さまのワレメが大好きなのです。
あ、モーツァルトもそれなりに好きですよ。
でももちろんさくらたんの主題歌のほうが好きですけどね。
　　　これからも幼女のワレメ萌え萌えな絵を描いていくつもりですので応援してください。
　　　描いて欲しいキャラなど要望ありましたら
　　　http://www.coara.or.jp/~yoshioh/までよろしく！
0844デフォルトの名無しさんNGNG
つまり、現代社会というオブジェクトから、病根というアスペクトを切り出すと>>843になり、
個別のインターフェースはアニメファン、ロリという事なのだろうな
＃そーじゃなかったら物故ろす！
0845デフォルトの名無しさんNGNG
未実装の抽象クラスは　クラシックファン　のあたり
0846デフォルトの名無しさんNGNG
…で？
0847U ◆tFsGiu0c NGNG
AOPが注目されているのは、OOPの弱いところを補完できるから。
だからAOPのデメリットは、「それだけじゃシステムが組めない」こと。
0848デフォルトの名無しさんNGNG
確かに、一般論過ぎて、
ＯＯに別の言葉を穴埋めしたくなるな(ｗ
0849デフォルトの名無しさんNGNG
>>848が注目に値するのは、>>847の弱いところを補完しているから。
だから>848のデメリットは「>>848だけではツッコミ漫才をできない」ことだ。
0850839NGNG
AOP唱えてる奴は、OOもわかってるんだと思ってね。
OOのデメリットは、まともなOO本ならちゃんと記されているので、
厨房な方々はそちらを参照してください。

>だからAOPのデメリットは、「それだけじゃシステムが組めない」こと。
俺の言い方が悪かったのか、コミュニケーション能力が足りないのか
あるいはバカなのかはよくわからないけど、
AOPを導入した場合のメリットと、導入した場合のデメリットを
「具体的」に書いてねって事。
それがわからないと、AOPのどこを評価していいのかわからない。
0851デフォルトの名無しさんNGNG
サクラ大戦ってなに？
0852プロの逝って良しの１NGNG
どうせＡＯＰＬとか出てきて
ＡＯＰＬで書いてるからＡＯＰだろ！
つうのが（略
0853_NGNG
クラスオブジェクトって実行時に必要だろうか？
それならSelf的な(真の意味で)全てがオブジェクトという方が綺麗な気がするけど。
0854デフォルトの名無しさんNGNG
>>853
気がする理由を考えないと、気のせいで終わっちゃうぞ。
0855デフォルトの名無しさんNGNG
おまえらさぁ、ちゃんとjavaとか使い込んだ上でいってんのか？
馬鹿ちやう？馬鹿？え？俺？そうだよ。あぁ。明日な。
いや、違うって。だからあの娘とは関係ないんだって。
え？もういい？ちょっとまてよ。え？え？
その話はまた今度ゆっくりしよ。な？な？なぁぁぁぁぁぁぁぁ！！！！！！！！！
0856デフォルトの名無しさんNGNG
理解の基盤が違うようですので、議論が成立しそうにありませんね。(苦笑
0857デフォルトの名無しさんNGNG
（°Д°)ﾊｧ？
0858デフォルトの名無しさんNGNG
（ﾟДﾟ;)ﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧ､ｳｯ
0859デフォルトの名無しさんNGNG
>>855
俺はOOﾏﾝｾｰ派だけど、OO使い=Javaが使えないとダメ、なんて短絡的発想しか出ない馬鹿はすっこんでろ。
0860プロの逝って良しの１NGNG
JavaOneが今年も開かれます。
生贄の少女から生きたまま心臓を引きずり出し、皆で生き血を飲むという野蛮な
儀式が今年も行われるそうです。
http://servlet.java.sun.com/javaone/
0861893NGNG
>>853
Selfって書きたいだけだろうと(略)
SPARC版Self触った事ないだろうと(略)
0862デフォルトの名無しさんNGNG
JavaなんてOOじゃない。本物のOOはFB
0863デフォルトの名無しさんNGNG
>>860
残念ながらそれが文化です。
日本だけに引き篭もってるから好きなことが言えるのです。
0864デフォルトの名無しさんNGNG
>>859
ＯＯＰは組み込み分野でこそ発揮されるべきだ！
0865プロの逝って良しの１NGNG
Java 高速GUI SWT
http://pc3.2ch.net/test/read.cgi/tech/1032448424/
SWTはJavaでOSのネイティブAPIを直接呼び出し、高速に動作する
GUIツールキッドです。


つうか、回りくどいこと止めてＣで組め。
んでＣからＪａｖａのＡＰＩ呼べるようにした方が率直だろうが
0866デフォルトの名無しさんNGNG
たしかにそうだ（ｗ
GUI全部Cで作って
ソケットでデータやり取りしてろって
0867プロの逝って良しの１NGNG
だいたい、トチ狂って「呼び出す」なんて書いちゃってるしな。
「メッセージを送ると自立的に動作する」んじゃなかったのか（藁
0868C言語ﾏﾝｾｰNGNG
>>865
ん、なんで？CからJavaのAPIを呼ぶ必要性なんて皆無だと思うけど？
Javaと違って本当の意味で「何でもできる」んだから、わざわざJavaのAPIなんか使う必要ない。
# もしJavaの便利なAPIが使いたいっていうのなら、JavaのAPIを使うよりも
# 用途に合わせたCのライブラリを使う方がずっと良いしスマートだよね。

遅いのをカバーするためにより下層のAPIやライブラリとかを使うのは普通のアプローチじゃないか。
Cが一部でasmを使うように、Javaがnativeを使ってもいいはず。

>>866
なんでソケット通信？SWTのアプローチの方が自然だし(おそらく)パフォーマンスも良いよ。
実装もはるかに簡単だし。

>>867
「メッセージを送ると自立的に動作する」ってのがこのスレのどっから出てきたか知らんが(検索したけど分からん)
それはOOで設計なり実装された場合であって、下層のnativeは当然OOじゃないよね。だから「呼び出す」とい
う表現は正しいと思う。


# もっと勉強してOO派を何とかしろよ。
# OO反対派だけど、ハッキリ言って見てられない。＞逝って良しの１やその他諸々。
0869デフォルトの名無しさんNGNG
>>868

>なんでソケット通信？SWTのアプローチの方が自然だし(おそらく)パフォーマンスも良いよ。
>実装もはるかに簡単だし。

疎結合にしてGUIの実装側を楽にした方が何百倍もマシということだろ
0870プロの逝って良しの１NGNG
>>868
オブジェクト指向では関数呼び出しの事を「オブジェクトにメッセージを送る」
などとほざくのです。
0871デフォルトの名無しさんNGNG
>>867
メッセージを送ると自律的に動作するのはエージェント指向と思われ。
もっとも一言でエージェント指向といっても粒度によって色々あるけど。

オブジェクト指向の場合は自律性よりも相互作用のほうに重点が置かれてるだろ。

>>870
ソースキボンヌ。もちろん君の脳内妄想以外の。
0872デフォルトの名無しさんNGNG
OOPLによるWindow systemハンドリング方法の変遷を、
仮に、

1)Window systemをグラフィックシステム上にOOPLで直接記述:
　　Smalltalk
2)Window widget/component簡易wrapping:
　　Java AWT, little smalltalk
3)既存のwindow systemにbitmap貼り付けて、軽量widget/component:
　　Java Swing, Dynamic HTML, Linux系WindowManager (KDE, GNOME)
4)特定環境固有のWindow system wrapping
　　MS SDK Java(J++)

ってな感じに分類できるものとすると、
SWTって、4)に近いの？それとも、5)新しい手法になるの？

＃OS～Windowシステム周辺のOOPL primitive を、
＃OS記述言語で記述するって当たり前の議論に見えるが

0873デフォルトの名無しさんNGNG
簡易ラッピングじゃなくて、
本格的なラッピング
0874プロの逝って良しの１NGNG
社会主義市場経済みたいなもん。
Write Once Run Anywhereの原則に反する。
自己否定に近い。
0875868NGNG
>>868
865の意図した事は
複雑な部分をJAVAで組んで
単純なGUIはCでいいじゃんって意味だと思うよ。

で、868では
俺は複雑な計算をするアプリケーションを作ってるんだけど
まあ、そういうロジックの部分はJAVAで書きたいわけ。
やっぱりJAVA>C++なんだよね。(生産性においては）
で、JAVAでGUI作って不満たれてるなら
GUIだけCで作ればいいだろ？ってね。
ちなみにソケット使ってパフォーマンスが落ちるって・・・
もうちょっと良く考えてみな。

まあ、俺はGUIなんてどうでもいいし
そんなのはコーダーにやらせとけばいいから、
SWINGで適当に作って、投げとくけどね。

ちなみにSWTのようなライブラリーが作れる技術がある人は
少ないよ。
それはJNIが難しいんじゃなくて、
設計が難しいという意味で。
0876デフォルトの名無しさんNGNG
>>868
俺はOO原理主義派だけどアンタはまとも。


アンチにまともな人がいたなんて驚き！

俺の中ではプロの逝って良しの１がアンチの基準なんだけど…(藁
0877デフォルトの名無しさんNGNG
どんどんOOから離れた枝葉の議論になってるな。矯正不可能って感じ
0878デフォルトの名無しさんNGNG
起動修正するか。

このスレで出た結論一覧

1)既存のライブラリ＆フレームワークの使いやすさ：ＯＯＰ＞非ＯＯＰ
2)メンテ＆引継ぎのし易さ：非ＯＯＰ＞ＯＯＰ
3)バグの混入度：非ＯＯＰ＝ＯＯＰ
4)生産性：非ＯＯＰ＞ＯＯＰ

反論よろしく。
0879デフォルトの名無しさんNGNG
オブジェクト指向がいらないとか下らないこと言ってる香具師は実名晒せや。
まあお前ら腰抜けは2chで煽るのが精一杯ってこった。
0880デフォルトの名無しさんNGNG
>>878
頼むから最初から読んでくれって。
このスレで出た結論は
アンチはポリもーフィズムが理解できていない。
よって、議論にならない。
だろ？
0881デフォルトの名無しさんNGNG
まあ、非OOPでJavaAPIよりいいもの作れたら
土下座して謝るよ。
0882デフォルトの名無しさんNGNG
>>880
パート I からそうだったが。
0883デフォルトの名無しさんNGNG
>>882
このスレの結論からゆうと
書き込む香具師はみんな職場では居場所のない寂しがりやさんだってことだよね
0884デフォルトの名無しさんNGNG
あるスレではこんな事が書いてあったけど、
>C++/Javaは定義済みのクラスライブラリの使い方との戦いであり
>言語仕様はCとそんなに変わらない
>構造体から拡張されたクラスの概念・設計手法を覚える程度
言語と、既存のライブラリーをセットで考えるからわけわかめになる。
言語があって、その上でのライブラリーなんだよね。

0885小笠原照栄NGNG
手続き型設計が最高だ。
OOP なんてやってられるか。
至急、仕事下さい。
0886デフォルトの名無しさんNGNG

.　　　　　　　∧＿∧
　　　　　　　（；´Д｀）ﾊｧﾊｧ
　　-=≡ 　/　　　 ヽ
.　　　　　 /|　|　　 |. |
　-=≡　/.　＼ヽ／＼＼_
　　　　/　　　 ヽ⌒)==ヽ_）=,.、,､,..,､､.,､,､､..,_　　　　　 　／i
-= 　 /　/⌒＼.＼　||　　;'｀;、､:、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i　）)
　　／ ／　　　 >　） || (( '､;: ...: ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣
　/　/ 　　　　/ ／＿||＿＿||｀"ﾞ',''`ﾞ.`´ﾞ｀´´´.＿＿＿
　し'　　　　　（＿つ￣(_））￣(.)）￣￣￣(_））￣(.)）￣

0887プロの逝って良しの１NGNG
朝出勤する。
今日の業務はツール作成だ。
言語はもちろんＣ。
私の指がキーボードの上を一閃すると、モニタ上を美しいコードが流れていく。
午後、デバックが完了する。
向かいのＪａｖａ坊が２ヶ月も掛かって作っているコードを自動生成するツールである。
プロジェクトで割り当てられた１２本のサーバーサイドプログラムを
私は一日で作り終えた。
午後は優雅に紅茶をたしなみ、定時に帰宅した。
0888デフォルトの名無しさんNGNG
しばらく来ないうちに電波が増大しとるなぁ。
コネクションプールでスピンロックかましてたのは直したのかよ。
0889デフォルトの名無しさんNGNG
プ逝１の書き込み時刻を見ていると、とても定時出社定時帰宅している人間には
見えないんだが…
0890デフォルトの名無しさんNGNG
寝る間も惜しんで、デバッグ
0891デフォルトの名無しさんNGNG
ぷいいち
コネクションプールでスピンロック

禿ﾜﾗ
0892デフォルトの名無しさんNGNG
J2EEってﾅﾝですか？
0893デフォルトの名無しさんNGNG
逝って良しの１は凄いな。
定時帰りか。
ここにきてるOO厨は無理だろうね。
あっ働いてないか。（ﾜﾗ
0894デフォルトの名無しさんNGNG
>>887
半日でおわるよーなツール作れば解決する問題を12本のサーブレットに分割設計するプイ一の職場、糞だな
0895プロの逝って良しの１NGNG
スピンロックって「直せる」ものなのか？
0896デフォルトの名無しさんNGNG
Java でコネクションプールを自作したという話はやはりヨタ話でしたか
0897プロの逝って良しの１NGNG
スピンロック
一方のCPUがある資源を利用中に、もう一方のCPUで同じ資源をアクセスする
場合、その資源の解放を待ってビジーウェイトする方法である。
資源を利用している排他区間が短い場合には、CPU間通信を利用した排他制御
を行うよりずっと軽い実装となる。

アセンブラならともかく、Javaではスピンロックを作ったり直したり出来ません。
0898デフォルトの名無しさんNGNG
( ´_ゝ`) ﾌｰﾝ
0899デフォルトの名無しさんNGNG
おまえらOOでデータベースなんぞ扱えんだろうが。
確かに、オブジェクトは使う。
しかしオブジェクト指向ではないな。
これだからOOﾏﾝｾｰは困るよ。
0900デフォルトの名無しさんNGNG
DBﾏｶﾞｼﾞﾝ読んで感動しちゃったですか？
0901デフォルトの名無しさんNGNG
>>900
はぁ？
0902デフォルトの名無しさんNGNG
>>899

オブジェクト指向にもいろんな側面があるから、具体的に何が要らないのか言え。

確かに データベースと連携する Web プログラミングにゃ、OO の知識はあまり要らない（ポリモーフィズム使う機会が無い）と感じる。
0903デフォルトの名無しさんNGNG
オブジェクト指向ってださい！
メソッド=振る舞い
ポリモーフィズム=多態性

メソッドについて言えば、振る舞いって何だ？ﾊｧ？
振る舞い振る舞い。あほかと。
おまえなぁ、そんなださい言葉使うぐらいならな、
サブルーチンぐらいいっとけ。
得意げにプロパティは属性とか性質とか言う意味です。
なんていってんじゃねぇよ。ｱﾌｫ
0904デフォルトの名無しさんNGNG
>サブルーチンぐらいいっとけ。

究極のバカ発見
0905デフォルトの名無しさんNGNG
>>904
オブジェクトのサブルーチンだろ？
おまえは至高の馬鹿だよ
0906デフォルトの名無しさんNGNG
>>904-905
今回は至高の馬鹿の勝ちとします。
0907傍観者NGNG
>>904
煽りならもうちょっと頭を使ってください。
0908デフォルトの名無しさんNGNG
真の傍観者は発言しません。
0909OOPM!NGNG
Object Oriental Programming Manse-
0910デフォルトの名無しさんNGNG
オブジェ糞至高
0911デフォルトの名無しさんNGNG
>>897
必死こいてググって調べてみたんだね。感心感心。
でも、
> アセンブラならともかく、Javaではスピンロックを作ったり直したり出来ません。
これはプ
0912デフォルトの名無しさんNGNG
>>897
ちなみに君がググったのは
ttp://www03.u-page.so-net.ne.jp/da2/h-takaha/internal24/node292.html
だろ。ほんと、ミジメな奴だね。
0913デフォルトの名無しさんNGNG
>>899
OODBMSも知らないシッタカ君ハケーン
0914プロの逝って良しの１NGNG
ああ、前にもＪａｖａでロック機構作れるとか言ってたヴォケがいたね。
検証してやるから具体的に書いてね。
0915デフォルトの名無しさんNGNG
>>914
なんのはなし？MUTEXロック相当なら言語仕様のうちのはずだが･･･
0916デフォルトの名無しさんNGNG
マルチスレッド対応のコネクションプール作ってください。
0917デフォルトの名無しさんNGNG
public class Pool{
　private LinkedList pool = new LinkedList();
　private ArrayList ref;
　private volatile boolean closed = false;
　public Pool(int count){
　　ref = new ArrayList(count);
　　for(int i = 0 ; i < count ;i++){
　　　Resource res = new Resource();ref.add(res);pool.addFirst(res);
　　}
　}
　public Resource get()throws InterruptedException{
　　if(closed)return null;
　　synchronized(pool){
　　　while(pool.size()==0)pool.wait();
　　　return pool.removeFirst();
　　}
　}
　public void release(Resource res){
　　if(closed)return;
　　synchronized(pool){pool.addLast();pool.notify();}
　}
　public void close(){
　　synchronized(this){
　　　if(closed)return;
　　　closed = true;
　　　for(Iterator iter = ref.iterator();iter.hasNext()){
　　　　((Resource)iter.next()).close();
　　　}
　　}
　}
}
0918デフォルトの名無しさんNGNG
399 ：逝って良しの１ ：02/05/30 03:31
クラス名と違う多態コンストラクタを作りたいのですが
どう書けば良いのでしょうか？


400 ：デフォルトの名無しさん ：02/05/30 03:47
>>399
ムリ。やるならnewするときに
temp a = new temp(1);
のようにパラメータをわたし、
ソレによりこんすとらくたの処理内容をかえるくらい。
あとはオーバーライドとかだけど


401 ：逝って良しの１ ：02/05/30 03:52
ありがとうございました。
やっぱ無理ですか・・。
0919デヴューでつかNGNG
http://pc.2ch.net/tech/kako/1007/10078/1007802486.html
868 名前： 逝って良しの１ 投稿日： 02/01/07 02:02

コテハン出してJava房への完全勝利宣言をしておこう。
0920デフォルトの名無しさんNGNG
http://pc.2ch.net/tech/kako/997/997791189.html438
名前： ＯＯ逝って良しの１ 投稿日： 01/09/23 07:00

オブジェクト指向の概念は危険です。
言語だけ見ましょう。
オブジェクト＝扱うべきデータ（たまにハード）ぐらいに捕らえていた方が
無難です。

「扱うべきデータとそれを操作する関数のパッケージがクラス。
クラスに操作入出力関数を埋めこんで、クラスからクラスへデータ
を渡すだけで必要なプログラム動作が得られるような構造」
と理解すればＯＫ。

解説本読んでも混乱するだけです。
0921プロの逝って良しの１NGNG
>>918
教えてもらったら礼を言う。
当然だろ。

>>919
いや、そのずううーと前に使ってる。
0922プロの逝って良しの１NGNG
>>915
ああ、言語仕様にあるのを使ったら自作したことにならないって事。
0923デフォルトの名無しさんNGNG
次スレ立てれ。
0924デフォルトの名無しさんNGNG
>>922
他の言語(アセンブラ除く)だったらロック機構を自作できるのかい？
0925プロの逝って良しの１NGNG
無理
0926デフォルトの名無しさんNGNG
>>354
今更だけど。
ニュータイプの手続き型の詳しい説明ｷﾎﾞﾝ。
367のコード見ても全然わからん。
0927デフォルトの名無しさんNGNG
オブジェクト指向でプログラミングすると
何がうれしいの？
ただのオナニーじゃん。
0928デフォルトの名無しさんNGNG
またひとり脱落～
0929デフォルトの名無しさんNGNG
>>928
早く復帰できるようにね。
0930プロの逝って良しの１NGNG
>>924
あの手のブロッキング関数（I/O待ちを含む関数）は
裏で結構複雑なメッセージ駆動型の処理をやっているのです。
ライブラリではマルチスレッドの機構などを駆使して手続き型にまとめてあります。
0931デフォルトの名無しさんNGNG
別にJavaでもロック機構は作れるだろ。
0932デフォルトの名無しさんNGNG
別にアセンブリでもロック機構は作れるだろ。
0933デフォルトの名無しさんNGNG
おまいら、ウザイから次スレ立てるなよ。
0934デフォルトの名無しさんNGNG
なんでロック(排他制御)の話が、ブロッキングIOの話にすり替わっているのか、よく理解できないでし。
つか、Linuxカーネル・ヲタが、カーネル内の話にすり替えてるの？

＃ブロッキングIOといえば、selectかmulti threadで処理と相場が決まってるでしょ
0935デフォルトの名無しさんNGNG
>>934
いいえ、厨房が話をはぐらかそうとしているだけです。
とりあえず、
「プロの逝って良しの1が書いたコネクションプールはツカエネエヨ！」
ってことでＯＫ？
0936デフォルトの名無しさんNGNG
桶
0937デフォルトの名無しさんNGNG
排他処理といえばセマファだけど
安全なセマファは INC か XCHG 命令が発行出来ないと難しいだろ
0938デフォルトの名無しさんNGNG
>>937
ﾈﾀだよなぁ…？
0939デフォルトの名無しさんNGNG
こうか？
Lock();
if (! fSemaphore){
fSemaphore=true;
UnLock();
処理
fSemaphore=false;
}else UnLock();

0940デフォルトの名無しさんNGNG
>>919
逝って良しの１は誰に勝利したと思ってるんだろう?
もし859が逝って良しの１だとしたら、862は悪くない。859の書き方が悪いだけ。
0941デフォルトの名無しさんNGNG
アセンブラやってたころ、目的の処理を実装する際に
コードは全てリロケータブルに書き、ルーチンコールを一括管理するモジュールを作り、
手続きとデータを一括で管理するようなコード書いてたな。
思えば、あれも今で言うオブジェクト指向みたいなもんか。
んで、アセンブラが無く、マシン語モニタで直接コーディングしてたころは、
コードの自己書き換えをするなんてゆーことが結構当たり前の手法だったなぁ。
最近のOOP厨なんかには、理解できない世界だろうな。

ところで、オブジェクト指向はいいんだけど、
Windowsとか、Macとか、GUI搭載OSからPC始めましたなんて香具師って
あんまりいい設計できない気がするのは、漏れの懐古主義的な気のせいかな。
今のチームでも、アセンブラとかやってた人間と、Winから始めた人間とでは、
細部のツメが甘い気がするんだよね。
特に、エラーハンドリング周りがツメられない。
漏れのところだけかな。。。ｵﾔｼﾞは死ねってか。ｳﾄｩ
0942デフォルトの名無しさんNGNG
ツメられないじゃなくて面倒だから手を抜いてるだけだろ。
0943デフォルトの名無しさんNGNG
それは言えるかも。
最近の開発環境って、いろいろ便利だからな～。
アセンブラの頃は、「無いモノは作る、穴は作らない」って感じだったけど、
最近は、「無いモノはサードパーティ探し、それでも無ければ、必要最低限だけ作る」
って感じ。特に、VBなんかやってるコ達に多い気がする。

設計や実装における手法やスキルがどうのこうのってよりは、思想の問題だな。
0944デフォルトの名無しさんNGNG
>>943 VBだけじゃないと思うけどね　兎に角　作るより使うってのを思想にしちゃってるよな
0945デフォルトの名無しさんNGNG
前半はともかく後半の「穴は作らない」については同感かも。
動けばよいでしょ、と例外処理が甘い輩は多い。
0946デフォルトの名無しさんNGNG
アセンブラからやってた親父は
例外処理とか言いながら関数毎にtryブロック作ったりして
余計に保守性のないコード量産するじゃねーか
0947デフォルトの名無しさんNGNG
燃料入りました～
0948デフォルトの名無しさんNGNG
何事もやりすぎはよくないってことでOK？
0949プロの逝って良しの１NGNG
>>937
ＩＮＣは多分ダメ。
セマフォにはそれ用の命令が有るはず

>>939
Lock()の中でセマフォ使ってるんでダメ
0950デフォルトの名無しさんNGNG
>>949
int が8bitだと厳しいけど16bit以上で かつ cnt++ が inc cnt になるならば

volatile int cntSemaphore = 0;

if (0==(cntSemaphore++)){
　・・・危険な処理・・・
}
cntSemaphore++;

で十分セマファの代わりになるよ。
少なくともこの32bitカウンタが溢れるより先にウオッチドッグがかかる
0951デフォルトの名無しさんNGNG
ロック機構を自作するってのは言語仕様に有る専用の命令を使わないで
CPUに有る専用の命令を使って作るってことか。ふーん。
0952デフォルトの名無しさんNGNG
>>951
From: [922] プロの逝って良しの１ <>
Date: 02/09/23 05:12

>>915
ああ、言語仕様にあるのを使ったら自作したことにならないって事。
0953950NGNG
あ　後の cntSemaphore++; は 当然 cntSemaphore--; だな・・・

>>951
　無理にやる必要はないけど、JAVAのように言語仕様中に常に用意されてるとは
限らない。　というか C/C++ にはそういう機能は仕様中にないから。
0954950NGNG
ただし cnt++が RISCだと read/inc/writeの３命令に展開される訳で
この場合、その３命令中にスレッド・タスク切替が起きる可能性があるとダメ

0955デフォルトの名無しさんNGNG
自作ったってたいした事はしてないのな。使っている命令が違うだけで。
0956プロの逝って良しの１NGNG
>>950
１命令でもマルチＣＰＵだとＲＭＷサイクル命令の命令じゃないとだめ。
ＩＮＣはたしか大抵違うと思った。
0957950NGNG
>>956
たとえばx86の場合、 XCHGだけはLOCKを付けずに実行出来るという話とか？
だけど、そういう場合 OS が載ってるからOSの機構を使うでしょ。

一般的にマルチCPUで共通RAMを通信路に使うような場合
セマファでロックするような機構は採用しないでしょう
例えば、
struct {
bool fReady; // CPU1がデータを用意し終わった事を CPU2に通告
bool fReadEnd;//CPU2がデータを確認した事をCPU1に通告
　・・他のデータ
｝　CONTROL;

みたいに　相互にフラグをたてあって通信する方式にするんじゃないの？
0958デフォルトの名無しさんNGNG
>思えば、あれも今で言うオブジェクト指向みたいなもんか。
それは構造化の範疇なんだけど・・・
大丈夫か？
>手続きとデータを一括で管理するようなコード書いてたな。
これはクラス思考というか、
モジュール化すると必然的にそうなると思う。
まあ、そもそも高級言語でやっと作れるようなもんは
アセンブラじゃ現実的には作れない事くらいは理解できてるのかな？

>最近のOOP厨なんかには、理解できない世界だろうな。
マジで言ってるの？
そりゃ、ライブラリー組み合わせ厨にはわからんだろうけどな。
俺的には高級言語での「コード書き換え」にあたるものは
アセンブラレベルでの書き換えより抽象的だから、
もっと難しいと思うけど。
まあ、ある種の高速化テクニックであるから、
かなりの計算をおこなうソフトウェアを書く人以外は使わないな。
あとはコンパイラを作ってる人に聞いた方がいいかもね。
コードを生成するプログラムね。
あ、コンパイラ自体もコードを生成するプログラムか（ｗ

>アセンブラの頃は、「無いモノは作る、穴は作らない」って感じだったけど、
趣味でやってるプログラマーがたくさんいるから
そんな気がするだけだと思うよ。
JAVAやってたって、SUNのライブラリーは一切使わないよ。
特にjava.util.*とかさ。
（nativeメソッドを呼ぶところは使うけどね）
0959デフォルトの名無しさんNGNG
>>958
>>アセンブラの頃は、「無いモノは作る、穴は作らない」って感じだったけど、
>趣味でやってるプログラマーがたくさんいるから
>そんな気がするだけだと思うよ。
>JAVAやってたって、SUNのライブラリーは一切使わないよ。
>特にjava.util.*とかさ。
>（nativeメソッドを呼ぶところは使うけどね）

それはまた、極端な。

nativeメソッドに言及されてるので
「java.util.*のクラス郡はパフォーマンスが良くないから使わない」
ということだと思いますが、8:2(9:1)の法則に従えば、nativeメソッドが
必要なほどハイパフォーマンスを求められる所はほんの1割から2割、
それ以外での java.util.*以外のメソッドの使用はむしろ有害かと。

はじめは標準ライブラリを使用してシステムを作成し、
パフォーマンスが悪ければプロファイリングを行いボトルネックを探し出す、
そこで Java標準ライブラリがボトルネックとなっていて初めて自作のライブラリを使うべきかと。
0960デフォルトの名無しさんNGNG
正直、自作ライブラリだらけだと引き継ぎに困る。

楽するために作ったはずのライブラリやフレームワークなのに、
サポートやらメンテやらの面倒ごとに追われるのは勘弁。
0961デフォルトの名無しさんNGNG
オマエラ、特に逝って良しの1、
せめてDijkstra先生が提唱したセマフォを構成する要素ぐらいは押さえて議論してくれよ。
このスレでの惨状を見て、Dijkstra先生もきっと天国で泣いてるぞ。
0962デフォルトの名無しさんNGNG
>>941
アセンブリレベルでそんなの自慢されてもねえ…
マルチスレッドだったりとか、コードページがread onlyだったり、そもそもROMに焼いたりしたら
全然動かなくなっちまうもんなあ。

ちなみに、Smalltalkで、methodAに最初はコードを自動生成するコードを書いておいて、
それが実行されたらmethodAを自動生成されたコードに置き替わるようにしたことはある。
環境に応じて(OSとか外部ライブラリとか)切り替えたかったもんでね。
0963プロの逝って良しの１NGNG
Dijkstra逝って良し！
0964デフォルトの名無しさんNGNG
>>963
あれ？最近、本当に逝ってしまわれたのでは？
0965デフォルトの名無しさんNGNG
http://www.cs.utexas.edu/users/EWD/

On 6 August 2002, Edsger W. Dijkstra, Professor Emeritus of Computer Sciences and Mathematics at The University of Texas at Austin, died at his home in Nuenen, the Netherlands.
0966デフォルトの名無しさんNGNG
>「java.util.*のクラス郡はパフォーマンスが良くないから使わない」
アルゴリズム自体のパフォーマンスが良くないので。
ようするに希望のアルゴリズムを実装したクラスが無いから。

nativeメソッドと書いたのは、
API(システムコール）呼び出しの事。
JNIじゃない。
ちなみにjava.util.*にnativeメソッドがあるかどうかはわからん。
あと、コレクション系はキャストするのが気持ち悪いのと、
内部でいろいろといじりたい事が多いのと、
頭に焼き付いてるので、リファレンスを参照するより
必要なメソッドのみをコーディングした方が、精神的に楽なのと・・・・
まあそんな感じ。

もちろん、どうでもいいプログラムには使うけどね。
つねに、改良しつづけるようなプログラムは
すべてのコードがいじれる状態であると便利。

また、汎用的なライブラリーほど(略
0967デフォルトの名無しさんNGNG
>>966
で、実際に自作してみたコードとjava.util.のコードとパフォーマンスを実測してみたわけ？
たまに自作した遅いコードを得意気に使ってるアフォがいるけど、
実測してみると汎用パッケージのコードのほうが速かったりするぞ。
特にコレクション系なんかは顕著だ。

> つねに、改良しつづけるようなプログラムは
> すべてのコードがいじれる状態であると便利。

改良しつづけるようなプログラムほど、
手を入れるべき部分を小さくするべきだと思うのだが。
0968デフォルトの名無しさんNGNG
改良し続けると、多くの場合、途中で担当者も変わってメロメロの改悪になるという罠。
0969デフォルトの名無しさんNGNG
>>967
> 改良しつづけるようなプログラムほど、
> 手を入れるべき部分を小さくするべきだと思うのだが。
君は未来の仕様変更で手を入れる部分がわかるのか？
0970デフォルトの名無しさんNGNG
>>969
考えられる範囲で汎用性のある設計をすべきと言ってるんじゃ?
それとも Hashtable の内部構造を B-Tree にしてくれとかいう
仕様変更が来るわけ?
0971デフォルトの名無しさんNGNG
YAGNI、とか言ってみる
0972デフォルトの名無しさんNGNG
>>970
> 考えられる範囲で汎用性のある設計をすべきと言ってるんじゃ?
そんなのは当たり前、そしてメモリと処理速度のトレードオフが有る程度可能なように
フレームワークを使えば変更されやすい箇所をより変更しやすくし、
他の箇所を変更しにくくさせることもできる

> それとも Hashtable の内部構造を B-Tree にしてくれとかいう
> 仕様変更が来るわけ?
50件程度処理できればいいという検索処理が5年後
10000件処理しなければならなくなったことはある。
よって、今までDBなど使わずにcsv & perlの適当な処理で済ましていたのを
DBを使わなければならなくなったことはある。

また、絶対にこの項目はユニークで重複することはない
と言いきられた項目が仕様変更で重複を許すことになったこともある。

バグのないプログラムを作るべきだが、現実はプログラムにはバグが付き物のように
汎用性のある設計はすべきだが、現実は汎用性のある設計などない。
0973デフォルトの名無しさんNGNG
ユーティリティとフレームワークの区別も付いていない厨でした
0974デフォルトの名無しさんNGNG
Javaのコレクションなら、Mapインターフェイスがあるから
HashTable => TreeMap の変更は単に「文字列置き換え」だしな。

仕様変更に強い強い。
0975デフォルトの名無しさんNGNG
データストア周りを自作して将来 DB 化されてラッキー「俺は標準の
コレクションクラスなんて使わん!」

って方が居られるようですが激しく痛いです。
0976デフォルトの名無しさんNGNG
あるものは使えよ。時間がもったいないよ。
きちんと作ってからあとからプロファイリングして
しょぼいところだけ作り直すってのが基本でしょ・・・
0977デフォルトの名無しさんNGNG
>実測してみると汎用パッケージのコードのほうが速かったりするぞ。
アルゴリズムの計算量で比較してるので、実測はしてない。
でも当然オリジナルの方が速いと思うけど。
少なくても俺はメリットとして実行速度以外にいくつか上げてるんで
そこも理解してね。
逆に聞くけど、ライブラリーのコレクションのアルゴリズムの計算量とか特性
を知ってるのかな？
どうせ、委譲しないで使ってるんじゃないかな。

あとは例えば、LinkedListで保存してたものを
急きょ、ヒープソートしたくなった時とかはどうするんだい？
もしかしたらJAVA-APIでやる方法があるのかもしれないけど
俺は知らない。
その時にリファレンスを読むよりは、実装した方が楽だと俺は思う。
ちなみに冗長な処理でよければ、いくらでもやり方はあると思うけど
（配列で取り出して、ソートして、クリアして、戻すとかね）
職人気質な人はそれを好まないよね、外から見てわからなくてもさ。
VBを嫌うようにね。

>手を入れるべき部分を小さくするべきだと思うのだが。
意味かよくわからない。

>ユーティリティとフレームワークの区別も付いていない厨でした
ユーティリティーじゃなくて、ライブラリ？
まあいいや。

>HashTable => TreeMap の変更は単に「文字列置き換え」だしな。
確かに便利だね。
あのライブラリーを作った人の労力はすごそうだ。
でも、HashTabeの内部構造を・・・ってのとは違う話っぽくない？
0978デフォルトの名無しさんNGNG
> アルゴリズムの計算量で比較してるので、実測はしてない。
> でも当然オリジナルの方が速いと思うけど。

車輪職人は大抵現実を見ないという結論。角度とか。
0979デフォルトの名無しさんNGNG
>>977
リファレンスを読めッ！ そっちの方が早いし速い。
0980デフォルトの名無しさんNGNG
職人は TOC を考慮しない
これ基本
0981デフォルトの名無しさんNGNG
だからアルゴリズムが違うんだって（ｗ
例えばね
線形リストでソートしながら格納するのと、
BTREEでソートしながら格納するのは
どっちが効率いいかわかるでしょ？
例えば、１００００個ノードがあって、
格納するデータが一番後ろにつくものだったら、
線形リストでは１００００個のデータをたどらなきゃいけないけど、
BTREEはlog2 10000くらいですむ可能性があるわけ。
また、データの分布によってはBTREEも平衡化する操作を加えたり
加えなかったりしていいわけだ。
他にも線形リストの主要なところにポインタを張ってあげると
（形としてはハッシュになるんだけど）
すごい効率があがるわけ。
実測する事にそれほど意味ない事が理解できましたか？
でもって、ライブラリーを使わないメリットもつかめました？
0982デフォルトの名無しさんNGNG
>>981
そんなあなたにデータベース。
0983デフォルトの名無しさんNGNG
>>978
>車輪職人は大抵現実を見ないという結論。角度とか。
古っ。
0984デフォルトの名無しさんNGNG
データベースってHD内で
ハッシュ＋BTreeなんだっけ？

実際にどれくらい速いの？
0985デフォルトの名無しさんNGNG
HD　vs メモリだとすると
４桁くらいの差があるのでは？
0986デフォルトの名無しさんNGNG
一番シンプルなスタックとかリストなら
３分ありゃ書けるだろ。
0987デフォルトの名無しさんNGNG
今さら大してメリットじゃないというか。
作るものにもよるんだろうけど。
0988デフォルトの名無しさんNGNG
1000とり合戦の始まりだ
0989デフォルトの名無しさんNGNG
>>984
そんな単純なものじゃない。
0990デフォルトの名無しさんNGNG
1000。
角度とか。
0991デフォルトの名無しさんNGNG
LinkedListって双方向リスト？単方向リスト？
単方向だと100000くらいデータ入れたあと
removeするのは気が引けるね。
0992991NGNG
あ、JAVAのLinkedListはどっちも
removeは重いんだった・・・
0993デフォルトの名無しさんNGNG
>>981
普通、アルゴリズムは最初から最速のものを使用しますが何か？
データ構造とアルゴリズムを分離して交換可能であるように設計するのがあたりまえですが何か？
それを体現したのがJavaのコレクションなわけですが何か？
0994991NGNG
訂正
あ、JAVAのLinkedListはどっちにしろ
0995デフォルトの名無しさんNGNG
また、データの分布によってはBTREEも平衡化する操作を加えたり
加えなかったりしていいわけだ。
他にも線形リストの主要なところにポインタを張ってあげると
（形としてはハッシュになるんだけど）
すごい効率があがるわけ
0996デフォルトの名無しさんNGNG
1000と千尋の神隠し
0997デフォルトの名無しさんNGNG
Mapを全部実装するのはしんどいな（ｗ

データ構造とアルゴリズムを分離ってなんだ？
0998デフォルトの名無しさんNGNG
1000 GET!!
次スレはいらん。
0999デフォルトの名無しさんNGNG
JavaのLinkedListはクソ
removeするのに走査が必要
1000デフォルトの名無しさんNGNG
10000 万件超えるなら素直にデータベース使え。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。