5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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


2 :デフォルトの名無しさん:02/05/15 22:15
OO最高!!!

3 : :02/05/15 22:16
(O_O)イイ!!

4 :デフォルトの名無しさん:02/05/15 22:16
>>1
クラスを実装するのも結構大変だね。

5 :デフォルトの名無しさん:02/05/15 22:17
いまどきOOしなかったらプログラミングできねーよ。

6 :デフォルトの名無しさん:02/05/15 22:23
>>10は削除依頼だしてこい

7 :デフォルトの名無しさん:02/05/15 22:30
アスペクト指向は戦場では必要なし!

8 :デフォルトの名無しさん:02/05/15 22:36
>>10 削除よろぴく

9 :デフォルトの名無しさん:02/05/15 22:47
エージェント指向は戦場では必要なし!

10 :デフォルトの名無しさん:02/05/15 22:48
削除依頼は必要なし!

11 :9:02/05/15 22:49
>>10
お前、俺を待ってただろ。

12 :10:02/05/15 22:52
>>11
顔真っ赤にしてロリードしてました。

13 :デフォルトの名無しさん:02/05/15 22:56
>>1-1001 ジサクジエンデシター


14 :デフォルトの名無しさん:02/05/15 22:57
じゃあ終了ってことで

15 :デフォルトの名無しさん:02/05/15 22:57
あいーん

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


16 :デフォルトの名無しさん:02/05/15 22:59

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



17 :John:02/05/15 23:16
俺のスレに来い

18 :仕様書無しさん:02/05/16 00:05
オプシェクト指向はブラックボックス化じゃーーー!
これを入れると、あれが出てくるみたいなのを大量生産して、
みんなで、もっと楽に作りましょう(ワラ

19 :デフォルトの名無しさん:02/05/16 01:47
オブジェクト指向、、必要最小限に使うってのがよさげかもね、てか一番楽だろうね
デザインパターンとかはしんどいと思うよ

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

20 :デフォルトの名無しさん:02/05/16 01:52
老人め。

21 :デフォルトの名無しさん:02/05/16 01:57
>>20
おまえもそのうち仲間入りだよ。
その前に死ぬか。

22 :デフォルトの名無しさん:02/05/16 01:59
>>21
なんか怖いよ

23 :デフォルトの名無しさん:02/05/16 02:02
プログラマは老いたら身を引くべきだ。
みんなそうおもってるだろ?

24 :デフォルトの名無しさん:02/05/16 02:06
c++におけるclassとは・・・structの亜種[なれの果て]とか言ってみる

25 :デフォルトの名無しさん:02/05/16 02:38
戦場じゃないのでオブジェクト指向は必要アリ

26 :デフォルトの名無しさん:02/05/16 02:42
>>25
同僚がそんなこと微塵も考えてないという罠。

27 :デフォルトの名無しさん:02/05/16 07:57
>>24
struct Hage {
  |
  :
  |
};
class Hoge : public Hage {
  |
  :
  |
};


28 :デフォルトの名無しさん:02/05/16 11:28
>ちゃんと整備されたドキュメントがなければ粗大ゴミソース。

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

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

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


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

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


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

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

31 :デフォルトの名無しさん:02/05/16 18:16
未だに汚い手法は使うが、同時にOO無しってのは考えられない。って
感じですが、みなさんはどう?

32 :デフォルトの名無しさん:02/05/16 18:51
>>19に概ね同意。
要は使いようだな。適用する必要がなければ適用しなければいいだけ。絶対に何が何でもOOPってのは変。
構造化プログラミングは必須だと思うがな。

33 :化石:02/05/16 19:20
結局OOPL使わない仕事って滅多に来ない…てかここ3年お目に掛かってない…俺に辞めろと?

34 :John ◆0z.4Is5E :02/05/16 20:04
OOPLのすごさが分かるのは、ライブラリー(フレームワーク)を作ってるときじゃないかな?

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

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

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

35 :デフォルトの名無しさん:02/05/16 23:48
GC?

36 :デフォルトの名無しさん:02/05/16 23:49
何言ってんかわかんねーよ

37 :デフォルトの名無しさん:02/05/17 00:02
ジョンだからしょうがいない。

38 :デフォルトの名無しさん:02/05/17 00:05
ゲームキューブ?

39 :デフォルトの名無しさん:02/05/17 00:22
General Combiner!!

40 :デフォルトの名無しさん:02/05/17 00:31
GCがわからんってネタだよね?

41 :デフォルトの名無しさん:02/05/17 00:33
マークアンドスウィープ
ストップアンドコピー
リファレンスカウント
いまどきGCを知らないバカはいないと思われ

42 :デフォルトの名無しさん:02/05/17 00:33
ガベージコレクタだとしたらなおのことJohnの言いたいことが分からない
からみんな遊んでるんだと思うよ。

43 :デフォルトの名無しさん:02/05/17 00:34
>>34が作ったライブラリはことごとく再利用されていないという罠。

44 :Mike:02/05/17 00:34
まあなんにしてもJohnはバカってことだ

45 :デフォルトの名無しさん :02/05/17 00:34
ごみ集め処理

46 :デフォルトの名無しさん:02/05/17 00:37
ジョンの言うGCつーのはこれだよ。
http://www.watch.impress.co.jp/game/docs/20020308/ban.htm

47 :デフォルトの名無しさん:02/05/17 00:38
41はどこかで見た単語を並べてみたんですか?

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

49 :デフォルトの名無しさん:02/05/17 00:41
確かにGCは再利用に役立つよね。
情報隠蔽を手助けするから。

50 :デフォルトの名無しさん:02/05/17 00:43
言語的仕掛けとランタイムな仕掛けをごっちゃ混ぜにしてるのはやっぱり
Java屋さんですか?

51 :デフォルトの名無しさん:02/05/17 00:45
GCはライブラリだけじゃ無理。
ホシュテキGCとかいう半端者になる。

52 :デフォルトの名無しさん:02/05/17 00:46
マルチスレッドはライブラリだけじゃ(以下略

53 :デフォルトの名無しさん:02/05/17 00:47
OOPL→使う人が意識して使う
GC→意識のしようが無い

たのむよJohn

54 :デフォルトの名無しさん:02/05/17 00:49
>>53
GC無しの動的メモリ管理だと意識せざるを得ないよね。
GC→余計なことを意識しなくて良くなる
かな。

55 :デフォルトの名無しさん:02/05/17 00:51
GCで情報隠蔽ってのは、他のモジュールがまだ参照しているかとか
気にしないですむから、情報が局所的になるって事かな?

56 :デフォルトの名無しさん:02/05/17 00:51
Objective-C のpoolみたいなのってのはやっぱ半端物かね?

57 :デフォルトの名無しさん:02/05/17 00:52
GCが再利用に関係するってのはちょっと飛躍しすぎじゃないか?

58 :デフォルトの名無しさん:02/05/17 00:54
autoreleaseか。GCほどの便利さ/安全さは無いよね。

59 :デフォルトの名無しさん:02/05/17 00:55
GCはどうでもいいけど

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

「それ」って何?

60 :デフォルトの名無しさん:02/05/17 00:55
>>58
うん。。。ない。つーか良く間違える。

61 :デフォルトの名無しさん:02/05/17 00:56
まあJohnをいじめるのはこれくらいにして、本題のOOの可否に戻ろうか?

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


63 :デフォルトの名無しさん:02/05/17 00:58
>>61
そりゃ可に決まってるだろ。
このスレはそういう意見を誘引するための罠
じゃないのか?

64 :デフォルトの名無しさん:02/05/17 01:00
>>63
スマソ言い方が悪かった。OOが生きる現場と、どうやってもOOが合わない
現場ってのをかたりませう

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


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

66 :デフォルトの名無しさん:02/05/17 01:05
>>65
古いソースとか読んでるとそういうのが行間から伝わって来る。

67 : :02/05/17 01:43
>>65
え、なんか間違ったこと言ってる?

68 :デフォルトの名無しさん:02/05/17 01:55
>>67 微妙にワラタ

69 :デフォルトの名無しさん:02/05/17 02:00
過剰にワラタ

70 :デフォルトの名無しさん:02/05/18 03:40
オブジェクト指向つーか、クラス化すると
遅くならねぇ?そうでもない?うーん。だめぽー

71 :デフォルトの名無しさん:02/05/18 05:49
クラス化しただけで遅くなることを示すベンチマークなら作れるけど、その話題はアレだよ・・・

72 :デフォルトの名無しさん:02/05/18 08:40
高級志向っつーか、ベンツ化すると
高くならねえ?そうでもない?うーん。だめぽー


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

74 :デフォルトの名無しさん:02/05/18 22:32
Javaはかなり遅くなるね
C++だと別の言語を組み合わせなくても性能低下を極限まで削れる
Smalltalkはしらん

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

75 :デフォルトの名無しさん:02/05/19 00:03
要求をこなすことができればどんなに糞遅くても構わんよ
それより納期を守ってくれること、バグがないことのほうが大切

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

76 :デフォルトの名無しさん:02/05/19 00:07
>>75
重すぎて使い物にならないは監査に引っかかる罠。

77 :デフォルトの名無しさん:02/05/19 00:08
> 重すぎて使い物にならない

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

78 :デフォルトの名無しさん:02/05/19 01:02
今世間で「オブジェクト指向」と思われているのは
「クラス型オブジェクト指向」なのです。
対抗する概念として「配列型オブジェクト指向」の存在をここに宣言します。

79 :デフォルトの名無しさん:02/05/19 01:08
>>78
どんな感じなんですか?それ。
void *型の関数があってデータと関数ポインタを同じ配列で管理したり?

80 :デフォルトの名無しさん:02/05/19 01:09
>>79
>void *型の関数
−>void *型の配列

81 :デフォルトの名無しさん:02/05/19 01:23
メンバー関数みたいのはありません。
クラス関数/メソッドの代用に関数ポインタを持った構造体なぞではありません。
(それじゃクラスと一緒じゃん)
例:クラス型と配列型で同じ物を書いてみます

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;
 }







82 :デフォルトの名無しさん:02/05/19 01:24
Schemeやクラス無しLispとどう違うの?

83 :デフォルトの名無しさん:02/05/19 01:25
Schemeやクラス無しLisp知らないし・・・。

84 :デフォルトの名無しさん:02/05/19 01:26
>>81
もとのコードに配列が出てこないときはどうなるの?

85 :デフォルトの名無しさん:02/05/19 01:27
>>81
意味わからん。それが?

86 :デフォルトの名無しさん:02/05/19 01:28
ただの配列だな。昔からみんなやってるよ。
xとyの関係が非常に疎なのが気になる。

87 :81:02/05/19 01:32
>昔からみんなやってるよ。

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


88 :John:02/05/19 01:33
OOPLのすごさが分かるのは、ライブラリー(フレームワーク)を作ってるときじゃないかな?

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

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

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


89 :デフォルトの名無しさん:02/05/19 01:34
>>87
ハアァ?「これ」とか「配列指向」とか、いちいち名付けるほどのもんかよ。
知るも知らないも、考え付かないのはおまえの同僚くらいのもんだろ。

90 :デフォルトの名無しさん:02/05/19 01:35
よく分からないんだけど、何がメリットなの?

91 :デフォルトの名無しさん:02/05/19 01:35
>>81
xとyはグローバル変数になるの?
使えねえと思うけど。


92 :デフォルトの名無しさん:02/05/19 01:36
>>88
それどっかで見た。コピペ文章っぽいな。

93 :John:02/05/19 01:36
>>81
Point間の距離を測りたいときとかどうするんだろうな・・・
その前に参照ができねー

94 :デフォルトの名無しさん:02/05/19 01:37
>ライブラリー(フレームワーク)
フ゜


95 :John:02/05/19 01:38
どこがおかしいんだよ>バカ

96 :デフォルトの名無しさん:02/05/19 01:42
おまえの顔

97 :デフォルトの名無しさん:02/05/19 01:43
>>96
サムイ
ムサイ

98 :81:02/05/19 01:53
クラス型と配列型は同じものを縦割りにしたか横割りにしたかだけの違い。


99 :デフォルトの名無しさん:02/05/19 01:58
>>98
つーか全ての質問に答えろ

100 :100:02/05/19 01:59
100だろ

101 :81:02/05/19 02:02
>>93
>距離の計算

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

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

102 :デフォルトの名無しさん:02/05/19 02:08
>>81 >>101
ネタ?

103 :デフォルトの名無しさん:02/05/19 02:11
>>101
アスペクト指向を調べて来い

104 :デフォルトの名無しさん:02/05/19 02:11
ああ、横のモノを縦に割っただけの詐欺商品にまだ気付かないなんて・・・。
哀れ・・・。

105 :デフォルトの名無しさん:02/05/19 02:31
>>103
つーかさ、>>101はアスペクト指向以前に「型」について勉強しる!

106 :デフォルトの名無しさん:02/05/19 02:38
ここで挙げた二つの型はオブジェクト指向の型の説明の為に私が
発明しました。
だから本で勉強してもそんなのは載っていません。
ニュートンが力学の説明の為に微積分を発明したのに似ていますが。

107 :デフォルトの名無しさん:02/05/19 02:51
これ、技術としてはどっちかというと退化じゃないの?
カプセル化のメリットも無くなるし。
なんで過去の技術の説明に発明が必要なんだか。
ニュートンがかわいそうだよ。

108 :デフォルトの名無しさん:02/05/19 02:57
むづかしく考えすぎ。

109 :81:02/05/19 03:03
配列型でもプログラムの部品化、再利用化はできてましたよ
という話かな?

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

110 :デフォルトの名無しさん:02/05/19 03:13
>>107
81に説明しても無駄だと思うけど。

111 :デフォルトの名無しさん:02/05/19 03:13
>>81
応援してるよ。

112 :107:02/05/19 03:30
> 81に説明しても無駄だと思うけど。

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

113 :デフォルトの名無しさん:02/05/19 03:37
>>106
そうじゃなくってさ、>>105でいってる「型」は「データ型」のことだよ。
とりあえず多ソート代数とか、その辺からお勉強してみたら?

114 :デフォルトの名無しさん:02/05/19 03:43
つーか、ネタみえみえなやつ、相手にするなよ。

115 :81:02/05/19 03:51
OO信者必死だな(藁

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

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

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

116 :デフォルトの名無しさん:02/05/19 03:58
81必死だな(w

117 :デフォルトの名無しさん:02/05/19 04:01
>同類との結合が強い場合にはクラス変数の配列ではなく、
>単一クラス内に配列作ってクラス内で処理するというのは
>かなり一般的に見られるコードです。

意味不明。

118 :81:02/05/19 04:01
もうちょっとだ!
もうちょっとでクラスを超える構造が出来る!

119 :デフォルトの名無しさん:02/05/19 04:02
誰か 81 を窓から投げ捨ててくれ。

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

120 :デフォルトの名無しさん:02/05/19 04:08
え? 勉強になるから、>>81には頑張ってほしいんだが。

121 :デフォルトの名無しさん:02/05/19 04:11
目的物ができれば良いのでわ?
言語の指向を達成するために人間が苦労するのは本末転倒でしょ。


122 :デフォルトの名無しさん:02/05/19 04:26
>>121
目的物を達成するために言語の指向があるのだと思われ。

123 :デフォルトの名無しさん:02/05/19 04:30
むかしFORTRAN66で構造体もどきをやるのに使われてたな。
もちろん今では存在価値ゼロなわけだが。

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

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

125 :デフォルトの名無しさん:02/05/19 06:09
>>124の様なバカには再教育が必要だな。

126 :デフォルトの名無しさん:02/05/19 08:55
>「データの集合」
collectionはなんだろう・・・

127 :デフォルトの名無しさん:02/05/19 09:07
無能は何をやってもだめ

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


129 :デフォルトの名無しさん:02/05/19 10:14
>>81
それはハッシュの事?

130 :81:02/05/19 10:15

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

131 :デフォルトの名無しさん:02/05/19 10:27
>>128

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

132 :81:02/05/19 10:28
超クラス構造への提案

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


133 :デフォルトの名無しさん:02/05/19 10:31
>>132
>単体は自己の要素との相互作用を想定していない。

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

134 :デフォルトの名無しさん:02/05/19 10:31
必要ないものをぐだぐだ議論しても、無駄なものは無駄。

135 :デフォルトの名無しさん:02/05/19 10:33
っていうか、81が求めてやまない「超クラス構造」ってデザインパターンそのもの
じゃ無いのか?

136 :デフォルトの名無しさん:02/05/19 10:35
いいじゃん日本発でだそーうよ「超クラス構造」、Lyeeみたいな感じで。


137 :デフォルトの名無しさん:02/05/19 10:40
81が問題を解決してコードを出したら、「それって○○○のことじゃん」って
言われることに23パターン

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

138 :デフォルトの名無しさん:02/05/19 10:53
とりあえず、煽りぬきでやろう

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

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




139 :デフォルトの名無しさん:02/05/19 11:00
「集合」といっても、要素の順番に意味があるもの、無いけれど順番に取り出せる(イテレートできる)もの、
集合の中にあるか無いかがわかればいいもの、キーで検索したいもの、いろいろあるけど、
そのへんは最初から考えといたほうがいいのかな?

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

141 :81:02/05/19 11:04
>>138
不細工。

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

142 :デフォルトの名無しさん:02/05/19 11:06
>>141
ヒント: リファクタリング

143 :デフォルトの名無しさん:02/05/19 11:07
>>141
デザインパターンをしらんなら勉強してみろ。
たぶん、今悩んでいることがいくつか解決されるはずだ。

144 :81:02/05/19 11:16
>>143
・い・や・だ・

145 :81:02/05/19 11:19
おまえまず日本語なんとかしろよ。

>参照てんこもり渡しにならんの?
これなんて、何行ってるのかさっぱりだよ。
もしかしてヴァカ?

146 :81:02/05/19 11:21
デザパタ厨が荒らしに失敗した模様(藁>>145

147 :デフォルトの名無しさん:02/05/19 11:21
けっきょく81は自分用語を振りまくアフォだったのか・・・

148 :デフォルトの名無しさん:02/05/19 11:24
>参照てんこもり渡しにならんの?
言いたい事はわかるし、>>143が答になってるからよし。

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

149 :デフォルトの名無しさん:02/05/19 11:27
>>81はデザパタすら越えられないってことで。

150 :デフォルトの名無しさん:02/05/19 11:35
「参照てんこもり渡し」が標準語になりますた。

151 :デフォルトの名無しさん:02/05/19 11:42
「参照てんこもり渡し」
これどういう意味だよ・・・

152 :デフォルトの名無しさん:02/05/19 11:43
2ちゃんねるって多くの人が集まるんだけど、
あげあしとり的な意見が大多数をしめている。
だから読んだり議論にさんかしてても何も残らないなぁ。
と思う今日この頃。


153 :デフォルトの名無しさん:02/05/19 11:45
>>152
そりゃまあ、あげあしとり的な意見を無意識のうちにフィルタリング
できなければ2chのS/N比は最悪だろうなあ。

154 :デフォルトの名無しさん:02/05/19 11:49
>>153
S/N比って、何よ?

155 :デフォルトの名無しさん:02/05/19 11:51
Sound/noise

156 :デフォルトの名無しさん:02/05/19 11:54
Soup/Noodle

157 :デフォルトの名無しさん:02/05/19 11:54
Signa/Noise

158 :デフォルトの名無しさん:02/05/19 11:56
>156
それじゃS/N比が大きくても嬉しくない

159 :デフォルトの名無しさん:02/05/19 12:07
起きたら面白いことになってるねえ。
81って超科学と似てない?
相対性力学は間違っていた、なぜなら○○が説明できない!
これからは私の提唱する超相対性力学だ!
とかなんとか言っておきながら、実は単に理解できてないので
とんちんかんなことを言ってるだけって奴。


160 :デフォルトの名無しさん:02/05/19 12:08
81に質問。
アクセサビリティって、もしかしてプログラムのどこからでも
自分の望む変数にアクセスできるのがいいって意味?

161 :81:02/05/19 12:17
>>160
まあそんな意味。

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

162 :デフォルトの名無しさん:02/05/19 12:19
>>160
とほほ発見!

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

164 :デフォルトの名無しさん:02/05/19 12:27
んじゃ、81にまた質問。
参照てんこもり渡しってのはもしかしてこういうの?

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

165 :デフォルトの名無しさん:02/05/19 12:31
>163
再発明大好き人間よりはデザパタ勉強する意欲のある人間の方が使える。

166 :デフォルトの名無しさん:02/05/19 12:42
>>165
再発明っつーかさ、81がやってる事ってのは

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

って感じだろ。

167 :デフォルトの名無しさん:02/05/19 12:44
>>163
どーでもいいから発展性のあるとこみせろよ。
たとえばデザパタの問題点を示してからそれを上回る解決策を示せ。

168 :デフォルトの名無しさん:02/05/19 12:51
>>81よ。すなおに「ボクは他人の意見は聞きません。自分だけが正しいのです。」って言ったら(w

169 :デフォルトの名無しさん:02/05/19 12:53
配列型オブジェクト指向だと、文字や文字列はどう書くの?

170 :デフォルトの名無しさん:02/05/19 12:57
「文字と文字列は同じ書き方で書けます。」とか言って逃げそう。
具体的なコード書いてね。>>81

171 :デフォルトの名無しさん:02/05/19 13:01
>>170
python?

172 :デフォルトの名無しさん:02/05/19 13:10
少なくても俺は81の言ってる事を理解できていない。
他の奴は言ってる事が理解できてるのか?

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

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

173 :デフォルトの名無しさん:02/05/19 13:13
81はすでに逃げました。

174 :81:02/05/19 13:23
>>164
そんなものだけど、渡すのは自分で作ったクラスの参照。

175 :デフォルトの名無しさん:02/05/19 13:26
81の作った関数の中で
一番引数が多かったものって
何個くらいあるの?

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

176 :デフォルトの名無しさん:02/05/19 13:28
>>175
イヤだぞ。そんなに多いの。
普通なら構造体か、クラスにすると思うが。

177 :デフォルトの名無しさん:02/05/19 13:28
俺がまとめていい?

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

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

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

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


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

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

179 :デフォルトの名無しさん:02/05/19 13:30
81の作った関数の中で
一番引数が多かったものって
何個くらいあるの?

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


180 :81:02/05/19 13:30
>>177
その結論は皮肉だろ。酷いなw

181 :デフォルトの名無しさん:02/05/19 13:32
81ってホントコミュニケーション能力無いな。
明らかにヒッキーだよな。

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

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

182 :81:02/05/19 13:33
配列型OOがクラス型より優れているなどとは言っていません
縦に切ったか横に切ったかの違いだけだと言っています。

183 :デフォルトの名無しさん:02/05/19 13:33
81の作った関数の中で
一番引数が多かったものって
何個くらいあるの?

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

184 :81:02/05/19 13:34
配列型というから抵抗があるのかな?
並列型オブジェクト指向と命名してあげよう。

185 :デフォルトの名無しさん:02/05/19 13:34
じゃあ、超クラスとか言ってたのはなんなんだよ。
違いが無いって事はメリットが無いって事か?

186 :81:02/05/19 13:34
>>175
10個くらい

187 :デフォルトの名無しさん:02/05/19 13:35
並列型オブジェクト指向と命名してあげよう。
こいつ頭悪すぎる。


188 :デフォルトの名無しさん:02/05/19 13:35
>>186
どんな関数?

189 :デフォルトの名無しさん:02/05/19 13:36
182
デザパタは結果論って切り捨てる根拠は何?
立てか横かだけ?
Gof読んだ?コード書いた?

190 :デフォルトの名無しさん:02/05/19 13:36
引数10個ってけっこう複雑な関数だな

191 :デフォルトの名無しさん:02/05/19 13:37
>>189
まあまあ、マターリ行きましょう

192 :デフォルトの名無しさん:02/05/19 13:38
>>178
どーでもいいから自分で新しいものを生み出せって。
ただし「新しいもの」だぞ。

193 :デフォルトの名無しさん:02/05/19 13:40
>10個くらい
どういう関数だよ。
本当に作ったのか?


194 :81:02/05/19 13:41
int max(int a,int b,int c,int d....){

}


195 :デフォルトの名無しさん:02/05/19 13:41
アホ決定だな

196 :デフォルトの名無しさん:02/05/19 13:46
>>194
引数の中から最大のものを取得する関数か?
俺だったら引数を配列、もしくはコレクション等にするか
配列、コレクションにgetmaxメソッドを持たせるが
君の方法だとどうなるのかね。

197 :デフォルトの名無しさん:02/05/19 13:57
>>194
ワラタ

198 :デフォルトの名無しさん:02/05/19 13:58
81は引きこもり暦何年目ですか?

199 :デフォルトの名無しさん:02/05/19 14:57
81は逃走か。
オブジェクト指向のメリットは情報隠蔽とポリモーフィズムなのに、
その両方が分かってない奴ははじめてみた。

200 :デフォルトの名無しさん:02/05/19 15:18
>>196
Smalltalkなら
aCollection
  inject: (aCollection detect: [ :x | true] ifNone: [nil])
  into: [ :x :y | x max: y]
ってとこだな。

201 :デフォルトの名無しさん:02/05/19 16:07
引数を沢山作るとスタック操作のオーバーヘッドが馬鹿にならない。
一回アセンブラ出力でも見ろ>81

202 :デフォルトの名無しさん:02/05/19 16:09
>>201
配列の添字渡したってオブジェクト渡したって
引数の個数は同じだろ?

203 :デフォルトの名無しさん:02/05/19 16:17
単数と集合を区別しない言語か。
LISP でいいような気がする。

204 :デフォルトの名無しさん:02/05/19 16:23
そろそろ81は利点を「それは欠点なんです〜。(理由は無し)」とか言いそう。
今ごろ自分と普通の人との差を埋めようと必死になって調べていることだろうよ。

205 :デフォルトの名無しさん:02/05/19 16:38
81降臨しないかな
厨房晒し祭りは楽しい

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

206 :haruka:02/05/19 16:49
あんまり関係ないけど引数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の考え方をどんどん進めていくと結果的に
アセンブラとかマシンコードで直接書けってことになってしまいそうな気がする。


207 :デフォルトの名無しさん:02/05/19 17:25
>>206
引数をスタックに積むのにかなり大きなコストがかかるから、
構造体にまとめてポインタか参照でちょびっとだけスタックに積む方がいいよ。


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

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

209 :デフォルトの名無しさん:02/05/19 18:02
>>208
呼び出しが1回なら同じだろうな。
100 回呼び出したら値のコピーが 1000 回発生するだろう。

210 :デフォルトの名無しさん:02/05/19 18:04
public abstract boolean drawImage( Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, ImageObserver observer)
                       ↑

ぶぅ。



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

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


212 :デフォルトの名無しさん:02/05/19 18:50
ポリモーフィズムってさ。
概念だけの説明じゃぁ、よくわかんないよね。。。
と言ってコードを見ても頭悪いからわかんないのよね。。。
情報隠蔽はよくわかるんだけどなぁ。誰かタチュケテ

213 :デフォルトの名無しさん:02/05/19 18:51
俺の肛門も洗浄は必要ありません。

214 :デフォルトの名無しさん:02/05/19 18:52
あと、デザパタってさ。
結果論じゃなくて、経験論じゃぁないの?
いや、さわりしか知らんのやけどね。頭悪いから・・・。

215 :デフォルトの名無しさん:02/05/19 18:53
>>214
知らんとかくのなら、書き込み自体をするな

216 :デフォルトの名無しさん:02/05/19 18:53
抽象動物クラスを継承した具象犬クラスはワンと鳴き、
猫クラスはニャ−と鳴くのがポリモ−らしいです。

217 :デフォルトの名無しさん:02/05/19 18:55
>>216
ぶっはっはっははははははは!


218 :デフォルトの名無しさん:02/05/19 18:55
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回の整数のコピーにかかるコストを気にしないといけないような環境は
なんだか微妙な環境でやってますな。
ちなみにオブジェクトプーリングは知ってるよね?


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


220 :デフォルトの名無しさん:02/05/19 19:38
>>219
オブジェクトプーリングは、ほぼシームレスに組み込めるだろ?

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

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

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

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

221 :デフォルトの名無しさん:02/05/19 19:38
オブジェクトプーリングって何ですか?

222 :デフォルトの名無しさん:02/05/19 19:41
>>220
http://java.sun.com/j2se/1.4/docs/api/java/awt/Graphics.html

223 :220:02/05/19 19:54
ああ、ほんとだ。
あるんだな。

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

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

224 :デフォルトの名無しさん:02/05/19 19:55
>>223
>ただ、JAVA2Dはまだあまり使われてないから、
>洗練されたクラスライブラリーというわけでもないと思う。


225 :220:02/05/19 20:01
あぁ、Java2Dじゃないか。
ごめんよ。
指摘の仕方が陰湿だね(w



226 :デフォルトの名無しさん:02/05/19 20:02
>>225
>ただ、Java2Dはまだあまり使われてないから、
>洗練されたクラスライブラリーというわけでもないと思う。

227 :デフォルトの名無しさん:02/05/19 20:04
陰湿勝負ですか?w

228 :デフォルトの名無しさん:02/05/19 20:18
オブジェクトプーリングって生成キャッシュのことですか?

229 :デフォルトの名無しさん:02/05/19 20:23
友達いないんだろうな・・・
カワイソ

230 :デフォルトの名無しさん:02/05/19 20:24
オイオイ、awt知らんってもしかしてjavaは殆ど知らないんでないかい?

231 :デフォルトの名無しさん:02/05/19 20:26
>>228
全然関係ないがこのスレ見た後だから気になった。
http://pc.2ch.net/test/read.cgi/prog/1021738082/l50

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

232 :220:02/05/19 20:26
>>230
グラフィックはほとんど使わないんだよ。
データマイニングが専門なんで。

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

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

234 :231:02/05/19 20:28
>>232
× データマイニング
○ データマイニン

ゴメン もうやめる。

235 :デフォルトの名無しさん:02/05/19 20:30
>>231
うん。231はそのままぷーりん、ぷーりんと呼びつづけるといいと思う。
俺は断固としてプーリングと呼ぶが。

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

236 :デフォルトの名無しさん:02/05/19 20:30
>× オブジェクトプーリング
>○ オブジェクトプーリン
アフォー
アフォー
アフォー

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





237 :デフォルトの名無しさん:02/05/19 20:30
>>231
...ngの音は鼻濁音だ。「ング」ではないが「ン」とはもっと遠い。
関東方言のガ行の発音をする人なら「ング」と書いた方が近い。

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

238 :デフォルトの名無しさん:02/05/19 20:31
くだらねーネタばっかり

239 :デフォルトの名無しさん:02/05/19 20:32
>>238
糞スレに何を期待してんだ。

240 :デフォルトの名無しさん:02/05/19 20:33
>>239
せめてsage進行でやってほしいね

241 :デフォルトの名無しさん:02/05/19 20:34
-------------------------->239<-------------------------------

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

243 :デフォルトの名無しさん:02/05/19 21:14
>>242
許さん。
プログラミング。
そんな感じ。
プログラミング。

244 :デフォルトの名無しさん:02/05/19 21:16
学生ですが。

245 :デフォルトの名無しさん:02/05/19 21:20
>>242
プログラム書いてます。
仕様書もたまに書きます。
でもほとんど遊んでます。

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

不良社員でごめんね。

246 :デフォルトの名無しさん:02/05/19 21:25
許さん。

247 :デフォルトの名無しさん:02/05/20 00:53
毎日ネット見て遊んでいます。

248 :デフォルトの名無しさん:02/05/20 01:51
>>219
Rectangleとまではいかなくとも、せめてPointぐらいは使ったほうがいいと思われ。


249 :haruka:02/05/20 05:42
微妙だなあ。
drawString(str,x,y)とかでも
Pointにしたほうがいい?


250 :デフォルトの名無しさん:02/05/20 07:24
>>249
うん。微妙だよね。

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

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

251 :デフォルトの名無しさん:02/05/20 07:35
81、帰ってこーい。
久々に楽しい奴だったのに。

252 :デフォルトの名無しさん:02/05/20 08:39
>>250
まあ、今回の関数の場合は
システムコールのようなもんだから、仕方無いんじゃないかな?


253 :デフォルトの名無しさん:02/05/20 17:01
>>12
とりあえずロリはやめとけロリは

254 :デフォルトの名無しさん:02/05/20 19:36
            ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
           ( ´Д` )< レベルの低い議論してんじゃねぇよ!!
          /,  /    \___________    
         (ぃ9  |
          /    /、
         /   ∧_二つ
         /   /
        /    \
現場で活用できるかどうかの議論じゃねぇのか?

255 :デフォルトの名無しさん:02/05/20 19:39
>>254
スレタイはあくまで>>1が熱望してやまなかった議題。
他人がスレの流れまで管理してやる必要は無いと思われ。

256 :デフォルトの名無しさん:02/05/21 06:07
つか、このスレの趣旨は、その3の>>1であると思われ

257 :デフォルトの名無しさん:02/05/21 10:00
            ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
           ( ´Д` )< どんな理由であれ、読んでてつまらねぇんだよ!!
          /,  /    \___________    
         (ぃ9  |
          /    /、
         /   ∧_二つ
         /   /
        /    \

258 :デフォルトの名無しさん:02/05/21 10:20
質問スレよりは面白いと思うがなぁ・・・

259 :逝って良しの1:02/06/04 08:58
俺の会社にも居るよ、オブジェクト指向だのデザインパターンだのの用語を
会話にちりばめるのが好きな奴が。

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

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

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

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

260 :デフォルトの名無しさん:02/06/04 09:12
ムムッ!約2週間ぶりのレス?

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

261 :デフォルトの名無しさん:02/06/04 09:34
>>259
「あんちでざいんぱたーん」を読ますべし!
技評より7月にでるが、すでに一部書店ででてる。

262 :デフォルトの名無しさん:02/06/04 09:35
まあ 構造化もオブジェクト指向も 明文化出来ない体得するしか
ない部分もあって、ホントに身につくにはそれなりの時間がかかる。

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

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


263 :デフォルトの名無しさん:02/06/04 10:08
>>262
最近実は最も難しいと思ってるのがパターンの習得よりも
クラスやメソッドの命名だったりして(w

264 :デフォルトの名無しさん:02/06/04 10:14
>>263
 そうだね 俺はもう諦めて外部に公開しないメソッドや関数名は func1とかproc3とか
 思いっきり手抜き。 その方が公開してないってわかって逆にいいやって思ってる。

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

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

266 :デフォルトの名無しさん:02/06/04 12:37
つまり、日本語プログラミング最強という事でよろしいですか?

267 :265:02/06/04 13:36
>>266
YEAAAAAAAAAAAAAAAAAAA

268 :デフォルトの名無しさん:02/06/04 13:38
>>266-277 (・∀・)同人物?

269 :デフォルトの名無しさん:02/06/04 13:39
ミスッタ。>>266-267

270 :デフォルトの名無しさん:02/06/04 15:11
日本語でも名前付けは結局迷う罠。
まあ製造・販売・在庫システムをseihanzaiとかにしなくてすむけど。

271 :デフォルトの名無しさん:02/06/04 15:58
低レベルなネタでスマソ。
ポリモーフィズムがわからん奴に簡単に教えるにはどうしたらよかんべ?

272 :デフォルトの名無しさん:02/06/04 16:41
>>271
プラグイン作成の実習

273 :デフォルトの名無しさん:02/06/04 16:42
ポリモルフィズムでしょ!

274 :デフォルトの名無しさん:02/06/04 16:44
ポリモーフィズムに一票
polymorphism

275 :デフォルトの名無しさん:02/06/04 17:00
ど〜でもいいに一票


276 :デフォルトの名無しさん:02/06/04 18:48
オーバーロードって継承したオブジェクトのメンバを
上書きするってこったよね?

277 :デフォルトの名無しさん:02/06/04 18:53
google結果
ポリモルフィズム 522件
ポリモーフィズム 781件
そんなに変わらんが普及してるポリモーフィズムにしとけ。

278 :デフォルトの名無しさん:02/06/04 18:56
おbじぇkとは戦場では必要ありまちぇん!

279 :デフォルトの名無しさん:02/06/04 18:58
ポリモルフィズムダサッッ

280 :デフォルトの名無しさん:02/06/04 19:00
>>276
あほか。オーバーロードってのはな。
継承した仮想メンバを実体化するってことだ。
virtualでも検索しとけ

281 :デフォルトの名無しさん:02/06/04 19:17
>>280
あほ。
http://yougo.ascii24.com/gh/23/002318.html

282 :デフォルトの名無しさん:02/06/04 19:24
オーバーロード≠オーバーライド

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

284 :デフォルトの名無しさん:02/06/04 20:19
>>280
実体化ですか?

285 :デフォルトの名無しさん:02/06/04 20:30
>>283
overrideはいいよ。ミスを防げるし。
C#は俺が前からほしかった機能を実装してくれたから嬉しい。

286 :271:02/06/05 07:39
あ・・・・・・・・・あの〜・・・・・・・・・・・・で、どうしたらいいのでしょ・・・・・

287 :デフォルトの名無しさん:02/06/05 08:44
>>224
 無理でしょ。
 あっちは自分らの監督権限や命令権限増やしいだけで作ってるんだから、
 そういうの希望なら、選挙くらい行かなくちゃね

288 :287:02/06/05 09:07
誤爆ゴメン
polymorphism を教えたいって話だけど、
Cが判るレベルならファイル入出力あたりから説明したら?

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


289 :デフォルトの名無しさん:02/06/05 09:23
>271
実際にサンプルプログラムを見せ、コーディングさせる。
見るだけじゃだめよ。自分でキーを叩かなきゃ。
とっかかりくらいにはなるでしょ。

290 :デフォルトの名無しさん:02/06/05 13:08
>>288
いや・・・VBしかわからんのが対象なだけに、とてつもなくチビシイモンが・・・(わら

291 :デフォルトの名無しさん:02/06/05 18:17
Javaならどうにかなるんじゃないか。

と思いたい(w

292 :デフォルトの名無しさん:02/06/06 10:24
>>291
Java ばっか OOP 関連の書籍が充実しているというのもいかがなものか?
間違っても VB や Delphi でパターンの書籍はみないぞ!
といっても VB で パターンはきついのか。
あ、今は .NET になったから対応できるのか?


293 :デフォルトの名無しさん:02/06/06 10:40
>>292 JAVAがある程度フリーで OOPとしてそれなりだった事がアカデミックな世界で評価されたんでしょうね

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


294 :デフォルトの名無しさん:02/06/07 20:16
クラス作ってみんな幸せ

295 :デフォルトの名無しさん:02/06/07 20:24
ちゃんと理解できている一握りの人の存在も理解したうえで行動すべし。

296 :デフォルトの名無しさん:02/06/07 23:38
>>292
http://labsoftware.com/vbpatterns/vbPatterns.htm

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

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

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


298 :デフォルトの名無しさん:02/06/08 05:12
オブジェクト指向は時代遅れ。
エージェント指向。これ。

299 :デフォルトの名無しさん:02/06/08 05:20
>>298
説明してみい

300 :デフォルトの名無しさん:02/06/08 05:23
オブジェクト指向は時代遅れ。
コンポーネント指向。これ。

301 :デフォルトの名無しさん:02/06/08 06:24
アンチ OO は心底憎らしかったけど
彼らが居なくなると寂しいスレだなや。

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

303 :デフォルトの名無しさん:02/06/08 11:42
>>302
まぁ下品な方ね・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・(ぷ

304 :デフォルトの名無しさん:02/06/08 12:06
オブジェクト指向が理解しやすい?
頭おかしいんじゃない?
オブジェクト指向が自然な考え方?
頭おかしいんじゃない?

305 :デフォルトの名無しさん:02/06/08 12:31
多重継承はすんな

306 :デフォルトの名無しさん:02/06/08 15:01
>>304
オブジェクト指向が理解しにくい?
頭壊れてるんじゃない?
オブジェクト指向が不自然な考え方?
頭壊れてるんじゃない?

(w

307 :デフォルトの名無しさん:02/06/08 15:10
>>304
時代についてこれない人はさっさと氏んでください。

308 :デフォルトの名無しさん:02/06/08 15:25
戦争再開です!
とりあえずアンチは腐った感情論と懐古主義を抜きにした理論的な反論をお願いします。

309 :デフォルトの名無しさん:02/06/08 15:25
1はオブジェクト指向に敗れた敗残兵ですか?

310 :デフォルトの名無しさん:02/06/08 15:26
>>308 とりあえず 308さんの自作自演でない事を証明して下さい。

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

311 :逝って良しの1:02/06/08 16:04
オブジェクト指向マンセーの前にsynchronizedでブロックする
とかいう馬鹿を退治すべき。

312 :デフォルトの名無しさん:02/06/08 16:35
くどいなこの馬鹿

313 :デフォルトの名無しさん:02/06/08 16:59
じゃあさ、これから長いことプログラムでご飯食べたい人はOOP極めて、
いろんな意味で別にそうでもない、って人はやらなくていいんじゃない?
アフォっていわれてもいいじゃん!

314 :デフォルトの名無しさん:02/06/08 17:08
OOPでやろうとしているのを邪魔しなければな。

できないやつができるやつの足を引っ張る。
足を引っ張るアフォは氏んでください。

315 :デフォルトの名無しさん:02/06/08 17:35
>>314 足を引っ張られる程度ってことで我慢しろよ。 同じ労働者だろ

316 :デフォルトの名無しさん:02/06/08 17:37
>>311
意味ワカラン。関係ねーだろ。

317 :デフォルトの名無しさん:02/06/08 17:38
>>315はコボラー

318 :デフォルトの名無しさん:02/06/08 17:44
>>315
> 同じ労働者だろ
同じ労働者じゃねーよ。アフォと一緒にすんな。

319 :デフォルトの名無しさん:02/06/08 17:48
>>318
 労働者じゃないんなら何? 書いたコードの著作権は自分の物な人?

320 :デフォルトの名無しさん:02/06/08 17:51
>>319
技術力がある労働者とアフォ労働者。

321 :デフォルトの名無しさん:02/06/08 17:56
>>320 労働に貴賎なしだよ。 妙なプライドは自分にも回りにも迷惑

322 :デフォルトの名無しさん:02/06/08 18:11
>>321
> 労働に貴賎なしだよ。
誰の言葉? 言葉を変えて自分の都合のいいように解釈してない?

323 :デフォルトの名無しさん:02/06/08 18:18
>>322 そりゃそうさ そもそも引用というのはそういうもの

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


324 :デフォルトの名無しさん:02/06/08 18:19
労働に貴賎は無い
あるのは評価だけだ

325 :デフォルトの名無しさん:02/06/08 18:37
OOPかどうか、はどうでもよし。

326 :デフォルトの名無しさん:02/06/08 18:39
職業に貴賎なし。
職業の違いで恥じることは無い。
向上心をもって今の仕事をがんばれ。
今時OOPやらないのは向上心が無い。
妙なプライドはもたんでOOPぐらいやれ。

327 :逝って良しの1:02/06/08 18:45
OOPブームで儲けた奴はもう逃げちゃったというのに
お前ら哀れだな(;´Д`)

328 :デフォルトの名無しさん:02/06/08 18:46
>>327
ということにしたいのですね。

329 :デフォルトの名無しさん:02/06/08 18:51
オブジェクト指向っていってもさ。
メンバ関数内で構造化プログラミングしてるじゃん。
だめじゃん

330 :デフォルトの名無しさん:02/06/08 18:52
>>329
オブジェクト指向は構造化プログラミングが含まれているだけですが?
オブジェクト指向と構造化プログラミングは排他ではありませんよ。

331 :デフォルトの名無しさん:02/06/08 18:54
混ぜるな。バカ

332 :デフォルトの名無しさん:02/06/08 18:56
>>331
くやしかったんですね。

333 :デフォルトの名無しさん:02/06/08 19:03
>>330
オイオイ

334 :デフォルトの名無しさん:02/06/08 19:05
>>333
オイオイ

335 :逝って良しの1:02/06/08 19:05
finallyはアンチ構造化ですがなにか?

336 :デフォルトの名無しさん:02/06/08 19:09
>>329
Smalltalkでは構造化のための制御構造などはなく、あるのはメッセージ式だけですが、何か?

337 :デフォルトの名無しさん:02/06/08 19:10
構造化を含むとか言ってる奴。
まじでオブジェクト指向をわかって言ってる?

338 :デフォルトの名無しさん:02/06/08 19:13
>>336 じゃ ifTrue とか whileFalse ってのはあれは何?


339 :デフォルトの名無しさん:02/06/08 19:14
オブジェクト指向を一言で表すと、クラスとか継承とかでてくると思うけど
構造化プログラミングって一言で言うと順次、選択、繰り返し?
オブジェクト指向でも(特にメソッド内では)当然使うと思うけど。

340 :デフォルトの名無しさん:02/06/08 19:15
>>339
構造化プログラミング自体わかってないやつハケーン

341 :デフォルトの名無しさん:02/06/08 19:18
>>340
説明求む

342 :デフォルトの名無しさん:02/06/08 19:25
構造化プログラミング

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


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


343 :デフォルトの名無しさん:02/06/08 19:28
>>339>>342と矛盾しないような。

344 :デフォルトの名無しさん:02/06/08 19:38
>>339
>、クラスとか継承とかでてくると思うけど
どの辺が「一言」?

345 :デフォルトの名無しさん:02/06/08 19:49
ねーおまえらよ

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

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

347 :デフォルトの名無しさん:02/06/08 20:14
>>345
論文ではないが・・・幾つか上げてやろう

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

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

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

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

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

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

348 :デフォルトの名無しさん:02/06/08 20:15
>劇的に少なくすることができる
>極端に少なくできる
>極度に柔軟性が増す。


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



350 :デフォルトの名無しさん:02/06/08 20:22
>>346
スパゲッティーな論文だ
たのむから提出レベルですれてくれ

    /。     \
   / 0       |
  /      ― ― |
  |.       -  - |
  | (6      > |
  |     ┏━┓|   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   |     ┃─┃|  < サッパリわからん
   |  \  ┃  ┃/   \________
   |     ̄  ̄|

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

>>348
レスはありがたいが、少ないって
ノー味噌少なすぎませんか?

351 :デフォルトの名無しさん:02/06/08 20:24
>>350
7が分かるのか。

352 :こういう事だろ?>348:02/06/08 20:24
>劇的に
>極端に
>極度に

353 :デフォルトの名無しさん:02/06/08 20:25
    /∵∴∵∴\
   /∵∴∵∴∵∴\
  /∵∴∴,(・)(・)∴|
  |∵∵/   ○ \|
  |∵ /  三 | 三 |  / ̄ ̄ ̄ ̄ ̄
  |∵ |   __|__  | < うるせー馬鹿!>>351
   \|   \_/ /  \_____
     \____/


354 :デフォルトの名無しさん:02/06/08 20:27
             /∴∵∴∵\
    r、       /∴∵∴∵∴∵ヽ
    \\.     |/   \\∴∵ヽ
      \\ .  | (・)  (・)  ヽ∵| つべこべ言わずに
     ( ( ̄\. |  ⊂       ∂) 小論文書いてくれよ
     (ヽ ̄/ | |  ___    |   理系だからかけませんってのはなしネ
     (ヽ (  |  \  \_/   /
     (ゝ   |    \_____/
       ̄|  |     |   /\___
        |  |  __/\/  /    \
        |  | /.............................................
        |  |/ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;卍;;;;;;;;


355 :347:02/06/08 20:31
>>350
1.良くある手だが、ポリモーフィズムを使って条件により生成するオブジェクトを変えてやる。

例えば

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

} else {

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

とかってコードを、

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

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

356 :デフォルトの名無しさん:02/06/08 20:31
>>354
まずお前が書けば

357 :デフォルトの名無しさん:02/06/08 20:36
関数ポインタ。

358 :デフォルトの名無しさん:02/06/08 20:39
オブジェクト指向には、これこれこのような特徴があり、
こうこうこうである。はたして、これこれの特徴には
メリットがあるか考えてみたいと思う。
 確かに、これこれこうだ。
例えば、これこれこうゆうことをするには、このような
メリットがあった。しかし、これこれこーいう理由で
このような不具合がある。
 これこれこえ、、、、、本命、、、、、、、、
dfskfjdslfjldsjflsdjfdsjfl
fskdfjlsdjflsdjfjsdfjsdjfl
 したがって、sfksdklfjsdlkfsdjfs
dlkfjsdlfjsdflsdfjlである。

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

359 :デフォルトの名無しさん:02/06/08 20:40
>>350
5.は、機能を追加していくと段々コードが複雑化していく傾向がある。
しかし、随時リファクタリングを行なう事によって、
逆に時間がたつにつれ、徐々にコードの可読性が増し
「果たして、この部分ってなにやってたんだっけ?」と
悩むことが少なくなり、変更に俄然強くなる。

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


361 :デフォルトの名無しさん:02/06/08 20:43
>>355
俺はVCとJAVAしかつかったことがない
それも、少しだ。
今の俺の解釈では、条件でオブジェクトをセレクトして
いるから、どうなんだ?意味を汲み取ることができませ
ん、申し訳ないが。

362 :デフォルトの名無しさん:02/06/08 20:49
>>359
なるほど
納得しますた
「りふぁくたりんぐ」は、きーたことがりませんですた



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

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

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

364 :デフォルトの名無しさん:02/06/08 20:53
>>362

本嫁厨房でスマソ

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




365 :デフォルトの名無しさん:02/06/08 20:54
>>357
それはC++ではないですか?
Cでも最近はできたかな

366 :デフォルトの名無しさん:02/06/08 20:55
>>361

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




367 :逝って良しの1:02/06/08 21:02
どうでもいいが、実戦では能書きよりそいつのコードを見るまで
信用してはいけません。

368 :デフォルトの名無しさん:02/06/08 21:02
>>364 Delphi での事例もあるよ。
http://asyrinx.fc2web.com/samples/index.htm

369 :デフォルトの名無しさん:02/06/08 21:02
構造体に関数ポインタ

370 :デフォルトの名無しさん:02/06/08 21:03
>>369
Cで実現するオブジェクト指向の実装手段だね。

371 :デフォルトの名無しさん:02/06/08 21:29
5.仕様変更等に対し、極度に柔軟性が増す。

ほんとか?これ

372 :デフォルトの名無しさん:02/06/08 21:35
>>361
Java が解るなら一言。
Java の interface は何の為にあるか小一時間考えてみて!

373 :361:02/06/08 22:11
>>372
とりあえず
Javaの継承とInterfaceの違いでなやんでますが何か

VC これわかりやすい

374 :gekiyasu:02/06/08 22:12

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

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

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

375 :デフォルトの名無しさん:02/06/08 22:14
>>373
実装のし忘れがない→実装し忘れたりスペルミスがあるとコンパイルは通らない

376 :デフォルトの名無しさん:02/06/08 22:23
>>372
interfaceは、あるオブジェクト他のオブジェクトと協調するにあたって、
相手のオブジェクトに要求する性質を定義したもの。
クラスとせずinterfaceとすることで、クラス階層相互依存の呪縛から開放され、再利用性が増す。

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

377 :デフォルトの名無しさん:02/06/08 22:28
C++では
#define interface struct
とすると吉(特にVC++)

378 :デフォルトの名無しさん:02/06/08 22:31
>>376

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

379 :デフォルトの名無しさん:02/06/08 22:42
>>378
おまえ再利用性の意味わかってるか?
再利用性の事を考えずにプログラムしてるなら、
相当レベルの低い対象をプログラムしてるとしか思えないな。

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

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

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

380 :デフォルトの名無しさん:02/06/08 22:42
>>375
それ最強

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

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

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

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


381 :デフォルトの名無しさん:02/06/08 22:43
>>379
頭悪そうな煽りにいちいちレスすな

382 :デフォルトの名無しさん:02/06/08 22:47
>>380
>つまり、Interfaceではオーバーライドするということでよろしいですか?
そう。C++では、interfaceとしてのクラスを多重継承の親とし、実装することで要求を満たす。

383 :デフォルトの名無しさん:02/06/08 22:57
>>379

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

384 :デフォルトの名無しさん:02/06/08 23:00
>>383
汎用性、再利用性はXPの敵でんな(笑) >「YAGNI=どうせ使わん」
しかしライブラリ書きには必要…。

385 :デフォルトの名無しさん:02/06/08 23:04
>>383
delegateの無いJavaじゃアルゴリズムの再利用にはinterfaceが必要でしょ

386 :デフォルトの名無しさん:02/06/08 23:14
>>385

コピペ
これ最強

387 :デフォルトの名無しさん:02/06/08 23:47
>>338
本気で聞いてる?
ネタだよね??

388 :デフォルトの名無しさん:02/06/09 00:01
個人の能力の差もあるし、オブジェクト指向が使えないのは
仕方ない事だと思うんだが、だからってオブジェクト指向を
敵対視するアホは消えて欲しい。
運転免許持ってないからって車を憎むようなもんだ。

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

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

390 :デフォルトの名無しさん:02/06/09 02:30
>>388
剥げ銅age

391 :逝って良しの1:02/06/09 03:00
>OO 分析設計の手法にはスタンダードが確立されていない。

確立阻止貫徹!

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

家康死すべし!

392 :デフォルトの名無しさん:02/06/09 04:08
このスレはさぁネタスレなんだから、そっとしておいてやろうよ。
職場で居心地の悪い先輩たちに、OO否定という安息の場を与えてあげないとさ・・・

393 :デフォルトの名無しさん:02/06/09 05:34


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


394 :デフォルトの名無しさん:02/06/09 08:50
>>338
> >>336 じゃ ifTrue とか whileFalse ってのはあれは何?

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


395 :逝って良しの1:02/06/09 09:48
0から100までの数に対して条件分岐する場合等は
BASICのON n GOSUB文かCの関数ポインタジャンプテーブルの方が読みやすい。
「RUBYの実装に疑問あり」スレでもでてたね。

396 :デフォルトの名無しさん:02/06/09 10:23
ifTrue:やwhileFalse:が ダイクストラの
 「どんなプログラムの流れも順次、選択、反復の3つ(3大制御構造)で構成されている」
 という 反復や 選択 では無いですか? と聞かれて

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

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

397 :デフォルトの名無しさん:02/06/09 10:47
オブジェクト指向は確かに便利だな。
でもここにきてる奴はタダ単に
クラス作って喜んでるやつばかりだろ?ツマンネ

398 :デフォルトの名無しさん:02/06/09 11:40
>>385

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

399 :デフォルトの名無しさん:02/06/09 13:18
>>396
>あなたは男性ですか? と聞かれて いえ学生ですと答えるようなもの
知らないからって、的外れなたとえ話はやめとけ。

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

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

400 :400:02/06/09 14:04
で?理論的反論はまだですか?>アンチ

401 :逝って良しの1:02/06/09 14:41
どれがプロの理論?

402 :395:02/06/10 07:54
あれ? 案外誰もツッコミ入れないね

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

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

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

403 :デフォルトの名無しさん:02/06/11 01:06
>>402
>夜の間に100レスくらい行くと思ってたんだけどなあ

( ゚Д゚) ポカーン

404 :デフォルトの名無しさん:02/06/11 07:38
>「どんなプログラムの流れも順次、選択、反復の3つ(3大制御構造)で構成されている」
というのは どんなプログラムでもこう分類出来るという定義だから、プログラム言語にこの
3つの構造が表現出来ないというような事はもちろんありえない。

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

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

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


405 :デフォルトの名無しさん:02/06/11 12:35
>>404

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

406 :デフォルトの名無しさん:02/06/13 07:04
>>404
>条件分岐・・・・・・・・・・言語の機能
>順次・選択・反復・・・・プログラムの構造
同じ理屈で
>>399
>ポリモーフィズムと末尾再帰

>選択、反復
を分けてること、わかってる??


407 :逝って良しの1:02/06/13 23:23
なんども言うが

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

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

408 :逝って良しの1:02/06/13 23:24
あげ忘れ

409 :デフォルトの名無しさん:02/06/14 01:12
を、なんか戦場スレっぽくなってきてる。

410 :デフォルトの名無しさん:02/06/15 02:36
つーことは、アンチはそのさらに2週遅れ?

411 :デフォルトの名無しさん:02/06/15 08:10
>>410

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

412 :逝って良しの1:02/06/15 14:14
そんなものは血を吐きながら続ける悲しいマラソンですよ。

413 :デフォルトの名無しさん:02/06/15 14:19
>>412
ウルトラセブンときたか

414 :デフォルトの名無しさん:02/06/15 14:34
>>412
負け惜しみの典型だな。
わかりやす過ぎてつまんないわ。

415 :デフォルトの名無しさん:02/06/15 14:49
>>414
だから>>412はウルトラセブンネタだって

416 :デフォルトの名無しさん:02/06/15 15:09
ネタ元知らんが、ネタだすことしか出来ないってことは反論できないってことだね。

417 :デフォルトの名無しさん:02/06/15 17:33
ソフトウェア工学マンセーなやつって
結局たいしたアプリ作った事無い奴ばっかりなんだけど。
あ、大学での話ね。

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


418 :デフォルトの名無しさん:02/06/15 17:36
>>417
大学時代くらいいろんなことして非効率でも良いから自分の世界観を広げておくことが大切だと思われ。

419 :デフォルトの名無しさん:02/06/15 17:36
>>417
つーか研究と実務は目的が違うじゃん。

420 :デフォルトの名無しさん:02/06/15 17:40
>>419
>あ、大学での話ね。

大学の話だろ?

421 :デフォルトの名無しさん:02/06/15 17:42
Smalltalkは実用的な言語だとももいます。

422 :デフォルトの名無しさん:02/06/15 17:45
>>417
ソフトウェア工学マンセーじゃなくても
結局たいしたアプリ作った事無い奴ばっかりだと思うが?
あ、大学での話ね。

423 :デフォルトの名無しさん:02/06/15 17:51
>>421
VC++ VB 以外は実用的ではありません。
PG は大人しく MS 製品を使いましょう。

424 :デフォルトの名無しさん:02/06/15 17:52
>>421
流石にフォローしきれない。

425 :デフォルトの名無しさん:02/06/15 19:01
(´-`).。oO(アンチ厨にフォローして欲しいとは、だれも…)

426 :逝って良しの1:02/06/15 21:23
オブジェクト指向がソフトウエア工学だって?
アフォですか?


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


428 :デフォルトの名無しさん:02/06/15 21:29

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

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

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

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

            ↑こいつらの中にスパムやってる奴いるぜ。
なんせ、↑こいつらキチガイ集団だからな。

429 :逝って良しの1:02/06/15 23:19
とうとう荒らし始めたか。
信者必死だな(藁
でも、もうすぐOOが廃れるのは変わらないがな。

430 :デフォルトの名無しさん:02/06/15 23:27
>>429
荒らしているのはアンチとアンタですけど。

431 :デフォルトの名無しさん:02/06/15 23:46
>>430
禿同!

432 :デフォルトの名無しさん:02/06/17 00:54
age

433 :デフォルトの名無しさん:02/06/17 00:57
ところで>>1はコボラーまたはVB厨なのか?

434 :逝って良しの1:02/06/17 01:00
あれだな、オブジェクト指向は、
「それを支持すると人を見下すことが出来るから支持する」
という点で危ない宗教と同じなんだな。

435 :デフォルトの名無しさん:02/06/17 01:02
そのほかはまったく関係ないけどね。

436 :デフォルトの名無しさん:02/06/17 01:10
>>433

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

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

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

437 :デフォルトの名無しさん:02/06/17 01:24
オブジェクト指向?ハァ?
本当に「オブジェクト指向」してますか?(w

438 :デフォルトの名無しさん:02/06/17 01:28
>>437

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

439 :デフォルトの名無しさん:02/06/17 01:33
むしろ俺が期待してるんだけど?

440 :デフォルトの名無しさん:02/06/17 01:39
>>439

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

441 :逝って良しの1:02/06/17 03:17
ふっふっふ
それらしい用語を並べ立てて判ってるつもりになってただけのようだな。

442 :山岡:02/06/17 04:03
くそっ雄山め。
究極のオブジェクト指向を見せてやる。

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


444 :デフォルトの名無しさん:02/06/17 12:26
>>436
アンチと言うかあのふざけたOOもどきを使ってOOをマスターしたと勘違いしてる奴が痛いだけかと。

445 :デフォルトの名無しさん:02/06/17 14:04
443のリンク先に書いてある目次より:

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

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

446 :雄山:02/06/18 11:49
>>445
> 目が覚めました!これが至高のオブジェクト指向なんですね!

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

447 :デフォルトの名無しさん:02/06/20 12:24
グローバル関数を使わないのもオブジェクト指向?

448 :デフォルトの名無しさん:02/06/20 13:25
漏れはOOP派だが、グローバル関数は別にあってもいいんじゃない?

449 :デフォルトの名無しさん:02/06/20 13:52
>>446
>>445は皮肉じゃねーの?

450 :雄山:02/06/20 14:21
>>449
知ってて書いてるに決まってんだろ(w

451 :デフォルトの名無しさん:02/06/20 15:02
OOPでは、グローバル関数はクラスにするって本当?
そのクラスのオブジェクトは、関数オブジェクトっていうの?

452 :おおぴーまんせーだが・・・:02/06/20 16:02
>>451
それはJAVAやC#だけやで。
C++ や Delphi やったら、わざわざそげんことせえへんで。

453 :デフォルトの名無しさん:02/06/20 17:50
だからC++は中途半端なOOPっていうんだね。で、C#つくっちゃったと。

454 :デフォルトの名無しさん:02/06/20 19:02
グローバル関数とOOPは別段関係なさそうな気がするが?

455 :デフォルトの名無しさん:02/06/20 19:14
え?そうなの?やっぱちゃんと調べてからもの書くか〜

456 :451:02/06/21 05:46
わかりました。
あるスレで、疑問に思ったんですが、質問する感じじゃなかったので。
C++でプログラムする場合、OOPとしてはクラスにすべきなんですか?
グローバル関数1つに、クラスを1つ作るのですか?

457 :デフォルトの名無しさん:02/06/21 07:12
しない。
namespaceにいれるだけ。

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


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

459 :デフォルトの名無しさん:02/06/22 07:11
>> OOP的にはグローバル関数は排除するべきだろ。
はぁ?


460 :デフォルトの名無しさん:02/06/22 07:47
新しく OO言語を開発する場合は、全てをメソッドにした方が楽だからそうするだけだろ

461 :デフォルトの名無しさん:02/06/22 09:47
>>459-460
ヴァカなのかネタなのか自己申告しる (藁

462 :逝って良しの1:02/06/22 13:09
COBOLオブジェクト

463 :デフォルトの名無しさん:02/06/22 16:09
COBOLごときでオブジェクト指向ずらされるとね・・・

464 :デフォルトの名無しさん:02/06/23 00:17
OOCOBOLって、OOすぎないか?

465 :デフォルトの名無しさん:02/06/23 02:06
>> OOすぎないか?
Oが多すぎないか?ってことか?(鬱)

466 :デフォルトの名無しさん:02/06/24 02:57
最初から仕様がしっかり決まっているプログラムであれば、
OOのメリットはあまりないですね。


467 :デフォルトの名無しさん:02/06/24 03:18
そういうネタも、もう飽きた。

468 :デフォルトの名無しさん:02/06/24 03:58
>>464-465
しばらく考えた、意味が判った、不覚にも笑ってしまった

469 :デフォルトの名無しさん:02/06/24 11:03
山田君〜!>>464 に座布団一枚持ってきてあげて!

470 :デフォルトの名無しさん:02/06/24 11:07


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

                 -― ̄ ̄ ` ―--  _         
            , ´  ......... . .   ,   ~  ̄" ー _
          _/...........::::::::::::::::: : : :/ ,r:::::::::::.:::::::::.:: :::.........` 、   
         , ´ : ::::::::::::::::::::::::::::::::::::/ /:::::::::::::: : ,ヘ ::::::::::::::::::::::: : ヽ
      ,/:::;;;;;;;| : ::::::::::::::::::::::::::::::/ /::::::::::::::::::: ● ::::::::::::::::: : : :,/
     と,-‐ ´ ̄: ::::::::::::::::::::::::::::::/ /:::::::::::r(:::::::::`'::::::::::::::::::::::く
    (´__  : : :;;:::::::::::::::::::::::::::/ /:::::::::::`(::::::::: ,ヘ:::::::::::::::::::::: ヽ
         ̄ ̄`ヾ_::::::::::::::::::::::し ::::::::::::::::::::::: :●::::::::::::::::::::::: : : :_>
            ,_  \:::::::::::::::::::::::::::::::::::::::::::::: `' __:::::::::-‐ ´
          (__  ̄~" __ , --‐一~ ̄
   もうだめぽ…


471 :デフォルトの名無しさん:02/06/24 15:48
予感って・・・

472 :デフォルトの名無しさん:02/06/24 23:03
http://www.ogis-ri.co.jp/otc/hiroba/technical/MixJuice/

473 :デフォルトの名無しさん:02/06/24 23:04
オブジェクト指向言語は間違っていた!


474 :デフォルトの名無しさん:02/06/24 23:05
_chsize : 76d76da0 56 57 8b 74 24 c 3b 35 0 dc da 76 73 47 8b c6

475 :逝って良しの1:02/06/25 02:38
マンセー
マンセー
マンセー
マンセー
マンセー

476 :逝って良しの1:02/06/25 02:40
さあ、お前ら、今まで会社で好き放題にやってたオブジェクト指向信者の
粛清が始まります。

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

477 :デフォルトの名無しさん:02/06/25 02:43
(´-`).。oO(「 」,John,81の次はこいつか…)

478 :デフォルトの名無しさん:02/06/25 09:03
>>477
12分にアフォなんだから構ってやるな。

479 :逝って良しの1:02/06/25 22:05
(゚∀゚)マンセーマンセーマンセーマンセーマンセーマンセー

480 :逝って良しの1:02/06/25 22:07
差分ベースモジュール(゚∀゚)マンセーマンセーマンセーマンセーマンセーマンセー

481 :デフォルトの名無しさん:02/06/26 01:41
AOPはよくしらんが、これもどーせろくなもんじゃない。
本当に優れた手法が洗練されて世に現れるころには俺たちゃジジーだよ
俺らの世代はOOP+(AOPかな?)なんだからさ


482 :逝って良しの1:02/06/26 02:18
こいつは本物です>差分モジュール
何故ならば俺のやってる方法と同じだから。
天才は天才を反省しる!

483 :デフォルトの名無しさん:02/06/27 14:57
OOPは便利なんだけど、C#とか モジュール(ユニット)をクラスで代用しようとし過ぎてないか?

484 :デフォルトの名無しさん:02/06/27 15:03
>>483

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

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

486 :デフォルトの名無しさん:02/06/27 20:09
オブジェクト指向は結構だ。けどさぁ、
Cで無闇に関数ポインタを使いまくる香具師は、
只のヴァカだよ…。

487 :デフォルトの名無しさん:02/06/27 20:25
>>486 そうか? 組み込みで全部の関数を関数ポインタにしたりはよくするぞ


488 :デフォルトの名無しさん:02/06/27 20:28
>>487
それは必要があって、そうしているのだろうから
"無闇に"関数ポインタを使いまくる とは、違うと思われ。

489 :narucy56 ◆wMOjCT4s :02/06/27 21:33
Web プログラミングってほとんどオブジェクト作る必要が無い。
OOP が最も不向きな分野だと思う。

490 ::02/06/27 21:42
CGIで掲示板に毛の生えたようなものつくってるだけなら
そうでしょうね。。

491 :デフォルトの名無しさん:02/06/27 21:42
>>489
まさか、いまだにPerlやPHPで、上から下へ流れるだけの
ソフト書いてるの?

492 :デフォルトの名無しさん:02/06/27 21:52
>>490 >>491

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


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

493 :デフォルトの名無しさん:02/06/27 22:03
Viewの部分(HTML部分)をOO使って分離・抽象化しないと
ビジネスロジックと表示用のHTMLが入り乱れて、訳わからなく
なりますけど、何か。

494 :デフォルトの名無しさん:02/06/27 22:23
>まさか、いまだにPerlやPHPで、上から下へ流れるだけの
>ソフト書いてるの?
他にどんなの作ってるの?
PHPやPerlはそんなイメージなんだけど。



495 :デフォルトの名無しさん:02/06/28 00:17
関数ポインタを使いまくった他人のCソースは、正直、追い難い。
OOはOO言語でやってホスィ…。

496 :デフォルトの名無しさん:02/06/28 01:16
>>495
禿同

497 : :02/06/28 01:52
>>494
労働時間長くて儲け低そう。


498 :逝って良しの1:02/06/28 05:21
>>495
「追う」というやり方が通用する時点で手続き型じゃん。

499 :デフォルトの名無しさん:02/06/28 07:59
>>498
で、何が言いたいの?

500 :デフォルトの名無しさん:02/06/28 09:49
>>493

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

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

501 :デフォルトの名無しさん:02/06/28 09:50
>>493
でも、悲しいけどASPとかJSPとかPHPとか。それが主流なのよね。


502 :デフォルトの名無しさん:02/06/28 09:53
>>501
それでもプログラマーですか!
軟弱もの。

503 :デフォルトの名無しさん:02/06/28 09:53
>>501

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

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

504 :デフォルトの名無しさん:02/06/28 09:59
>>502
あの文章だけで何となくガンダムの雰囲気をかぎ取っただと!
奴も・・・ニュータイプなのか!



505 :デフォルトの名無しさん:02/06/28 10:10
おやじどもの会話はよくわからん。

506 :デフォルトの名無しさん:02/06/28 10:14
>>500
ブラウザによってFactoryを切り替えればあらゆるページに対応できて良いかも知れない。

507 :デフォルトの名無しさん:02/06/28 10:16
>>498
> 「追う」というやり方が通用する時点で手続き型じゃん。
確かに
手続き型の場合、取りあえず追ってみれば何とかなるが、
OOの場合、まず全体像を把握してみないとサッパリわからん。


508 :デフォルトの名無しさん:02/06/28 10:18
>>506
 それってオブジェクトじゃなくてユニットでも出来るよ
 ユニットをブラウザ毎にカスタマイズして用意するのは手続き型の範疇でしょう


509 :デフォルトの名無しさん:02/06/28 10:21
>>508
まぁね。Cなら必要なぶんの関数ポインタ使えば出来るし。
静的で良いならリンクするファイルを換えても良いし。


510 :デフォルトの名無しさん:02/06/28 10:23
ユニットってなんだよ?

511 :デフォルトの名無しさん:02/06/28 10:32
>>510 モジュールとかユニットは同じ概念で、Cだと曖昧だけど
 ようは 手続きと内部構造をひとまとめしたもの


512 :デフォルトの名無しさん:02/06/28 10:44
Singletonパターンなんて特に
JAVAで手続型を実装する場合の苦肉の策って感じだよね



513 :デフォルトの名無しさん:02/06/28 10:53
>>512
以上ささやかな反抗でした。

514 :デフォルトの名無しさん:02/06/28 11:17
>>512
この場合、
クラス=名前空間的にはローカルだがグローバルなな変数を使用する関数群か。


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


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

517 :デフォルトの名無しさん:02/06/29 02:58
つーことは、アンチはそのさらに2週遅れ?


518 :デフォルトの名無しさん:02/06/29 02:58
はいはい、あおりだけじゃなくて電(略

519 :デフォルトの名無しさん:02/06/29 02:58
>>517

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

520 :デフォルトの名無しさん:02/06/29 03:08
>>516
もっと高度なプログラム構造ってなぁに?

521 :デフォルトの名無しさん:02/06/29 03:37
でじゃびゅ…

522 :デフォルトの名無しさん:02/06/29 05:12
どぴゅぴゅ…



523 :デフォルトの名無しさん:02/06/29 07:38
アンチ構造化のゴトウ(GoTo)君もまだ存在するみたいですし
光蔵(構造)君がわめいてるのも
負け犬の遠吠えですからみなさん気にしないで下さい。

524 :デフォルトの名無しさん:02/06/29 07:42
オブジェクト指向って行っても呼び出す方は
手続き(変数の宣言をし、メソッドなどを呼び出す)に
よってオブジェクト使ってんじゃん。
つまり手続き指向が最高ってことじゃん

525 :デフォルトの名無しさん:02/06/29 07:59
>>524
オブジェクト指向でもコードの末端はただのフローの組み合わせ。
OO がフロー制御に置き換わる技術とでも思ってた?

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

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

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

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

527 :デフォルトの名無しさん:02/06/29 10:02
中途半端な使い方っていうのは、言い方を変えれば、柔軟な発想で使っているってことだ。
白黒はっきりが好きな奴には向いていないし、こういう奴は戦場では使えない局面があるね。

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

529 :デフォルトの名無しさん:02/06/29 19:41
漏れは多重継承はeiffelで一応の結論が出てると見ているが。

530 :デフォルトの名無しさん:02/06/29 20:16
>>528
あなたは間違っている!

と言う切り口から。

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

531 :528:02/06/29 23:43
>>529
eiffelってよく知らないけど、
それの多重継承の定義を使えば
矛盾は起きなくなるの?
へえ、勉強してみようかなあ。

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

532 :デフォルトの名無しさん:02/06/29 23:43
>>529
激しく同意!

533 :デフォルトの名無しさん:02/06/29 23:50
PowerPCだって純粋なRISCやCISC主義者を無視したからあれだけの性能が出たんだよ。

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

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


534 :デフォルトの名無しさん:02/06/29 23:56
>>533
そうだ、オブジェクト指向は十分普及した。これからはAOPの時代だ。

535 :デフォルトの名無しさん:02/06/30 01:21
Pen4>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PPC

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

537 :デフォルトの名無しさん:02/06/30 15:56
>(つうかすでにある)
どんなのがあるの?


538 :デフォルトの名無しさん:02/06/30 15:59
>>536
one of themなのはあたりまえ。今ごろ気づいたのか?
別の方法がなにかは知らんが、それもone of them。
完璧なのはない。現時点で最良なのはオブジェクト指向。

539 :逝って良しの1:02/06/30 16:00
俺は荒らし。

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

541 :デフォルトの名無しさん:02/06/30 16:02
えてしてそのようなメモリ食いな手法では
話にならない分野もあることを忘れるな。

542 :デフォルトの名無しさん:02/06/30 16:02
>この議論からもっといい言語が生まれることを期待しています。

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

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

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

544 :デフォルトの名無しさん:02/06/30 16:21
<pre>
10
20
30
</pre>

545 :デフォルトの名無しさん:02/06/30 16:23
>>543
ドコヲタテヨミ?
単なる方法論に人生哲学持ち込む奴はドキュンです。


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

547 :逝って良しの1:02/06/30 16:42
ネタ元はアムウェイのパンフですか?

548 :逝っちゃってる543=546:02/06/30 16:46
アムウェイって会社だっけ?

どちらにせよ、違うけどな。ニヤリ

549 :デフォルトの名無しさん:02/06/30 16:46
気軽に「哲学」をクチにする時点でアウトだな。
岩谷宏か、おめえは?

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

551 :逝って良しの1:02/06/30 17:05
層化ですか。
なんだそうか・・・。

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


553 :逝って良しの1:02/06/30 18:06
逝って良しの1

554 :デフォルトの名無しさん:02/06/30 20:07
>>543
俺は逆に真のオブジェクト指向言語を手に入れるのは
人間では無理なんじゃないかとすら思った。

555 :デフォルトの名無しさん:02/07/02 01:18
age

556 :逝って良しの1:02/07/02 03:30
1)オブジェクト指向は使わない。
2)メッセージ機構は使わない。
3)基本は手続き型。
4)グローバル関数には担当ブロックの名前を付ける。
5)設計はフローチャート。
6)ドキュメントビューアークテクチャの場合は描画関数にメイン処理を書く。
7)再利用性は忘れる。

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

557 :デフォルトの名無しさん:02/07/02 03:39
>>556
また荒らしの真似事ですか?

558 :デフォルトの名無しさん:02/07/02 04:09
>>557
彼の生き甲斐を奪うな
町で包丁振り回したらどうする

559 :デフォルトの名無しさん:02/07/04 17:19
age

560 :デフォルトの名無しさん:02/07/04 17:54
あげる意味が分からん

561 :逝って良しの1:02/07/05 00:23
>>557
>>539>>553は偽者です。

562 :逝って良しの1:02/07/05 00:46
逝って良しの1

563 :デフォルトの名無しさん:02/07/05 15:07
素人はライブラリを使用&作成だけすれば良いのでは?

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

564 :デフォルトの名無しさん:02/07/05 16:09
>>563
そうだな。フレーワークが善とは言わんが。

565 :デフォルトの名無しさん:02/07/05 19:08

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

566 :デフォルトの名無しさん:02/07/06 01:20
>>565

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

567 :デフォルトの名無しさん:02/07/06 01:28
お前ら全員.逝って良し();

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

1つの単体プログラム(100%)=クラス(65%)+普通のコーディング(35%)

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

569 :デフォルトの名無しさん:02/07/06 13:44
日本語で話してくれ

570 :デフォルトの名無しさん:02/07/06 14:05
>>550, >>552
構造化したから、OO 使ったから
それでバグの出なくなる世界に私は逝きたい・・・。

571 :デフォルトの名無しさん:02/07/06 14:36
その日曜にやっているという集会に俺はでたい・・・

572 :デフォルトの名無しさん:02/07/06 14:42
  ( ・∀・)   | | ガッ
 と    )    | |
   Y /ノ    人
    / )    <  >__Λ∩
  _/し' //. V`Д´)/ ←>>571
 (_フ彡        /

573 :デフォルトの名無しさん:02/07/06 14:48
>>570-572
これが有名な三段オチというやつですか?

574 :デフォルトの名無しさん:02/07/06 14:58
>>573
tmp=a;
a=b;
b=tmp;

575 :デフォルトの名無しさん:02/07/06 15:05
>>574
それは三段論法です

576 :デフォルトの名無しさん:02/07/06 15:09
♪三段落ちぃと〜 さよなら〜するのよ〜
幼い〜おとおと〜 ゆくな〜と〜泣〜い〜た〜

577 :デフォルトの名無しさん:02/07/06 18:05
>>575
いえ、あれは三角飛びですよ。

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

579 :デフォルトの名無しさん:02/07/06 18:45
>>578
本当に効率的か。それが問題だ。

580 :デフォルトの名無しさん:02/07/06 20:01
XORを使うヤシは禿しいドキュソ!略してHDQN!!

581 :デフォルトの名無しさん:02/07/06 22:29
ほーっしゅあげ

582 :逝って良しの1:02/07/10 02:41
最近2CHに来た人は知らないだろうが、OOは効率が下がるという統計があります。
http://piza2.2ch.net/tech/kako/1003/10038/1003815855.html

583 :海原難山:02/07/10 02:55
至高のオブジェクトを使いなさい。

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


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

586 :デフォルトの名無しさん:02/07/10 03:20
最近2CHに来た人は知らないだろうが、逝って良しの1の言うことはウソという統計があります。

587 : :02/07/10 03:46
今日も微弱な電波発してんな>逝1

588 :デフォルトの名無しさん:02/07/11 14:57
最近リニアが不調なもんで・・・

589 :逝って良しの1:02/07/11 23:54
お前ら、数年後に
「ああ、あの時言って良しの1の意見に真剣に耳を傾けていれば」
と後悔する日がきっと来る。

590 :デフォルトの名無しさん:02/07/12 01:30
やろうと思わなければ効率のいい使い方なんかできるわけない。

591 :589の続き:02/07/12 11:56
そう言い残し、言って良しの1は肩を落としながら寂しく去っていくのであった。

592 :デフォルトの名無しさん:02/07/12 12:54
馬鹿PGのスパゲッティソースはnamespceで閉じ込めるがキチ。


593 :デフォルトの名無しさん:02/07/12 13:07
>>592
そのname spaceを開いた瞬間、そこにあったのは混沌であった…
次回、OO戦士Jガンダム、「スパゲティの渦」
〜君はPGの涙を見る〜

594 :デフォルトの名無しさん:02/07/12 14:12
namespace vaka_pg {
俺 (T∀T){うえーん;}
}

595 :592:02/07/12 17:51
おっとaが抜け取るよ。
namespaceも定義できない馬鹿PG
だった〜Yo (゚∀゚)アヒャ

596 :逝って良しの1:02/07/13 01:22
今日気付いたんだけど、外国でも

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

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

597 :デフォルトの名無しさん:02/07/13 01:25
今日のオナニーは17点。

598 :デフォルトの名無しさん:02/07/13 01:26
クラスはコンセプトとか資源の表現とかだろう?

599 :デフォルトの名無しさん:02/07/13 01:49
同一の性質(属性、振る舞い)を持つオブジェクトを分類(Classify)した
のがクラスだろ。

600 :デフォルトの名無しさん:02/07/13 10:36
ある作業をするのに必要な生徒をまとめてひとつの部屋に押し込めて、
外から出席番号でアクセスすると教師に許された話題に関してだけお話
できるようにしたのがクラス。


601 :逝って良しの1:02/07/14 00:31
みんな間違い。
クラスはオブジェクトの型情報で実体ではない。

602 :デフォルトの名無しさん:02/07/14 00:43
(゚Д゚)ハァ?
ちゃんとした本読んでくださいね。

603 :デフォルトの名無しさん:02/07/14 00:49
マムコの中にティムポつっこむのがセクースだろ。

604 :デフォルトの名無しさん:02/07/14 00:52
(´-`).。oO(ほんとに逝ってくれないかな...名前通り)

605 :デフォルトの名無しさん:02/07/14 01:28
仕事の後のゲラゲラは、健康にイイ。


606 :デフォルトの名無しさん:02/07/14 01:46
>>601
機能実装的にはその認識で良い。
つまり逝1は設計に慣れてないパシリプログラマらしい。

607 :デフォルトの名無しさん:02/07/14 22:04
マルチスレッドプログラミングだと、
オブジェクト指向は何の役にも立たないな。


608 :デフォルトの名無しさん:02/07/14 22:06
>>607
はぁ ?

609 :デフォルトの名無しさん:02/07/14 22:11
>>607
まあ、>>607 には使えないってことでいいですか ?

610 :デフォルトの名無しさん:02/07/14 22:12
>>609
おおすじで同意

611 :デフォルトの名無しさん:02/07/14 22:32
オブジェクト指向な、
ネットワークのプログラム
って実際あるの?



612 :デフォルトの名無しさん:02/07/14 22:35
オブジェクト指向でない、
ネットワークのプログラム
の例を挙げてくれ?

613 :デフォルトの名無しさん:02/07/14 23:03
>>612
普通にソケット開いて送る?

614 :デフォルトの名無しさん:02/07/14 23:20
ソケット通信と、その通信量をゲージで表示する機能を持つ
アプリケーションをモデリングしてください。


615 :デフォルトの名無しさん:02/07/14 23:32
CORBA使え

616 :デフォルトの名無しさん:02/07/15 01:16
オブジェクト指向の一種で、オブジェクト毎にプロセスを割り当てるようなやつなかったけ?

617 :逝って良しの1:02/07/15 02:17
分散おぶじぇくとしこう?

618 :逝って良しの1:02/07/15 02:18
並列だったような気もする。

619 :デフォルトの名無しさん:02/07/15 03:00
ポブナント降下艇が接近中!安全を確保して!
チーフ、会えてよかった!
思ったよりでかいな。
ぐはっ きをつけろ!
すまん!
気は確かか?

620 :デフォルトの名無しさん:02/07/15 03:04
オブジェクト指向って設計がうまくいくと後が凄い楽になるような気がする

621 :デフォルトの名無しさん:02/07/15 03:08
>>620
裏を返せばって言葉もある

622 :デフォルトの名無しさん:02/07/15 03:11
プログラムをするとエラー・バグがあることを前提に対策を考えるからネガティブな思考になると思うんだが違うか。

623 :デフォルトの名無しさん:02/07/15 03:37
C++のnamespaceってネストできるんだっけ?
namespace 隔離病棟 {
namespace vaka_pg {
俺 (T∀T){うえーん;}
}
}


624 :デフォルトの名無しさん:02/07/15 03:38
>>622
>ネガティブな思考
薬の飲めば解決する

625 :デフォルトの名無しさん:02/07/15 03:41
>>623
できるよ。

626 :デフォルトの名無しさん:02/07/15 03:51
ThreadをSubjectにして、
Observerのrunでnotify
を繰り返すのってあり?


627 :デフォルトの名無しさん:02/07/15 03:54
>624
本当に精神科っていいんだべか。効果あったか?

628 :デフォルトの名無しさん:02/07/15 06:47
>>626
Smalltalkのテストツール作った時に、そんな感じの事したよ。

629 :デフォルトの名無しさん:02/07/15 07:09
>>628

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

630 :デフォルトの名無しさん:02/07/15 15:41
しばらく動向をみてきたがオブジェクト指向つかう奴あまりおらんな。

631 :デフォルトの名無しさん:02/07/15 18:57
>630
俺のまわりで行われているプロジェクト(Java)は、全部オブジェクト指向開発だよ。
業務分析からオブジェクト指向分析やっている案件は、極一部だけど、
実装は全てのプロジェクトがオブジェクト指向。UML必須。

632 :デフォルトの名無しさん:02/07/15 22:01
>全部オブジェクト指向開発だよ。
反射的にうさんくささを感じてしまう…

633 :デフォルトの名無しさん:02/07/15 23:07
>>632
だからこそ約4時間放置されてたんだと思われ。

634 :デフォルトの名無しさん:02/07/16 00:52
>632
最初はうざったく思うけど、スパゲッティ-プログラム防止には良いと思う。1回目プロジェクト
は、かえって時間も掛かってコスト増だけど、2回目プロジェクトからは納期も短縮できる。

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


635 :逝って良しの1:02/07/16 02:04
UML使ってても只のサブルーチン集のクラス作ってるアフォも一杯見てきたので
それだけじゃあ本当にオブジェクト指向やってるかどうか判らんね。
つうかプログラマーの9割はサブルーチンの設計もロクに出来ない奴ばっかじゃん。

636 :デフォルトの名無しさん:02/07/16 02:10
その9割のうちの一人だから「逝って良し」なんだね。

637 :デフォルトの名無しさん:02/07/16 02:19
>>635
どのレベルをもって「設計もロクに出来ない」と言っているんだろうかね。
635の言う「サブルーチンの設計がちゃんと出来ている」基準を是非知りたいモノだ。(w


638 :逝って良しの1:02/07/16 02:36
サブルーチンの設計できてない奴のコーディング方法なら

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

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

639 :逝って良しの1:02/07/16 02:40
ああ、「一画面に収まらないからサブルーチンに分割する」
という奴もあるね。

640 :デフォルトの名無しさん:02/07/16 02:40
派遣でJavaの仕事中。
現在製作中のメソッドが400行に届いたけど、
これを分割しちゃいけないらしい。
さらに、このメソッド中で実行されるSQLを
メソッド内に記述しないといけないらしく、
そうすると1.5倍近くまで伸びそう。

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


641 :逝って良しの1:02/07/16 02:57
>>640
1メソッド400行なら、すでに自力でDQNです。

642 :逝って良しの1:02/07/16 03:00
ただしインタプリタやどうしても避けられないステートモデルを除く。


643 :デフォルトの名無しさん:02/07/16 03:15
>>640
400行かよ!

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

おまえが引退しろ

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

645 :逝って良しの1:02/07/16 03:57
わかりました。すいません。ごめんなさいい!
慰めになるか判らないけど、私はインタプリタなら2000行のを作ったことがあります。

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

646 :デフォルトの名無しさん:02/07/16 04:01

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

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

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

648 :デフォルトの名無しさん:02/07/16 06:28
>くっだらねえ。
お前の人生そのものだな。

649 :デフォルトの名無しさん:02/07/16 07:28
>>645
 2000行もってツールで吐かせたの?
 ステートメントはハッシュ+関数ポインタの構造+再帰下降で
 書けばせいぜい30行程度のブロックが沢山という感じじゃない?

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


650 :デフォルトの名無しさん:02/07/16 08:37
printf っぽい構文解析変換とか?

651 :デフォルトの名無しさん:02/07/16 11:07
>>649
再帰下降って、インタプリタつーよりパーサの仕事じゃない?
インタプリタは単純に次の命令を拾ってきてインタープリトすればいいのでは。
何故それが2000行もかかるのか、余計わからんけど。

139 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)