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

もう結論でちゃったんだもん

お疲れ〜というべきかどうか激しく迷う。

「必要なし」といいつつ新ｽﾚ立てる>>1の精神状態が心配だ。

あ〜あ

たっちゃったね

必要ないなら、このスレはこれにて


　終　了

　♪ｴｯﾋﾞﾏﾖﾏﾖｴﾋﾞﾏﾖｰ　ｴｯﾋﾞﾏﾖﾏﾖｴﾋﾞﾏﾖｰ　ｴｯﾋﾞﾏﾖﾏﾖｴﾋﾞﾏﾖｰ
　　　　　　　 　ﾍ　へ　　　　　　 　ﾍ　へ　　　　　　 　ﾍ　へ
　　　　　　　　:| / ／　　　　　　　:| / ／　　　　　　　:| / ／
　　　　　 　　 .;: ":;.　　　　　 　　 .;: ":;.　　　　　 　　 .;: ":;.
　　∧∧,..,.. ;'､., : 、 　∧∧,..,.. ;'､., : 、　　∧∧,..,.. ;'､., : 、
　;'ﾟДﾟ、､:、.: :　;:' 　 ;'ﾟДﾟ、､:、.: :　;:'　　;'ﾟДﾟ、､:、.: :　;:'
　'､;: ...: ,:. :.､.: '　　 　'､;: ...: ,:. :.､.: '　　 　'､;: ...: ,:. :.､.: '
　　｀"∪∪''ﾞ 　　　　　｀"∪∪''ﾞ 　　　　　｀"∪∪''ﾞ

>>7
その表現はOOとしては全く美しくない。
どちらかというと構造化の方に適した表現だ。

オブジェクト指向って
クラスのメンバー変数が
そのクラスの複数のメンバー関数の間で
グローバル変数みたいになって
いかがなものかって思わない？

クラスローカルでスパゲッティーになる危険を
孕んでいるような。

メンバー変数の頭にアンダースコアとか付けて
区別して注意してるコードとかよく見るけど。
そういう工夫が必要なこと自体
Ｏｂｊｅｃｔ指向の欠陥を意味しているのでは？

>>9
なにを言ってるのかよくわからん

>>10
ひとつのクラスにおいて
メンバー変数はメンバー関数間で共有するでしょ？

>>9
その質問、漏れには釣りかネタにしか聞こえないが。

と優香、構造化のグローバル変数が危険といってる時点で
プログラマ失格というか、もう一度C言語からやり直しって感じだよな。
んでもってOOでも同じようなこと言うなんて、恥の上塗り。
というか、グローバル変数が云々っていうのはすでにOOとは
関係ない低レベルな話。
いいかげんにしてください。

まぁ、もしかすると>>1の狙いはこういうことだったのかもしれんが。

共有できるよ

>>9
ﾒﾝﾊﾞ変数を管理する能力が欠けてる>>9がOOを語る資格無し。

でも、共有するべき値なのか
共有すべきじゃない値なのかは考えることが必要。

>>12
いや釣りじゃないんだけど。
つまり構造化とオブジェクト指向の
見解の相違なのかな？

スコープにプレフィックス付けるのはいまや常識

>>12

なんで“優香”と変換されるのか、小一時間、問い詰めたい。

>>12
＞と優香、構造化のグローバル変数が危険といってる時点で
＞プログラマ失格というか、もう一度C言語からやり直しって感じだよな。

危険じゃないっつーこと？

いや見解の相違じゃなくて…
たぶん、あなたはオブジェクト指向（この場合言語だろうな）をどうのこうの言うにはまだ知識が足りてない。

>>16
いやぜんぜん。
構造化だろうとOOだろうと、ｸﾞﾛｰﾊﾞﾙ変数とﾒﾝﾊﾞ変数の意味合いは
似たようなもんだよ。
じゃあさ、ｸﾞﾛｰﾊﾞﾙ変数とかﾒﾝﾊﾞ変数ってどういうときに使うものよ？
たまに「ｸﾞﾛｰﾊﾞﾙ変数は使わずに書け」とかいう房がいるが、そんな
ｱﾌｫは無視ということで。必要だからｸﾞﾛｰﾊﾞﾙ変数があるわけでしょ？

>>18
たまにMS-IMEがﾊﾞｶになって、「有価」と変換されるようになるときがある。

>>19
危険だと？なぜ危険なんだ？
そもそも危険だから使わないってのは本末転倒だと思うが。
それなら、ｸﾞﾛｰﾊﾞﾙ変数とﾒﾝﾊﾞ変数使わずにプログラム書けるのか？

名前に番号付けとこう、と。

２０と２１に見解の相違があるように思える。

http://gatecity.gaiax.com/home/emiko1018/main
初めて先日婦人科検診に行きました。
クリトリスや膣口を念入りに消毒され、先生が指を入れてグニュグニュしてきました。
診察なので別にその時は変な感じはなかったのですが
少し時間が長いかなぁと思っていると、先生の指が微妙にゆっくりと
ピストン運動をしていたのです。
私は恥ずかしいのと気持ちいいのと腹立たしいのとが一緒になり
頭が混乱し、固定されていた足をバタバタ動かしました。
すると先生はすぐに指を抜き「ごめんねぇ、もう少しがまんしてねぇ」
と言いながら、ゼリーのようなものをクリトリスに塗り始めました。
もうその時点で膣口付近は濡れてベトベトだったと思います。
下半身がしびれてしまい、すぐにオナニーをしたいような状況でした。
先生は「ここ痒いでしょ、少しかぶれてるみたいだから薬塗っときますね。」
と言いクリトリスを念入りに指で摘みながら揉んできました。
たしかに最近クリが痒かったので納得したのですが
先生は皮まで剥いて激しく揉んでくるので、私は声を抑えるので必死でした。
かなり濡れているのが自分でもハッキリ分かって、お尻に液が垂れる感じがしたとき
「グボボボボ」と音がして掃除機のようなもので液を看護婦さんが吸い取りました。
自分の状況がとても恥ずかしいと思い「先生、も、もういいです」と言いました。
先生は「はいはい、もうすぐですよ」と淡々と言いながらクリトリスを揉みしだいています。
恥ずかしいので絶対逝ってはいけないとして我慢しました。
やっと診察が終わり、すぐにトイレに駆け込みオナニーをしました。
１０秒ほどで逝ってしまいました。
翌日、会社の同僚にこのことを話すと「それ絶対変だよー、そんなことする医者いないよ」
と言われました。あの医者はやはり私で遊んでたのでしょうか、とても悔しいです。
このカキコに文句があれば掲示板へどうぞ。

>>21
あごめん。
>>16じゃなくて>>19ね。

9さんは自分の書いたプログラムをよくながめてください。
たぶんあなたのクラスは巨大に肥満しています。

そのクラス名とまったく関係ないメソッドがあり、
特定のメソッドからしか使わないメンバ、
特にフラグとしてのメンバがたくさんありますね。
とりあえず、リファクタリングで検索かけて勉強してきてください。

>>24は
アンチOOかOO厨かはわからないが
PHPユーザーにちがいない

…ﾊｧﾊｧ
>>19
グローバル変数が危険ということじゃなく
staticとかprivateとか、そういうことを考えずに変数つくっちゃう人が危険なの。
変数とか言語に罪はないのよ。

おめーら過去スレのURL貼れよ

管理できんのならクラス内にクラスでも作るとか。

>>29
ロンブー的にいうと、まわりをもっとよくみろ。

9 が言及しているのはオブジェクト指向ではなく、C++だろう？
ＯＯＰＬとしての C++ がイマイチなのはいいとして、ＯＯＰＬは
どうあるべきだと思うのかね。

つーか結局スレ立ったのな。

>>28
goto文は有害だがな

>>32
OOPLつっても種類は多いからな。
関数型ベースなのもあれば、論理型ベースなのもある。
同じ手続き型ベースでも、JavaとEiffelじゃあ狙いが全然違うし。
あと、Modula-3みたいなのをOOPLにカウントするのかという問題もあるし。

「大域変数が有害」とか「goto文は有害」とか主張したい貴方は、
↓のスレで続きの議論をどうぞ

【構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは戦場のﾒﾘｰｸﾘｽﾏｽ 】
http://pc3.2ch.net/test/read.cgi/tech/1030039898/

>>34
ボケが、新スレ立ててんじゃねーよ。

ﾊｧｰﾝ？

>>22
グローバル変数を使わずに、構造化プログラミングは書けるよ。
メンバー変数を使わずに、オブジェクト指向プログラミングは書けないよ。

たとえばC言語だと
main関数をルートに全ての関数がツリー状になるから、
main関数以外の全ての関数にグローバル変数用の引数があればいい。
具体的に書くと、

int A;

main()
{
sub1();
sub2();
}

とする代わりに

main()
{
int A;

sub(A);
sub(A);
}

とする。

>>22
> そもそも危険だから使わないってのは本末転倒だと思うが。

そんなことは無い。
goto文はあってもよほどのことが無いと使わない。
グローバル変数も同じ。

３８は１９です。

>>22
グローバル変数が危険じゃないなら
関数に引数なんていらないだろ？

別に使うなとは言わないけど
グローバル変数は少ない方が、プログラムが
ややこしくならいのは自明だと思うんだが。

>>37
訂正

>main()
> {
> int A;
>
> sub(A);
> sub(A);
> }
>
> とする。
>

main()
{
int A;

A = sub1(A);
A = sub2(A);
}

もしくは

main()
{
int A;

sub1(&A);
sub2(&A);
}

で、結局何が言いたいかと言うと
構造化プログラミングとOOPでは
当たり前だけど、ポリシーが違うと。

で、違うと言うと、
そんなことは無いという人が
必ず居て俺は混乱してしまうのです。

OOPはオブジェクトのために
クラスローカルで共有できる変数を許した。
そうしないとOOPできないし。
でもそれは原理主義的構造化から見ると
ポリシーを緩めたことになる。

>>41
スタックが溢れたらどうするですか？
予めスタックサイズを増やしとくですか？
関数内でstatic変数を使うですか？
それとも動的にメモリを確保するですか？

>>42
あなたはグローバル変数やgo toが許される言語仕様のもとでは構造化プログラミングはできないよ〜
とでもお考えか？

構造化の定義から始めないと。もともと構造化って
連接、分岐、繰り返し、だけを使うって奴だよな。

>>37
てめえ！何でもかんでもCで例えるんじゃねーヴォケが！
たまにはPascalとかawkとか使え！

>>41
> A = sub1(A);
> A = sub2(A);
> }
>
> もしくは
>
> main()
> {
> int A;
>
> sub1(&A);
> sub2(&A);

Aが構造体だとさあ
上のやり方だと効率悪すぎて下のやり方にするだろ？
そうすると、はっきり言ってそれ、オブジェクトの一歩手前じゃんすか

>>40
> グローバル変数が危険じゃないなら
> 関数に引数なんていらないだろ？

いや、そうすると再帰が…

あああぁぁぁぁ>>19さんむちゃくちゃですぅぅ〜
貴方は反グローバル（変数）主義者なのですか〜

そりゃ構造化でグローバル変数使わずに書くことは可能です。
しかし、そんな効率悪いこと普通しませんよね？
上のほうに書いてある効率悪い構造なんて、現実書けませんよ。
いや、趣味でやるなら別ですけど。

そもそもなぜグローバル変数なるものがあるのか、考えたことありますか？
使用すべき用途があるから、わざわざ用意されてるんでしょ？
「危険」と言ってるのは、経験が浅いまたは下手であるといういいわけでしか
ありません。
というか、グローバル変数の「用途」については誰もかかれてなので
そこのところの認識があまいとしか思えないのですが、つまりは
プログラム全体の「状態」を表わす値としてグローバル変数を使うんでしょ？
もし「状態」を気にしなくてもいいプログラムがあるなら、それは前世代的な
バッチ処理とか、ｽｸﾘﾌﾟﾄとかいうものです。
同様に、OOでも、クラスというのはオブジェクトなのだから、状態があるわけです。
その状態を示す値としてﾒﾝﾊﾞ関数を使うんですよね。

>>49
> もし「状態」を気にしなくてもいいプログラムがあるなら、それは前世代的な
> バッチ処理とか、ｽｸﾘﾌﾟﾄとかいうものです。

前時代的かどうかは知らんが、
関数型言語では「状態」を気にしなくていいことになっとります。

> 同様に、OOでも、クラスというのはオブジェクトなのだから、状態があるわけです。

関数型ベースのOOPLではオブジェクトには状態はないです。
オブジェクト毎の「環境」はあるけど、少なくとも変化を伴なう「状態」はない。
詳しくはないが、論理型ベースのOOPLも同様だったと思う。

その上であえて問うが、
> その状態を示す値としてﾒﾝﾊﾞ関数を使うんですよね。
ここで言うメンバ関数ってのは、
インスタンス変数(メンバ変数とも言われることがある)の間違い？

>>50
> 前時代的かどうかは知らんが、
> 関数型言語では「状態」を気にしなくていいことになっとります。
そうですね。関数としては状態を気にしなくていいにしても、
アプリケーションとしては保持しなければならない状態に対する変数が
あるはずです。ない場合もありますが、それはそれでプログラムが簡単で
いいことだと思います。しかし、規模が大きくなるにつれて状態を
気にしなければならなくなりますよ。

> 関数型ベースのOOPLではオブジェクトには状態はないです。
そうです。上に書いたとおりです。

> オブジェクト毎の「環境」はあるけど、少なくとも変化を伴なう「状態」はない。
上にも書きましたhが、アプリケーションの1つの状態として、オブジェクトが保持しないと
いけないものもありますよね。あなたの使ってる「環境」というのがよく理解できないのですが、
なんだか私の言ってるところの「状態」と同じことを言ってるような。

> ここで言うメンバ関数ってのは、
> インスタンス変数(メンバ変数とも言われることがある)の間違い？
すんません。ﾒﾝﾊﾞ変数です。

仕事しよー。

激しくマジメだか妄想だか分からない議論が続いてるな。
ところで、UML使ってる？
漏れは、ころころﾊﾞｰｼﾞｮﾝが変わってるからあまり使いたくないなと
思いつつも、使わざるをえない状況なんだけどね。
どうよ？

1.3準拠で使ってるんだが、またバージョン上がったの？参ったやね〜…。
まぁどの道、無いと仕事にならんよ…。

図の隅に
　　「この図はUML 1.3準拠です」
って書いとけば多少バージョン上がっても問題ないかと(ﾏﾃ

>>51
> アプリケーションとしては保持しなければならない状態に対する変数が
> あるはずです。

ありません。

> ない場合もありますが、それはそれでプログラムが簡単で
> いいことだと思います。

いいえ。
例えばオンラインショッピングのシステムをHTTPも含めて全て関数型言語で、
すなわち状態なしで構築した例があります。

Cookieとか仮引数とかURL (ScriptName)に状態保持してもオッケなら、
そりゃ可能でしょうね。

昔のPerl厨でそやってWebフロントエンド書いてる奴いたし、
関数言語厨はDBMSとかレポジトリとかモナドは使ってﾖｼって立場だろーから。

本質的な議論とは思えんが。

>>54
苫米地さんとこの関係者ﾊｹｰｿ

生真面目に書いちゃうけど、こういうことではないの？

どこでアクセスされてるか調べるとすると、、

・クラス内の情報（privateなメンバ変数、フィールド変数）にアクセス　
　できるのは、メンバ関数（メソッド）に限定できる
　（クラス内でどこかをまず探せばいい）
・クラス外からのアクセスをトレースする際は、アクセッサ(setXXX(),
　getXXX())に限定してサーチすればいい

Ｃのグローバル変数を横着に利用した時や、全て関数へのパラメータ渡し
より、トレーサビリティ上は向上してると思う。全てパラメータ渡しにす
るとどこでアクセスされてるか、シーケンシャルに追う事ができるかもし
れんけど、本当に必要な所に辿りつくまで大変じゃないの？
（激しく勘違いしてます？）

問題になるとしたら、既出ですが超巨大なクラスを作ってる場合かな？

クラスのメンバ変数とメンバ関数ローカル変数と命名規約で区別するのは
トレーサビリティの向上につながると思うので、あってもいいと思う。
(javaで書くときは上位クラス変数ならsuper.XXXだし、同一クラス内なら
this.XXXと書くし、複数クラス間で色々な場所で共有したい情報はシング
　ルトン作ってgetInstanceして使うし）

特定の情報にアクセスできるメソッドを集めてクラスを作成して、グロー
バルに共有したり、クラス間でやりとりする情報を最小限にして疎な状況
を作るように促すオブジェクト指向の方が、構造化設計より進歩してると
思うのですが、教科書レベルでしょうか？


・設計におけるオブジェクトの責務分配に有効なものさし　凝集度と結合度
　http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html
・SCだより
「ソフトウェア開発201の鉄則
　設計の原理73カップリングとコピージョンをつかえ」
　http://village.infoweb.ne.jp/~fwgf2942/SCNews/hpblock96/SCNews96.html#anchor830805
・キーワード(凝集度と結合度)：
http://village.infoweb.ne.jp/~fwgf2942/KeyWords/KW.Coupling.html

長すぎて省略されちゃったから、リンク先だけもう一回

・設計におけるオブジェクトの責務分配に有効なものさし　凝集度と結合度
　http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html
・SCだより
「ソフトウェア開発201の鉄則
　設計の原理73カップリングとコピージョンをつかえ」
　http://village.infoweb.ne.jp/~fwgf2942/SCNews/hpblock96/SCNews96.html#anchor830805
・キーワード(凝集度と結合度)：
http://village.infoweb.ne.jp/~fwgf2942/KeyWords/KW.Coupling.html

いきなり、変な話振っちゃって申し訳ないんだけど
C++等のクラスって、わかりにくいと思わないですか？
ひとつのクラスにズラーとメンバが並んでいて、
ズラーとメソッドが並んでて、各メソッドの実装で
m_bTrueとかm_dw○○○とか突発的に出現したりして、
メンバを1個2個という単位では理解出来ず、まず全体の構成を頭に入れなければ
駄目というか。
引数数十個とか冗長になろうとも、個々の関数がそれぞれ独立完結している方が
理解は早いんじゃないかなぁと最近思ったりするんですが。

>>59
> ひとつのクラスにズラーとメンバが並んでいて、
当たり前。
> ズラーとメソッドが並んでて、
それが普通。
> 各メソッドの実装でm_bTrueとかm_dw○○○とか突発的に出現したりして、
お前がよく分かってないだけ。
> メンバを1個2個という単位では理解出来ず、まず全体の構成を頭に入れなければ
> 駄目というか。
当然。
> 引数数十個とか冗長になろうとも、個々の関数がそれぞれ独立完結している方が
> 理解は早いんじゃないかなぁと最近思ったりするんですが。
お前の脳内と一緒にしないでくれる？

Ｃｏｃｏａ---------

>>60
夏厨ですか？
別に理解出来ないとは言ってないよ。
理解し辛いと言ってるだけで。

人のソースコードは読みがたいので、
人のソースコードは糞です。

>>62
いや別に夏休み欲しいくらいですね。
もうこのレベルだと、典型的な初心者というか、Cが一通りできれば
C++ができると勘違いしてるレベルなので、相手にするのもいやなんですが、
一応今暇なんで簡単にレスしてみただけです。

>>64
可読性のことを俺は言ってるのよ。
クラスつーのはどっちかってーと
オブジェクト指向に沿って再利用性を高める為に
あるようなもんだろ？
それともクラスにすると可読性が上がるとか、定説になってたりする訳？
つまり、ある機能を有するクラスがあったとして、それと同じ機能を関数群で実現出来たのなら
そっちの方が可読性は良いんじゃないかとふと思った訳。
まあそんなうまくいかないからクラスなんかが出来たつーのはわかってるけど。

>>65
関数群＝クラス

>>59
それ読んだ限りでは、それはC++というよりMFCなんじゃないの？
1つのクラスに沢山のメンバを並べるのって、C++的にもお行儀がいいとは思わないけど。
継承の結果、メンバが沢山になることはあるけどさ。

>>57
Cにはファイル内static変数っつうもんがあるから
それはOOの利点ではない.

Cで真のグローバル変数(staticじゃないやつ)を使うなどと想像するのは
OO厨だけだと思われる

>>68
> Cで真のグローバル変数(staticじゃないやつ)を使うなどと想像するのは
> OO厨だけだと思われる

まだまだ残暑が続くねぇ。
つーか、君、マジですか？

>>69
９９.９％使わないに言い換えるよ

>>65
可読性はどちらかというとﾄﾞｷｭﾒﾝﾄの問題であるような。
オブジェクト指向はﾄﾞｷｭﾒﾝﾄ命といいつつも、あまり読みやすいのが
ないんだよね。特に紙に印刷してるのなんて最悪。

>>70
マジですか？

>>68
グローバル変数のことを言ったのはまずかったか。

メンバ関数間でクラス内変数を共有可能にしてるのは、進歩じゃない
という９の主張がオカシイというのが本論で（68でも、ファイル内
スタティック変数の利用を言われてますし）

グローバル変数を一切使わないで、全てパラメータ渡しにするのも、
ウザイというか煩雑？　密に結合する所と疎にする所の切り分けさえでき
ればいいと言いたかった。

Ｃのベテランプログラマが上記をさりげなく習慣的にやれてしまう所を、
ＯＯ言語では言語機構上強制したり、促したりするのかなあと言いたい。
（せっかく与えられた機構をダメにするように肥大化したクラスを作成
　させたり、クラスの切り出しをおかしくして、アクセッサメソッドの
　フォワーディングみたいなんが極端になると、結局無意味だけど）

>>73
> Ｃのベテランプログラマが上記をさりげなく習慣的にやれてしまう所を、
> ＯＯ言語では言語機構上強制したり、促したりするのかなあと言いたい。
いいことじゃん。

>>73
>Ｃのベテランプログラマが上記をさりげなく習慣的にやれてしまう所を、
>ＯＯ言語では言語機構上強制したり、促したりするのかなあと言いたい。
これもまた違う
Cはたまたまstatic を強制していないだけで､グローバル変数のスコープは
デフォルトでstaticにするような実装でもかまわない.
それをもってしてCが糞だというならいいがOOの優位性とは関係がない

要は「変数のスコープは狭いほうがいい」というだけのことだ.

前のスレにもあったけど、どうしてOOと独立した概念をOO固有
のものだと勘違いしてしまう人が多いのだろう?

>>75
>前のスレにもあったけど、どうしてOOと独立した概念をOO固有
>のものだと勘違いしてしまう人が多いのだろう?
OOをキチンと理解していないから。

>>75
勉強不足ですんまそん。自分の文章ツッコミ所だらけなんだろう。

>>76
まあたしかにそうっすね。

メンバ変数間の情報共有が危険とか、全てグローバル変数をなしにして
パラメータ渡しにすればいいという話に対して、違うんじゃない？？と
自分が言ってる部分は問題ないっすか？（もう終わったネタ？）

ドキュメントさえあれば可読性はさほど問題ではないと思われ。

>>78
ドキュメントはあっても可読性が低いのは糞。
ドキュメントはソースコードには入らない部分(背景説明など)を記述するのみにして
ソースコードを読むべき所はソースコードの可読性を上げることでドキュメントの代りとするべき。

>>79
同意.

結局OOの勝利で幕引きか。

結局、ＯＯは「状態」を持つプログラム向け、
構造化は「状態」を持たないプログラム向け
ってことでいいのですか？

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
上のようなまとめをすると
まとまるものもまとまらないという例
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

　　　　　　　　　　　　 ／￣￣￣￣＼　　 ＿＿＿＿
　　　　　　　　　　　／　／￣￣ ￣￣ヽ／∵∴∵∴＼
　　　　　　　　　　　|　　|　　 ／　　＼　|∵∴∵∴∵∴＼
　　　　　　　　∫　 |　 / 　　　　ﾟ　ﾟ　　 |⌒ 　　⌒＼∴∵|　うきえさ〜ん
　　　　 ／￣￣￣＼(6　　　　　　ゝ　　|(･)　　(･) 　ヽ∵｜
　　　/　　　　　　　　＼　　　＿＿＿ ｜ ⊂ 　 　 　 　　6)
　　 /＼　　 ⌒　 　⌒ ｜　　＼＿/／ ＿＿＿ 　　　　/
　　｜ ／ 　　(･)　　(･)｜＼＿＿_／ ＼ ＼＿/ 　　 ／
　　(6-------◯⌒つ ｜-　- 　　⌒＼＼＿＿＿_／
　　｜　　　　＿||||||||| ｜非　｡ ⊆､＼　＼＿　⌒ヽ
　　　＼　／　＼＿/ ／八　 彡/＼ /　/＿＿＿/
　　　　 ＼＿＿＿_／　 ⌒　　 ／ ￣ ＼　　　 　/
　　　／⌒ 　 　 　 　⌒＼　／　　⊆ヽ 　）ヽ　／
　 ／　人　 人 　 　ﾉﾞ＼　＼　 ／　　|　/＿ノ
　 ＼ ＼|　　l　　　 /／　／ 　　　　（_､＿）
　　　＼⊇　ﾉ 　 　 ⊆／
　　　　（ 　　Y　　 　）

>>82
そもそも状態を持たないってのはマクロとかスクリプトのレベルじゃねぇの？

お前らほんとに素人レヴェルだな

ＯＯの人、これは構造化ではエレガントには書けまいという
短めのプログラムを書いてくれ。
それを俺（か誰か）が構造化でエレガントに書けるかやってみよう。
ＪａｖａかＣ＋＋でおながいします。

>>85,82
両方とも勘違い
状態を持たないっていうのは
const int A = 3 ;
とか
#define A 3
とか見たいな、一回設定したら変化しないものの事
関数型言語は変数がなく、全部これだけで組んである、一度みれ。

>>88
関数型言語も状態を持たないプログラマ向けってことか。

>>89
わけわかんねぇな、とりあえず関数型っていうのは
強靭な論理を使うのに適しているっていうだけだ、
バグに対する徹底した対処ができるのが特徴。
それだけ、プログラマは関係ない、目的が何なのかということ。

構造化＝状態をもたないって事になちゃーたのかぁ、このすれ。
んじゃ、Lispは純関数言語に昇格ぅー(Lisper喜べ、屈辱の日々は過ぎ去ったぞ

>>91
ｱﾌｫ

ちょっと先走りすぎた、
Lisp の手続き実行関数 PROGとかって、
再帰ﾏﾝｾｰなLispに 手続き型言語とか構造化の流れを取り込んだものだよね、
っつう同意が前提ですた。

>>90
強靭な論理を扱う関数型言語ってなんですか？
論理関数言語の刷れの人ですか？

schemeとかLispの関数型言語と、Java,Eiffel,C++の
OO言語とは対立するものなんですか。

>>87
即興で書く
マップに基づいてプレイヤーが迷路の中のゴールを目指す。
プレイヤーには各ターン毎に不完全な情報が与えられる。
それに基づいて、アクションを決定する。
どのアルゴリズムが最も優れているかを試すのが目的
public interface Player{
public Action move(Map map);
}

public class Game{
(メンバ省略）
public void start(){
while(true){
Player player=playerList.RandomSelect();
player.move(makeMap());
}
}

意味わかるよね？

まあ、JAVAでもLISPでもCでも同じプログラムが作れる。
言語の優劣を決めるポイントは
読みやすさとか、
どの程度抽象化できるかとか、
デバッグのしやすさとか、
そんなところ。

まあ、LISPも悪くないけど
数式が読みにくいとか、いろいろデメリットはあるよね。
あと、LISPでOOすると読みづらいし。

>>95
無関係が正解。

>>88
いやそういう厳密な学術的な意味での「状態」ではなく、
>>49の文脈における「状態」なのですが。

>>99
まあでも結局両方とも同じですが。

>>97
＞まあ、JAVAでもLISPでもCでも同じプログラムが作れる。
わけで

結論は「必要なし」となるわけで

>>97
＞読みやすさとか、
＞どの程度抽象化できるかとか、
＞デバッグのしやすさとか

それらが定量化できない主観的基準であることに
議論が平行線を辿る問題の本質があると思われ

でもそれを推し進めると構造化すら「必要なし」となるわけで

ゴージャス松野
↓

>>104
更に、アセンブラでいいじゃん、マシン語でいいじゃん、となるわけで。
でも、ここまでくると明らかにおかしいわけで。

何言ってるんだ？
便利だから必要だろ。

必須じゃないけど。

>>88
それは状態じゃなくて「定数」だろが。
状態って言うのは、例えばGUIならば、ウインドウが閉じてるとか
開いてるとかいうことだろ。

構造化 → やっつけ仕事用 → ﾉｰﾐｿ使わなくても適当に書けば
どうにかなる → あとあとの保守が・・・ｱﾋｬ！

>>108
変数でもウインドウでも事情はおんなじじゃねぇの？

>>110
「変数」と言ってしまえば同じだよ。

例えば構造化の関数は普通、引数のみを変数として処理するわけでしょ？
でもオブジェクトは、それに加えてオブジェクトの状態も変数として
とるわけ。
まぁ構造化でも、ｸﾞﾛｰﾊﾞﾙ変数は一用途として、そのプログラムなりアプリなりの
状態を保持するものとしてとして使用されるわけだが。

>>87 短めのプログラムっていうのからはずれるが
OO使わないですむエレガントなマルチウィンドウのGUIマネージャのフレームワーク（ライブラリ）考えてくれよ。
だいたいのアーキテクチャだけでいいからさ

MSC5時代のＷｉｎみたいにメッセージループ＆巨大スイッチ文は明らかにダサいし、
そうでなければ
ウィンドウやコンポーネントのハンドルとコールバック関数を使いまくって
ＸみたいにＯＯもどきをやる以外に道はないとおもうんだが。

それなら素直にちゃんと設計されたＧＵＩクラスライブラリ使ったほうが
いいとおもうがどうか？

なんでそんなわかりにくい例なんだよ（ｗ
もちっと抽象的な例挙げた方が、多くの人に伝わると思うけど。

>>97
＞読みやすさとか、
＞どの程度抽象化できるかとか、
＞デバッグのしやすさとか
ここに問題があると思う。読みやすさとでバックのしやすさはわかるが
どの程度抽象化できるかは意味ない。

適度な抽象化はさまざまなメリットももたらすが、行き過ぎた抽象化は
デメリットのほうが多い。

「抽象化」「オブジェクト指向」は最終的にメリットがあるときに行うべきで
決して手段を目的にしてはいけないと思う

>>114
ＯＯが使いこなせてない間はＯＯを適切に使うことも目的になりえる。
で本当の目的を見失って抽象化の階層を増殖させて袋小路にはまって
遊んでいられるのは学生の特権かもしれない。

>>115
まあだれでも一度は通る道。
そう思えばほほえましい限りだけど、5年前とは違って
今のOO中毒者はなんか違う気がするんだよなぁ…

つい調子こいて書き込みすぎたけど
要するに「ＧＵＩ関係はＯＯでないとつらい」っていいたかっただけ。

小さなコマンドプログラムとシェルだけで完結した世界とかなら
「ＯＯいらねー」って思ってしまう気持ちもわかるけどな。

>>117
決してOOいらねーなんて言うつもりないけど

>要するに「ＧＵＩ関係はＯＯでないとつらい」っていいたかっただけ。
これはどうかな？
VBみたいにリソース至上主義のほうがJavaでSwinｇするより保守も
作るのも簡単だよ.

> VBみたいにリソース至上主義
？

>>119
ヴビ厨にいちいち反応してんじゃねーよ

>>120
あれをVB厨だと判断するのか。ﾔﾚﾔﾚ

>>121
おいおい、>>118はコンポーネントを使う事しか考えてないだろ。
そこがヴビ厨だってんの。

VBのコンポーネントを作るにはOOせざるを得ないんだから、
結局は「GUI関係はOOでないとつらい」になるだろ。

>>122
「OOでないGUIは使いづらい」とも言える。

>>122 コンポーネントを作るのにOOしなければならないなんて誰が決めたの？

VBのコンポーネントはActiveXで 単に関数ポインタを渡してるだけという見方もあるのに

>>124
ﾜｹﾜｶﾗﾝ

みんなすげーな。「VBみたいにリソース至上主義」の意味がわかるんだ。
VBってリソース至上主義だったのか？ ってそもそもリソース至上主義ってなんだよ。

>>124
「コンポーネントの設計がOO」であることと、「コンポーネントの使用時に
関数ポインタ渡す」というのは別に矛盾して無いと思うけどな。

>>126
いやわけわからんで無視してるだけ。
または適当にかわしてるか。

VBのGUI関連はオブジェクト指向だろ。

>>126
VBでぺたぺたお絵かきしてるのはBasicのコードじゃないでしょ？
何らかの形のリソースになってんじゃないの？
#実はVBはほとんど触ってないのでVCからの推測になってるけど
反対にSwingの場合はJavaのコードの中だけでGUIを書こうとしてる。

それとVBのGUI部分の実装がOOかどうかは関係ないぞ。
使ってるユーザーからすればぺたぺたお絵かきしてハンドラかいてるだけ。
それを「OO技術の上に構築されている」というのなら全ての言語は
「マシン語の上に構築されている」になっちゃう

>>118 VB取っ掛かりは楽だが
保守はかんたんじゃないぞ

フレームワークみたいな指針がないから
コードがぐちゃぐちゃになる。

じゃあきちんと設計して構造考えてやればよいじゃんて事になるが
「つくればよい」と「最初からある」の差は大きい
そういった類のルールをチーム全体に周知徹底させるのがどれだけ大変か。

メジャーな言語や開発環境に最初からフレームワークがあれば
プロジェクトの始まるまえから知っている事を前提として始められる。
（知らん奴は「XXの本読んどけ」ですむ。
「あるいはXXで開発経験ある人」で最初から人集めできる
コードレビューするにしても説得力が違う。）

で、問題はＧＵＩのフレームワークが
ＯＯ使わないでエレガントにできるか？てことなんだ。

>>122
残念だったな。VBではあまり使われない、しかしVCでは良く使われる
リソースと言う単語。それをVBと組み合わせて使っているところから
VBに疎いがVCは使っているという推理は無知な単純バカには無理だったか。
信じないのは勝手だがこれは後付けではない。

>>130
VBのGUI部分の保守は楽でしょ？
コードに変更を与えずに(バグを出す心配なしに)レイアウトやら
ボタンの大きさなんぞを変えられる。
#もちろんVBでビジネスロジック書いたりしたら保守が大変なのはわかるけど

Swingで(JBuilderなしに)作ったアプリはそうはいかんのよ。
ボタンの大きさかえるだけでもコードを触らなくちゃいけなくて、
常にバグの危険性が伴う。

>>129
> 何らかの形のリソースになってんじゃないの？
> #実はVBはほとんど触ってないのでVCからの推測になってるけど
> 反対にSwingの場合はJavaのコードの中だけでGUIを書こうとしてる。

？？？
あいかわらず「リソース」という単語の意味が謎に満ちたままだよ。

あ、ひょっとしてOSないしはGUIプラットフォームが提供する機能を
使っているだけと言いたい？それがリソース至上主義？

>>132
ひょっいてGUIビルダの事を「リソース」と言っているのか？

http://www2.freenet.jp/muneo/index.htm
超悪徳会社　Ｊ−ＣＯＭ（ジェイコム）の定期点検を大儀名文とした
勧誘営業に困っていませんか？
点検と言いつつ何もせず、結局はインターネット等の契約をして欲しい
の話へもっていく腐れ外道集団。
断ると「テレビの映りが悪くなっても知らんぞ」と脅迫メッセージをぶつけてくる。
苦情は総務省へ直接電話をすること。
マスコミはケーブルＴＶとは仲がいいので、テレビで取り上げることはまず無い。
2ちゃんねるパワーでジェイコムを追い詰めよう！！

>>132
だからさ、それは既存の部品を使うだけの場合でしょ？
VC使ってるって、なんだか君が書いたもの読んでると、
どうもＧＵＩビルダしか使ってないんじゃないかと思えてくるよ。

>>132 は VB と Swing(Java) の話をしてるんじゃなくって、
IDEでの開発とエディタでベタ書きの違いを言っているんじゃないの？ じゃないと

> Swingで(JBuilderなしに)作ったアプリはそうはいかんのよ。
> ボタンの大きさかえるだけでもコードを触らなくちゃいけなくて、
> 常にバグの危険性が伴う。

これってすごくバカ発言に思えるよ。eclipse とか使ってみ。

>>131
で、結局の所、VBコンポーネントでもCOMコントロールでも何でもいいが、
自分でコンポーネントを作る場合の事は全然想定してなかったということで
ＯＫなのか？

ヴビ厨と呼ばれるのが嫌だというのなら、
しょうがないから「グイペタ厨」と呼んであげるよ、グイペタ君。

>>137
ああ、そういうことか。
OOPLとしての技術要素とライブラリの機能と開発環境の話が混ぜこぜになってたわけね。

>>133 >>134
VBの場合はよくしらんが、VCなら.rcというテキストファイルのこと。
このファイルにGUIのレイアウト的なことが書いてあって、適当なAPI
にこれを渡すと勝手にGUIを作ってくれる。
VBも同じだと思っただけで、何の確証もないっす

>>136
そう、既存の部品を使うのにリソース方式は適してる。
カスタムウィジェット作ろうと思ったらOOの恩恵が必要になるよ。
まさに差分プログラム万歳。
でもVBの場合はカスタムウィジェットはどっかからか調達するものだと思うので
結局どんなウィジェットも「既存の部品」でしょ？

>>137
つうかさ、IDE使ってぺたぺたお絵かきして以後の変更も全てIDE経由で
行うなら、実装がSwingだろうがなんだろうがもはや別言語でしょ？
それってOO？
そうやって作った画面レイアウトのことをリソースって呼んでるのよ。

>>140
> でもVBの場合はカスタムウィジェットはどっかからか調達するものだと思うので
> 結局どんなウィジェットも「既存の部品」でしょ？

ウジ虫みたく湧いて出てくるもんじゃないんだから、「既存の部品」なわけないだろ。
誰かが仕様を考えて、誰かがGUIを設計して、誰かが作るんだろ？

>>141
だから、それは開発環境の問題でしょ？開発環境がOO的などうかを問題にしてるわけ？

あと、GUIとOOの相性がいいのは、差分プログラミングの恩恵というよりは
「仮想実体ごとに公開インターフェースを設定していって、
GUI環境は仮想実体に公開インターフェースを通じて操作を委譲し、
実際の動作は仮想実体が管理/実行する」
というモデルが多様なGUI部品を管理するのに適していたからでしょ。

>>142
VB使う人にとっては「既存の部品」でしょ？
誰かが作るんだけど、そのときにOOを目いっぱい使うんだろうけど

逆に質問したいけどVCのようなリソース主義はOOなの？それとも非OO？
俺は非OOだと思っていて、だけど一番有効だと思っている。

>>144
だから、そのリソース主義ってのが何を言いたいのかよくわからんのよ。
GUIビルダみたいな開発環境の事を言いたいのだとすると、
ほとんどのGUIビルダはとてもOO的だと思うよ。
まさに>>143が言っている通りの理由で。

>>143
>だから、それは開発環境の問題でしょ？
>開発環境がOO的などうかを問題にしてるわけ？
端的に言えばYES。でもよく考えてみて。Javaはコンパイルしなくちゃ動かない。
だからといって
・バイトコード生書きと
・Javaで書いてコンパイラーという開発環境を使ってバイトコードにする
この2つを「開発環境の問題」っていう？

>>145
>GUIビルダみたいな開発環境の事を言いたいのだとすると
GUIビルダとはちょっと意味が違う。

プロジェクトの生涯を通して画面レイアウトはコードを編集することなしに、
画面レイアウトを他の言語（そのひとつの例がGUIビルダ）で保守する。

そうなっていたらその画面レイアウトのことをリソースって呼んでる（俺定義だけど）
この定義で言うとSQL文とかPrintfのフォーマット文とかもリソース。
もちろんビットマップとかキーバインドとかも。

>>143
>あと、GUIとOOの相性がいいのは、差分プログラミングの恩恵というよりは
>「仮想実体ごとに公開インターフェースを設定していって、
>GUI環境は仮想実体に公開インターフェースを通じて操作を委譲し、
>実際の動作は仮想実体が管理/実行する」
これをOOといってしまうのはひどい。
これは単にインターフェイスと実装の分離であって、サブルーチン
が発明されたときからあるソフトウェア工学の根本理念だと思うけど。

>>146
当然、開発環境の問題でしょ。少なくともバイトコードの問題とは思えないが。
# ここでのバイトコードが今までの話の中でのOOPLに相当するよね。

>>147
オブジェクト指向開発環境っていう考え方はもちろんあるし、
実はオブジェクト指向を牽引してきたSmalltalk環境はXeroxで開発されてきたが、
Xeroxの狙いがまさにオブジェクト指向的作業環境だったりする。J-starとか。

プログラミング環境でいえば、まさにそのSmalltalkの末裔であるSqueakがそうだし。

> （俺定義だけど）
恥ずかしいセリフを偉そうに言うな。

作業環境ということでいうと、ウィンドウシステムを初めとするGUI環境は
Smalltalk環境から派生してきたといって過言ではない。
操作環境だけを真似したものもあれば、資源の管理も真似したものもある。
ただ、Smalltalk環境ほどの柔軟な拡張性をもったGUI環境は今だに出現していない。

で、何が言いたいのかというと、GUIを使っている以上、
程度の違いこそあれオブジェクト指向的だということ。

>>148
「仮想実体ごとに」がミソなんだよ。

それとも画面上に生成されたGUI部品ごとにモジュールをロードするのか？

>>152
ん？
俺が話してたのはGUI部品を「作る」ときの利便性であって、
GUI部品を実際に生成する時の話じゃないよ。

あなたのほうのその文脈で返答したわけじゃなかったってことか。

あのー、オブジェクト指向でよく見かける、
インターフェースと、その実装(インプル)を分けるメリット
を教えてもらいたいのですが。

>>153
もちろん、GUI部品を作るときの話だよ。
GUI部品をオブジェクトとすることによって、>>143に書いたようなメリットを亨受できるんだよ。
つまり、GUI部品に求められる複雑さの多くはGUI部品をオブジェクトにすることで解決できるんだよ。

>>154
主に可換性だね。
可換性があることで、多態性とか拡張性につながっていく。

>>155
それは違うでしょ。
>GUI環境は仮想実体に公開インターフェースを通じて操作を委譲し、
>実際の動作は仮想実体が管理/実行する」
この恩恵は実装とインターフェイスを分離するという方針の結果であって

オブジェクトにすることの恩恵って言うのは
>それとも画面上に生成されたGUI部品ごとにモジュールをロードするのか？
のように部品ごとにロードしなくていい、てことでしょ？
#これだっていくらでも非OOで実装方法があるけど、OO的であることには賛成する

まあ仮想実態という言葉が下のことも含んでいるっていうのがあなたの立場なんだろうけど、
この2つのことは分けて考えるべきでしょ。

>>154
>あのー、オブジェクト指向でよく見かける、
>インターフェースと、その実装(インプル)を分けるメリット
違う違う。OOとは関係ない
インターフェースと、その実装(インプル)を分けるっていうのはものすごく一般的な手法で、
2chがIEだろうがネスケだろうがかちゅーしゃだろうが同じように使えるのだって
これのおかげ。

HTMLやHTTPというインターフェイスとIEやかちゅーしゃといった実装をわけているから
こんなことが出来る。

コンピュータを離れれば、トヨタだろうが日産だろうがGMだろうが、同じように運転できる
のだって、ハンドルやウィンカーというインターフェイスと実際の車がきちんと分離されているから

>>157
実装とインターフェースの分離をGUI上の各仮想実体(=オブジェクト)に対しておこなうのはオブジェクト指向でしょ？
一方でこれを手続き的に実装したら、GUI上の各仮想実体(=データ)は公開インターフェースを持っていない。
公開インターフェースを用意するのは各モジュールだからね。

もちろん、手続き型言語でもGUI上の各仮想実体ごとに公開インターフェースを設定することも可能だよ。
でも、それは手続き型言語でOOをしているにすぎないし、
それが可能なのは双方がチューリングマシン互換である以上、当然の話。

>>158
そりゃそうだが、>>154が訊いているのは、
プログラミング言語での細粒度な構成単位に「インターフェースと実装の分離」をするメリットでしょ？

こいつらA⊃Bがわからないらしいな。

>>159
Widgetごとにモジュールをロードすれば、普通のDLLやsoでWidgetになるでしょ？
この場合のデメリットは無駄が生じることだけど、それがOOであることの特有の
利点で、可換になることは実装とインターフェイスを分離したという単純な事実
の利点でしょ。

>>162
この人はキーワードだけで語っていて、
そのキーワードがプログラミング言語のどの要素に適用されているかを完全に無視(あるいは無知)してるんだよなー。
ほんと疲れるよ、こういうのの相手は。

> Widgetごとにモジュールをロードすれば、普通のDLLやsoでWidgetになるでしょ？

普通のDLLやsoを多重にロードできるのか？
ボタンDLLを3個とチェックボックスDLLを12個という具合に？
普通はシステム全体で共有されるんだよ。

> 可換になることは実装とインターフェイスを分離したという単純な事実
> の利点でしょ。

だから、その可換可能な要素の粒度を言ってるんだけど、まだわからんのか？

アホにわざわざ文句たれる>>163がｽﾃｷ

そんな暇人につっこんであげてる>>164もｽﾃｷ

つーことは、>>162はアホに認定されました。

つーことは、>>163,>>164はそれぞれ暇でｽﾃｷな人、ｽﾃｷな人に認定されました。

>>165にも何か称号を！

>>167 あたしは？

つーことは、>>165はスレッドレイプstに認定されました。

つーことは、>>169はネカマに認定されました。

1行野郎（一部ネカマ）がいるスレはここですか

>>1からして1行というスレはここです

そうだ！1行で進行しようよ、ここ。ウザイから。

今>>174がいい事言った！

↓がたぶん1行で書かないからすぐにそのルールは崩壊する

何？このスレ

深夜にネカマとは、恐れ入った！

>>177はいい奴だ

>>176を晒しageするスレはここですか

>>180 sage進行でお願いします。

↓唐突にピチョン君登場！

もうどうにでもして・・・

>>183 頑張った

>>183はいい奴だ

>>176がこれで一安心

つーことは、>>182はピチョン君です。

>>183は誰なんですか？

>>183良く頑張った、感動した！

誤爆した>>187を晒しageするスレはここですか

何
で
す
か
？
こ
の
ス
レ
は
？

>>190 sage進行でお願いします。

>>190ageちゃだめな空気を読めない奴。

>>191 こんな深夜に真性リアル厨房登場！

>>191ＯＫなのかどうなのか激しく迷う

じゃあ、特別に縦書き1桁も許可します。

↓斜め挑戦者登場？！↓

も
　　　う
　　　　　だ
　　　　　　め
　　　　　　　だ

許
　可
　　す
　　　る
　　　　の
　　　　　か
　　　　　　よ
　　　　　　　っ
　　　　　　　　！

200げとずさ

やはり深夜だからスピードダウン

じゃぁOOについて語ろうか

>>202 ＯＯ＝んこ　という結論は既に出ていますが？

すげぇ。元スレより活動レベルがあがってる‥‥‥。

自分の彼女のウンコなら食えるって人いる？

>>205 おれションベンなら飲める。うんこはちょっと・・

205=206

>>207正解。マジでションベンは飲んだよ。うんこは食えなかった。

↓↓↓↓さあ、うんこ食えるって人、どうぞ！！↓↓↓↓

>>209
なにか？

オブジェクト指向が悪いとはイワンが
オブジェクト指向を楽に扱える言語がないのがなんだかなぁって感じ
JavaもC#もめんどくせーんだよ

なんだかんだ言っても結局OOは有効って事じゃん。

>>211 君の様な無粋者によって全てぶち壊しだよ。俺のうんこ食え！

>>211
C言語なんかはさらにめんどくさいね。

>>211
楽したい→動的OOだけど効率低い
めんどくさい事やる→静的OOで速いけど柔軟性が‥‥‥

うんこ関係の人はこちらへＧＯ
読心男性です!!ウンコ食べたい　part12
http://salami.2ch.net/test/read.cgi/male/1029087480/

>>216
じゃ、俺は一人で逝ってくるよっ！ありがとっ！

見事なまでの埋め荒らしだな。藁わせてもらったよ。

先生！学校の宿題が終わらないので腹いせに

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

っていうスレ立ててもいいですか？

夏厨っぽく偉そうなコテハンでカキコ

>>219
お前は２行以上書き込むな

>>221おまえもな

難しげなことを難しげに語る奴は実はなにも理解していない、ここはOOについて１行で語るスレです。

1行ずつみんなでポンポン書けば、本家の投稿数抜けるかな？

>>224
ポンポン

ポンポン

pompom

ﾎﾟﾑﾎﾟﾑ？

ﾃｨﾝPOm

みんな疲れているんだね

ポポンＳでも飲んで下さい。

先生！学校の宿題が終わらないので腹いせに

オブジェクト指向は戦場では必要あり７　は必要あり

っていうスレ立ててもいいですか？

>>231　ageるなという空気を首筋に感じてほすぃ

夏が終わるよ、思い出なにも残さずに。

>>208
板違い

結局OOの勝利で幕引きか。
あっけない勝負だった・・・



↑
夏の思ひ出

↑本家でOO厨に吐いてくれ

>>236　他に思い出ないのなら泣いてもいいぜ。

>>237
じゃあ本家に誘導でもしろよ（ｗ
「次スレです」みたいな感じで。

>>239 じゃ、こっち逝けttp://life2.2ch.net/test/read.cgi/jinsei/1030142713/l50

>>240
お前のお悩み相談所紹介されても逝くわけないじゃん（ｗ
毛が無いにしても、もうすこし頭を使ってください。

じゃ、今なら本家はこちら↓

http://pc3.2ch.net/test/read.cgi/software/1019544241/

>>241は逝くわけないじゃんと言いながら逝ってるｶﾜｲｲ奴。

>>244
Jane使ってますので、逝かなくても分かります。

>>244しょぼん

なあこの板にID導入しないか？

>>247だな。

見事なまでに内容の無いレスがつらつらと・・・

誰がヅラやねん

愉快なアンチ諸君、あと残り749、がんばって埋めたまえ (W

この板のたんつぼスレはここですか？

た

ん　

つ　　　　　　　　　　　　

ぼ　　

ポ　　　　　　　　　　　　　　　　　　　　　　　　　　　

ポ　　　　　　　　　　　　　　　

ン　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

S　　　　　　　　　　　　　　　　　　　　　　　

当ｽﾚは

「頂上対決！！　ruby vs. Delphi 」

に変更しますた。

Deiphi万歳

rubyやるよりWSHの方がはるかに役に立ってる漏れは
すでにM$工作員の一味ですか？

始めの方はキチンとしたスレだったのにね

>>9からはじまるレスはへぼい内容ですがいかがなものか？

>>265
へぼい>>9を説得するために皆でレベルを下げすぎたな。

>>266 今じゃ一行スレがお似合いだよ

オブジェクト指向って無意味に複雑だよな。

オブジェクト指向マンセーな奴って
みんな言うことがバラバラだよな。
統一見解が無いってところが
オブジェクト指向の不完全性表している。

>>269
じゃあオブジェクト指向じゃなかったら統一見解があるのか？

>>270
ありません。

>>271
いやそうかもしれんけど
オブジェクト指向は特別ひどいと思わん？

>>87

class OcelloGame{
　　Man man;
　　Computer com;
　　Board board;

public:

　　void start(){
　　　　while(board.judge()){
　　　　　board.put(man.put());
　　　　　 board.put(com.put());
　　　　}
}

>>272
それだけ抽象度が高いってことだろ。
やってることは同じでも実現方法が違う、という。

今回のオブジェクト思考は
理解できるが、納得できない。
前回のは過ぎた事だからいいけど。

>>275
何逝ってるか理解できない。

>>276
どうせ脳内電波が外に漏れただけだろ。
いちいち反応するんじゃねぇよ。
理解できなくて当然。理解できる方がおかしい。

オブジェクト指向が必要かどうかって、
電話が必要かどうかとかって議論と同じだよね。





時代の流れについてこれない年寄りの話は適当に聞いておいてやろう。

今日もDelphiで遊ぶとするか。
今度はタブブラウザ作っちゃおうかな〜♪

オブジェクト指向にはDVORAK配列が必要不可欠です。

ベポラップ？

>>280
確かにアルファベットのタイプは速くなるけど
ショートカットキーが無茶苦茶になって大混乱してしまうので
結局使い物にならなかったよ。

>>280
EmacsでM-/で十分じゃない？