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

　オブジェクト指向はより自然なモデルに即したものではあるが、クラス
を理解する労力が大きく、目的まで達成するのに時間がかかる。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
んと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞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/

　またいつの間にかスレが1000に達しようとしていました
ご意見ありがとうございます。
やはりこれだけレスが多いということは、OOに疑問を感じている
技術者がどれだけ多いかということを実証していると思います。
　私の独自の調査においても、OOの現場での有効性に疑問をもっている
という人は全体の54.3％にも達しています。やはりOOはその有効性
に疑問があると言わざるをえません。

　皆さんも本当に何が残ってゆく技術なのか、何がイマイチぱっ
とせずに中途半端に終る技術なのか見きわめて、技術を習得して
いきましょう。

OO最高！！！

（O_O）ｲｲ!!

>>1
クラスを実装するのも結構大変だね。

いまどきOOしなかったらプログラミングできねーよ。

>>10は削除依頼だしてこい

アスペクト指向は戦場では必要なし！

>>10 削除よろぴく

エージェント指向は戦場では必要なし！

削除依頼は必要なし！

>>10
お前、俺を待ってただろ。

>>11
顔真っ赤にしてロリードしてました。

>>1-1001 ｼﾞｻｸｼﾞｴﾝﾃﾞｼﾀｰ

じゃあ終了ってことで

あいーん

とったんラビュ
http://www.katch.ne.jp/~manion/
気持ち悪い引きこもりのサイトだよ。
テキストサイト

　　　　　　　　　　　　　　ζ
　　　　　　　　　 ,,.-‐''""""'''ー-.､
　　　　　　　　,ｨ"　　　　　　　　　 ＼ 　　　やった2ゲットだ！
　　　　 　 　 /　　　　　　　　　 　 　 `､ ボケ共がオレ様にひれ伏せ！！
　　　　　 　 ,illlllllllllll　　　　　　　　　 　i
　　　　　　r'-=ﾆ;'_ー-､___,,.ｨ‐‐-,,_　　_| >>3おせーんだよボケが
　　　　 　 | r,i　　　~`'ー-l;l : : : `l-r'"ﾒ､ 　>>4人間やめろ
　　　　　　ヾ､　　　　　　　`ー‐'": i!_,l_ノ` >>5ラーメンの汁でも飲んで窒息しろ！
　　　　　　　|　　　　　　　　 ,:(,..､ ;:|/ 　>>6回線切って首吊れ
　　　　　　　|　　　　　　　　,,,..lllllll,/ 　　>>7さくらたんにでも萌えてろ　　
　　　　　　 /　　`::;;.　　　'"`ﾆ二ｿ　　>>8チンコちっさそう　　　
　　　　　/7　　　　ﾞﾞ:`-､;:;:;;;:;:;:;;/ 　　　　　　>>9バカ
　　　,,.ィ"`:､　　　　　　　　"/;:`ｰ-:､.._ 　　>>10病院逝ったら？
　‐'":;:;:;:;:;:;:;:＼　　　. : :;: .　 ;/;:;:;:;:;:;:;:;:;:~`'''ー--:､,,_

俺のスレに来い

ｵﾌﾟｼｪｸﾄ指向はﾌﾞﾗｯｸﾎﾞｯｸｽ化じゃーーー！
これを入れると、あれが出てくるみたいなのを大量生産して、
みんなで、もっと楽に作りましょう（ﾜﾗ

オブジェクト指向、、必要最小限に使うってのがよさげかもね、てか一番楽だろうね
デザインパターンとかはしんどいと思うよ

でもクラスをまったく使わないってのは
それはそれでしんどいだろう

老人め。

>>20
おまえもそのうち仲間入りだよ。
その前に死ぬか。

>>21
なんか怖いよ

プログラマは老いたら身を引くべきだ。
みんなそうおもってるだろ？

c++におけるclassとは・・・structの亜種[なれの果て]とか言ってみる

戦場じゃないのでオブジェクト指向は必要アリ

>>25
同僚がそんなこと微塵も考えてないという罠。

>>24
struct Hage {
　　|
　　:
　　|
};
class Hoge : public Hage {
　　|
　　:
　　|
};

>ちゃんと整備されたドキュメントがなければ粗大ゴミソース。

OOに限った話しでは無い。

>またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
>んと設計され、ちゃんと実装されたクラスがあるという前提での話。
>実際は世の中にどれだけの糞SEや糞PGがいることか。。。

これもOOに限った話しでは無い。

　またいつの間にかスレが1000に達しようとしていました
ご意見ありがとうございます。
やはりこれだけレスが多いということは、OOに疑問を感じている
技術者がどれだけ多いかということを実証していると思います。
　私の独自の調査においても、OOの現場での有効性に疑問をもっている
という人は全体の54.3％にも達しています。やはりOOはその有効性
に疑問があると言わざるをえません。

　皆さんも本当に何が残ってゆく技術なのか、何がイマイチぱっ
とせずに中途半端に終る技術なのか見きわめて、技術を習得して
いきましょう。


↑本当にこう考えているんだったらそうとう頭がおかしなやつってことだ。

まー、アレだアレ。
C言語が流行りだした当初、新しい技術についていけないダメ人間が
「ローカル変数はわかりにくい。グローバル変数と名前が同じだと
　混乱する。よってローカル変数は使わないほうが良い」
とか言ってたのと同じだよ。

未だに汚い手法は使うが、同時にOO無しってのは考えられない。って
感じですが、みなさんはどう？

>>19に概ね同意。
要は使いようだな。適用する必要がなければ適用しなければいいだけ。絶対に何が何でもOOPってのは変。
構造化プログラミングは必須だと思うがな。

結局OOPL使わない仕事って滅多に来ない…てかここ3年お目に掛かってない…俺に辞めろと？

OOPLのすごさが分かるのは、ライブラリー(フレームワーク）を作ってるときじゃないかな？

ライブラリー使ってるだけの人にとっては、OOPLだろうがなんだろうが
あまり関係ないと思う。

そしてそれはそのままGCにも当てはまる。

すなわち最近の言語は「再利用」というキーワードを中心として設計されているという事かも？

GC?

何言ってんかわかんねーよ

ジョンだからしょうがいない。

ｹﾞｰﾑｷｭｰﾌﾞ?

General Combiner!!

GCがわからんってネタだよね？

マークアンドスウィープ
ストップアンドコピー
リファレンスカウント
いまどきGCを知らないバカはいないと思われ

ガベージコレクタだとしたらなおのことJohnの言いたいことが分からない
からみんな遊んでるんだと思うよ。

>>34が作ったライブラリはことごとく再利用されていないという罠。

まあなんにしてもJohnはバカってことだ

ごみ集め処理

ジョンの言うGCつーのはこれだよ。
http://www.watch.impress.co.jp/game/docs/20020308/ban.htm

41はどこかで見た単語を並べてみたんですか？

>>47
マイケルとしては煽るにももっとゲージュツ的見地からの類推がホシーのよね
＃まさかマジで関連が分からんわけじゃあるまい

確かにGCは再利用に役立つよね。
情報隠蔽を手助けするから。

言語的仕掛けとランタイムな仕掛けをごっちゃ混ぜにしてるのはやっぱり
Java屋さんですか？

GCはライブラリだけじゃ無理。
ホシュテキGCとかいう半端者になる。

マルチスレッドはライブラリだけじゃ（以下略

OOPL→使う人が意識して使う
GC→意識のしようが無い

たのむよJohn

>>53
GC無しの動的メモリ管理だと意識せざるを得ないよね。
GC→余計なことを意識しなくて良くなる
かな。

GCで情報隠蔽ってのは、他のモジュールがまだ参照しているかとか
気にしないですむから、情報が局所的になるって事かな？

Objective-C のpoolみたいなのってのはやっぱ半端物かね？

GCが再利用に関係するってのはちょっと飛躍しすぎじゃないか？

autoreleaseか。GCほどの便利さ/安全さは無いよね。

GCはどうでもいいけど

> そしてそれはそのままGCにも当てはまる。

「それ」って何？

>>58
うん。。。ない。つーか良く間違える。

まあJohnをいじめるのはこれくらいにして、本題のOOの可否に戻ろうか？

CやC++のGUIツールキットを使ってると、他のモジュールが中でどうメモリ
管理してるか知らざるを得ないことが多いよね。この文字列は誰がfreeする
んだとか、このフォント今freeしていいかどうかとか。

>>61
そりゃ可に決まってるだろ。
このスレはそういう意見を誘引するための罠
じゃないのか？

>>63
スマソ言い方が悪かった。OOが生きる現場と、どうやってもOOが合わない
現場ってのをかたりませう

まー、アレだアレ。
C言語が流行りだした当初、新しい技術についていけないダメ人間が
「ローカル変数はわかりにくい。グローバル変数と名前が同じだと
　混乱する。よってローカル変数は使わないほうが良い」
とか言ってたのと同じだよ。

↑
マジでこんなバカなこと言ってた人がいるんですか？

>>65
古いソースとか読んでるとそういうのが行間から伝わって来る。

>>65
え、なんか間違ったこと言ってる？

>>67　微妙にﾜﾗﾀ

過剰にﾜﾗﾀ

オブジェクト指向つーか、クラス化すると
遅くならねぇ？そうでもない？うーん。だめぽー

クラス化しただけで遅くなることを示すベンチマークなら作れるけど、その話題はアレだよ･･･

高級志向っつーか、ベンツ化すると
高くならねえ？そうでもない？うーん。だめぽー

遅くなるのは事実だろうけど、それが問題にならないレベルで、
性能低下を補ってあまりあるほど開発効率を上げるから
オブジェクト指向を使おうって話でしょ。
性能低下が問題になるような環境じゃ
使わなきゃいいんだし。

Javaはかなり遅くなるね
C++だと別の言語を組み合わせなくても性能低下を極限まで削れる
Smalltalkはしらん

Cでクラスの継承っぽいことしたけどC++以上に効率の悪いコードになったな

要求をこなすことができればどんなに糞遅くても構わんよ
それより納期を守ってくれること、バグがないことのほうが大切

↑という視点でしか管理部門は見てないってことを念頭におくべし

>>75
重すぎて使い物にならないは監査に引っかかる罠。

> 重すぎて使い物にならない

「要求をこなす」に含まれると思われ。

今世間で「オブジェクト指向」と思われているのは
「クラス型オブジェクト指向」なのです。
対抗する概念として「配列型オブジェクト指向」の存在をここに宣言します。

>>78
どんな感じなんですか？それ。
void *型の関数があってデータと関数ポインタを同じ配列で管理したり？

>>79
＞void *型の関数
−＞void *型の配列

メンバー関数みたいのはありません。
クラス関数/メソッドの代用に関数ポインタを持った構造体なぞではありません。
（それじゃクラスと一緒じゃん）
例：クラス型と配列型で同じ物を書いてみます

Point point[10];

public class Point{
　　　int x;
　　　int y;

　　　void set_xy( int a,int b ){
　　　　　x = a;
　　　　　y = b;
　　　}
}

配列型

int　x[10];
int　y[10];

　void　set_xy( int n,int a,int b){　　
　　x[n] = a;
　　y[n] = b;
　}

Schemeやクラス無しLispとどう違うの？

Schemeやクラス無しLisp知らないし・・・。

>>81
もとのコードに配列が出てこないときはどうなるの？

>>81
意味わからん。それが？

ただの配列だな。昔からみんなやってるよ。
xとyの関係が非常に疎なのが気になる。

＞昔からみんなやってるよ。

承知の上だけど、オブジェクト指向を過剰に支持している人の中に
これ知らない人がいるのを思い出したもので。

OOPLのすごさが分かるのは、ライブラリー(フレームワーク）を作ってるときじゃないかな？

ライブラリー使ってるだけの人にとっては、OOPLだろうがなんだろうが
あまり関係ないと思う。

そしてそれはそのままGCにも当てはまる。
つまり、GCの便利さはライブラリー使ってるだけの人には分からない。

最近の言語は「再利用」というキーワードを中心として設計されているという事かも？

>>87
ハアァ？「これ」とか「配列指向」とか、いちいち名付けるほどのもんかよ。
知るも知らないも、考え付かないのはおまえの同僚くらいのもんだろ。

よく分からないんだけど、何がメリットなの？

>>81
xとyはグローバル変数になるの？
使えねえと思うけど。

>>88
それどっかで見た。コピペ文章っぽいな。

>>81
Point間の距離を測りたいときとかどうするんだろうな・・・
その前に参照ができねー

＞ライブラリー(フレームワーク）
フ゜

どこがおかしいんだよ＞バカ

おまえの顔

>>96
ｻﾑｲ
ﾑｻｲ

クラス型と配列型は同じものを縦割りにしたか横割りにしたかだけの違い。

>>98
つーか全ての質問に答えろ

100だろ

>>93
＞距離の計算

クラス型　　クラス内ではできない。外部に構造が必要。
　　　　　　（内部に持って来れるけど見苦しい）

配列型　　　
int get_distance( int n1 ,int n2 ){
　return( sqrt( pow(x[n2]-x[n1],2) + pow(y[2n]-y[n1],2) ) );
}

>>81 >>101
ネタ？

>>101
アスペクト指向を調べて来い

ああ、横のモノを縦に割っただけの詐欺商品にまだ気付かないなんて・・・。
哀れ・・・。

>>103
つーかさ、>>101はアスペクト指向以前に「型」について勉強しる！

ここで挙げた二つの型はオブジェクト指向の型の説明の為に私が
発明しました。
だから本で勉強してもそんなのは載っていません。
ニュートンが力学の説明の為に微積分を発明したのに似ていますが。

これ、技術としてはどっちかというと退化じゃないの？
カプセル化のメリットも無くなるし。
なんで過去の技術の説明に発明が必要なんだか。
ニュートンがかわいそうだよ。

むづかしく考えすぎ。

配列型でもプログラムの部品化、再利用化はできてましたよ
という話かな？

>>107
過去の技術ではありません。
クラス自体が只のブームで終わる可能性が高い。
クラス型オブジェクト指向には根本的な問題点が有り過ぎ。
１）アクセサビリティーの問題
２）継承スパゲッティーの問題
３）クラスの爆発　←　致命的にダメ

>>107
81に説明しても無駄だと思うけど。

>>81
応援してるよ。

> 81に説明しても無駄だと思うけど。

確かに。
俺、まだプログラミング始めたばっかで右も左も分からなかった頃に
似たようなこと考えた記憶有るな。
まさか人に喜んで言いふらすほど図々しくなかったけど。
俺も81を応援するよ。
がんばってくれ。
でも、一緒の職場になるのは勘弁な。

>>106
そうじゃなくってさ、>>105でいってる「型」は「データ型」のことだよ。
とりあえず多ソート代数とか、その辺からお勉強してみたら？

つーか、ネタみえみえなやつ、相手にするなよ。

ＯＯ信者必死だな（藁

同類との結合が強い場合にはクラス変数の配列ではなく、
単一クラス内に配列作ってクラス内で処理するというのは
かなり一般的に見られるコードです。

これはもう、クラス型オブジェクト指向がすでにその欠陥にぶち当たって
自己否定しないと目的物を作れなくなっている証拠です。

「データ」と「データの集合」とを統一的に扱えない時点で
クラス型オブジェクト指向は生まれた時から死ぬ運命だったのです。

81必死だな(w

>同類との結合が強い場合にはクラス変数の配列ではなく、
>単一クラス内に配列作ってクラス内で処理するというのは
>かなり一般的に見られるコードです。

意味不明。

もうちょっとだ！
もうちょっとでクラスを超える構造が出来る！

誰か 81 を窓から投げ捨ててくれ。

>>118
超構造体でも作れば。

え？　勉強になるから、>>81には頑張ってほしいんだが。

目的物ができれば良いのでわ？
言語の指向を達成するために人間が苦労するのは本末転倒でしょ。

>>121
目的物を達成するために言語の指向があるのだと思われ。

むかしFORTRAN66で構造体もどきをやるのに使われてたな。
もちろん今では存在価値ゼロなわけだが。

目的物を達成するために言語の指向が存在するのは確かだが、
もっと重要なのは人間自身が楽することでわ。
指向が仮にビューティフルでも、ユーズフルじゃない時だってあるじゃんかさ。
そういう指向が腐ってる、ってばっさり切るのは簡単だが、
代案はすぐには生まれんでしょ。

だから、逃げ道があるなら指向に因われるのは損だとおもう。
ナニナニ指向言語、っていう大看板の言語でも、
実際は逃げ道的仕様が用意されてる場合も多々あると思われ。
粘着してすまん。

>>124の様なバカには再教育が必要だな。

>「データの集合」
collectionはなんだろう・・・

無能は何をやってもだめ

>>117
訂正
同類との結合が強い場合にはクラス・インスタンスの・変数配列ではなく、
単一クラス内に配列作ってクラス内で処理するというのは
かなり一般的に見られるコードです。

>>81
それはハッシュの事？

例
CharクラスとStringクラス
文字と文字の集合を統一的に扱えないので二つのクラス生まれた。

>>128

クラスの中に配列持つことが悪とか思ってるだろ。
インデクサみたいに適切なアクセサがあれば何の支障も無く利用できると思うが？

超クラス構造への提案

１）アクセサビリティーの問題
　　スコープー階層モデルではもうやっていけないんでなんか考えれ
２）継承スパゲッティーの問題
　　１）と同時に解決できそう。
　　継承の為の継承ではなく、再利用に主眼を置いた構造をなんか考えれ
３）クラスの爆発
　　集約する方法を考えれ。
４）単体と集合の問題
　　ヒント
　　単体とは要素数１の集合だけど、この解決法では突破口に繋がりそうにないかも。
　　単体は自己の要素との相互作用を想定していない。
　　集合は自己の要素との相互作用を想定している。

>>132
>単体は自己の要素との相互作用を想定していない。

Compositパターンって聞いたこと無い？

必要ないものをぐだぐだ議論しても、無駄なものは無駄。

っていうか、81が求めてやまない「超クラス構造」ってデザインパターンそのもの
じゃ無いのか？

いいじゃん日本発でだそーうよ「超クラス構造」、Lyeeみたいな感じで。

81が問題を解決してコードを出したら、「それって○○○のことじゃん」って
言われることに23パターン

>>81
問題をあげるのは良いけど解決策を具体的に出さないと意味ないからね。

とりあえず､煽りぬきでやろう

>>81の言いたい事がいまいちよくわからない。
いったん具体性を持った議論をしよう。
既存のクラスで問題になっている具体例をあげてみて欲しい。

>CharクラスとStringクラス
>文字と文字の集合を統一的に扱えないので二つのクラス生まれた。
ここで具体例をあげてくれているけど、これは何が問題なんだろうか？

「集合」といっても、要素の順番に意味があるもの、無いけれど順番に取り出せる（イテレートできる）もの、
集合の中にあるか無いかがわかればいいもの、キーで検索したいもの、いろいろあるけど、
そのへんは最初から考えといたほうがいいのかな？

>>132
1) 何いってんだかサパーリわからん。スコープー階層モデルって何だ？
　　ちなみに動的スコープならもうあるぞ。
2) 実装継承と汎化-特化に基づく継承は区別できてる？
3) adaptorとinterface型
4) 相互作用とは何か定義を示してくれ。何が言いたいのかサパーリわからん。
　　

>>138
不細工。

>>133
良くしらんが、クラスが増え、複雑な構造になってくると
参照てんこもり渡しにならんの？

>>141
ヒント： リファクタリング

>>141
デザインパターンをしらんなら勉強してみろ。
たぶん、今悩んでいることがいくつか解決されるはずだ。

>>143
・い・や・だ・

おまえまず日本語なんとかしろよ。

>参照てんこもり渡しにならんの？
これなんて､何行ってるのかさっぱりだよ。
もしかしてｳﾞｧｶ?

デザパタ厨が荒らしに失敗した模様（藁>>145

けっきょく８１は自分用語を振りまくアフォだったのか・・・

>参照てんこもり渡しにならんの？
言いたい事はわかるし、>>143が答になってるからよし。

>・い・や・だ・
終わったな･･･

>>81はデザパタすら越えられないってことで。

「参照てんこもり渡し」が標準語になりますた。

「参照てんこもり渡し」
これどういう意味だよ・・・

２ちゃんねるって多くの人が集まるんだけど､
あげあしとり的な意見が大多数をしめている。
だから読んだり議論にさんかしてても何も残らないなぁ。
と思う今日この頃。

>>152
そりゃまあ、あげあしとり的な意見を無意識のうちにフィルタリング
できなければ2chのS/N比は最悪だろうなあ。

>>153
S/N比って、何よ？

Sound/noise

Soup/Noodle

Signa/Noise

>156
それじゃS/N比が大きくても嬉しくない

起きたら面白いことになってるねえ。
81って超科学と似てない？
相対性力学は間違っていた、なぜなら○○が説明できない！
これからは私の提唱する超相対性力学だ！
とかなんとか言っておきながら、実は単に理解できてないので
とんちんかんなことを言ってるだけって奴。

81に質問。
アクセサビリティって、もしかしてプログラムのどこからでも
自分の望む変数にアクセスできるのがいいって意味？

>>160
まあそんな意味。

>>151
仕事でやってるならそのうち突き当たるかも。

>>160
とほほ発見！

デザパタ厨になると「それって○○○のことじゃん」で全部済ませようと
する発展性の無い人間になるから嫌。

んじゃ、81にまた質問。
参照てんこもり渡しってのはもしかしてこういうの？

public int methodA(String a, String b, String c, String d, int e,
int f, int g, （２０個くらい中略） double z) {
}

>163
再発明大好き人間よりはデザパタ勉強する意欲のある人間の方が使える。

>>165
再発明っつーかさ、81がやってる事ってのは

車輪が発明されもう皆がそれを利用している状況で
「おい、車輪信者ども、俺は車輪を越えるものを発見したぞ。
　自分の足で歩けば車輪はいらない！ どうだ、スゴイだろ！」

って感じだろ。

>>163
どーでもいいから発展性のあるとこみせろよ。
たとえばデザパタの問題点を示してからそれを上回る解決策を示せ。

>>81よ。すなおに「ボクは他人の意見は聞きません。自分だけが正しいのです。」って言ったら(w

配列型オブジェクト指向だと、文字や文字列はどう書くの？

「文字と文字列は同じ書き方で書けます。」とか言って逃げそう。
具体的なコード書いてね。>>81

>>170
python?

少なくても俺は81の言ってる事を理解できていない。
他の奴は言ってる事が理解できてるのか？

まず、81の意見をまとめないかい？
あるいは81は、自分の意見をしっかりとまとめて主張するべきだと思う。
その際、参照てんこもり渡しと言った用語は控えてもらいたい。

81はコミュニケーション能力がだいぶ低い人間と言う印象を受けている。

81はすでに逃げました。

>>164
そんなものだけど、渡すのは自分で作ったクラスの参照。

81の作った関数の中で
一番引数が多かったものって
何個くらいあるの？

俺は最高35個だけど。
これくらいならたいしたことない。

>>175
イヤだぞ。そんなに多いの。
普通なら構造体か、クラスにすると思うが。

俺がまとめていい？

１，クラスを使うと、内部変数が隠蔽されてしまうので不便だ。
２，クラスを使うと、関数にパラメータを渡すときに呼び出す側の変数を
　　片っ端からパラメーターに渡さないといけないから不便だ。
３，継承すると一つの機能が複数のソースをまたがるので
　　わかりづらくて不便だ。
４，沢山クラスがあるととにかく訳がわからなくて不便だ。

よって、結論。
ソースコードは一つにまとめ、配列とそのインデックスを
駆使すれば良い。
さらに何でもかんでも配列にすれば要素数１でも１０００でも
同じに扱えて幸せ。

間違ってるなら言ってくれ、81よ。

アンチOOは81を養護しないのか？

デザパタは結果論。デザパタ厨は評論家と同じ。
出来あがった後で人のものに「すでにデザパタにある」などとのたもう。
んでもって自分では決して生み出さない。
文明の廃退期に生まれる一連の後退的な思想の一つ。

宇宙方程式が「全てを説明できるがなにも予言できない」と言われていたのを
思い出す。

81の作った関数の中で
一番引数が多かったものって
何個くらいあるの？

俺は最高35個だけど。
これくらいならたいしたことない。

>>177
その結論は皮肉だろ。酷いなｗ

81ってホントコミュニケーション能力無いな。
明らかにヒッキーだよな。

今まで２ｃｈにいたヒッキーの中でも群を抜いてるよ、こいつ・・・

もっと積極的に意見を言えよな。
そんなに批判されるのが恐いのか？
震えながらキーボード打つくらいなら２ｃｈに来るなよ。

配列型ＯＯがクラス型より優れているなどとは言っていません
縦に切ったか横に切ったかの違いだけだと言っています。

81の作った関数の中で
一番引数が多かったものって
何個くらいあるの？

もしかしてコードを書いたことないの？

配列型というから抵抗があるのかな？
並列型オブジェクト指向と命名してあげよう。

じゃあ、超クラスとか言ってたのはなんなんだよ。
違いが無いって事はメリットが無いって事か？

>>175
10個くらい

並列型オブジェクト指向と命名してあげよう。
こいつ頭悪すぎる。

>>186
どんな関数？

182
デザパタは結果論って切り捨てる根拠は何？
立てか横かだけ？
Gof読んだ？コード書いた？

引数10個ってけっこう複雑な関数だな

>>189
まあまあ､ﾏﾀｰﾘ行きましょう

>>178
どーでもいいから自分で新しいものを生み出せって。
ただし「新しいもの」だぞ。

>10個くらい
どういう関数だよ。
本当に作ったのか？

int max(int a,int b,int c,int d....){
略
}

アホ決定だな

>>194
引数の中から最大のものを取得する関数か？
俺だったら引数を配列、もしくはコレクション等にするか
配列、コレクションにgetmaxメソッドを持たせるが
君の方法だとどうなるのかね。

>>194
ﾜﾗﾀ

81は引きこもり暦何年目ですか？

81は逃走か。
オブジェクト指向のメリットは情報隠蔽とポリモーフィズムなのに、
その両方が分かってない奴ははじめてみた。

>>196
Smalltalkなら
aCollection
　　inject: (aCollection detect: [ :x | true] ifNone: [nil])
　　into: [ :x :y | x max: y]
ってとこだな。

引数を沢山作るとスタック操作のオーバーヘッドが馬鹿にならない。
一回アセンブラ出力でも見ろ＞81

>>201
配列の添字渡したってオブジェクト渡したって
引数の個数は同じだろ？

単数と集合を区別しない言語か。
LISP でいいような気がする。

そろそろ81は利点を「それは欠点なんです〜。(理由は無し)」とか言いそう。
今ごろ自分と普通の人との差を埋めようと必死になって調べていることだろうよ。

81降臨しないかな
厨房晒し祭りは楽しい

10個の引数の関数を聞き出せなかったのが悔しい。
193-195およびその他の誘導レスは全部漏れ
誘導下手かな？

あんまり関係ないけど引数10個のメソッドよく使ってます。
public abstract boolean drawImage( Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, ImageObserver observer)
dx1 〜 sy2 をオブジェクトにしちゃうとパフォーマンスがかなり犠牲になってしまうので、
引数になっちゃうのもしょうがないと思う。

それはそうと>>81の考え方をどんどん進めていくと結果的に
アセンブラとかマシンコードで直接書けってことになってしまいそうな気がする。

>>206
引数をスタックに積むのにかなり大きなコストがかかるから、
構造体にまとめてポインタか参照でちょびっとだけスタックに積む方がいいよ。

>>207
スタックに積むのにかかるコストは、
構造体をスタックにつくってそこに値を入れる
コストと同じくらいでしかないと思います。

それにCだとスタックに構造体つくれるからまだOKだけど、
Javaだとそうはいかないのです。

>>208
呼び出しが1回なら同じだろうな。
100 回呼び出したら値のコピーが 1000 回発生するだろう。

public abstract boolean drawImage( Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, ImageObserver observer)
　　　　　　　　　　　　　　　　　　　　　　　↑

ぶぅ。

構造体の中身を使いまわすことが多い用途だと、
構造体使うことでコピー減らせるかもしれませんねぇ。

私は>>207の「かなり大きなコストかかる」ってのを訂正したかっただけで
1000回の整数のコピーにかかるコストを気にしないといけないような環境は
あんまり考えてませんでした。

ポリモーフィズムってさ。
概念だけの説明じゃぁ、よくわかんないよね。。。
と言ってコードを見ても頭悪いからわかんないのよね。。。
情報隠蔽はよくわかるんだけどなぁ。誰かﾀﾁｭｹﾃ

俺の肛門も洗浄は必要ありません。

あと、デザパタってさ。
結果論じゃなくて、経験論じゃぁないの？
いや、さわりしか知らんのやけどね。頭悪いから・・・。

>>214
知らんとかくのなら、書き込み自体をするな

抽象動物クラスを継承した具象犬クラスはワンと鳴き、
猫クラスはニャ−と鳴くのがポリモ−らしいです。

>>216
ぶっはっはっははははははは！

public abstract boolean drawImage( Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, ImageObserver observer)
まぁ、この関数だけ書かれても
設計が悪いんじゃないかと疑うくらいしかできないからな・・・

>dx1 〜 sy2 をオブジェクトにしちゃうとパフォーマンスがかなり犠牲になってしまうので
>1000回の整数のコピーにかかるコストを気にしないといけないような環境は
なんだか微妙な環境でやってますな。
ちなみにオブジェクトプーリングは知ってるよね？

>>218
オブジェクトプーリングを使うのを事実上強要するくらいなら
引数10個の方がシンプルでマシな場合も多々あるので、
引数10個ってだけでバカにするのもどうかと思って。

>>219
オブジェクトプーリングは､ほぼシームレスに組み込めるだろ？

関連のある変数自体はセットにしておくほうがいいと思う。
上のx,yをペアにするだけでも6個になる。

なぜ引数が多いのはいけないのかと言うと、
バグを作りやすいから。
変数を局所化するメリットが分かるなら、
直感的には正しいと思える気がするんだが。

もちろん引数10個をとらなきゃならないケースが
0だとは言い切れない。
ただ、まともにOOをやっている人間からすれば
普通は設計を疑ってかかるだろう。

とりあえず、
その関数がどういうクラスのメソッドで、
Image img
ImageObserver observer
はどういうクラスなんだ？
面倒だった無視してくれて構わない。

オブジェクトプーリングって何ですか？

>>220
http://java.sun.com/j2se/1.4/docs/api/java/awt/Graphics.html

ああ、ほんとだ。
あるんだな。

ただ、JAVA2Dはまだあまり使われてないから、
洗練されたクラスライブラリーというわけでもないと思う。

あるいはこれは､ネイティブファンクションに近いもので、
使う場合はこれをラップして使うんじゃないのか？

>>223
＞ただ、JAVA2Dはまだあまり使われてないから、
＞洗練されたクラスライブラリーというわけでもないと思う。

あぁ、Java2Dじゃないか。
ごめんよ。
指摘の仕方が陰湿だね（ｗ

>>225
＞ただ、Java2Dはまだあまり使われてないから、
＞洗練されたクラスライブラリーというわけでもないと思う。

陰湿勝負ですか？ｗ

オブジェクトプーリングって生成キャッシュのことですか？

友達いないんだろうな・・・
ｶﾜｲｿ

ｵｲｵｲ、awt知らんってもしかしてjavaは殆ど知らないんでないかい？

>>228
全然関係ないがこのスレ見た後だから気になった。
http://pc.2ch.net/test/read.cgi/prog/1021738082/l50

× オブジェクトプーリング
○ オブジェクトプーリン

>>230
グラフィックはほとんど使わないんだよ。
データマイニングが専門なんで。

>>231
プールという単語の動名詞です。
プーリンの方が発音は良さげですが、
キャメラと言っているようなもんですな。

プーリン・・・プリンが食べたくなった。

>>232
× データマイニング
○ データマイニン

ｺﾞﾒﾝ もうやめる。

>>231
うん。231はそのままぷーりん、ぷーりんと呼びつづけるといいと思う。
俺は断固としてプーリングと呼ぶが。

>>232
そうか、ﾜﾘｨ。DevかProの試験受けるならグラフィック必須なんどすよ。それでちょとね。

>× オブジェクトプーリング
>○ オブジェクトプーリン
ｱﾌｫｰ
ｱﾌｫｰ
ｱﾌｫｰ

>プーリン・・・プリンが食べたくなった。
ｻﾑｰ
ｻﾑｰ
ｻﾑｰ

>>231
...ngの音は鼻濁音だ。「ング」ではないが「ン」とはもっと遠い。
関東方言のガ行の発音をする人なら「ング」と書いた方が近い。

「プーリンク゜」と書くことを提案する。

くだらねーネタばっかり

>>238
糞スレに何を期待してんだ。

>>239
せめてsage進行でやってほしいね

-------------------------->239<-------------------------------

厨房質問でごめんね。
プログラマーの人って、実際どんな仕事やってるの？
ゲームとかソフトの会社とか？
あとどんな仕事があるの？

>>242
許さん。
プログラミング。
そんな感じ。
プログラミング。

学生ですが。

>>242
プログラム書いてます。
仕様書もたまに書きます。
でもほとんど遊んでます。

納期は守ります。
デスマーチもたまにあります。
でもほとんど遊んでます。

不良社員でごめんね。

許さん。

毎日ネット見て遊んでいます。

>>219
Rectangleとまではいかなくとも、せめてPointぐらいは使ったほうがいいと思われ。

微妙だなあ。
drawString(str,x,y)とかでも
Pointにしたほうがいい?

>>249
うん。微妙だよね。

もしクライアント側がその座標点を計算したり保持したりするのにPointを使ってたり
ライブラリ側がdrawString内で結局ベクトル計算してたりしたら
drawString(str, x, y)のほうが無駄が多いよね。

また、仮に現在はdrawString(str, x, y)が全部自前でラスター描画していたとしても
後々、ハードウェアアクセラレーションを利用する外部ライブラリ等の外部ライブラリを
利用して描画する可能性があるのなら、drawString(str, point)にしておいたほうが無難かも。
drawString(str, x, y) -> _drawString(str, point)だと確実に短寿命なオブジェクトを生成/消滅
させなきゃいけないからね。

81、帰ってこーい。
久々に楽しい奴だったのに。

>>250
まあ､今回の関数の場合は
システムコールのようなもんだから、仕方無いんじゃないかな？

>>12
とりあえずロリはやめとけロリは

　　　　　　　　　　　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　（ ´Д｀ ）＜　レベルの低い議論してんじゃねぇよ！！
　　　　　　　　　　／,　　/　　　 ＼＿＿＿＿＿＿＿＿＿＿＿　　　　
　　　　　　　　　(ぃ９　　|
　　　　　　　 　 /　　　 /、
　　　　　　　　 /　　　∧_二つ
　　　　　　 　 /　　　/
　　　　　　　 /　　　 ＼
現場で活用できるかどうかの議論じゃねぇのか？

>>254
スレタイはあくまで>>1が熱望してやまなかった議題。
他人がスレの流れまで管理してやる必要は無いと思われ。

つか、このスレの趣旨は、その３の>>1であると思われ

　　　　　　　　　　　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　（ ´Д｀ ）＜　どんな理由であれ､読んでてつまらねぇんだよ！！
　　　　　　　　　　／,　　/　　　 ＼＿＿＿＿＿＿＿＿＿＿＿　　　　
　　　　　　　　　(ぃ９　　|
　　　　　　　 　 /　　　 /、
　　　　　　　　 /　　　∧_二つ
　　　　　　 　 /　　　/
　　　　　　　 /　　　 ＼

質問スレよりは面白いと思うがなぁ・・・

俺の会社にも居るよ、オブジェクト指向だのデザインパターンだのの用語を
会話にちりばめるのが好きな奴が。

そいつが「フレームワーク」とやらを作って社内で標準化しようとしてるんだけど
ソース見てビックリ。
まず、入出力メソッドが無い。ファイルの読み書きのメソッドが無く、
ファイルを読み書きする度にInputStream()〜open()〜だのをいちいち並べてる。
オマエ、サブルーチンってなんだか知らないの？って感じ。

かと思えば、文字列と文字列を連結するメソッドとかがあったりする。
Javaなんだが、そんなメソッド使いたいか？　「+」１発で済む話だぞ？

クラスは有るけど何のオブジェクトを実現したいのか判らない、適当に
サブルーチン集めただけのクラスだったり、コードはJavaのライブラリを
どこまでもどこまでもベターっと並べてるだけだったり、そりゃあ酷いもんでした。

オブジェクト指向どころか、構造化にも構造化以前の水準にも達していない。
BASICから勉強しなおせって感じ？

ﾑﾑｯ!約２週間ぶりのレス？

へたれでも
オブジェクトで
十分幸せになれるよね！
今日も、オブジェクトに仕事を頼むべし！

>>259
「あんちでざいんぱたーん」を読ますべし！
技評より７月にでるが、すでに一部書店ででてる。

まあ　構造化もオブジェクト指向も　明文化出来ない体得するしか
ない部分もあって、ホントに身につくにはそれなりの時間がかかる。

その明文化された部分と体得するしかない部分のどちらがプログラミングに
役立つかというと、当然体得するしかない部分な訳で、それは
その明文化された部分＝テクニカルタームを手がかりに体得するし
かない。逆に体得してしまえばテクニカルタームは捨てても構わないと思う。

だから、逆にテクニカルタームを連発してる間はまだまだって事になって
しまうんだろうね。

>>262
最近実は最も難しいと思ってるのがパターンの習得よりも
クラスやメソッドの命名だったりして（ｗ

>>263
　そうだね　俺はもう諦めて外部に公開しないメソッドや関数名は func1とかproc3とか
　思いっきり手抜き。　その方が公開してないってわかって逆にいいやって思ってる。

が、つい2CHでそういうコードを晒すと・・・・

>>263
確かにその通り。
メソッドの動作を簡潔に表す、名前を付けるのに悩むこと悩むこと。
ドラクエの名前付けで、1時間ぐらい掛ける私にはきついです。
あ、だからリファクタリングツールがいるんだね。

つまり、日本語プログラミング最強という事でよろしいですか？

>>266
YEAAAAAAAAAAAAAAAAAAA

>>266-277 (・∀・)同人物?

ﾐｽｯﾀ。>>266-267ね

日本語でも名前付けは結局迷う罠。
まあ製造・販売・在庫システムをseihanzaiとかにしなくてすむけど。

低レベルなネタでスマソ。
ポリモーフィズムがわからん奴に簡単に教えるにはどうしたらよかんべ？

>>271
プラグイン作成の実習

ポリモルフィズムでしょ！

ポリモーフィズムに一票
polymorphism

ど〜でもいいに一票

オーバーロードって継承したオブジェクトのメンバを
上書きするってこったよね？

google結果
ポリモルフィズム 522件
ポリモーフィズム 781件
そんなに変わらんが普及してるポリモーフィズムにしとけ。

おｂじぇｋとは戦場では必要ありまちぇん！

ポリモルフィズムﾀﾞｻｯｯ

>>276
あほか。オーバーロードってのはな。
継承した仮想メンバを実体化するってことだ。
virtualでも検索しとけ

>>280
あほ。
http://yougo.ascii24.com/gh/23/002318.html

オーバーロード≠オーバーライド

>>276
それはオーバーライド。
にしてもC#はjavaと違ってoverride明治せないかんからウザイ。
あとクラスメソッドの大文字がウザイ。stringの小文字もウザイ

>>280
実体化ですか?

>>283
overrideはいいよ。ミスを防げるし。
C#は俺が前からほしかった機能を実装してくれたから嬉しい。

あ・・・・・・・・・あの〜・・・・・・・・・・・・で、どうしたらいいのでしょ・・・・・

>>224
　無理でしょ。
　あっちは自分らの監督権限や命令権限増やしいだけで作ってるんだから、
　そういうの希望なら、選挙くらい行かなくちゃね

誤爆ゴメン
polymorphism を教えたいって話だけど、
Cが判るレベルならファイル入出力あたりから説明したら？

fprintfは、ファイル以外にも画面にも、シリアル通信も同じ
関数名で操作出来る。この場合 fprintfの最初の引数で
オブジェクトを指定してると見立てて貰ってさ

>271
実際にサンプルプログラムを見せ、コーディングさせる。
見るだけじゃだめよ。自分でキーを叩かなきゃ。
とっかかりくらいにはなるでしょ。

>>288
いや・・・ＶＢしかわからんのが対象なだけに、とてつもなくチビシイモンが・・・（わら

Javaならどうにかなるんじゃないか。

と思いたい（ｗ

>>291
Java ばっか OOP 関連の書籍が充実しているというのもいかがなものか？
間違っても VB や Delphi でパターンの書籍はみないぞ！
といっても　VB で パターンはきついのか。
あ、今は .NET になったから対応できるのか？

>>292　JAVAがある程度フリーで OOPとしてそれなりだった事がアカデミックな世界で評価されたんでしょうね

VBやDelphiだとどうしても特定の企業色が強くて難しいのでしょう。

クラス作ってみんな幸せ

ちゃんと理解できている一握りの人の存在も理解したうえで行動すべし。

>>292
http://labsoftware.com/vbpatterns/vbPatterns.htm

勤め先のフレームワーク、Javaだけど極端にCOBOL的に
記述することを要求してくる。
身元ばれると困るんで詳しく書けないけど、
過去十数年のプログラム技術の進歩を片っ端から
否定するような内容だったよ。
新しい技術についていけない年寄りをフォローするのが目的で、
実際その目的は果たしているし、そういう意味では
正しいフレームワークだと思うんだが、

俺はあんな仕事大嫌いだ。

契約切れたらとっとと辞めてやる。

オブジェクト指向は時代遅れ。
エージェント指向。これ。

>>298
説明してみい

オブジェクト指向は時代遅れ。
コンポーネント指向。これ。

アンチ OO は心底憎らしかったけど
彼らが居なくなると寂しいスレだなや。

反論がなかったので>>1の通りとする。
おれ様の偉大さがわかったか、オブジェクト指向信者どもめ。
しねしねしねしねしねしねしねしねしねしねしねしねしねしねしね。

>>302
まぁ下品な方ね・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・（ぷ

オブジェクト指向が理解しやすい？
頭おかしいんじゃない？
オブジェクト指向が自然な考え方？
頭おかしいんじゃない？

多重継承はすんな

>>304
オブジェクト指向が理解しにくい？
頭壊れてるんじゃない？
オブジェクト指向が不自然な考え方？
頭壊れてるんじゃない？

（ｗ

>>304
時代についてこれない人はさっさと氏んでください。

戦争再開です！
とりあえずアンチは腐った感情論と懐古主義を抜きにした理論的な反論をお願いします。

1はオブジェクト指向に敗れた敗残兵ですか？

>>308　とりあえず　308さんの自作自演でない事を証明して下さい。

　あまりにも低レベルな煽りが続きすぎています

オブジェクト指向マンセーの前にsynchronizedでブロックする
とかいう馬鹿を退治すべき。

くどいなこの馬鹿

じゃあさ、これから長いことプログラムでご飯食べたい人はOOP極めて、
いろんな意味で別にそうでもない、って人はやらなくていいんじゃない？
ｱﾌｫっていわれてもいいじゃん！

OOPでやろうとしているのを邪魔しなければな。

できないやつができるやつの足を引っ張る。
足を引っ張るｱﾌｫは氏んでください。

>>314　足を引っ張られる程度ってことで我慢しろよ。　同じ労働者だろ

>>311
意味ワカラン。関係ねーだろ。

>>315はコボラー

>>315
> 同じ労働者だろ
同じ労働者じゃねーよ。ｱﾌｫと一緒にすんな。

>>318
　労働者じゃないんなら何？　書いたコードの著作権は自分の物な人？

>>319
技術力がある労働者とｱﾌｫ労働者。

>>320　労働に貴賎なしだよ。　妙なプライドは自分にも回りにも迷惑

>>321
> 労働に貴賎なしだよ。
誰の言葉？ 言葉を変えて自分の都合のいいように解釈してない？

>>322 そりゃそうさ　そもそも引用というのはそういうもの

で言いたい事は、技術力がある労働者も　ない労働者もいる
のは当然だ。しかし、その差は報酬の差で具体的に埋められ
てるのだから、それ以上妙なプライドを持ち出すなよって事さ

労働に貴賎は無い
あるのは評価だけだ

OOPかどうか、はどうでもよし。

職業に貴賎なし。
職業の違いで恥じることは無い。
向上心をもって今の仕事をがんばれ。
今時OOPやらないのは向上心が無い。
妙なプライドはもたんでOOPぐらいやれ。

ＯＯＰブームで儲けた奴はもう逃げちゃったというのに
お前ら哀れだな(;´Д｀)

>>327
ということにしたいのですね。

オブジェクト指向っていってもさ。
メンバ関数内で構造化プログラミングしてるじゃん。
だめじゃん

>>329
オブジェクト指向は構造化プログラミングが含まれているだけですが？
オブジェクト指向と構造化プログラミングは排他ではありませんよ。

混ぜるな。バカ

>>331
くやしかったんですね。

>>330
ｵｲｵｲ

>>333
ｵｲｵｲ

finallyはアンチ構造化ですがなにか？

>>329
Smalltalkでは構造化のための制御構造などはなく、あるのはメッセージ式だけですが、何か？

構造化を含むとか言ってる奴。
まじでオブジェクト指向をわかって言ってる？

>>336 じゃ ifTrue とか whileFalse　ってのはあれは何？

オブジェクト指向を一言で表すと、クラスとか継承とかでてくると思うけど
構造化プログラミングって一言で言うと順次、選択、繰り返し？
オブジェクト指向でも(特にメソッド内では)当然使うと思うけど。

>>339
構造化プログラミング自体わかってないやつﾊｹｰﾝ

>>340
説明求む

構造化プログラミング

ダイクストラが提唱したプログラミング技法
　　命令の流れは順次、分岐、繰り返しの３つで全て表現出来るという原理
　　を証明し、gotoを出来るだけ使わないプログラムを推奨した。


構造化設計　手続き型プログラミングのモジュール設計手法

>>339は>>342と矛盾しないような。

>>339
＞、クラスとか継承とかでてくると思うけど
どの辺が「一言」？

ねーおまえらよ

小論文書いてみてよ
「オブジェクト指向のメリットについて」
４００字程度

オブジェクト指向において重要な点は２つ。
カプセル化、継承
カプセルを継承するという抽象的なことを
可能にしてくれるのだ。
オブジェクト指向において
カプセルに頼む頼まれる。これは凄い機能だ。
意味不明だろうが、これが最大の利点なのだ。
ましてや構造化プログラミングにおけるスパゲティプログラムにおいて
ソースのメンテナンスは非常に困難を極めた。
しかし、オブジェクト指向によって構造化プログラミングを排除し、
継承によるスパゲティを作ることができる。
継承とはスパゲティなバグありプログラムでも
ユーザーから見れば大変うまく食すことができる。
グルメな人にはたまらないオブジェクト指向の機能の一部だ。
そこにソースを加えて作るプログラムはまさに阿鼻叫喚。

>>345
論文ではないが・・・幾つか上げてやろう

１．複雑にネストした条件分岐を、劇的に少なくすることができる。

２．複雑かつ肥大化した関数をスリムにし、可読性＝保守性が増す。

３．データ自体にメソッドを持たせることにより、ソフトウェア部品の独立性が増す。

４．変更に際して、修正部分が構造化型と比較し極端に少なくできる。

５．仕様変更等に対し、極度に柔軟性が増す。

６．リファクタリング等の導入により 「実装しながらの設計」 が可能になる。

＞劇的に少なくすることができる
＞極端に少なくできる
＞極度に柔軟性が増す。

>>348
オブジェクト指向の恩恵を最大限に引き出すには、「リファクタリング」のテクニックが必要になるが。

>>346
スパゲッティーな論文だ
たのむから提出レベルですれてくれ

　　　 ／。　　　　　＼
　 　/　0　　　　　　　|
　　/　　　 　 ―　― |
　　|.　 　 　 　-　　- |
　　| (6　　　　　　>　|
　　｜ 　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣
　　 | 　　　　┃─┃|　 ＜　ｻｯﾊﾟﾘわからん
　　 | 　＼　 ┃　 ┃/　 　＼＿＿＿＿＿＿＿＿
　　 |　　　　￣　￣|

>>347
2.4.7はわかるが、他はわからん

>>348
ﾚｽはありがたいが、少ないって
ノー味噌少なすぎませんか？

>>350
7が分かるのか。

＞劇的に
＞極端に
＞極度に

　　　 ／∵∴∵∴＼
　　 /∵∴∵∴∵∴＼
　　/∵∴∴,（･）（･）∴|
　　|∵∵／　　 ○　＼|
　　|∵ /　　三　|　三　|　　／￣￣￣￣￣
　　|∵ |　　　＿_|＿_ 　|　＜　うるせー馬鹿！>>351
　　 ＼|　　　＼＿/　／　　＼＿＿＿＿＿
　　　 　＼＿＿＿_／

　　　　　　　　　　　　　／∴∵∴∵＼
　　　　r､　　　　　　 ／∴∵∴∵∴∵ヽ
　　　　＼＼.　　　　 |／　　　＼＼∴∵ヽ
　　　　 　＼＼ .　　｜ (･)　　(･)　　ヽ∵｜　つべこべ言わずに
　　　　　(　(￣＼.　｜　　⊂　　　　　　 ∂)　小論文書いてくれよ
　　　　　(ヽ￣/　|　｜　　＿＿＿　　　 ｜　　　理系だからかけませんってのはなしネ
　　　　　(ヽ　（ 　|　　＼　　＼＿/　　 ／
　　　　　（ゝ　　　|　　　 ＼＿＿＿__／
　　　　　　￣|　　|　　　　　|　　　／＼＿＿＿
　　　　　　　 |　　|　 ＿＿/＼／　　／　　　　＼
　　　　　　　 |　　|　/.............................................
　　　　　　　 |　　|/　;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;卍;;;;;;;;

>>350
１．良くある手だが、ポリモーフィズムを使って条件により生成するオブジェクトを変えてやる。

例えば

if (条件１) {
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　if (条件2) {
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　}
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

} else {

　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　if (条件2) {
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　}
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
}

とかってコードを、

if (条件) {
　　・・・・・・・・・・・・・・・・・・・・・・・・・・・
} else ｛
　　・・・・・・・・・・・・・・・・・・・・・・・・・・・
}

に縮めることが出来たらどうよ？
ポリモーフィズムを巧く使えばこういうコーディングが可能になる。

>>354
まずお前が書けば

関数ポインタ。

オブジェクト指向には、これこれこのような特徴があり、
こうこうこうである。はたして、これこれの特徴には
メリットがあるか考えてみたいと思う。
　確かに、これこれこうだ。
例えば、これこれこうゆうことをするには、このような
メリットがあった。しかし、これこれこーいう理由で
このような不具合がある。
　これこれこえ、、、、、本命、、、、、、、、
ｄｆｓｋｆｊｄｓｌｆｊｌｄｓｊｆｌｓｄｊｆｄｓｊｆｌ
ｆｓｋｄｆｊｌｓｄｊｆｌｓｄｊｆｊｓｄｆｊｓｄｊｆｌ
　したがって、ｓｆｋｓｄｋｌｆｊｓｄｌｋｆｓｄｊｆｓ
ｄｌｋｆｊｓｄｌｆｊｓｄｆｌｓｄｆｊｌである。

ここに埋め込んでくれ
たのむ！

>>350
５．は、機能を追加していくと段々コードが複雑化していく傾向がある。
しかし、随時リファクタリングを行なう事によって、
逆に時間がたつにつれ、徐々にコードの可読性が増し
「果たして、この部分ってなにやってたんだっけ？」と
悩むことが少なくなり、変更に俄然強くなる。

漏れ的結論・・・「オブジェクト指向」だけでも問題がある。
「リファクタリング」の導入により、はじめて「オブジェクト指向」のポテンシャルが活かされるようになる。

>>355
俺はVCとJAVAしかつかったことがない
それも、少しだ。
今の俺の解釈では、条件でオブジェクトをセレクトして
いるから、どうなんだ？意味を汲み取ることができませ
ん、申し訳ないが。

>>359
なるほど
納得しますた
「りふぁくたりんぐ」は、きーたことがりませんですた

1. カプセル化によって、仕様変更の影響範囲を小さくすることができる(保守性の向上)。
2. 実装の継承によって、性質が異なる部分だけを作る差分プログラミングが実現する(作業量の削減)。
3. 多態性によって、インターフェイスと実装を分離し、性質が部分的に異なるデータ群に対する
場合分けを実際の利用部分から削減できる(複雑性の削減)。

　ただし最近は、カプセル化のメリットを失う側面があるため、実装の継承は避けて他のオブジェクトに移譲することで
差分プログラミングを実現するようになってきた。

リファクタリングとデザパタも外せないが、サッカー見るのに忙しいので省略

>>362

本嫁厨房でスマソ

「リファクタリング」
http://www.pearsoned.co.jp/washo/object/wa_obj25-j.html

>>357
それはC++ではないですか？
Cでも最近はできたかな

>>361

解説がめんどいんで・・・ >>364 の 237ページ「条件記述の単純化」 以降を読んでっちょ！

どうでもいいが、実戦では能書きよりそいつのコードを見るまで
信用してはいけません。

>>364　Delphi での事例もあるよ。
http://asyrinx.fc2web.com/samples/index.htm

構造体に関数ポインタ

>>369
Cで実現するオブジェクト指向の実装手段だね。

５．仕様変更等に対し、極度に柔軟性が増す。

ほんとか？これ

>>361
Java が解るなら一言。
Java の interface は何の為にあるか小一時間考えてみて！

>>372
とりあえず
Javaの継承とInterfaceの違いでなやんでますが何か

VC　これわかりやすい

「 RX-2001 」がパワーアップした、
「 RX-2000�V 」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA

店頭販売価格は、13900 円なんですが、
今回だけ、破格の 7100 円に設定して
おります。

ヤフー ID の無い方は、当社オンライン
ショップで、御購入下さい↓
http://www.h4.dion.ne.jp/~gekiyasu/

>>373
実装のし忘れがない→実装し忘れたりスペルミスがあるとコンパイルは通らない

>>372
interfaceは、あるオブジェクト他のオブジェクトと協調するにあたって、
相手のオブジェクトに要求する性質を定義したもの。
クラスとせずinterfaceとすることで、クラス階層相互依存の呪縛から開放され、再利用性が増す。

C++でも純粋仮想関数だけからなるクラス定義で同じ目的が達成できる。

C++では
#define interface struct
とすると吉（特にVC++）

>>376

いまどき再利用性なんて言ってるよこの人（ｗ
実戦に出たこと無いのがバレバレ。

>>378
おまえ再利用性の意味わかってるか？
再利用性の事を考えずにプログラムしてるなら、
相当レベルの低い対象をプログラムしてるとしか思えないな。

同じアルゴリズムを2度コーディングする事ほど
馬鹿げてる事はない。

アルゴリズムが複雑になればなるほど､そう思う。

と、NNによる評価関数を作り直して、再認識した。

>>375
それ最強

>>376
>C++でも純粋仮想関数だけからなるクラス定義で同じ目的が達成できる。
仮想関数は、オーバーライドするのが目的のはず
ってことは、Interface＝仮想関数

つまり、Interfaceではオーバーライドするということでよろしいですか？

>>377
うーん、考えてみる

>>378
やはり、学者のいうことには反対ですか？

>>379
頭悪そうな煽りにいちいちレスすな

>>380
>つまり、Interfaceではオーバーライドするということでよろしいですか？
そう。C++では、interfaceとしてのクラスを多重継承の親とし、実装することで要求を満たす。

>>379

interfaceの話しててなんでアルゴリズムの再利用の話になるんだｺﾞﾙｧ!!
おまえほんとにオブジェクト指向における再利用って意味解ってんの？
つーかね、おまえらYAGNIって知ってますか？

>>383
汎用性、再利用性はXPの敵でんな(笑) >「YAGNI=どうせ使わん」
しかしライブラリ書きには必要…。

>>383
delegateの無いJavaじゃアルゴリズムの再利用にはinterfaceが必要でしょ

>>385

コピペ
これ最強

>>338
本気で聞いてる？
ネタだよね？？

個人の能力の差もあるし、オブジェクト指向が使えないのは
仕方ない事だと思うんだが、だからってオブジェクト指向を
敵対視するアホは消えて欲しい。
運転免許持ってないからって車を憎むようなもんだ。

>>388
そこまで基本的な技術か、というのが問題になると思う。
クラスベースのオブジェクト指向と
ActiveX や Delphi、 JavaBeans 程度のコンポーネントアーキテクチャは十分に市民権を得たが、
デザインパターンや OO 分析設計といった分野はまだまだ周知されているとは言い難い。
OO 分析設計の手法にはスタンダードが確立されていない。
デザパタや UML で外堀は埋まりつつあるが。

学術分野でもあるので OO をベースとしたあやしげな手法がやたらと発表されて
惑わされるってのも悪印象の原因なのかも。

>>388
剥げ銅age

＞OO 分析設計の手法にはスタンダードが確立されていない。

確立阻止貫徹！

＞デザパタや UML で外堀は埋まりつつあるが。

家康死すべし！

このスレはさぁネタスレなんだから、そっとしておいてやろうよ。
職場で居心地の悪い先輩たちに、ＯＯ否定という安息の場を与えてあげないとさ・・・

アンチの意見をまとめると「俺が理解できないものは糞」ということだね。

>>338
> >>336 じゃ ifTrue とか whileFalse　ってのはあれは何？

ifTrue:やwhileFalse:はメッセージセレクタですが何か？
つまり、それらもメッセージ式にすぎない。

０から１００までの数に対して条件分岐する場合等は
BASICのON n GOSUB文かCの関数ポインタジャンプテーブルの方が読みやすい。
「RUBYの実装に疑問あり」スレでもでてたね。

ifTrue:やwhileFalse:が　ダイクストラの
　「どんなプログラムの流れも順次、選択、反復の３つ（３大制御構造）で構成されている」
　という　反復や　選択　では無いですか？　と聞かれて

それはメッセージ式ですという答えは

　あなたは男性ですか？　と聞かれて　いえ学生ですと答えるようなもの

オブジェクト指向は確かに便利だな。
でもここにきてる奴はタダ単に
クラス作って喜んでるやつばかりだろ？ﾂﾏﾝﾈ

>>385

間違いとは言い切れないが、そういう風に視点を固定してしまうと、「特定のアル
ゴリズムに縛られずに済む」というinterfaceのメリットが見えなくなる。
単にアルゴリズムを使いまわすだけならconcreteなクラスで十分なわけだしな。

>>396
＞あなたは男性ですか？　と聞かれて　いえ学生ですと答えるようなもの
知らないからって、的外れなたとえ話はやめとけ。

Smalltalkではポリモーフィズムと末尾再帰が選択と反復の代わりにはなるが、
概念として別のものだから、選択、反復は無い。

ダイクストラだって、条件分岐を選択と反復の２つに区別しているだろ。

で？理論的反論はまだですか？＞アンチ

どれがプロの理論？

あれ？　案外誰もツッコミ入れないね

＞概念として別のものだから、選択、反復は無い。
俺も昨日レスしかけたけど止めたんだけど、このネタなら
夜の間に100レスくらい行くと思ってたんだけどなあ >>399

＞ダイクストラだって、条件分岐を選択と反復の２つに区別しているだろ
ってあたりが巧くネタ仕込んだみたいで、如何にもがミエミエ
やっぱりシラケるか

　とりあえず煽っておこう　本気ならバカ？

>>402
>夜の間に100レスくらい行くと思ってたんだけどなあ

( ﾟДﾟ)　ﾎﾟｶｰﾝ

＞「どんなプログラムの流れも順次、選択、反復の３つ（３大制御構造）で構成されている」
というのは　どんなプログラムでもこう分類出来るという定義だから、プログラム言語にこの
３つの構造が表現出来ないというような事はもちろんありえない。

　たとえば、C言語からgotoとif文を取り去っても、３項演算子で選択が出来る
　あるいは、条件型というクラスを作って、そのメソッドで関数ポインタを渡すと
　その関数を評価するかどうかという言語を作ったって　それは選択に分類される

＞ダイクストラだって、条件分岐を選択と反復の２つに区別しているだろ。
　これはリンゴ１個とアメ1個を足して２個と数えるようなもの
　条件分岐・・・・・・・・・・言語の機能
　順次・選択・反復・・・・プログラムの構造

オブジェクト指向バカの一種にこの手の単位の別や、概念の別がついてない奴がいる
概念を混同する事はオブジェクト指向の土台を壊してしまう行為なのに、
それでいてオブジェクト指向マンセーなんだから手に負えない

>>404

>>403は説明を要求したわけじゃないと思うが？

>>404
＞条件分岐・・・・・・・・・・言語の機能
＞順次・選択・反復・・・・プログラムの構造
同じ理屈で
>>399
＞ポリモーフィズムと末尾再帰
と
＞選択、反復
を分けてること、わかってる？？

なんども言うが

二周遅れのランナーが先頭を走ってると勘違いしている

それがオブジェクト指向信者

あげ忘れ

を、なんか戦場スレっぽくなってきてる。

つーことは、アンチはそのさらに２週遅れ？

>>410

いや、途中棄権したくせにまだがんばって走ってるランナーに野次飛ばしてる負け犬です。

そんなものは血を吐きながら続ける悲しいマラソンですよ。

>>412
ウルトラセブンときたか

>>412
負け惜しみの典型だな。
わかりやす過ぎてつまんないわ。

>>414
だから>>412はウルトラセブンネタだって

ネタ元知らんが、ネタだすことしか出来ないってことは反論できないってことだね。

ｿﾌﾄｳｪｱ工学ﾏﾝｾｰなやつって
結局たいしたアプリ作った事無い奴ばっかりなんだけど。
あ、大学での話ね。

一方､すごいアプリ作ってる奴はsmalltalkがどうとか抜かさず
実用的な言語で物事語るけどな。

>>417
大学時代くらいいろんなことして非効率でも良いから自分の世界観を広げておくことが大切だと思われ。

>>417
つーか研究と実務は目的が違うじゃん。

>>419
＞あ、大学での話ね。

大学の話だろ？

Smalltalkは実用的な言語だとももいます。

>>417
ソフトウェア工学マンセーじゃなくても
結局たいしたアプリ作った事無い奴ばっかりだと思うが？
あ、大学での話ね。

>>421
VC++ VB 以外は実用的ではありません。
PG は大人しく MS 製品を使いましょう。

>>421
流石にフォローしきれない。

(´-`).｡ｏＯ（アンチ厨にフォローして欲しいとは、だれも…）

オブジェクト指向がソフトウエア工学だって？
アフォですか？

>結局たいしたアプリ作った事無い奴ばっかりだと思うが？
>あ、大学での話ね。
そう言われてみればそうだな。
あー、でもアメリカの学生はすごいよ。
日本の学生はもう少しがんばった方がいいとおもうよ。
情報処理学会の雑誌かなんかに書いてあったけど、
プログラマーは大事な仕事だけど、儲からないから
優秀なプログラマーを教育する大学が日本にはないらしい。

　　　　　　◆プログラマーさん、ちょと一息ですよ。みんなで笑いましょうのコーナー◆

-----↓史上最低クズ板発見 !! (^o^)丿↓-------------------------
http://pc.2ch.net/hard/
カテゴリ;ハードウェア
★↑↓こいつら買えない糞ｶﾞｷのくせして憧れ主義で話してます。
こいつら、ﾊﾟｰﾂすら触った事すら無いのにえらそーに、
さも知ったかぶって話してます。　　可哀想すぎます。アワレで見てられません。★
▼こいつら、哀れな"カタログお眺め主義者君たち"です。▼
◎自作の自の字もした事無いお可哀想な哀れ乞食(ｺｼﾞｷ)どもです。◎
　　　笑ってやって下さい。↓ こいつら　使ってるﾏｼﾝは皆、NECPC９８ｼﾘｰｽﾞのオンボロマシンです。
⇒こいつら見栄だけで生きてます。　笑い殺してやって下さい。　あ〜　腹ｲﾃー

------該当板発見、 ↓ちっともお勉強にも屁にもならない板発見 !!↓---------

××××http://pc.2ch.net/hard/←チンカス板 or ｸｽﾞの集まり××××

　　　　　　　　　　　　↑こいつらの中にｽﾊﾟﾑやってる奴いるぜ。
なんせ、↑こいつらｷﾁｶﾞｲ集団だからな。

とうとう荒らし始めたか。
信者必死だな（藁
でも、もうすぐＯＯが廃れるのは変わらないがな。

>>429
荒らしているのはアンチとアンタですけど。

>>430
禿同！

age

ところで>>1はコボラーまたはVB厨なのか？

あれだな、オブジェクト指向は、
「それを支持すると人を見下すことが出来るから支持する」
という点で危ない宗教と同じなんだな。

そのほかはまったく関係ないけどね。

>>433

もうそろそろVBユーザー==アンチOOという図式で語るのはやめれ。

http://pc.2ch.net/tech/kako/1013/10132/1013266554.html
の頭の方なんか読んどくとよろし。

まぁ、どんな言語でも厨はOO理解してないけどね。

オブジェクト指向？ﾊｧ？
本当に「オブジェクト指向」してますか？（ｗ

>>437

そう言うからには「オブジェクト指向」の定義をハッキリさせてくれるんだろうな。
期待してるぞ！期待してるぞ！！

むしろ俺が期待してるんだけど？

>>439

「本当に」って言うからには「本当のオブジェクト指向」を知ってるんでしょ？
ageて書くぐらいだから自身満々なんでしょ？
もったいぶらずにおしえてYO!

ふっふっふ
それらしい用語を並べ立てて判ってるつもりになってただけのようだな。

くそっ雄山め。
究極のオブジェクト指向を見せてやる。

>>442
ふ・・・・・まだまだ青いな。
至高のオブジェクト指向を見せてやろう。
http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1490-1

>>436
アンチと言うかあのふざけたOOもどきを使ってOOをマスターしたと勘違いしてる奴が痛いだけかと。

443のリンク先に書いてある目次より:

> 1-2　初心者が最初にやりそうなこと〜コピー＆ペースト攻撃
>
> 1-2-1　コピー＆ペーストは簡単だけど…
> 1-2-2　コピー＆ペーストによる拡張の欠点
< 1-2-3　ソースコードの汚染は少なめに

目が覚めました!これが至高のオブジェクト指向なんですね!

>>445
> 目が覚めました!これが至高のオブジェクト指向なんですね!

ふ・・・・・まだまだ青いな。
初心者向けにわかりやすいとこから解説してるが、結局これの言ってることって煎じ詰めればデザパタを通じた Refactoring Technology の紹介だよ。
Refactoring の最も効果的な所は　『実装しながら設計』 を行なうとこにある・・・そのときデザパタが役に立つってことだね。

グローバル関数を使わないのもオブジェクト指向？

漏れはOOP派だが、グローバル関数は別にあってもいいんじゃない？

>>446
>>445は皮肉じゃねーの?

>>449
知ってて書いてるに決まってんだろ（ｗ

OOPでは、グローバル関数はクラスにするって本当？
そのクラスのオブジェクトは、関数オブジェクトっていうの？

>>451
それはJAVAやC＃だけやで。
C++ や Delphi やったら、わざわざそげんことせえへんで。

だからC++は中途半端なOOPっていうんだね。で、C#つくっちゃったと。

グローバル関数とＯＯＰは別段関係なさそうな気がするが？

え？そうなの？やっぱちゃんと調べてからもの書くか〜

わかりました。
あるスレで、疑問に思ったんですが、質問する感じじゃなかったので。
C++でプログラムする場合、OOPとしてはクラスにすべきなんですか？
グローバル関数１つに、クラスを１つ作るのですか？

しない。
namespaceにいれるだけ。

クラスにするかどうかは分析次第だが、
たとえばoperator << や operator < みたいのはいわゆるグローバル関数に
なりやすいな。

>>457
OOP的にはグローバル関数は排除するべきだろ。
C++的にはOOP的な部分と手続き的部分のトレードオフの結果
> クラスにするかどうかは分析次第だが、
> たとえばoperator << や operator < みたいのはいわゆるグローバル関数に
> なりやすいな。
という結論になるわけで。

>> OOP的にはグローバル関数は排除するべきだろ。
はぁ？

新しく OO言語を開発する場合は、全てをメソッドにした方が楽だからそうするだけだろ

>>459-460
ヴァカなのかネタなのか自己申告しる (藁

COBOLオブジェクト

COBOLごときでオブジェクト指向ずらされるとね・・・

OOCOBOLって、OOすぎないか?

>> OOすぎないか?
Ｏが多すぎないか？ってことか？（鬱）

最初から仕様がしっかり決まっているプログラムであれば、
OOのメリットはあまりないですね。

そういうネタも、もう飽きた。

>>464-465
しばらく考えた、意味が判った、不覚にも笑ってしまった

山田君〜！>>464 に座布団一枚持ってきてあげて！

　　　　　＼　　 　 　　　　∧∧　　 　ミ　＿　ドスッ 　　　.　　　　　／
　　　　　　..＼　 　 　 　 (　 　,,)┌―─┴┴─――┐　.　　.　 ／
　　　∧∧　　＼ 　 　 　/　　　つ.もうだめぽ 　 . 　.│　　　／　　
　　 /⌒ヽ)　　　＼ 　〜′　/´.└―─┬┬─――┘.　／
　　i三　∪ 　　　　＼　∪ ∪　　　　　 .││　_ε３　.／　　λ......　λ......　λ......
　○三　|　　　　　　　＼　　　　　　　　 ゛゛'゛'゛ 　　 .／
　　(/~∪　　　　　　　　 ＼ 　　　∧∧∧∧∧.　／　λ......　λ.....　λ......
　　三三 　もう　　　　　　 ＼ . ＜　 　 　 　 　 ＞
　　三　　　　だめぽ　　　　 ＼＜　　　　 .だ　.＞　　　　もう
三三　　 三　　　　　　　　　　. ＜　予 　 .め　.＞　　　　　だめぽ
――――――――――――＜　感　　.す　 ＞――――――――――――
　　　　　　　　　　　　　　　　　 ＜　!!!! 　　れ　＞
　　　　　　　　　　　　　　　　 　＜.　 　　　の　＞
　　　　　　　　　　　　　　　 　　 　∨∨∨∨∨

　　　　　　　　　　　　　　 　 -―￣￣ ｀ ―-- 　_　　　　　　　　　
　　　　　　　　　　　　,　´ 　......... . .　　　,　　　~　￣"　ー _
　　　　　　　　　　_／...........::::::::::::::::: : : :/　,r:::::::::::.:::::::::.:: :::.........｀　、 　　
　　　　　　　　 , ´ : ::::::::::::::::::::::::::::::::::::/　/:::::::::::::: : ,ﾍ ::::::::::::::::::::::: : ヽ
　　　　　　,／:::;;;;;;;| : ::::::::::::::::::::::::::::::/　/::::::::::::::::::: ● ::::::::::::::::: : : :,／
　　　　　と,-‐ ´￣: ::::::::::::::::::::::::::::::/　/:::::::::::r(:::::::::`'::::::::::::::::::::::く
　　　　(´＿＿　 : : :;;:::::::::::::::::::::::::::/　/:::::::::::`(::::::::: ,ﾍ:::::::::::::::::::::: ヽ
　　　　　　　 ￣￣｀ヾ＿::::::::::::::::::::::し ::::::::::::::::::::::: :●::::::::::::::::::::::: : : :_>
　　　　　　　　　 　 ,＿ 　＼:::::::::::::::::::::::::::::::::::::::::::::: `' _＿:::::::::-‐ ´
　　　　　　　　　　(＿_ ￣~"　＿＿ , --‐一~￣
　　　もうだめぽ…

予感って・・・

http://www.ogis-ri.co.jp/otc/hiroba/technical/MixJuice/

オブジェクト指向言語は間違っていた！

_chsize : 76d76da0 56 57 8b 74 24 c 3b 35 0 dc da 76 73 47 8b c6

マンセー
マンセー
マンセー
マンセー
マンセー

さあ、お前ら、今まで会社で好き放題にやってたオブジェクト指向信者の
粛清が始まります。

ぷっ、明日からリストラ候補だね。（藁

(´-`).｡ｏＯ（「　」,John,81の次はこいつか…）

>>477
１２分にアフォなんだから構ってやるな。

(ﾟ∀ﾟ)マンセーマンセーマンセーマンセーマンセーマンセー

差分ベースモジュール(ﾟ∀ﾟ)マンセーマンセーマンセーマンセーマンセーマンセー

AOPはよくしらんが、これもどーせろくなもんじゃない。
本当に優れた手法が洗練されて世に現れるころには俺たちゃジジーだよ
俺らの世代はOOP＋(AOPかな？）なんだからさ

こいつは本物です＞差分モジュール
何故ならば俺のやってる方法と同じだから。
天才は天才を反省しる！

OOPは便利なんだけど、C#とか　モジュール（ユニット）をクラスで代用しようとし過ぎてないか？

>>483

君は「Ruby使いなさい」と突っ込まれたいのか。

>>481
知らないものをろくなもんじゃないと決め付けていることに説得力は無いよ。
仮に本当に優れた手法があったとして、その名前を聞いても
「どーせろくなもんじゃない。」と言うんでしょ。

オブジェクト指向は結構だ。けどさぁ、
Cで無闇に関数ポインタを使いまくる香具師は、
只のヴァカだよ…。

>>486 そうか？　組み込みで全部の関数を関数ポインタにしたりはよくするぞ

>>487
それは必要があって、そうしているのだろうから
"無闇に"関数ポインタを使いまくる とは、違うと思われ。

Web プログラミングってほとんどオブジェクト作る必要が無い。
OOP が最も不向きな分野だと思う。

CGIで掲示板に毛の生えたようなものつくってるだけなら
そうでしょうね。。

>>489
まさか、いまだにPerlやPHPで、上から下へ流れるだけの
ソフト書いてるの？

>>490 >>491

貴殿のいうとおりでござんす。


まぁ、
Model <-> View でいうところの、View の部分では、GUI アプリケーションよりは、
Web のほうが OO 知らなくても作りやすいかな。

Viewの部分（HTML部分）をOO使って分離・抽象化しないと
ビジネスロジックと表示用のHTMLが入り乱れて、訳わからなく
なりますけど、何か。

>まさか、いまだにPerlやPHPで、上から下へ流れるだけの
>ソフト書いてるの？
他にどんなの作ってるの？
PHPやPerlはそんなイメージなんだけど。

関数ポインタを使いまくった他人のCソースは、正直、追い難い。
OOはOO言語でやってﾎｽｨ…。

>>495
禿同

>>494
労働時間長くて儲け低そう。

>>495
「追う」というやり方が通用する時点で手続き型じゃん。

>>498
で、何が言いたいの?

>>493

そういえばそうだったかな。HTML 文章のテンプレートを AbstractFactory で生成なんてのは、
技巧が好きなウェブサイトではあるかもしれん。

（そんな機能ほしがる人っているのかしら）

>>493
でも、悲しいけどASPとかJSPとかPHPとか。それが主流なのよね。

>>501
それでもプログラマーですか!
軟弱もの。

>>501

PHP でも Perl でも OO はできる。
しかし、それをやるなら Ruby が最適。

サーバサイドの Java はなんだか面倒。

>>502
あの文章だけで何となくガンダムの雰囲気をかぎ取っただと！
奴も・・・ニュータイプなのか！

おやじどもの会話はよくわからん。

>>500
ブラウザによってFactoryを切り替えればあらゆるページに対応できて良いかも知れない。

>>498
> 「追う」というやり方が通用する時点で手続き型じゃん。
確かに
手続き型の場合、取りあえず追ってみれば何とかなるが、
ＯＯの場合、まず全体像を把握してみないとサッパリわからん。

>>506
　それってオブジェクトじゃなくてユニットでも出来るよ
　ユニットをブラウザ毎にカスタマイズして用意するのは手続き型の範疇でしょう

>>508
まぁね。Ｃなら必要なぶんの関数ポインタ使えば出来るし。
静的で良いならリンクするファイルを換えても良いし。

ユニットってなんだよ？

>>510　モジュールとかユニットは同じ概念で、Cだと曖昧だけど
　ようは　手続きと内部構造をひとまとめしたもの

Singletonパターンなんて特に
JAVAで手続型を実装する場合の苦肉の策って感じだよね

>>512
以上ささやかな反抗でした。

>>512
この場合、
クラス＝名前空間的にはローカルだがグローバルなな変数を使用する関数群か。

そんなに手続き指向やりたいんならsingletonなぞ使わないで
全部staticメソッドとか、
一つのクラスに全部書き込むとか、
そういう偉大なる先人の生み出した技があるよ。
mainメソッドがうん千行なんてのもポイント高いね。

真のメッセージ駆動だと、最初の初期化の後は「メッセージの森」に処理が
移ってしまって追うのは難しく、メンテナンス性は下がる。
そういうアプローチは１０年以上前に一瞬で通り過ぎて、もっと高度な
プログラム構造を作り上げている。
「オブジェクト指向信者は二周遅れのランナーが先頭を走っていると勘違いしている
ようなもの」という比喩は煽りだけではない。

つーことは、アンチはそのさらに２週遅れ？

はいはい、あおりだけじゃなくて電（略

>>517

いや、途中棄権したくせにまだがんばって走ってるランナーに野次飛ばしてる負け犬です。

>>516
もっと高度なプログラム構造ってなぁに?

でじゃびゅ…

どぴゅぴゅ…

アンチ構造化のゴトウ(GoTo)君もまだ存在するみたいですし
光蔵(構造)君がわめいてるのも
負け犬の遠吠えですからみなさん気にしないで下さい。

オブジェクト指向って行っても呼び出す方は
手続き(変数の宣言をし、メソッドなどを呼び出す)に
よってオブジェクト使ってんじゃん。
つまり手続き指向が最高ってことじゃん

>>524
オブジェクト指向でもコードの末端はただのフローの組み合わせ。
OO がフロー制御に置き換わる技術とでも思ってた?

今のオブジェクト指向は中途半端
　やっぱり実行保留とかの機構が実装されて始めて本物だと思う
　実行保留は、サブルーチンのreturn した場所から次の呼び出しが
　行える仕掛けでコルーチンで実装される。

どうして必要かというと、
今のオブジェクト指向は、オブジェクトをサーバ・クライアントのどちら
かに設定して設計しなければならない。　

クライアントというのは別のオブジェクトにget ・putとかのメッセージを
投げる方で　サーバというのは投げられるほうだ。

クライアントで作られたものでも実行保留の仕掛けがあればサーバに
する事が出来る。　もちろんそれはやろうと思えば同期スレッドを使って
出来ない事ではないが、同期スレッドは重い。

中途半端な使い方っていうのは、言い方を変えれば、柔軟な発想で使っているってことだ。
白黒はっきりが好きな奴には向いていないし、こういう奴は戦場では使えない局面があるね。

>>526とはまた違うけど、
俺も今のオブジェクト指向言語は中途半端だと思う。
中途半端というより不完全。
つーか完全なものは作れないんだろうなあ。
昨今の新しい言語で、多重継承が不採用なのも
それは多重継承に欠陥があるんじゃなくて、
自分達が多重継承を使いこなせない
多重継承を正しく使う為の完璧なルールを
手に入れることが出来ないからなんだろうなぁ。

漏れは多重継承はeiffelで一応の結論が出てると見ているが。

>>528
あなたは間違っている！

と言う切り口から。

オブジェクト指向言語はあくまで効率の良いプログラミングを追求するため。
とうのプログラマの効率を下げてまでオブジェクト指向なんぞを推進しても
それはゴミでしかない。

>>529
eiffelってよく知らないけど、
それの多重継承の定義を使えば
矛盾は起きなくなるの？
へえ、勉強してみようかなあ。

>>530
そうだね。制限が増えることは確かだ。
規定が緩いから矛盾を含む余地が出来る訳であって。

>>529
激しく同意！

PowerPCだって純粋なRISCやCISC主義者を無視したからあれだけの性能が出たんだよ。

目的と手段が本末転倒になってませんか？と。

この議論からもっといい言語が生まれることを期待しています。

>>533
そうだ、オブジェクト指向は十分普及した。これからはAOPの時代だ。

Pen4>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PPC

オブジェクト指向万能主義は生産性・保守性共に悪いので滅びます。
全体設計に部分的に使ってもいいかな？という程度には生き残るでしょう。
数多ある設計構造のone of themになるでしょう。
開発手法や再利用性や保守性は別の方法が現れるでしょう。
（つうかすでにある）

>（つうかすでにある）
どんなのがあるの？

>>536
one of themなのはあたりまえ。今ごろ気づいたのか？
別の方法がなにかは知らんが、それもone of them。
完璧なのはない。現時点で最良なのはオブジェクト指向。

俺は荒らし。

構造化プログラミング万能主義は生産性・保守性共に悪いので滅びます。
全体設計に部分的に使ってもいいかな？という程度には生き残るでしょう。
数多ある設計構造のone of themになるでしょう。
開発手法や再利用性や保守性は別の方法が現れるでしょう。
（つうかすでにある）

えてしてそのようなメモリ食いな手法では
話にならない分野もあることを忘れるな。

＞この議論からもっといい言語が生まれることを期待しています。

2chで？2chから言語が生まれる？Rubyすら不可能だな。

おいおい。オブジェクト指向っつーのは理解したと思ってるやつ。
オブジェクト指向ってのは実に奥が深い。
死ぬまで勉強なのさ。人生と似たようなもんだ。
理解した！とそこで壁を作っちゃだめだ。
もっと勉強しよう、わかろうとしなきゃだめだ。
その壁を乗り越えろ。乗り越えたときに人間として
プログラマとして成長して、オブジェクト指向の何たるかがわかるのだ。

言ってること間違ってるか？

<pre>
10
20
30
</pre>

>>543
ﾄﾞｺｦﾀﾃﾖﾐ?
単なる方法論に人生哲学持ち込む奴はドキュンです。

オブジェクト指向は単なる方法論ではないのだ。
それは哲学だ。
奥が深い哲学だ。
これに触れて格闘した後、幸福なプログラミングライフを
送れるようになる。
あなたのためを考えて言ってるんだ。
だから誓約書にサインしなさい。
あなたの人生のため、
プログラマーとしての価値を内側から
引き出すために勇気を持って
オブジェクト指向に触れなさい。
ただ誓約書に名前を書くだけでいい。
オブジェクト指向がだめだと思ったら
やめたらいい。それはあなたの自由だ。
一歩踏み出すか、踏み出さないかで、
これからの人生、得するか損していくかが決まるのです。

ネタ元はアムウェイのパンフですか？

アムウェイって会社だっけ？

どちらにせよ、違うけどな。ﾆﾔﾘ

気軽に「哲学」をクチにする時点でアウトだな。
岩谷宏か、おめえは？

やってみなきゃわからないでしょう？
やる前からあーだこーだ言ってると、
それ以上進まないですよね？
ただ僕はオブジェクト指向を知ってほしい。
僕はね。オブジェクト指向で本当に幸せになれたんです。
昔は、僕もあなたと同じ考えでした。
でもまぁ僕の話なんだけども、構造化プログラミングでバグに悩まされてて、
先生にオブジェクト指向を信じてやってみなさいって言われたんです。
で、それから一生懸命ね。オブジェクト指向を勉強して
信心したらね。ｽｯﾄ頭の中が整理されて、バグもなくなったんです。
なんでもっと早くオブジェクト指向を習わなかったのかなぁと今は思ってます。
なんで僕がね。こんなことを言うかと言うと、
あなたに幸せになって欲しいからなんです。
だから一度、オブジェクト指向の集会がや日曜にやってますんで、
一度でいいですから来てみてください。
そしたらオブジェクト指向について今の誤ったイメージが間違っていたと
思うようになると思います。もしオブジェクト指向がやっぱりだめだと
思ったらそれは構いせん。それは自由です。
でも幸せになれないでしょう。一度集会に顔出してみてください。

層化ですか。
なんだそうか・・・。

やってみなきゃわからないでしょう？
やる前からあーだこーだ言ってると、
それ以上進まないですよね？
ただ僕は構造化プログラミングを知ってほしい。
僕はね。構造化プログラミングで本当に幸せになれたんです。
昔は、僕もあなたと同じ考えでした。
でもまぁ僕の話なんだけども、オブジェクト指向でバグに悩まされてて、
先生に構造化プログラミングを信じてやってみなさいって言われたんです。
で、それから一生懸命ね。構造化プログラミングを勉強して
信心したらね。ｽｯﾄ頭の中が整理されて、バグもなくなったんです。
なんでもっと早く構造化プログラミングを習わなかったのかなぁと今は思ってます。
なんで僕がね。こんなことを言うかと言うと、
あなたに幸せになって欲しいからなんです。
だから一度、構造化プログラミングの集会がや日曜にやってますんで、
一度でいいですから来てみてください。
そしたら構造化プログラミングについて今の誤ったイメージが間違っていたと
思うようになると思います。もし構造化プログラミングがやっぱりだめだと
思ったらそれは構いせん。それは自由です。
でも幸せになれないでしょう。一度集会に顔出してみてください。

逝って良しの１

>>543
俺は逆に真のオブジェクト指向言語を手に入れるのは
人間では無理なんじゃないかとすら思った。

age

１）オブジェクト指向は使わない。
２）メッセージ機構は使わない。
３）基本は手続き型。
４）グローバル関数には担当ブロックの名前を付ける。
５）設計はフローチャート。
６）ドキュメントビューアークテクチャの場合は描画関数にメイン処理を書く。
７）再利用性は忘れる。

これでばっちり、保守性向上、見積もり安定、コスト削減のプロジェクト
が出来あがります。

>>556
また荒らしの真似事ですか？

>>557
彼の生き甲斐を奪うな
町で包丁振り回したらどうする

age

あげる意味が分からん

>>557
>>539と>>553は偽者です。

逝って良しの１

素人はライブラリを使用＆作成だけすれば良いのでは？

下手にフレームワークとか作ろうとするから失敗する。

>>563
そうだな。フレーワークが善とは言わんが。

とにかく、馬鹿ＰＧのスパゲッティソースを、クラスで封じ込めるのは良い方法と思うが・・。
被害が最小ですむ。あとプログラム設計書が自動生成できる。

>>565

クラス設計書とプログラム設計書を混同するような馬鹿はクラスで封じ込めるのが
良い方法だと思わないか？

お前ら全員.逝って良し();

>566
ああ、一応「クラス設計書」＝「プログラム設計書」のようなイメージで考えていました。
ある１つのプログラムは複数のクラスにより成り立つので・・。１つの単体プログラムは
クラスだけでは作りにくいんですよね。コーディング量から見ると、

１つの単体プログラム(１００％)＝クラス(６５％)＋普通のコーディング(３５％)

ぐらいの割合かな。
少なくともクラスの部分６５％に業務ロジックを集中するので、この部分のロジック変更は他に
影響を与えない。残りの３５％がＵＩとか印刷処理とかのマンマシンインターフェースの部分に
なるんだけれど、この部分で共通変数がかなり少なく出来るので、プログラム視認性が良い。
以前はクラスの部分が全部スパゲッティーファンクションで、一つ弄ると根こそぎバグって
大変だった。

日本語で話してくれ

>>550, >>552
構造化したから、OO 使ったから
それでバグの出なくなる世界に私は逝きたい・・・。

その日曜にやっているという集会に俺はでたい・・・

　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/ ←>>571
　（＿フ彡　　　　　 　　/

>>570-572
これが有名な三段オチというやつですか？

>>573
tmp=a;
a=b;
b=tmp;

>>574
それは三段論法です

♪三段落ちぃと〜　さよなら〜するのよ〜
幼い〜おとおと〜　ゆくな〜と〜泣〜い〜た〜

>>575
いえ、あれは三角飛びですよ。

間違えました。
あれは♥夫婦♥交換♥です。
数値型なら xor を使うほうが効率的ですけどね。

>>578
本当に効率的か。それが問題だ。

XORを使うヤシは禿しいドキュソ！略してHDQN!!

ほーっしゅあげ

最近2CHに来た人は知らないだろうが、OOは効率が下がるという統計があります。
http://piza2.2ch.net/tech/kako/1003/10038/1003815855.html

至高のオブジェクトを使いなさい。

>>582
なんだよ、期待してみりゃリンク元の結果は
> フリーソフトウェアプロジェクトの成功とプログラミング言語との関係を算出
> する極めていいかげんな方法を考案したので、その方法といくつかのプログラミング
> 言語に対する算出結果を報告する。
で全然あてにならんじゃん。OOは効率が下がるという統計にもなってない。
というかAPLやPerlやTCLを使えってことか？

>>582 の統計だと C でちっこいプロジェクトばかりやってれば
おのずと成功率が上がるな (警官が駐禁で点数稼ぐみたい)。

最近2CHに来た人は知らないだろうが、逝って良しの１の言うことはウソという統計があります。

今日も微弱な電波発してんな＞逝1

最近リニアが不調なもんで・・・

お前ら、数年後に
「ああ、あの時言って良しの１の意見に真剣に耳を傾けていれば」
と後悔する日がきっと来る。

やろうと思わなければ効率のいい使い方なんかできるわけない。

そう言い残し、言って良しの１は肩を落としながら寂しく去っていくのであった。

馬鹿ＰＧのスパゲッティソースはnamespceで閉じ込めるがキチ。

>>592
そのname spaceを開いた瞬間、そこにあったのは混沌であった…
次回、OO戦士Jガンダム、「スパゲティの渦」
〜君はPGの涙を見る〜

namespace vaka_pg {
俺 (T∀T){うえーん;}
}

おっとaが抜け取るよ。
namespaceも定義できない馬鹿ＰＧ
だった〜Ｙｏ　（ﾟ∀ﾟ）ｱﾋｬ

今日気付いたんだけど、外国でも

・クラスで書いたからオブジェクト指向
・色んなサブルーチンをぶち込んだ只のサブルーチン集
・名前が動詞ののクラス

なんてのがまかり通ってるな。
アフリカに伝承されたキリスト教がすっかり変質して、呪術と生贄の変な宗教に
なった例もあることだし、数の多いこっちの方の認識が主流になるかも。
酷いもんだ。
そのうち「何をするクラスか判り易い様にクラス名は動詞にすること」
なんてコーディング規則が出来あがったりしそう。

今日のオナニーは17点。

クラスはコンセプトとか資源の表現とかだろう？

同一の性質(属性、振る舞い)を持つオブジェクトを分類(Classify)した
のがクラスだろ。

ある作業をするのに必要な生徒をまとめてひとつの部屋に押し込めて、
外から出席番号でアクセスすると教師に許された話題に関してだけお話
できるようにしたのがクラス。

みんな間違い。
クラスはオブジェクトの型情報で実体ではない。

(ﾟДﾟ)ﾊｧ？
ちゃんとした本読んでくださいね。

マムコの中にティムポつっこむのがセクースだろ。

(´-`).｡oO(ほんとに逝ってくれないかな...名前通り)

仕事の後のゲラゲラは、健康にイイ。

>>601
機能実装的にはその認識で良い。
つまり逝1は設計に慣れてないパシリプログラマらしい。

マルチスレッドプログラミングだと、
オブジェクト指向は何の役にも立たないな。

>>607
はぁ ?

>>607
まあ、>>607 には使えないってことでいいですか ?

>>609
おおすじで同意

オブジェクト指向な、
ネットワークのプログラム
って実際あるの？

オブジェクト指向でない、
ネットワークのプログラム
の例を挙げてくれ？

>>612
普通にソケット開いて送る？

ソケット通信と、その通信量をゲージで表示する機能を持つ
アプリケーションをモデリングしてください。

CORBA使え

オブジェクト指向の一種で、オブジェクト毎にプロセスを割り当てるようなやつなかったけ？

分散おぶじぇくとしこう？

並列だったような気もする。

ポブナント降下艇が接近中！安全を確保して！
チーフ、会えてよかった！
思ったよりでかいな。
ぐはっ　きをつけろ！
すまん！
気は確かか？

オブジェクト指向って設計がうまくいくと後が凄い楽になるような気がする

>>620
裏を返せばって言葉もある

プログラムをするとエラー・バグがあることを前提に対策を考えるからネガティブな思考になると思うんだが違うか。

C++のnamespaceってネストできるんだっけ？
namespace 隔離病棟 {
namespace vaka_pg {
俺 (T∀T){うえーん;}
}
}

>>622
>ネガティブな思考
薬の飲めば解決する

>>623
できるよ。

ThreadをSubjectにして、
Observerのrunでnotify
を繰り返すのってあり？

>624
本当に精神科っていいんだべか。効果あったか？

>>626
Smalltalkのテストツール作った時に、そんな感じの事したよ。

>>628

javaでやってみます。
意味無さそうだけど…

しばらく動向をみてきたがオブジェクト指向つかう奴あまりおらんな。

>630
俺のまわりで行われているプロジェクト(Ｊａｖａ)は、全部オブジェクト指向開発だよ。
業務分析からオブジェクト指向分析やっている案件は、極一部だけど、
実装は全てのプロジェクトがオブジェクト指向。ＵＭＬ必須。

＞全部オブジェクト指向開発だよ。
反射的にうさんくささを感じてしまう…

>>632
だからこそ約４時間放置されてたんだと思われ。

>632
最初はうざったく思うけど、スパゲッティ-プログラム防止には良いと思う。１回目プロジェクト
は、かえって時間も掛かってコスト増だけど、２回目プロジェクトからは納期も短縮できる。

あと、ドキュメント作成でＵＭＬを標準にしているので、ドキュメント標準化が容易。
ＵＭＬを使うまでは、まともなドキュメントを書かせるのに非常に苦労した。

ＵＭＬ使ってても只のサブルーチン集のクラス作ってるアフォも一杯見てきたので
それだけじゃあ本当にオブジェクト指向やってるかどうか判らんね。
つうかプログラマーの９割はサブルーチンの設計もロクに出来ない奴ばっかじゃん。

その９割のうちの一人だから「逝って良し」なんだね。

>>635
どのレベルをもって「設計もロクに出来ない」と言っているんだろうかね。
635の言う「サブルーチンの設計がちゃんと出来ている」基準を是非知りたいモノだ。（ｗ

サブルーチンの設計できてない奴のコーディング方法なら

１）とりあえずライブラリのコードを並べるだけの書き方をする。
２）同じような並びのコードがあったらサブルーチンにして一個にまとめる。

このようにして出来あがったサブルーチンは再利用できる可能性が殆どありません。
特に２）をコーディング規則にしているＤＱＮ会社や個人の多いこと多いこと。

ああ、「一画面に収まらないからサブルーチンに分割する」
という奴もあるね。

派遣でJavaの仕事中。
現在製作中のメソッドが400行に届いたけど、
これを分割しちゃいけないらしい。
さらに、このメソッド中で実行されるSQLを
メソッド内に記述しないといけないらしく、
そうすると1.5倍近くまで伸びそう。

オブジェクト指向どころかカプセル化すらも
理解できないような年寄りは、
みんな引退しちまえと最近思う。

>>640
１メソッド４００行なら、すでに自力でＤＱＮです。

ただしインタプリタやどうしても避けられないステートモデルを除く。

>>640
400行かよ！

>みんな引退しちまえと最近思う。

おまえが引退しろ

>>641, 643
アホ、誰が好きこのんで４００行のメソッドなんか書くか。
うちのコーディング規約じゃ、メソッドすら作っちゃいけなくて、
一つのメソッドに全部押し込まなきゃなんねえんだよ。
書いてるこっちだって吐き気がしてるんだ。
この規約決めた奴が引退しなかったら誰が引退するってんだ。

わかりました。すいません。ごめんなさいい！
慰めになるか判らないけど、私はインタプリタなら２０００行のを作ったことがあります。

それから好き好んで無意味に１メソッドに数百行書く奴も実在します。

Javaって640みたいなアホが使ってるんですか？
正直、幻滅しました。

コーディング規約守るために、
せっかく書いたメソッドを手で
インライン展開してんだぞ、俺は。
くっだらねえ。

>>645
分かれば良し。
でもあんまり慰めにならない。

>くっだらねえ。
お前の人生そのものだな。

>>645
　2000行もってツールで吐かせたの？
　ステートメントはハッシュ＋関数ポインタの構造＋再帰下降で
　書けばせいぜい30行程度のブロックが沢山という感じじゃない？

あれ？インタプリタ言語で2千行のを書いたという事？

printf っぽい構文解析変換とか？

>>649
再帰下降って、インタプリタつーよりパーサの仕事じゃない？
インタプリタは単純に次の命令を拾ってきてインタープリトすればいいのでは。
何故それが2000行もかかるのか、余計わからんけど。

ager

あえて、わかるように書くけど、
鼠園でスポンサーしてたところじゃ、
オブジェクト指向、
ＵＭＬ、
デザインパターン
を知っている前提で
会話が進むようになったよ。
とうぜん、ここで最近かかれているような
長いメソッドなんか書かないし。
でかい仕事してみりゃ、長所と短所がわかるよ。

あわわ、嫌な会話だな（ｗ

中間コード方式で構文解析は無いよ。
Javaだから関数ポインタは無し。
巨大なswitch-case文なのだ。
Rubyの実装に問題ありスレにも似たような事が書いてあったが。

>>653
そこらの業務アプリだとそれで収まるね。
でも自慢にはならないと思う。

>>653
つーか、そこらの業務アプリ以外にはどんなのでそうなってきた？
>>655さんはそこらの業務アプリ以外でそうなってきたところを
ご存知？
おれはまだしらない。

今や、糞Webｱﾌﾟﾘでしか使われないJavaだが、
WebｱﾌﾟﾘほどJavaに向かない物もない。
てか、Javaに向くものなどないか。

４００行メソッドに耐えられなくなって、
リファクタリングかけてきた。
完成したら逆リファクタリングかけて
ダメコードに戻さなくちゃいけないから鬱。

他の連中はなんでこんなんでコードかけるんだ？
変数がやたらと増えて管理しきれなくなるし、
オブジェクト指向は難しいとか言って、
そっちの方がよっぽど難しいと思うんだが・・・

>>653
俺もそこに連れてってくれ。
夢のような職場だ。

まず言語開発
未だに各言語用のコンパイラをいちいち書いてるのが実情で、どうやっても
汎言語で再利用可能なモジュールを作れない。
ゲーム
一部の戦略ゲームとは相性が良さそうだけど、一般には相性が悪い。
シミュレーション分野
境界問題や基本原理が別にある事からオブジェクト化できない場合が多そう。
制御
多くは、それ以上分割できないモジュールだしねえ・・・。
アナログフィードバックっぽい動作なんかどうオブジェクト指向で書けと？

>>659
言語開発という語の指示する業務内容がよく分からん。
ゲームと相性が悪いですと？効率を別にすれば逆に相性はいい方だろう。
シミュレーションと言っても分野が色々ある。
構成要素間の相互作用が複雑な場合なんかはオブジェクト指向が有効だろう。
制御などは、そもそも粒度がある程度にならないとオブジェクト指向は適用外。
対象領域が違うものに向いてないと言われてもねぇ。

>>655
君、polymorphismについて勉強したほうがいいよ。

>>659
各言語用のコンパイラを書くことと再利用可能なモジュールを作る事の関連性は何？

ゲームについては、アドベンチャーゲームやロールプレイングゲームが典型的な適用対象だろう。
つーか、適用しにくいのはシューティング系ぐらいなもんだろ。

シミュレーション分野って…オブジェクト指向はシミュレーション記述言語から始まったの、知らない？
実際、俺もオブジェクト指向言語でシミュレーション関係のシステム3つほど仕事で作ったことあるぞ。

>>661
> 君、polymorphismについて勉強したほうがいいよ。

ポリモルフィズムがあるとどうしてバイトコードインタプリタ
のソースコードが短かくなるの？

> 各言語用のコンパイラを書くことと再利用可能なモジュールを作る事の関連性は何？

コンパイラインフラのことじゃないの？SUIFやvortexのような

>>662
インタプリタのソースコード全体が短かくなるわけではないが、
とりあえず、1メソッド2000行なんて事にはならんですむだろ。
>>655が関数ポインタがないからみたいな事いってるけど、それは違うだろって事。

>>663
各バイトコードに対応する処理 (通常は巨大な switch 文の中の一つの case)
を関数とすればよいということ？それはちと無茶な気がする．
インタプリタはただでさえディスパッチのコストが痛いのに関数呼出し
にするのは…．それに関数に分割しても見通しはそんなに変わらないのではと．

あ，それと，バイトコードインタプリタの実装とポリモルフィズムの関係が
まだよくわからない．

＞それに関数に分割しても見通しはそんなに変わらないのではと．
ゴチャゴチャした方が見やすいのか？
へー、ヨカッタネ　ヘンジン

バイトコードって仮想マシン用のバイナリだったのかー
しらなかた

>>664
ディスパッチ速度を気にする人がJavaでインタプリタ実装するか？

属性の継承を許さない言語きぼんぬ

スタックに定数を積むようなバイトコードは関数にする必要ないだろうけど、
たとえば、0,1,2,4をそれぞれスタックに積むようなのはマクロにすれば
あわせて１行で書けるし、ある程度の行になったらインラインにすれば
いいしで、2000行とかいうサイズにはならんと思うが…

>>670
Javaで実装っつーとるだろが…

ソフトウエアの生産性を落とす最も大きな要因は言語転換です。

よくもまあ、次から次へと面白いことを言い出すね。

>>658
札幌においで。

インタプリタか。
バイトコード命令まで分割するとなると、
switch-case のトランポリン形式で分岐書くだけでも2000行軽く超えると思う。
それと各case内の処理を関数化してもほとんどメリットないよ。
むしろ関数化よりはファイル分割が有効だけど、
Javaはマクロや#includeみたいな便利な物は無いみたいね。

根本的に異なる言語間では辛いものがありますね

過去の文明の利器を捨て去ったJavaはクソコードしか書けないってコトですね。

たまに「500行超えるメソッド? 信じらんな〜い」みたいなのいるね。
大規模なシステムでは、そんなに珍しくもないと思うけど。
というより、行数でプログラムを語ろうってのが厨房すぎる。

>>674
札幌に逝くくらいなら氏を選ぶ

>>678
なんか矛盾した文章ですね。

>>678
メソッド自体は珍しくないが、
それを見て何も感じない奴は信用できないな。

>>678
いやー、5000行のメソッドはさすがにアホ過ぎるだろ。

5000行････
400行以下にできんかね

井の中のJava厨大海を知らず(恥)

トレーディングオフってヤシを知れ。

>>675
あのさ、Cやアセンブリで書く時にはどうするって考えて、それがJavaでできないって
…典型的な厨PGの発想だね。

ファクトリーメソッドパターンでゴー

ＪＡＶＡ使いなら、各命令毎にオブジェクトを作って　その命令のリストクラスに処理させるのが普通では？

>>688
え、じゃあコンパイラがそのオブジェクトを生成しないといかんわけ？
えらい使いにくいバイトコードインタプリタだな。

そんぐらいなら、配列に各命令オブジェクトを入れておいて
命令はその配列へのインデックスにでもしたほうが大分マシじゃないの？
遅いけど。
ま、どうせインタプリタをJavaで実装するんなら、
そんぐらい遅くても気にしないかもしれんがな (藁

GUIのイベント処理ですけど、
イベントの種類だけ、if ...elseってするのが正しいのですか？

>>690
Windowsではそうやってるな。

>>688
意味わかんね

>>690
動的にイベント追加するときはHashでやったほうがいいかもね。

>>692
多様のもっとも有名な使い方だろ。

class MyEvent
{
void DoEvent();
}

class MouseClick :MyEvent
{
void DoEvent()
{
}
}

class KeyInput :MyEvent
{
void DoEvent()
{
}
}


void Event(MyEvent ev)
{
ev.DoEvent();
}

まぁ、そのクラスを生成するためにイベントをswtichで振り分ける必要が・・・ｗ

>>691
>>693

javaですけど、これはあり？

public void actionPerformed (ActionEvent ae)
{
Handler handler = (Handler)ae.getSource();
handler.perform();
}

>>694　Switchを使わないなら、こうだろ

class MyEvent
{
int GetByteCode();
void DoEvent();
}

これを入れるコンテナ作って、GetByteCodeでハッシュで検索させるとか

無理にOOしないで、switch使え。
OOより、わかりやすさを選べ。
OOじゃなきゃわかりにくいという、固定概念を捨てろ。
行数より、わかりやすさを選べ。
短い行数じゃなきゃわかりにくいという、固定概念を捨てろ。
そんなもん、ケースバイケースだ。

そもそも、JAVAは関数ポインタが無いから仕方なく機構を使うしかないだけで
それと OO は全く関係ない。

いや2千行も構造化されてない手続きがあるのは、やっぱりいやだな

どうしてもというなら、コードを吐くツールを作るとかしろよと思う

>>697
> OOじゃなきゃわかりにくいという、固定概念を捨てろ。
彼らはOO*しか*知らないので、OOは固定概念ということすら気づきません。
彼らは10年後もOOで開発を行い、10年後に流行する方法論者に嘲笑されるでしょう。
# 現在のCOBOLerのように

間違えたかも。
actionPerformedは、
コマンドパターソがいいみたいだね。
switchは言語仕様でいらないね。

OOしか知らなければ、「行数が多い＝わかりづらい」は正しい。
長い手続処理を、わかりやすくする術がない。
オブジェクトに分割するしかない。
たとえかえってわかりづらくなっても、非効率的な処理でも。

>>697
OOを知らないとさっきの例の効率の良さに気づけない。
それはそれで不幸かと。

switchが必要になる度に、個々のケースをオブジェクトにする気です。
さすがです、さすがすぎます、脱帽です。もう、なにも言えません。
負けました。／(_ _)＼

>>704
極論ですね。逆に言うと極論でしか論破できない？

>>703

>OOを知らないと
相手がオブジェクト指向を
知らないと決めつける以外の
反論は無いのかなぁ

>>706
>彼らはOO*しか*知らないので

相手がオブジェクト指向しか
知らないと決めつける以外の
反論は無いのかなぁ

>>705
極論を逝ってるのはあなた。自分の書いたレスを読んでね。
# switch いらないんでしょ(藁
折れは書いてあるレスを、的確にまとめたつもりだけどな。

>>707

漏れが書いたんじゃないよ
ところで本当は知ってるの?

OO言語で、手続きですか…
こだわりでもあるのですかね。

>>710
＞OO言語で、手続きですか…
smalltalk以外は該当しないな。

メソッドは手続ですが何か？

switch の話はどうなった？いるのか、いらん(藁)のか。

http://js-web.cside.com/index.html

>>713
お前、論点ずれてるな。

>>713

そう追いつめなくても
変なスレたてまくるよ
その辺で許してあげれ

>>716
お前、やさしいな。これからミーティングなんで、折れは逝く。
あとは頼んだぞ(藁)

switchは標準でいりません。
else ifも数に制限かけてください。

>>718
＞else ifも数に制限かけてください。
南下し欄が理不尽だなｗ

>>718
ｱﾝﾁOOのｼﾞｻｸｼﾞｴﾝﾈﾀだろうが、
OO厨にはこんなのいそうだな。
自分の知識だけの範囲で、
気にくわない物を禁止したがる奴。

>>720
アンチOOにもいえるよな。

俗に言うわかってないくせにけなすだけの奴。

っていうかOOしか知らないって可能なの？
いったいどんな勉強すれば・・・。

>>721
OO知らなくて、プログラマなんて出来ないよ。
誰でも知ってる基礎的な知識。
君と違うのは、盲信してない点だけ。

>>722
悪い。マジレスほしいんだよ。俺。

>>718

switch の件は
終わりにしてやってくだされ
すまそ

>>724
あっちが勝手に問題を誇大にしてるだけなので謝ることはないかと。

>>723
根拠のないプライドが傷つきすぎて、
心がゆがみ・ねじ曲がっちゃったかな？
VB厨でも叩いて、心を癒してきなさい。

>>726
もうやってる。ｗ

701=718です。

だれか同意する人いないのですか？

漏れには収拾できません
さらばです

>>728
ifもforもswitchも言語仕様でいらないね。

>>730
私はアンチOOですがたしかにifもforもswitchもいらないと思います。

イベントをハッシュから引くのとスイッチとどっちが速い？

>>732
そらswitchだろ。
さんざん語られてきたOOは速度が遅いとか言うので攻めてくる気かいな？

>>730
>>731

つまんねーよ。バーカ。

>>732
JavaをやめてC++にして、switch使えば、実行も開発もはやいです。

>>735
アンチOOならCだろ。

>>736
OOのある状況での不適合を指摘する人間が、すべてアンチではありません。

#includeで委譲、これ最強。
OO原理主義者にはマネが出来ない。

決着も付いたしそろそろ消えよっと

>>738
悪いことはマネしたらだめって教わらなかったかい？

>>737
でも、736はアホなのでステレオタイプ的なアンチOOが存在すると信じています。

アンチ馬鹿も消えたようだな。
鬼の居ぬ間にアンチを叩こうぜ。
二度とここに来れないようにな。

>>742
> 鬼の居ぬ間にアンチを叩こうぜ。
プッ。そういうのを
「負　け　犬　の　遠　吠　え」
と呼ぶんだよ。

あと、君って一人だと叩くこともできないの？
君みたいなヘタレ厨房は二度とここに来なほうがいいよ。

暇なときアンチと遊ぶスレですか？

>>697,>>700

http://game.2ch.net/test/read.cgi/gamedev/1026918889/7-

オブジェクト指向は戦場では必要なし！に１票！！！

>>746
お前はN88BASICでもやってろ

火がついてからのプロジェクトは大方の方法論は役にたたんわな。
転ばぬ先の杖。

で、単体テストってどうやってる？

引きこもりだから適当に限界値。

>>749
鼻歌交じりに。

あのさ、元の議論はインタプリタの実装だよね？
だったら、バイトコードの命令は連番になってるから
ハッシュなんて要らないんじゃない？
単に配列へのインデックスで十分。
これなら、命令数によっては配列のほうが早くない？

イベント番号の場合も、連番になってれば同じ事が言えるね。

そもそもハッシュは配列並の速度を出す為の手法だというのはおいといて

バイトコードって普通そんなに詰まっていないと思うのだが・・
スタックマシンだと
push/pop/add/sub/mul/div/and/or/xor/neg を１アイテムに
分岐/CALL/LD/ST系を残りにパックする程度で

つーか、飛び番を連番に近いものにするのがハッシュ関数でしょ。

で、1アイテムって何の事？オペランド無しの1バイト命令って事？

>>754　ごめん　バイトコードは大抵スカスカになる程度の事を言いたかったんだ

>>755
そう、大抵スカスカだね。でも1バイト命令ならサイズ256の配列で十分だよね。
わざわざハッシュ関数を適用するまでもないでしょ。
ちなみにSmalltalkだと、バイトコードの命令数は実装によるバラツキはあるけど、80個ぐらい。
80個相手にif...then...else...とかswitchとかするぐらいなら配列使ったほうがよくない？
しかもJavaで実装するんなら、なおさらswitchとかする意義がわからん。
256サイズの配列使えば、配列アクセスとmethod dispatchだけで済むんだもん。

なんか、必死だねぇ。
switch使わずに、オブジェクト指向でやるんじゃなかったの？
配列って、オブジェクト指向と関係あるのか？
なんか、switch不要のオブジェクト指向論が破綻して、
必死で配列使用論を主張して、話を逸らしてるように見えるが。
自分でプログラムしてみりゃわかるが、switchの方がわかりやすいぞ。
この手の各ケースが細かい処理ならな。

配列って関数ポインタの配列？

>>758
JAVA厨が言うには
関数ポインタのようなダサイ事を
多態でスマートに出来るようにしたのが
オブジェクト指向らしいから
まさかそんなダサイ事しないだろ

関数ポインタというかメソッドポインタ　欲しいねえ

配列アクセスするとして、オブジェクトを入れておくんだとしたら、
参照と呼び出しのコストが増えるから、
どう考えても遅くなる気がする。（これは関数ポインタと一緒だね。）
追加は楽そうだけど、見通しは悪くなりそう。

>>758
オブジェクトの配列という手もある。

>>762
オブジェクトの配列は、さらに遅い。

←速い　　　　　　　　　　　　　　　　　遅い→
switch>>>関数ポインタ配列>>>オブジェクト配列

gccだと、gotoのラベル(＝ジャンプ先)も配列に入るんだよね。
あれさえあれば・・・

＞Ｑ．Javaでgoto文を使おうとするとエラーとなるのですが。
＞
＞Ａ．Javaでは、gotoはキーワードとして用意されていますが、goto文は使われてません。したがってgoto文を利用することはできないのです。

>>766
＞Ａ．Javaでは、gotoはキーワードとして用意されていますが、goto文は使われてません。したがってgoto文を利用することはできないのです。
理由が意味不明な感じ

キーワードっつーか、ＮＧワードって感じ＜goto

メソッドポインタない？

>>769
すいません。付け忘れました。

>>769
C#使え

inheritance is cool

actionPerformってことは、
すでに、分岐の数だけオブジェクトは存在すると思われる。

704 ：デフォルトの名無しさん ：02/07/18 15:34
switchが必要になる度に、個々のケースをオブジェクトにする気です。

ところで携帯のJava開発関係者はＯＯな仕事できてる？
↑みたいな例でもswitch使わずに
バコバコ多態オブジェクト作ってんの？

>>774
組み込みなどリソースの極端に少ない場合、現行のOOが不利なのは常識。
今は考え方としてのOOが有害か無害かを語っているのでは？

昨日から調べて得られた反論がそれか。見損なった。

おまえらつべこべ言わんとﾃﾞｻﾞﾊﾟﾀやれ。

携帯関係ってファミコンとかで飯食ってた
真のプログラマが多そう…

ていうか携帯って組み込みだろ？
OOだから携帯でJava使ってるんじゃなくて、
標準化されたバイトコードが走るからつかってるんでねーの？

バイトコードなんて使うJavaは珈琲です。

>>775
> 今は考え方としてのOOが有害か無害かを語っているのでは？
お前のようなOO厨が有害

>>774
メモリ少ないのでクラスが作れません。

>>781
「OOだから」携帯でJavaを使ってるんじゃないから、携帯関係でクラス
を作らないことが手法としてのOOを否定している事にはならないんでねーか？

>>782
>>775で外出かと。

クラスとくらすたい（ちょっと苦しい）

>>783
どこに反論が？？？

Javaで構造化だろ？？(w

Cで書いたプログラムを携帯にダウンロードかぁ。
互換性なさそうだね。

アフォに絡むから泥沼にはまる。

>>787
そっか、携帯は使ってるCPUその他違うもんな。
どうしてもVMが必要だったわけか。

C++で書いたクラス。
決定。

Javaのバイトコードはコンパクトだから、通信とかでプログラムを
やり取りするのには向いてるんでなかった？

>>791
！？

そうか、だから形態なんだな

携帯でメモリ気にするのも今だけだよ。
一瞬のことです。

で、一瞬経ったわけだが・・・なんか変わった？

>>794
そうなったとしてもWindowsCEでJavaを動かすようなもん。

>>764は、議論の前提が「Javaでインタプリタを実装」だということがわかってるのかな？

Javaで100個近いcaseをswitchで分岐するのと、オブジェクト配列を使うのと、どっちが速いか、試してみた？
俺がj2sdk1.4.0で試した所では、

オ ブ ジ ェ ク ト 配 列 の ほ う が ２　０　％ ほ ど 速 か っ た よ 。

コードの見通しも、各命令毎にサブクラス作るほうがいいよ。拡張性もね。
例えば、実行されたバイトコード数を数えたり、テストカバレッジ計測したり、
そういうことも命令毎に独立したオブジェクトになってたほうが
断然やりやすいね。

>>795
http://www.nttdocomo.co.jp/p_s/imode/java/qa.html#1-2

>>797
なかなかに想像を絶するテスト結果だな・・・・。

jphoneは100kbだし。

>>789
>そっか、携帯は使ってるCPUその他違うもんな。
>どうしてもVMが必要だったわけか。
>>791
>Javaのバイトコードはコンパクトだから、通信とかでプログラムを
>やり取りするのには向いてるんでなかった？
すべてはずれです。
携帯Javaにコードレベルでの互換性はありません。
DojaとMIDPではAPIの仕様が違います。
なぜ携帯でJavaか？というと一般人でもプログラムが
書ける言語だからです。
ほかの言語で書かれている核となる電話機能を壊されたら
メーカーはたまったものではありません。

アンチ嘘かよ。
何がswitch速いだよ、、アホか。

>>797
馬鹿に付ける薬はないな

>>801

つーか、docomoだけが違うことやってるだけなんですけど。

>>801
>DojaとMIDPではAPIの仕様が違います。

ドコモの携帯間の互換性をゆーとるんだが。
Dojaでいっしょだからバイトコード互換性あるの当たり前なんだが。

>>804
そーか？
同じメーカーでも機種ごとに拡張された機能なんて互換性ないぞ。
ってゆうかその機能が各社の売り名わけで。
それとJava自体にカテゴリーがいったいいくつ分かれていると思う。
結局Sunの理想も企業の営利目的の前ではまったく意味がない。

>>803
お得意の「勝利宣言」ですか？(w
反論できないだけ‥‥‥‥‥か‥‥‥‥‥。

>>806
はぁ？

>>806

こだわりすぎ。
MIDPでいくかどうか作り手が選べるんだYO。

つーか、Javaの場合はswitchよりもオブジェクト配列使ったほうが速いなんて当然だろ。

1. switchでシーケンシャルに比較を繰り返す
2. オブジェクト配列で定数時間でメソッドを叩く

case数が大きくなれば、いつかオブジェクト配列のほうが速くなるのが当然。
アルゴリズムの基礎だぞ。
もっとも、Cなどではコンパイラが最適化がんがればswitchも単純な線型探索じゃなくなるがな。
でもJavaでその最適化は無理。

>>789
ＣＰＵはＡＲＭしか事実上の選択肢が無いと言う罠。
ＶＭは現実的には意味無いです。

>>810
最適化がんばらなくてもJavaが速いと認めましたか。
素直で良いね。

>>811
んなわけない。
VMだからCPUが＊今後＊変わったとしても動作が保証できるんだろ？

>>810
ベタなswitchにすりゃそうだが、それは実装がタコなだけと言わんか？
パフォーマンスを気にして巨大switchを組むような奴なら
普通は上位何ビットかで分けてからなんて具合にツリーにすると思うが。

もちろんcase数が小さければ、switchのほうが断然速い。これまた当然。

switch > 関数配列 > オブジェクト配列

などという何の意味もない不等式に踊らされるより、
ちゃんと何をするためには何が適切なのか、考えてコーディングしようね、PGさん。

ところで逝って良しの１はJavaの代わりに何言語を使えば
携帯には理想的だと考えているのかにゃ？
COBOL??

>>814
そうだね、ある程度のcase数までなら2分探索のほうがいいね。
いずれにせよ、
「 switch > 関数配列 > オブジェクト配列」
はアフォ。

>>813
携帯に乗っているチップへの命令はVMのみではサポートできない。

>>818
いたたたたたたたたたたたっ！！

ＢＡＳＩＣ

話を戻すと、この手の言語周りのプログラムって難易度高いよね、
作ってるとものすごく疲れる。

>>820
逝って良しの１が構造化マンセーではないということが証明されますた。

多態オブジェクトも計測してください。
おながいします。

逝って良しの１＝HSP廚

>>821
「真のプログラマはPASCALを使わない」って奴なのね。

携帯のJavaは現代版のBASICである。
ユーザーからは危険な命令を実行できない。
ちなみにリソース限られている携帯でOOPLなんて
かなり機能が限定される。

ＢＡＳＩＣなら　
ON N GOTO 1発だから最速じゃん

ON-GOTO＞ジャンプテーブル＞＞＞switch>オブジェクト配列

>>821
そうか？まあ処理系のパフォーマンスとか最適化技術とか言い出すと難易度激高だけど、
君みたくJavaでインタプリタ作るっていうんならパフォーマンスとかとは無縁なんでしょ？
なら別にたいした難易度じゃないよ、つーか、プログラミングの基礎でしょ。

疲労コンパイラと言う。

Cのジャンプテーブル＞Javaのオブジェクト配列＞＞＞＞＞＞＞BASICのON n GOTO

>>827
だからさ、違う言語のパフォーマンスを比較しても意味ないだろうが。
何でもいいから言語設計の本でも読んでから出直してきな。

訂正：
逝って良しの１＝N88BASIC世代のじじい

40〜50過ぎのじいさんの独り言だろ？
ほっとけよ。

BASICはジャンプテーブルが言語レベルで提供されているんだよ？
構造化ファシズムで消されたけど、どうせCでも書かなきゃならないなら
自作より言語で提供してくれた方が安全じゃん。

逝って良しの１が言語をつくるどころかBASICの内部構造も知らない事が
証明されますた。

相当な馬鹿じゃなきゃ、配列が早いように組める。
では、普通に組んだ場合は？
switchの方が速いし、メンテナンス性、可読性で上回る。
ケースが100あれば、100の異なるオブジェクトを生成し、
配列を初期化する？
1つあたりのオブジェクトが大きければまだしも、
そんな細切れのソースが、わかりやすいとか
メンテナンスしやすいとか、頭おかしいんじゃないか？
結局Java馬鹿OO厨の言うことは、所詮妄想なんだよなぁ。

switchと多態で計測すれ

臨機応変

オブジェクト指向についてうんちく垂れたいなら、オブジェクトの粒度について本でも読め。

>>837
逝って良しの１はJavaで書けないからそれを要求するのは酷かと

>>836
相当な馬鹿でなきゃ、配列が速いように組めるが、
普通に組んだ場合はswitchのほうが速い？

ワケワカラン。普通の人が組んだら、どっちが速いんだ？
相当な馬鹿じゃないから、配列のほうが速いのか？

>>841
日本語の解説もしなきゃならんのか？
相当な馬鹿でなきゃ、意図的に配列が速いように組めるが、
普通にまともな実装で組んだ場合は、switchのほうが速いってことだ。
ほんとに日本人か？

if分で分岐が最強なのは常識。

>>836
各caseに単一の機能しか持たせないんなら、switchのほうが見易いな。
でも、例えばVMが実行時にデバッグモードとプロファイルモードと通常モードを
切り替えたりしたい場合はどうする？
オブジェクトにしたほうが断然やりやすいね。命令単位でモードを切り替えることすらできる。

ちなみに配列の初期化うんぬんはソースコードを自動生成すれば済む話だね。

>>844
あのなあ、オブジェクトにするかswitchにするかは、ケースバイケースってのは、俺の持論なんだよ。
お前の持論は、switch不要だろ。

>>836にオブジェクト指向設計は無理、ということが証明されますた。

>>845
コテハンに戻しなよON GOTOの好きな逝って良しの１タン。

>>842
逆じゃないのか？

普通にまともな実装でswitchを使って100000caseの分岐をやってみてくださいな。
意図的にやろうがやらまいが、配列を使えば定数時間で済むが、
switchを使って配列より速くするのは大変だぞ。よっぽどカリカリやらんと。

お前は単に、ソースが長いからオブジェクトにしたんだろ。
その結果、オブジェクトの粒度が細かくなり過ぎて、メンテナンス性・可読性が落ちた。
ソースの長さなんてのは、考慮の一項目にすぎない。
絶対的なもんじゃない。

>>845
俺の持論も、815に書いた通り。何をやりたいのかに応じて適切な方法を取れ。

>>848
普通に２分木つかえっての。

いろいろ忙しいから、俺は逝くぞ。
また今度来たときかまってやるよ。

>>849
とりあえず>>844読め。
お前は自分が見慣れたスタイルじゃないと「メンテナンス性・可読性が落ちた」と言い出すアフォなのか？

>>852
戻ってくる前にちゃんとアルゴリズムと言語設計と国語の本読んできなさいね。
宿題しない子は先生叱りますよ (藁

２ちゃんねるだと、人はなぜ、こうもお互いに罵りあえるのだろう・・・そんな思いに駆られた、この夏。

俺の「疲労コンパイラ」が原因でこんな騒ぎに・・・。

騒ぎ？見慣れた矩形いや光景だけど

>>856
むしろチミの存在が原因。

>>855
まあ、「またーりモード」から「罵りモード」へは一方通行な場合が多いからな。
よほどいいタイミングで「またーりいこうぜ」が出ない限り。

昔、人々が神を敬う気持ちを忘れた時代がありました。
その国の王はバベルの塔という巨大な塔を作り、神に挑戦しようとしました。
神が怒り、人々が互いに異なる言葉を話し、互いに通じないように呪いを
掛けました。人々は互いに争うようになりました。

で？

つうわけで、言語乱立はエホバ神の呪い。

　　　　　　こ　こ　で　も　オ　ナ　ニ　ー　全　開　!!

プログラミング言語の場合は人の欲望だと思うが…

人の欲望っつーより、技術の進歩だろ。

欲望が技術を進歩させる。

技術の進歩もそうだけど目的への言語適性だろ。

C#はM$のオナニーだろ。

>>868
いや、Javaキラーのつもりで作ったのが、そのまま歴史の闇へ…

>>867
そうそう。目的に適した言語選びが必要だから、色々な言語が生き残る。

ドーキンジアンのいるスレはここですか？

なんかこのスレみてて思い出しました
唯一正しい答えはないのに
みんなが
「僕が正しい、アイツは馬鹿」
って言い合ってるっていう話を。

ﾌﾟﾌﾟｯですね。

答えが無いから罵り合えるのだよ

仕事で2chに来るやつなんかいないだろ（ﾜﾗ

負け犬の遠吠えは哀れだぽ･･･猫で良かったぽ

木の上に笑う猫がいた。
その姿がだんだん薄れて行った。
やがて猫は消え、笑いだけが残った。

不思議の国のアリスに出てくる猫の話だが、この概念を理解できない奴にＯＯは無理。
（ちなみに作者のルイス・キャロルは数学者で本も書いている、小説は趣味）

>>876
> 不思議の国のアリスに出てくる猫の話だが、この概念を理解できない奴にＯＯは無理。
"概念を理解できない奴"は"ＯＯが無理な奴"だと言うのか。
それはちっとも同じではない。もしそうならこうもいえる。
「"食べるもの"を"見る"」と「"見るもの"を"食べる"」が同じである。
また、「"手に入るもの"が"好き"」と「"好きなもの"が"手に入る"」が同じである。

>>877
同じですがなにか？

頭の回転が速い人(≠成績が良い人)は、例を上げるのが旨い。
>>877 は頭に油を差しなさい。

>>879
油といってもいろいろありますが、何がいいですか？
菜種油、ひまし油、ミシン・オイル、CRC-556、バルブ・オイル？？？

switchで書いたらジャンプテーブルに最適化してくれる
処理系だったらよかったのにね。

"概念を理解できない奴"は"ＯＯが無理な奴"だと言うのか。

量子力学の解釈問題は未だに議論されているが
半導体はいたるところにあふれている。

>>876
笑うのは猫だけではない、ということならＯＯの抽象化だね。
面白い。

代替スレ上げ

いちおう言っておきますが、オブジェクト指向をやると
女の子にモテモテでヨット別荘も夢ではなくて家内安全・開運・子宝に
恵まれるという噂が一部に流れていますがデマです。信じてはいけません。

教養の差って面白いな。

VBしか書けない人、というのを相手にすることが多いのですが、
そういう方たちに Cを学ばせる苦労ってのは、
じつは Javaを学ばせるよりタイヘンなんですね。

Javaとしてきれいに書かせるのは 確かにタイヘンなんですが、
少なくとも動くコードは書けちゃうわけです。

Cだと 動かせるようになる前に 仕事を辞めちゃうかも、
ってぐらいもがき苦しんでしまうようです。

最終的なマスターまでのコストから見たら、
どちらもそう変わらないと思うんですが、
Cのほうが 最初の山がきつすぎるようです。

システム管理からいうと、
最初の設計に制約をきつめにいれておくと
Javaでもきれいに作ってもらえるみたいです。
構成をがちがちに決めてやると
ソース眺めるのも大して苦痛ではないと。

要は 開発の運用方法に依存するってことで。
当たり前の結論で すんまそん

>>887
JavaとCは一緒だろ。

ポインタ＝参照

な訳だし。

クラスの中にmainとか言うエントリポイントを強要される時点で汚いし。
まぁ、誰かが用意してくれたクラスライブラリがあるというのはJavaだけか。

>>888
アフォですか？

>>889
自分で書いた文章ながら改めてみたら痛すぎた。
申し訳ないです。

だからさー、型変換できない時点でポインタとは違うんだってば。

基底で言えることは全て、派生でもいえる。

>>891
プリミティブ型は参照に取れない。
あくまでオブジェクトが対象。
ってことは親の違うクラスに型変換する必要はないわけであって・・・

>>888
目的は一緒でも使い勝手と安全性は
フィリップスの電気髭剃と床屋の剃刀くらい違う

>>894
つーか初心者にCのポインタを使わせるのは
鉈で髭を剃ろうとするくらい危険だと思う。
# スタックとヒープの違いもわかってなかったりとかね。

>>893
ポインタ演算もないしな。このあたりは安全性だけでなく最適化の妨げにもなってる。
例えばエイリアス解析とか、ポインタ演算があるだけでもうダメダメ。

>>1
戦場では必要ありませんじょー

とか言ってみるテスト

ポインタがいらないって言ってるヤシは
「俺は足し算できるから掛け算要らない。掛け算は間違うと危険だ。」
つうヤシと同じだな。

ちげーよはげ

>>899
しっ。　みちゃだめ。

>>898
なんかおまえ微妙にダサいな
「俺は引き算できるから割り算は要らない。割り算は間違うと危険だ。」
というならまだちょっとアリかなと

「割り算は間違うと危険だから、逆数をかける」は？

ポインタはいらねーけどあの使い方は必要じゃねえ？

ポインタが無いと生きて行けませんよ、わたしは。

ポインタは素人にはお勧めできない。
ってここなんのスレだよ（藁

>>905
以降、「ポインタは戦場では必要なし！」について語ってくだされ。

ポインタは必要だよ　JAVAで関数ポインタが使えなくて妙な苦労させらてからJAVAは忘れたし

>>907
別に関数ポインタが使えなくても、ポリモーフィズム使えば問題ないだろ。

>>907
Javaでオブジェクト指向しない方が変です。

フィリップスの電気髭剃ってそんなにお手頃な使い勝手なの？
C のポインタが床屋の剃刀で Java の参照が電気髭剃という例えには烈しく同意。

プロの道具は使いこなせれば細かい部分で融通が利くけど
(例え使いこなせる人でも)忙しい朝のしたくの時に使うもんじゃない。

>>908
うん結局オブジェクト参照を関数ポインタ代わりに使えば解決する事がわかったんだけど
それは自分のスタイルには合わなかったんだ

携帯Ｊａｖａではいちいちクラス作れるほどメモリが無いのだ。

>>912
あんな環境を引き合いに出してJavaを語ったりするなよ。

逝って良しの１を見てると悲しくなるのは私だけですか？

愚かな。
Ｊａｖａが実際に役に立っているのは携帯とサーバーサイドだけ。
二大用途の一方を「あんな環境」などと言うのは自己否定に等しい。

役に立ってるというか選択肢がないというか

「C か Java が選べます」って言われて現状の環境の制約で
Java を選ぶのは真性厨房だと思う。
(携帯でちゃんと使える形式の) JVM のバイトコードを吐く
C コンパイラが欲しいよ。

>>915
>愚かな。
> Ｊａｖａが実際に役に立っているのは携帯とサーバーサイドだけ。
> 二大用途の一方を「あんな環境」などと言うのは自己否定に等しい。

いつもお馬鹿な逝って良しの１ だけど今回は禿げ同だな。
Javaと名乗った以上、OOPLとしての完成度とか、Javaが本来目指してたはずの
WORAとかで突っ込みいれられるのは当然。
それが嫌なら改名しろっての。

>>916
ハァ？
ネイティブコード吐くJavaコンパイラじゃなくて、Javaバイトコードを吐くCコンパイラ？
誰が使うんだ、そんなもん。Cの繁雑さでJavaの遅さを組み合わせてどうする。

>>917
現状の携帯のみで評価するのはアフォだと思うぞ。もうちっと先見れや。

>>918
アフォはおまえじゃ
パソコンでも何年たっても駄目なJAVAに
携帯で先なんてあるわけないだろ
もうちっと現実見れや

>>919
君が何をどう遠吠えようが、Javaは携帯でも使われているという事実は動かないよ。
そもそもが「パソコンで何年たっても駄目なJAVA」というが、
マイクロソフトの腐ったOSの上でねマイクロソフトの腐ったJVMが駄目といわれても。
まあ素敵な妄想でも見てろや。

>>920
携帯以外のJavaはどのOSでもどのJVMでも駄目じゃん。

駄目って・・・俺はJAVAはキライだけど「ここは駄目」はいいけど全否定はどうかな

全否定する時はキライとか主観的な表現にしないとさあ　馬鹿みたいだよ

主観も何もないよ。駄目じゃん。

>>920
TRONは?

つーか、大規模なサーバ系のお仕事だったらJ2EEだろ。

>>923
馬鹿じゃん。

Javaが使えない人間ってこんなにいるのかぁ・・・優越感に浸らせてくれてありがとう。

俺の仕事は制御だからJavaなんてどーでもいいし

Java否定してる人はC#も否定するのかな？
どうなんだろ？(w

あと、Javaを否定する人は
・言語としてのJava
・処理系アーキテクチャとしてのJava
・ライブラリとしてのJava
のどれを否定してるのかな、ってのもあるな。

C#も勿論滅びるべき。


・言語としてのJava
　　ポインタ無いからダメ。
・処理系アーキテクチャとしてのJava
　　write once debug anywhereだからダメ。
・ライブラリとしてのJava
　　ＧＵＩ系は自爆で全滅だろ。

C#は、Javaの糞言語仕様と糞GUIを多少改善。
さらに、Delphi的GUIプログラミングで、VB厨･Delphi厨期待の星。
よって、C#はJavaに置き換わる。
ただし、Javaと同じ問題を抱えているため、Web専用言語の域を出ない。

>>932
Javaの問題を改善したんじゃないのか？

ｳﾜｧﾝ
新スレが多ってルー

>>932
どうでもいいが、言語と開発環境ぐらいはちゃんと分けて考えてくれ。
で、C#で改善されたJavaの言語仕様って何なのか具体的に列挙きぼーん。

目立ったところでプロパティとか

アフォは放置するとして、
実際問題として、言語仕様の上でC#はJavaの何が改善されたんだ？

とりあえず、構造体がメソッドを持てるとか？まあそれが何の役に立つかは知らんが、
value typeなオブジェクトっぽい物を作ることでGCの負担を減らしてるとか？

Boxing/Unboxingはまあobject typeとvalue typeの差を埋める上で有効だわな。

他には何かある？

>937
氏ね糞。

>>938
> アフォは放置するとして、
反応するなよ。オレモナー

一番改善されたのは 仕様をM$が握ってる事だな
　このおかげでVBのように最低２年に一度は仕様変更出来る

受託で一度作れば以後もいくらかの収入が期待出来るんだからおいしい。

JAVAだとバージョン違いで動かないとなると、下手したらこっちが悪いように言われるからな

>>937
列挙型がある。
オーバーライドしようとしたが、タイプミスで別のメソッドを
定義してしまったというようなミスが、overrideキーワードにより、
コンパイルエラーで防止できる。
switch文のfall throughのバグが出ないようになった。

言語って徹底的に違うか、ホントにソックリかのどっちかでないと嫌だな

switchみたいに微妙に違うのはホント嫌

Cの頃から何度も何度も何度も何度も何度も指摘されてきた欠点を
直さないで放置する糞言語よりかはよっぽど良いがな。（ｗ

C++マンセー<`ω´>

>>941
enum型とswitchのfall through防止はいいね。
overrideについては、まあそれはそれで便利なんだろうけど、開発環境で対処すべき問題のような気もする。

>>937
デリゲート、プロパティ、インデクサ、多次元配列、アンセーフコード

Java、C#のどちらにしてもこれからはオブジェクト指向言語が
開発の主流になると言う結論がでますた。

オブジェクト指向言語を使う事と、オブジェクト指向する事は別の問題

いつまでもゆうてろって感じ。

>>948
無理してOOしない理由もないがね。