OOスレ7 なぜオブジェクト指向は普及しないのか

1 ：仕様書無しさん：2007/10/18(木) 19:29:43

前スレ「OOスレ6 なぜオブジェクト指向は普及しないのか」

http://pc11.2ch.net/test/read.cgi/prog/1190731526/

過去ログ
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 http://pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 http://pc11.2ch.net/test/read.cgi/prog/1189946678/

2 ：仕様書無しさん：2007/10/18(木) 19:35:08

前スレでおじゃばの自作自演と誤爆っぷりが笑えた。
おじゃばの嘘を指摘したレスに賛同示してるのに、
嘘指摘した名無し(十中八九おじゃばの自作自演)が言い訳するって何？

あのバカは自作自演も満足にできねえのか(悲惨

3 ：仕様書無しさん：2007/10/18(木) 20:36:32

おじゃばよ
頑張れ、なっ

4 ：仕様書無しさん：2007/10/18(木) 21:09:50

　　　　　　　　　　　＿
　　　　　　　 r-､' ´　　｀ヽr-､
　　　　　　　ｨ7　/l: ハヽﾊﾄヾ　　駄スレを隠すことは、この俺が許さん！
　　　　　　　 '|l |'´_`　´_ ｀| || 　　　信念に基づいて行動する。
　　　　　　　 |　|´ﾋ} 　ﾋ}｀! l|　　　それを人は正義と言う。
　　　__ノﾞ).　从 l,　　_'_. 　|从　　　今俺が行ってることは、上げ荒らしではない。
　,_'（＿ﾉ_ヽ　ヾl.＞ - ,イ;ﾘ　　　　正義という名の粛清だぁ！
　{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ　　　
　ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i　'､　　　バーニング！
　/ iゝ＿ﾉ iヽ　/l　　 |l　　l 　 ',
　lﾝヽ/ムノじ

5 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/18(木) 21:54:42

>>2
何が笑えたのか分からない。どの発言が俺の自演だと思うと納得出来るのか分からない。
まあ、辻褄が合わないから笑っているのだろうが、普通はそれを見て自作自演ではないと思う所が、
自作自演を間違えたと解釈する所がすごい。ここまで来ると一種の才能だな。

ちなみに自作自演している人、自作自演だと騒ぐ人、思い込みの極端に激しい人は、一人しかいないと思う。
だってそんな才能のある人は、滅多にいないだろう？

6 ：仕様書無しさん：2007/10/18(木) 22:01:52

そんな才能を持っているのはおじゃばさま一人だけだね
他の誰にも真似できない
唯一無二の才能

7 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/18(木) 22:28:48

では少し真似してみよう。

オブジェクト指向は崇高な学問だから、お前らのような低学歴朝鮮人には10年かかっても無理だよ。
マサチューセッツを首席で卒業した友達の友達がいる俺は、そんなの10年前にマスターしているけどな。
大体、俺が10年前に考えていたシステムと似てると言えなくもない物を、今頃、Googleで研究してる
ぐらいだから、世の中俺以外は全員バカだよ。

そうだよねー。
全員バカだよねー。

こんな感じかな？

8 ：仕様書無しさん：2007/10/18(木) 22:32:20

信じられないかもしれないが、
実は>>2-3 = >>5　なのだよ。
現実はすごいよな。

とりあえず、皆様、駄スレはあげ進行で！

9 ：仕様書無しさん：2007/10/18(木) 22:36:40

>>7
イルボンにはOO不可能ニダ
謝罪と賠償を要求するニダ

10 ：仕様書無しさん：2007/10/18(木) 23:27:16

非OOプロジェクトでなんちゃってFWつくってる
香具師いるんだけど、若くてわかいいと思います。
全て修正させますけど。

11 ：仕様書無しさん：2007/10/19(金) 01:59:01

とりあえずおじゃばの身の回りにはMIT卒が居ない事は良く判った

12 ：仕様書無しさん：2007/10/19(金) 02:50:54

http://pc11.2ch.net/test/read.cgi/prog/1162350547/

591 名前：仕様書無しさん[] 投稿日：2007/10/19(金) 02:01:34
はやくＥＪＢ自慢書けよ糞じゃば
火達磨にしてやるからよ

13 ：仕様書無しさん：2007/10/19(金) 03:41:23

C++限定だけど、+とか+=とかをオーバーロードをする人っている？
今日怒られちった。
「やるな」と。「わかんねーから」と。

顧客情報のクラスがあって、その中で金額関係の数値項目が１０項目以上あるんだけど、
一個一個書くのめんどいから、CClass a = a + b みたいにしたんよ。
そしたらわかんねーと。

AddMoneyメソッド書けって言われたんだけど、
確かにそっちの方がいいなあ、とは思った。

14 ：仕様書無しさん：2007/10/19(金) 03:41:54

あ、おじゃばには聞いてないから。

15 ：仕様書無しさん：2007/10/19(金) 04:28:47

状況によるけどフツーにやる。
もう頭ん中じゃ、その辺の演算子はメンバ関数と扱い変わらん。（C++の話な）
[]とか<<ぐらいまでならやる。
->辺りは、まだやったこと無いな。使い所分からん。

16 ：仕様書無しさん：2007/10/19(金) 08:26:00

おじゃばよ
お前にはどうせ分からんからだまって聞いていろ
演算子のオーバロードはやりすぎてもいかんな
CString型をchar *型に変換する機能をオーバロードしている例としてMFC
VSでコード書けばオーバーロード解析もすぐできるだろう
結論は「オーバーロードは(利用する側にとって)分かりにくい」これはある意味正しい表現だ
しかしC++の仕様としては存在する。

17 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/19(金) 08:55:25

>>12
Googleに入社したいスレに誤爆か？
そこまでは真似出来んな。

18 ：仕様書無しさん：2007/10/19(金) 09:16:06

鈴木高弘が朝から涙目ｗｗｗ

19 ：仕様書無しさん：2007/10/19(金) 09:25:51

> 顧客情報のクラスがあって、その中で金額関係の数値項目が１０項目以上あるんだけど、
> 一個一個書くのめんどいから、CClass a = a + b みたいにしたんよ。

そのクラスって、金額関係以外のメンバ変数もたくさん持ってるの？
+演算子で金額関係だけ足されて、他は足されないのなら分かりにくいね。
そういう状況だと、AddMoney（この命名がいいかどうかは別として・・）
の方が金額だけが足されることが明示されていて分かりやすいと思う。

20 ：仕様書無しさん：2007/10/19(金) 09:27:27

なんたる初心者談義

21 ：仕様書無しさん：2007/10/19(金) 09:34:13

おじゃばよ
開発に行き詰ったらこれが特効薬だ
中村屋のチキンカリー(レトルトではだめだぞ)
そして紀伊国屋で本を買え。なっ。

22 ：仕様書無しさん：2007/10/19(金) 11:47:37

>>13
するよ、一時期javaでそういう議論があったがやはり在った方が良いし、適切なら可読性向上につながる。
実際C#では、そのような議論があったにも関わらずしっかり復活しているからね。
ただし、ポインタへのキャスト演算子のオーバーロードには十分に注意を払ったほうが良いと思われる。
ダウンキャストコピーコンストラクタと同様に問題が多いから。
そのあたりはC#の演算子のオーバーロードを参考にしてみると良いかもしれない、問題のあるオーバーロードは全部省かれているから。

23 ：仕様書無しさん：2007/10/19(金) 13:18:49

>>13
検索しづらい＝保守性が劣るので、俺なら却下

24 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/19(金) 23:49:16

>>21
レトルトはダメって事は食いに行けって事か。
チキンカリーは効きそうだが、書籍はダメだな。
ああ、マンが買って気分転換しろって事かな？

25 ：仕様書無しさん：2007/10/20(土) 00:28:49

おじゃばさまじゃない俺も食いたいぞ！
チキンカリー

26 ：13：2007/10/20(土) 00:42:45

説明不足申し訳。
先に挙げたクラスは金額と領収証枚数とかの数値項目だけで構成されてて、
キーが顧客情報用のインデックスと紐づいてるだけの子クラス。
演算子オーバーロードでは全メンバーに対して演算が行われますけどＮＧ宣告でました。
全額入金されると領収証１枚加算、って感じ。

operatoraのオーバーロードも良し悪し？
あと、焼き鳥帰りで酔っぱらってるのでさらに申し訳。

27 ：仕様書無しさん：2007/10/20(土) 06:31:52

>先に挙げたクラスは金額と領収証枚数とかの数値項目だけで構成されてて、
>キーが顧客情報用のインデックスと紐づいてるだけの子クラス
不適切な演算子オーバーロードになっている予感がする・・・

28 ：仕様書無しさん：2007/10/20(土) 11:21:04

演算子のオーバロードで分かりやすい例としては
Javaの
String ojava = "おじゃばの知能指数: " + 50 ;
の例だろう

29 ：仕様書無しさん：2007/10/20(土) 11:51:02

>>28
おじゃば、お前は出てこなくていいから

30 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/20(土) 12:14:57

>>29
また妄想か？
まあ、チキンカリーでも食って落ち着けよ。

31 ：仕様書無しさん：2007/10/20(土) 12:15:02

＞operatoraのオーバーロードも良し悪し？
その通りだと思う。

（良い例）i = 1 + 2; d = 1.0 + 2.0;
普通はオーバーロードと意識することすらないぐらい自然。

（悪い例）std::cout << "hello, world." << std::endl;
本来どう考えても不適切。慣れれば自然になってしまうが・・。

適切、不適切に絶対的な基準はないから、
周りが反対するなら、そこでは不適切ということになるんだろうね。

32 ：仕様書無しさん：2007/10/20(土) 13:02:14

"hello"+"world" ができるのも演算子オーバーロードのおかげ
C言語はこれができないのが終わってる

33 ：仕様書無しさん：2007/10/20(土) 13:20:38

>>32 いや…まぁ…頑張れ。

34 ：仕様書無しさん：2007/10/20(土) 13:26:46

ポインタにポインタを足すなよ。

35 ：仕様書無しさん：2007/10/20(土) 13:34:29

printf("hello" "world");

何か？

36 ：仕様書無しさん：2007/10/20(土) 13:40:22

意味ねー

37 ：仕様書無しさん：2007/10/20(土) 14:48:10

なんだここには伊賀知己>>29がいるのか

38 ：仕様書無しさん：2007/10/20(土) 15:23:41

std::vector<int> a;
a += my::assign, 1, 2, 3, 4, 5;
こういうのが出来るC++

39 ：仕様書無しさん：2007/10/20(土) 15:34:11

"hello　world"-"world"は、やっぱり、文字列削除で結果は"hello　"だよね。
これって便利だよね。
たとえばstr = str - "mojiretsu1"-"mojiretsu2"-"mojiretsu3";
とすると不必要な文字列を全て削除してくれる

40 ：仕様書無しさん：2007/10/20(土) 17:59:09

なあ、オブジェクト指向の言語仕様ならばとっくに普及してるんじゃねえの
スレタイへんだよここ、だから話がおじゃばの話しかできなくなる

41 ：仕様書無しさん：2007/10/20(土) 19:43:01

言語仕様とオブジェクト指向を同一視してる時点でへんだろ

42 ：仕様書無しさん：2007/10/20(土) 23:12:38

>>31
その程度であれば適切として差し支えないだろう

43 ：仕様書無しさん：2007/10/20(土) 23:15:47

ここの常駐者

レベルが低すぎる

44 ：仕様書無しさん：2007/10/20(土) 23:21:15

実装とか低レベルの話の方が楽しいじゃん

45 ：仕様書無しさん：2007/10/21(日) 12:34:55

心配するな
このスレも前スレ同様、アホコテがOO無視の荒らしを行うから。

46 ：仕様書無しさん：2007/10/21(日) 21:59:31

初めてこのスレを見たものですが．．．．．

>>8の指摘は図星みたいですねｗ

47 ：仕様書無しさん：2007/10/22(月) 01:32:54

>>8=>>46
おつ

48 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/22(月) 08:46:05

45==46 46==ヒロタカ
スズキヒロタカ必死乙wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

初めて書き込む通りすがりですが、きゅん萌えと伊賀知己と偽コンサルとヒロタカは同じ人物に
十中八九間違いない。
ヒロタカと言うのはMaccroSoft社長兼外注で、町内会のセミナーで小学生にダメ出し食らった奴。
お前のセミナーなんて誰も聞いてないんだよ。
つーか自作自演乙www。みんな自作自演だろ。バレバレなんだよ。
このスレ2人しかいないことに早く気付けよ。こいつもあいつもみんな自作自演、お前ら全員自作自演だ。

そうだよねー。
自作自演だよねー。

こんな感じか？

49 ：仕様書無しさん：2007/10/22(月) 08:55:40

おじゃばよ
伊賀知己のワンパターンは見え見え飽き飽きだ
お前がしっかり締めろ、なっ

50 ：仕様書無しさん：2007/10/22(月) 09:07:57

なにこれ？

51 ：仕様書無しさん：2007/10/22(月) 16:27:45

おじゃばがさっき発狂して救急車で運ばれて逝った
その残骸

52 ：仕様書無しさん：2007/10/22(月) 17:51:36

もう気付いていると思うがこれが事実
traitsの継承関係
class ヒロタカ : public おじゃば ◆GxjxF3yEw6
class 伊賀知己 : public おじゃば ◆GxjxF3yEw6
class きゅん萌え : public おじゃば ◆GxjxF3yEw6

結局、おじゃば ◆GxjxF3yEw6がウルトラスパークラスなっ

53 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/22(月) 20:05:48

3人の能力を全て持っているなら、継承は不要だろう？

54 ：仕様書無しさん：2007/10/22(月) 20:24:14

おまぃ・・・
継承わかってねーじゃん

55 ：仕様書無しさん：2007/10/22(月) 20:26:19

じゃあこうか。

class おじゃば ◆GxjxF3yEw6 ：public ヒロタカ , public 伊賀知己 , public きゅん萌え

56 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/22(月) 20:43:14

3人を足しても俺にはならないよな。
強いて言うならこんな感じじゃね？

class おじゃば {
　　　　:
　　　　:
　　　　:
　　　　:
　　　　:
　　string getきゅん萌えもどき();
　　string get伊賀知己もどき();
};

57 ：仕様書無しさん：2007/10/22(月) 22:09:07

traitsの継承関係とかもうね
わかってねー奴はこんなとこ来ねーで勉強してろよアホが

58 ：仕様書無しさん：2007/10/23(火) 15:09:51

× ヒロタカ
○ 高弘

59 ：仕様書無しさん：2007/10/23(火) 15:40:01

おじゃばよ
クラスの定義がC++になっているところが
一年前のジャワしかできんお前と比較して成長が認められる所だな

60 ：仕様書無しさん：2007/10/23(火) 22:41:42

また自演・・・・

61 ：仕様書無しさん：2007/10/24(水) 00:52:13

汎用的な共通関数はどうしたらいいんでしょか？
業務特有の文字列処理とか演算処理とか、
いたるところで使う関数なんですけど。
クラスメソッドばかりのクラスがいいのかな？
OO初心者なんで＞＜

あ、おじゃばには聞いてないから。

62 ：仕様書無しさん：2007/10/24(水) 00:54:30

commons lang

63 ：仕様書無しさん：2007/10/24(水) 00:55:40

オブジェクト指向のスレですら
オブジェクト指向のことが語られないのだから、
普及にはまだ遠い

20年後くらいか？

64 ：wolf ◆8VH3XAqjlU ：2007/10/24(水) 07:25:26

>>61

The Dependency Inversion Principle(DIP) has been proposed by Robert C. Martin.
High level modules should not depend upon low level modules.

65 ：仕様書無しさん：2007/10/24(水) 12:37:32

おじゃばよ
ジャワを捨てたのなら
おしいぷらぷらさまとかにコテ名変更しろ

66 ：仕様書無しさん：2007/10/24(水) 16:35:59

スレは進むがレベルは底辺

67 ：仕様書無しさん：2007/10/24(水) 17:00:09

レベルというかオブジェクト指向の話になってないじゃん

68 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/24(水) 20:43:57

>>58
俺にとってはタカヒロもヒロタカも、どこかの知らないおっさんと言う意味で、同じだと言うのを
表現するために、名前を逆にしたのだが、意味が分からなかったかな？

>>59
一年前のJavaしか出来ないのって誰だ？少なくとも俺はCとCOBOLは出来たぞ。

>>65
別に捨ててないぞ。
いちいち使っている言語に合わせて名前を変えていたら、大変だろう？

69 ：仕様書無しさん：2007/10/24(水) 22:51:48

おじゃばの錬度
COBOL>>>>>プロの壁>>>JAVA>>>>C>>>>>>>C++
COBOL以外は、初心者レベル、OOに関しても初心者レベル
だが、COBOLに関しては経験25年以上の仙人レベル

70 ：仕様書無しさん：2007/10/24(水) 23:22:18

COBOL使えるのか
正直羨ましい

71 ：仕様書無しさん：2007/10/24(水) 23:48:35

COmmon Business Oriented Language　は名前からして最強言語！
COBOLは銭儲け志向言語である。COBOL+物志向=COBOL++ => JAVAなんだよ

72 ：基地も書かずば晒されまいに(ﾜﾗ：2007/10/25(木) 00:09:32

>>68
　本　人　乙　！

73 ：仕様書無しさん：2007/10/25(木) 02:15:11

レベルが右肩下がり・・・
最近の急降下っぷりはスゴイなぁー

>>61
本来、オブジェクト指向で考えれば
共通関数は何らかのオブジェクトのメソッド(protectedで良い)にできる場合が多い。
そのクラスを継承したクラスの中から呼ばれるのが理想でしょう。
# 脱線　>>　C++ならば多重継承が出来る。弊害ウンヌンは置いといて
# その共通処理を使うクラスは次々に継承してみる。
# ある程度やると、次第に特徴が見えてきて、上手くデザイン出来るのでは無いかな？

本当に広域で至る所で使われるならばクラスメンバstatic関数かnamespaceで対処する。
因みにそんなケースは僕的にはかなりレアですよ？

それ以外では、staticオブジェクトで対処する手のもあり。
iostream の ::std::cout とかを参考にしてみ？
（個人的には .so or .dll が必要になってくるのでキライ）

74 ：73：2007/10/25(木) 02:17:21

おっと、、、
static オブジェクト　×
global オブジェクト　○

staticオブジェクトじゃ外から見えんorz...

75 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/25(木) 08:18:36

>>69
おいおい、そんな事言っていいのか？
これでJavaやC/C++で俺に負けたら、素人以下と言う事になるぞ。

76 ：仕様書無しさん：2007/10/25(木) 09:12:50

おじゃばよ
少なくともC/C++でお前に負ける奴は伊賀知己ぐらいなものだろう

77 ：仕様書無しさん：2007/10/25(木) 09:52:10

以上自作自演でした

78 ：仕様書無しさん：2007/10/25(木) 12:02:01

おじゃばよ
伊賀知己はどうころんでも自作自演にしたいみたいだな
だから伊賀知己なんだけどさ

79 ：78：2007/10/25(木) 12:12:30

誰か相手にしてよぅぅぅ

ボク寂しくて死んじゃうよぉぉぉ

80 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/25(木) 20:35:06

何で自作自演にしたいのか考えて見た。
伊賀知己が自分で書き込んだ書き込みも、俺の書き込みだと言っている所を考えると、
本当に自作自演だと思っていない事が分かる。
そうなると、自分の書き込んだ恥ずかしい書き込みを、誰かの書き込みや、釣りに見せたいと考えられる。
しかし伊賀知己の書き込みは特徴があるので、誰かの書き込みに見せるのは無理がある。

何がやりたいのかイマイチわからんな。何だと思う？

81 ：仕様書無しさん：2007/10/25(木) 20:55:57

はいはい
荒らすなキチガイ

82 ：仕様書無しさん：2007/10/25(木) 21:38:14

ここって何のスレだっけ？

83 ：仕様書無しさん：2007/10/25(木) 21:50:29

キチガイコテを介護するスレ

84 ：仕様書無しさん：2007/10/25(木) 23:14:36

オブジェクト指向が普及してない（できない？）原因はなんでしょか？
設計できる人があまりいないからかなあと思ってみたりしてるんだけど違うのかな？

あ、おじゃばには聞いてないから

85 ：仕様書無しさん：2007/10/26(金) 01:00:36

トートロジー

86 ：仕様書無しさん：2007/10/26(金) 01:54:09

>>84
世の中はここの住人の相似だから・・・
OOの話なんて1mmも無いぞ？

87 ：仕様書無しさん：2007/10/26(金) 09:28:23

おじゃばよ
>何がやりたいのかイマイチわからんな。何だと思う？
だから伊賀知己なんだろｗ

88 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/26(金) 20:33:55

>>87
なるほど、理解出来ない物は無理に考えずに、そういう物だと思えと言う事だな。

89 ：仕様書無しさん：2007/10/26(金) 22:56:43

そういうだとか曖昧な表現で勝手に納得してろ屑

90 ：仕様書無しさん：2007/10/26(金) 23:32:29

素朴な疑問なのだが、何故おじゃぱというコテはここまで嫌われてるのだ？
前スレ読んだが、ここまで叩かれるほどトンチンカンなこと言ってないだろ。

91 ：仕様書無しさん：2007/10/26(金) 23:56:58

んで、ＯＯってなんぢゃ？

92 ：仕様書無しさん：2007/10/27(土) 01:13:45

ひどい自演を見た

93 ：仕様書無しさん：2007/10/27(土) 12:27:48

自演がなけりゃあなあ

94 ：仕様書無しさん：2007/10/27(土) 23:14:17

Language-oriented Programming and Language Workbenches: Shifting Paradigms (EVENT: 92643)
http://event.on24.com/eventRegistration/EventLobbyServlet?target=previewLobby.jsp&eventid=92643&sessionid=1&key=8EF4FE3D4124E466F5A04BD0537FFDC5#
http://www.nealford.com/downloads/conferences/Neal_Ford_Martin_Fowler-Language_Oriented_Programming-keynote.pdf
http://www.nealford.com/downloads/conferences/Neal_Ford_erubycon_polyglot_programming-slides.pdf

95 ：仕様書無しさん：2007/10/28(日) 16:30:10

OR mapping is Vietnam of Computer Science.
http://blogs.tedneward.com/default,month,2006-06.aspx

96 ：wolf ◆8VH3XAqjlU ：2007/10/28(日) 18:45:42

>>94
History repeats itself.

Application Generator Definition
http://www.pcmag.com/encyclopedia_term/0,2542,t=application+generator&i=37909,00.asp

97 ：仕様書無しさん：2007/10/28(日) 20:25:46

え？　　
オールドタイプが多いからだろ。

98 ：仕様書無しさん：2007/10/28(日) 21:38:45

ドメイン特化型言語は今年ピークに達するが、来年には小さなバックラッシュが始まるだろう。ある人にとって
の”ＤＳＬ”が、他の人には"little language"(ＵＮＩＸの世界では７０年代初期からずっとやっている)にでしか
ないことに気づく開発者が増えてくるということだ。これでＤＳＬの輝きはすぐ失われてしまう。なぜなら、７０年
代に我々がしたことは、どういうわけか、何であれ悪ということになっているからだ。（ディスコを覚えているか？）
http://blogs.tedneward.com/2007/01/01/Tech+Predictions+2007+Edition.aspx

99 ：仕様書無しさん：2007/10/28(日) 23:08:08

>>98みたいなレス、フレームワークスレに書いた覚えあるなぁ

100 ：仕様書無しさん：2007/10/28(日) 23:41:32

70'sディスコ・ムーブメントって、
意外と現在のクラブ文化と地続きだと思う。JBとかレアグルーヴとかフュージョン、ラテンディスコって未だに人気あるし。
ただ当時との決定的な違いは情報量と選択権。
個人が入手可能な音楽情報の量と質が飛躍的に広がり、
大量の音楽を聞き良いものを選ぶ権利が
一部の専門家から世界の一般人に開放され、
その結果、昔のような画一的な国民的大ヒット戦略が
もはや音楽貧困層(子供)にしか通用しなくなった。

この間の事情はFAX網による東西の壁崩壊、
オプソ特にPC POSIXやインターネットによる情報科学(の一部分野)の普及、
と同時に発生しているのが興味深い。
いわゆる情報革命(その一部がIT革命)って奴だね。発端は宇宙開発と電卓戦争だった飢餓する

101 ：仕様書無しさん：2007/10/29(月) 00:33:41

で、それがOOとなんの関係があるんだ？

102 ：仕様書無しさん：2007/10/29(月) 01:36:55

言うまでもない事だが、
60年代末～70年代にかけ特殊な状況下で萌芽が発生し、
今や一般人の日常生活レベルで普及しているという普遍性。

103 ：仕様書無しさん：2007/10/29(月) 02:13:52

で、それがOOとなんの関係があるんだ？

104 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/29(月) 08:49:23

つまり、以前は一部の専門の物だったOOが、今は一般に解放されていて、
昔のように誰でも出来る言語は、プログラミング貧困層にしか通用しなくなったと言いたいのだろう。

105 ：仕様書無しさん：2007/10/29(月) 09:20:16

おじゃばよ
OOは専門家がこの世の馬鹿の多さに嘆き、プログラミングを簡単に
していこうではないかと発生したものだ
それによってお前とか伊賀知己が生まれたわけだ

106 ：仕様書無しさん：2007/10/29(月) 20:15:25

>>95
そもそもOR-mappingには、楽観派と暫定派が居ると思う。
「ORM=楽観して泥沼化したベトナム戦争」などと寝言を言っているのは、OO方法論者のビジネストークに騙された愚か者ではないかな。
俺は元々、世に蔓延るRDBやデータ指向との境界こそ、OOが破綻するポイントだと考えていて、
このポイントを実務的に解決する事こそ
俺が大嫌いなOO教条主義者(盲目的信者)を破滅させる有効な手段だと捉えている。

107 ：仕様書無しさん：2007/10/29(月) 20:23:57

で、お前は何が出来るんだ？

108 ：仕様書無しさん：2007/10/29(月) 20:26:30

「業務指向のアーキテクチャ設計手法」

アーキテクチャもフレームワークもロクに組んだ事のない人間が
アーキテクチャ設計手法の講釈かよ。

本物のアーキテクトとして片腹痛いわ

109 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/29(月) 21:12:22

>>105
俺はOOの専門家でもある。しかし世の中のバカの多さを嘆いた事はない。
そして、プログラムを簡単にする為にOOが生まれた訳ではなく、当然、OOから俺が生まれた訳でもない。
つまり何が言いたいかというと、見当違いだと言う事だ。

110 ：仕様書無しさん：2007/10/29(月) 21:26:12

自分がバカならバカの多さを嘆くことなんてしないだろ。
おじゃばはOOの専門家かもしれんがOOの技術者じゃないよな
確かにおじゃばはOOから生まれてはいないが、OOに群がる専門家ってことだな。

111 ：仕様書無しさん：2007/10/29(月) 21:35:16

専門家にしては知識不足なのはどうして？

112 ：仕様書無しさん：2007/10/29(月) 21:57:04

>しかし世の中のバカの多さを嘆いた事はない。

あんたのような、優越感に浸りきった独善なナルシストが、バカの多さを嘆かないなんて、怠惰だな。

ちょっと見損なったわ。

113 ：仕様書無しさん：2007/10/29(月) 22:54:40

>>107
お前風情に重要な議論をしてやっても
どうせ何の事かも判らず流して
10年後になって「あの時騙された」とか見当違いな泣き言言ってくるのがオチだからなぁ

説明するだけ無駄ってもんだ

114 ：仕様書無しさん：2007/10/30(火) 00:12:46

JavaとC++でOOの部分の違いってあるの？
C++だとこういうOO設計できるけどJavaはちょっと違う、とか

あ、おじゃばには聞いてないから

115 ：仕様書無しさん：2007/10/30(火) 00:51:24

つーか、JavaのOOの部分・C++のOOの部分って何？

116 ：仕様書無しさん：2007/10/30(火) 00:53:03

知らん

117 ：仕様書無しさん：2007/10/30(火) 00:54:56

>>114
おじゃばはOOの専門家なんだぞ。よく解らんが、専門家ってすごいんだぞ、きっとなぁ
専門家に聞かないで、ど素人に聞くなんて。お前アホか？

>>113 お前、おじゃばと違ってレスほとんどされてないんだから...
そんなこと言ったら、独り言日記になるぞ。ココはお前の日記帳じゃないから別スレへ池よ

118 ：仕様書無しさん：2007/10/30(火) 01:12:38

キチガイ死ね

119 ：仕様書無しさん：2007/10/30(火) 01:31:58

OOPまたはOODを現場のプログラマに浸透させるためには
どんなアプローチが効果的だろうか？

120 ：仕様書無しさん：2007/10/30(火) 01:35:02

話題に継続性がない点に
異常さを感じた。

121 ：仕様書無しさん：2007/10/30(火) 01:47:41

まともな話一つできない異常者が常駐してるスレは
どこもこんなもんだ

122 ：仕様書無しさん：2007/10/30(火) 08:32:28

自画自賛の自演がひどいな

123 ：仕様書無しさん：2007/10/30(火) 08:55:07

なぜ普及しないのかって、もうこれでもかってほど普及してるんじゃないの？

124 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/30(火) 09:03:02

>>110
俺は専門家であり技術者だ。そしてプログラミング技法の一つに過ぎないOOに群がる必要はない。
つまり何が言いたいかというと、見当違いだと言う事だ。

>>111
知識不足と言うより、知識を披露する機会がないと言うのが正しい。

>>112
殆どの犬は4本足で歩く。君は犬が二足歩行しないのを嘆くのかね？

125 ：仕様書無しさん：2007/10/30(火) 09:26:45

キミの文章、どうみてもアホっぽいよ？
どうして？

126 ：仕様書無しさん：2007/10/30(火) 09:42:25

おじゃばよ
お前の披露は聞いても疲労するだけだ
ただ、伊賀知己より人気だけはある。これは間違いない。

127 ：仕様書無しさん：2007/10/30(火) 21:33:11

>殆どの犬は4本足で歩く。君は犬が二足歩行しないのを嘆くのかね？

馬鹿の表現というよりも、人種の違いの表現だな。
馬鹿と人種の違いを一緒くたにするところから、
つまり、すごい独善的だというわけか・・・

オレ様凄いという観点から嘆かないわけか。
見直しておこう(ｗ。

128 ：仕様書無しさん：2007/10/30(火) 22:00:52

>OOに群がる必要はない
実は、解らないから群がる必要性がわからないおじゃばでありましゅる。
>知識不足と言うより、知識を披露する機会がないと言うのが正しい。
さらに、知識を活用する機会もありません。だから、技術力ありません。
ほとんどのPGはOOを活用している。君はPGがOOを活用していないのを嘆くかね？
そんなおじゃばでも伊賀知己より人気だけはある。
つまり何が言いたいかというと、見当違いだと言う事だ。

129 ：仕様書無しさん：2007/10/30(火) 23:02:23

自分で身に付けた知識ではなく
本で勉強さただけの知識で「広く用いられている(これが正しい道ですよ～)」
などと公の場に書いてしまう奴が存在する。

披露する機会が無い「知識」などと言うものは
きっと使った経験すら怪しい「机の上だけの知識」ではないかな。
もし使ったことがあれば、本で得た知識に何らかの意見を持ち、
そして技術者という者は「自分の経験知」を「普遍的な知識」に近付けるために
仲間と議論を試みる癖のある種族なのだから。

そこの議論をきちんとせずに
自分の狭い経験知を普遍的知識であるかのように言いくるめ、
自分を売り込もうとする人種を
「詐欺師」「キチガイ」と呼ぶ。

130 ：オリエント八高 ◆w2WjK8fIMw ：2007/10/30(火) 23:05:58

あれ？
オブジェクト指向は普及してるんじゃないの？
みんなの大好きなVBとかもそうでしょう？

131 ：仕様書無しさん：2007/10/30(火) 23:30:48

おじゃば～。
クラス作成や構造体作るときに、パディングの事考えて作った事ある？

132 ：仕様書無しさん：2007/10/31(水) 00:07:04

paddingって何よ。きっと、コンピラーがいい感じにやってくれるよー

133 ：仕様書無しさん：2007/10/31(水) 03:59:09

ここってお笑い板？

134 ：おじゃばさま ◆GxjxF3yEw6 ：2007/10/31(水) 19:34:40

>>128
意味を理解しないまま引用する行為に、芸術性を感じる。

>>129
言いたい事は2点ある。
「広く用いられている」と「正しい方法だ」は同じ意味ではないと思うし、
「披露する機会がない」と言うのは「この2chスレでは披露する機会がなかった」と言う事だ。

>>131
通信の電文やバイナリファイルを扱う時は考える。
Cでは慣例的に無意識でやっている。JavaやC++では考えない。

135 ：仕様書無しさん：2007/10/31(水) 19:51:35

>>134
>通信の電文やバイナリファイルを扱う時は考える。
>Cでは慣例的に無意識でやっている。JavaやC++では考えない。

・・・なんか、おじゃばがまともな事逝ってるんですけど。

136 ：仕様書無しさん：2007/10/31(水) 21:15:03

相変わらず後付けの言い訳
典型的な使えない奴だな

137 ：仕様書無しさん：2007/10/31(水) 22:29:06

エロイヒト教えて
クラス図ってやっぱExcelで書くの？
コテは答えなくていいから

138 ：仕様書無しさん：2007/10/31(水) 23:37:17

オブジェクト指向ってだいたいいくらぐらいですか？

139 ：仕様書無しさん：2007/10/31(水) 23:38:12

お前の価値の3倍ぐらいかな

140 ：仕様書無しさん：2007/10/31(水) 23:41:35

６万円でおつりがくるぐらい

141 ：仕様書無しさん：2007/11/01(木) 00:05:45

白石マートで売ってますか？

142 ：仕様書無しさん：2007/11/01(木) 01:59:10

>>137
人それぞれかね。
個人的にExcelはねぇなぁ。やっぱ専用ツールのが書くの楽。
うちはJudeとかで書いてるけど、あんまりオススメはしない。
タダで使えるのは良いけど、重い。

143 ：仕様書無しさん：2007/11/01(木) 10:02:01

CRCカードが「広く一般に用いられている」という記事がダウト

144 ：仕様書無しさん：2007/11/01(木) 10:31:42

おじゃばよ
DNS仕様も満足にしらんくせに「電文」とか言うな

145 ：仕様書無しさん：2007/11/01(木) 14:07:55

>>137
紙に書け紙に

146 ：仕様書無しさん：2007/11/01(木) 17:57:42

紙に墨と筆でクラス図を描く、やっぱ日本人だね

147 ：仕様書無しさん：2007/11/01(木) 18:20:49

UMLの類はルールとか余り気にせずに
チラ裏に100円のボールペンでメモ程度に書くのが良いらしいよ
スケッチとしてのUMLってやつで

148 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/01(木) 19:37:17

なんというコボラーコード･･･
読んだ瞬間捨て駒だとわかってしまった
この俺は間違いなく死ぬ
　　┏━
　／￣ヽ
　|　＾o＾|
　└⊂└⊂

149 ：仕様書無しさん：2007/11/01(木) 19:50:35

何この糞コテ

150 ：仕様書無しさん：2007/11/01(木) 20:19:52

>>144
電話屋にDNS関係ねぇからしょうがねんじゃね？

151 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/01(木) 22:55:32

>>136
後付けの言い訳って「披露」の事か？
冷静に考えれば俺の後付けなのか、136の読み違いなのか分かると思うが。

>>144
DNSの仕様って何の事を言っているんだ？
その仕様ってやつを披露してくれよ。

152 ：仕様書無しさん：2007/11/01(木) 22:56:51

池沼粘着スレ

153 ：仕様書無しさん：2007/11/02(金) 14:54:14

おじゃばよ
お前には披露はしない。なぜならばお前は年寄りの永久独身だ。
くやしかつたら結婚披露宴をヒルズで催してから言え。

154 ：仕様書無しさん：2007/11/02(金) 21:20:28

>>153
おじゃばって子持ちの×一で、今、子供の養育費が重くのしかかり大変らしい
披露宴は国民宿舎だった。....と思う

155 ：仕様書無しさん：2007/11/02(金) 23:10:06

オブジェクト指向を極めて、
周りからオブジェクター○○と呼ばれるようになってやる！

156 ：仕様書無しさん：2007/11/02(金) 23:10:55

なんかイン○クター○賀みたいで
フル○ッコにされそうだからやっぱやめた。

157 ：仕様書無しさん：2007/11/02(金) 23:51:44

頭の弱い子が粘着中ですねん

158 ：仕様書無しさん：2007/11/03(土) 01:58:39

世間じゃJavaや.netの仕事ばかりなのにオブジェクト指向が普及していないというのはなぜ？
UMLとか使ってないからか？

159 ：仕様書無しさん：2007/11/03(土) 02:01:26

オブジェクト指向で「作」ってないから

160 ：仕様書無しさん：2007/11/03(土) 10:24:27

>>154
ほー、なんだ奥に逃げられたのか。でも子供を引き取って親の責任を
果たすのは感心だな。

おじゃばよ
子供の教育費はケチるなよ

161 ：仕様書無しさん：2007/11/03(土) 10:32:25

オブジェクト指向は素粒子・原子レベルの物質を切り捨てて
具象化された物体(物質・実態)のみを対象として操作管理する手法だから
研究者のスキルは必要なくて、伊賀知己のような奴でも扱う事ができる仕組み。
だから普及とかなんてどうでもよい。印刷会社バイトなんかでやるの印刷物を
製本機に積み上げていく単純作業のバイトと同じなんだよ。極論を言えば奴隷
コントロール仕様なのがオブジェクト指向。

162 ：仕様書無しさん：2007/11/03(土) 12:09:30

いや違う。遥かならイル平原のヌルポの獣に対する祈りだよ。
おじゃばはその邪悪なる司祭。

163 ：仕様書無しさん：2007/11/03(土) 15:38:03

オブジェクト指向は、共産主義と同じで、理論や理想は凄いが実際は狂気の手法

164 ：仕様書無しさん：2007/11/03(土) 19:22:58

友達が居ない子なんです。どうか皆さん相手してやって下さい。お願いします。

165 ：仕様書無しさん：2007/11/04(日) 12:11:06

オブジェクト指向は、まずい惣菜おかずコンポーネントを組み合わせて
昼のランチを作成する仕様。完成したものは「こだわり」が少なく100円ショップの
安物商品のようなものしか出来ない。惣菜一つ一つからこだわって作るスキルは
必要ないわけだ。

166 ：仕様書無しさん：2007/11/04(日) 14:21:13

カプセル化するには、自分で作るクラスがその外界に対して、何を許可し、何を許可しないかと
いうことを、全体の整合性を壊さないように、よく考えなければならないから、法律家に求めら
れる素養の多少なりとも必要だろうよ。素人が場当たり的に作ってなんとなく的なエリート気分に
浸るためのものではないのよ。

167 ：仕様書無しさん：2007/11/04(日) 17:11:26

ついでに拡張性もな・・・。
一応パッケージ開発しているんだが、
アホ上司の仕様そのままにしたせいで苦労しています。

168 ：仕様書無しさん：2007/11/04(日) 17:13:09

オブジェクト指向とは
レトルトのカレーとパックされたご飯の組み合わせ
暖めてカレーをごはんにかけるだけ
もし「カレーを作りたい」とか言うと車輪の再発明とかいわれてしまう

169 ：仕様書無しさん：2007/11/04(日) 17:16:01

拡張性は
チキンカリーの肉をビーフにオーバライドして
ビーフカレーにする。ルーはヨーロピアンに変更されるため
デミグラスソースの色見を追加する必要がある。

170 ：仕様書無しさん：2007/11/04(日) 17:35:18

それは主婦の発想だね。調理師の発想ではない。
ま、プログラマにも両者がいるのは確かだが。

171 ：wolf ◆8VH3XAqjlU ：2007/11/04(日) 18:10:29

>>170
主婦と言うか
ＭＢＡ持った飲食業コンサルの発想かな
>>169
LSPだと味はチキンのままかも？

172 ：仕様書無しさん：2007/11/04(日) 18:15:54

次から次に糞コテが

173 ：仕様書無しさん：2007/11/04(日) 18:17:45

カレー肉は豚に限る

174 ：仕様書無しさん：2007/11/04(日) 18:20:48

じゃがいも入れる奴は死んでいい

175 ：仕様書無しさん：2007/11/04(日) 18:43:34

public class カレー {
　private final niku = new 豚肉();
　:
　private list 具List;
　public void addGu(具 gu) {
　　if (gu instanceof じゃがいも) {
　　　throw new 死んでいいException('死ねっ');
　　}
　　具List.add(gu);
　}
public void cook() {
　:
　}
　:
}

176 ：仕様書無しさん：2007/11/04(日) 19:19:24

>>175
肉は動的に　牛、鳥、豚、ラムを決定できないとな
じゃがいもはたしかに入れるとダサい
伊賀知己の住んでいる浦和人になってしまいそうだ。

177 ：仕様書無しさん：2007/11/04(日) 22:09:19

話題が絶望的に退屈い

178 ：仕様書無しさん：2007/11/04(日) 22:30:21

お前もな

179 ：仕様書無しさん：2007/11/04(日) 23:02:14

明日の朝あたり、おじゃばが出てくるわけだが、
今週は今市なので食いついて来ないかもね。

悪食で有名なおじゃばなので無問題か。

180 ：仕様書無しさん：2007/11/04(日) 23:43:11

| ∧ 　　　　　　　∧
|/　ヽ　　　　　./ .∧
|　　｀､　　　　　/ 　 ∧
|　　　￣￣￣　　　　ヽ
|￣　　おじゃば　　　￣）
|￣￣￣￣￣￣￣￣￣.＼
|ヽ-=・=-′　ヽ-=・=-　　/ 　もう少し待ってね
|:: 　　＼＿＿_／　　　　/
|:::::::　　　＼／　　　　　/

181 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/05(月) 08:51:58

まず構造化プログラミングを物に例えるとすると、ベルトコンベアだ。
生産ライン（プログラム）の上に商品（データ）を置いて、機械や人が作業（処理）する。
大量の商品（データ）を短時間で製造（処理）するのに向いている。
全体を俯瞰する製造ライン図（モジュール構成図）があれば、製造（処理）の流れが分かりやすい。
欠点としては生産ライン（プログラム）の変更が難しい事だ。
最初の生産ライン（プログラム）設計段階で、矛盾や無理のない設計をする必要がある。
また、ラインを外れた作業（gotoや外部変数）を行うと、破綻しやすくなる。

182 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/05(月) 09:22:15

オブジェクト指向を物に例えるのは難しい。
実際にはありえない物になるが、それでも例えるとすると、蛇口のたくさんついたタンクだ。
巨大なタンクもあれば、小さなタンクもある。蛇口の数は様々で、形状や役割（入出力）も様々でだ。
このタンクは内部に複数の、同様のタンクを含める事ができる。
外側のタンクをぶち抜いて、内側の蛇口を出す事もできる。
システムとしては、巨大な1つのタンクに見えるかもしれないが、その中は複雑に絡み合っている。
利点としては、変更が容易な事だ。
新しい出力が欲しければ蛇口を追加すればいいし、複数のタンクを組み合わせて新しいタンクを作ればいい。
タンクを使うだけなら中身を把握する必要は（基本的には）ない。
欠点としては、内部構造が非常に分かりにくいことだ。
図にするのは非常に困難で、把握するには一つずつタンクを開けて中身を確認し、頭の中で組み立てて
いかなくてはならない。一目見ただけでは超能力者でもない限り、内容を把握するのは無理だろう。
そして、このお化けタンクの設計には、ベルトコンベア設計技術とは全く異なった技術が必要となる。

183 ：仕様書無しさん：2007/11/05(月) 09:46:46

おじゃばよ
カレーを例題に解説せよ

184 ：仕様書無しさん：2007/11/05(月) 17:10:24

結論としては、ある手法が普及しない理由は、さほど有用じゃないから、以外には無い、と。

185 ：仕様書無しさん：2007/11/05(月) 20:42:13

javaカレー食いたい
おじゃば、作ってくれ

186 ：仕様書無しさん：2007/11/05(月) 21:10:42

最近カレーカレーわめいてるキチガイがわいてるけど何なん？
トリップでもつけてくんね？

187 ：仕様書無しさん：2007/11/05(月) 21:14:32

貧乏人なんだからそっとしておいてやってくれ

188 ：仕様書無しさん：2007/11/05(月) 21:47:19

カレーも樽も、何の役にもたたん
妙な例えを出すから混乱するんだ
樽にいたっては現存すらしない例えで悲惨

189 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/05(月) 22:57:35

>>184
いやそんな事、一言も言ってない。

>>185
中村屋に行け。レトルトはダメらしいぞ。

>>188
そう思うなら、的確な例や、面白い例を出して見ろ。
評論家気取りですかぁ！！

190 ：仕様書無しさん：2007/11/05(月) 23:04:59

机を例にして、構造化プログラムとオブジェクト指向を説明しよう。

机で作業をする事の前提で、
構造化プログラム：机の上に必要なものを配置して作業する。
オブジェクト指向：机の引き出しに種類によったものを入れておき必要に応じて取出しして作業する。

・・・書いてて、全然適切じゃないので不許可。

191 ：仕様書無しさん：2007/11/05(月) 23:17:31

例として的を得てるかどうかまでは別に言わんけど、
>>181-182は例示してる割に読み辛くてかなわん。

>>181
例え話をしつつ平行して実際を説明しようとするなら、
いっそ例え話なんて無い方がマシ。
例え話するときゃ例えだけ言え。
で、説明したけりゃその前なり後なりで「何がどう対応するか」を別途言え。

>>182
簡潔で短く言えないなら例え話にする意味がない。

わざとこう書いてるなら見事に釣られたな。

192 ：仕様書無しさん：2007/11/05(月) 23:44:57

そろそろスレにオブジェクト指向原理主義者の俺が必要か？ｗ

193 ：仕様書無しさん：2007/11/05(月) 23:49:59

>>185
中村屋っておじゃばの行きつけのカレー屋？
でも、中村屋って和菓子屋みたいな屋号だな...そこはあんこがカレーでそれが超美味いとか

194 ：仕様書無しさん：2007/11/06(火) 00:41:47

>188の言う通りじゃね？
カレーとかの例えは現場に役に立たないし、
材料だけやしｗ
タンクはひどすぎｗ
例えきれてない例えってどんだけｗ

195 ：仕様書無しさん：2007/11/06(火) 00:45:01

わかりやすくなければ例えとして落第点だっつーのに

196 ：仕様書無しさん：2007/11/06(火) 00:50:45

・・・おじゃば聞くが、新人に教えるときにこんな説明しているのか？

197 ：仕様書無しさん：2007/11/06(火) 01:04:25

そこで、電卓ですよ、ね、皆様

198 ：仕様書無しさん：2007/11/06(火) 01:17:43

え、Hello, world!だろ？

199 ：仕様書無しさん：2007/11/06(火) 02:16:23

このアホコテは新人教育係なのか？
それどんな新人潰し？

200 ：仕様書無しさん：2007/11/06(火) 07:34:25

アニマルクラスから継承して犬、猫を作る。
「吠えろ」とメッセージを送ると
犬は「ワン」、猫は「ニャー」となく。

これより的確にオブジェクト指向を表してるものって
存在するの？
あったら教えなよ。

201 ：仕様書無しさん：2007/11/06(火) 07:58:49

カレークラスを継承して、チキンカレー、ビーフカレーを作る。
「肉追加」とメッセージを送ると、チキンカレーには鶏肉が、ビーフカレーには牛肉が追加される。
カレークラスのset主食メソッドでは「ごはん」と「ナン」しか入れられないようになっているが、
オーバーライドすることで、「うどん」や「そば」も入れられるようになる。

個人的にはカレークラスよりカレーインターフェースを考えた方がいいと思うけどな。

202 ：仕様書無しさん：2007/11/06(火) 08:47:45

>>200

俺は、別に悪いとまで言わないが発想の順番が逆のような気がする。
俺なら犬と猫の共通動作（鳴く、歩く等）を抜き出して、
スーパークラス（アニマル？）を作る話からはじめるな。

203 ：仕様書無しさん：2007/11/06(火) 09:13:42

>>200
猫は吠えないのでｺﾝﾊﾟｲﾙｴﾗｰ

204 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/06(火) 09:53:30

>>191
だから自分の言葉で説明してみろって言ってるだろ。この評論家気取りの偽国語教師がぁ！！
わざと書いたが釣りではない。話の流れ的に設計技法をカルト的に説明しただけだ。

>>193
中村屋のチキンカリーだよ。知らないのか？

>>194
だから俺を感心させる書き込みをしてみろよ。
191も194も195もカスだな。無駄でも頑張った190の方が遥かに評価できる。
つーか194はカスの上に文末に「ｗ」ついて、いまどき「どんだけ」かよ。
自分の知性を犠牲にして相手を煽る、自爆攻撃か？

>>196,199
新人にカルト的説明する訳無いだろう。ソースコード見せて説明するよ。

205 ：仕様書無しさん：2007/11/06(火) 09:56:22

あらら
中村屋のカリーも知らない田舎者がいるのか・・・

206 ：仕様書無しさん：2007/11/06(火) 09:59:04

おまいら設計を含めたオブジェクト指向について議論するんだろ
だったらカレーはすごく良い題材だ
カレーの表面的な部分しか見れないやつは>>201のような考えしかできんわけだ
>>201はたんに実装ドカタなんだろうがな
カレーの深いところまで洞察できる椰子がオブジェクト指向を語る資格があると思うよ

207 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/06(火) 09:59:33

200はどこかで見た説明だな。
201は的確でオリジナリティーあって、良く出来てるんじゃないか。

208 ：仕様書無しさん：2007/11/06(火) 10:03:19

ワンワンニャンニャンでしか説明できない伊賀知己どもよ
ええかげんにそこは卒業せいよ

209 ：仕様書無しさん：2007/11/06(火) 11:48:53

> 新人にカルト的説明する訳無いだろう。ソースコード見せて説明するよ。

このスレでもわかりやすい説明してくださーい

ぶっちゃけキミの文章読んでると
確実にわかってることすらわからない気になってくるから不思議

210 ：仕様書無しさん：2007/11/06(火) 21:13:11

>>204
○ 構造化プログラミングとベルトコンベアによる生産ライン
構造化プログラミングによるプログラムでは、与えられたデータを各関数モジュール(など)が処理し、
次の処理を行う関数に順次渡されていく。

これは、ベルトコンベアによる生産ラインに良く似ている。
ベルトコンベアによる生産ラインでは、生産ラインの上で流れてきた商品に対して
機械や人が作業し、さらに次の作業を行う機械や人に送られる。
すなわち、
　プログラム＝製造ライン、データ＝商品、処理＝作業／製造、
　データ処理モジュール＝製造ラインの機械
である。

また、ベルトコンベアによる生産の利点と欠点に、以下のような事柄がある。
利点
・大量の商品を短時間で製造するのに向いている。
（中略）

これらの点についても、前述のように読み替えると、
構造化プログラミングの特徴についても、似たようなことが言える。
利点
・大量のデータを短時間で処理するのに向いている。
以下略

○ オブジェクト指向を例えるタンク
オブジェクト指向は例えるなら蛇口のたくさんついたタンクである。
タンクの中身がどうなっているか分からないが、
適した蛇口を捻ると目的の液体を取り出すことが出来る。

利点は、タンクを使う人は中身がどうなっているか知る必要が無いことでである。
また、タンクを使る人は蛇口を変えなければ、中身の改造や蛇口の増設を自由に出来る。
欠点は、逆にタンクの中身がどうなっているか分かりにくいことである。

211 ：仕様書無しさん：2007/11/06(火) 21:14:30

ぶｗｗｗ
不自由な日本語ｗｗｗ

× また、タンクを使る人は
○ また、タンクを作る人は

212 ：仕様書無しさん：2007/11/06(火) 21:19:00

>>204
俺はど田舎者だから、中村屋なんて知らないぞ。
どこにあるんだ、京都？　南禅寺の湯豆腐、栂尾のもみじ天ぷら食いたくなった

213 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/06(火) 22:38:48

>>209
ぶっちゃけ、俺の書き込み見て分からなくなるぐらいなら、最初から分かってないんだよ。
210が俺の書き込みを解説してくれたようなので、見てみれば？
何で210のリンクが204なのかは謎だが。

>>211
そんなくだらない所に突っ込むなよ。本当にどうしようもない生き方だな。
学校では批判だけで生きて来られたかもしれんが、社会では自分の知性を貶めるだけだぞ。
改めろ、生き方を。

>>212
新宿だよ。

214 ：仕様書無しさん：2007/11/06(火) 23:15:53

191＝210＝211＝俺

>>204で「やってみろ」と言われたと思ったんで、
俺なりに>>181-182を書き直してみたのが>>210。
内容云々以前に読みづらいっつー話なんで、例えの中身は変えてない。
（つもり。一部冗長だと思った部分は削ったが

だから210のレス先が204で、211は単に自分で書いた訂正。

1分ソコソコで他人が211の突っ込みって、読むの速すぎじゃね？

215 ：仕様書無しさん：2007/11/07(水) 02:08:53

普通に本で数ページ、場合によっては一章つかって説明する内容を
一レス～数レスで書けると思ってるのは凄いな。
絵も使って説明しているわけだし。

216 ：仕様書無しさん：2007/11/07(水) 08:31:37

ｴﾛｲ人教えてください
タンクのような変な例えは聞いたことがありませんが、
なぜこんな変な例えが出てくるのでしょうか？
初代オブジェクトの性質を二世代目も使えるって言えばいいのにって思うのですけど
プレステ２はプレステ１のソフトが使えるけど、独自のソフトも使える、みたいな感じで

あ、おじゃばには当然聞いてないから

217 ：仕様書無しさん：2007/11/07(水) 08:43:11

>>216
プレステ継承例ｲｲ！

218 ：仕様書無しさん：2007/11/07(水) 12:28:44

継承とか差分プログラミングは説明しやすいけど
オブジェクト指向にとって、あまり重要性は高くないからな

219 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/07(水) 19:24:09

>>214
その流れは読めなかったな。
批判的だが、真面目で照れ屋な性格か？

>>215
本当に凄いと思っているのか、出来る訳無いと諦めているのかどっちだ？

>>217
プレステ継承？
表面しか見ていないというのはこういう事を言うんだよ。

220 ：仕様書無しさん：2007/11/07(水) 20:26:55

裏を見てそれを理解できず妄想で補完して
わけのわからんことを垂れ流すお前みたいな説明よりは
上辺だけでもきっちりわかってるヤツの若干的を外した説明のほうが遙かにマシ

221 ：仕様書無しさん：2007/11/07(水) 20:56:50

>>219
>本当に凄いと思っているのか、
出来れば、本当に凄い。

>出来る訳無いと諦めているのかどっちだ？
到達指標が想像できない事なので諦めている。
おじゃばは、数スレで説明しきれると確信を持っているだろう。
だから凄いといったんだが。

222 ：仕様書無しさん：2007/11/07(水) 20:57:23

おじゃば氏のタンクの例えですが、
「複雑に絡み合っている」～「変更が容易」という部分が良く分かりません。
複雑ならば変更は困難なのが普通じゃないでしょうか？
「内部構造が非常に分かりにくい」という欠点をもっていて「図にするのは非常に困難」からもそのように感じます。
ああ、だから普及しないのですね。

あと、ベルトコンベアの説明はどちらかというと「ウォーターフォール」を想像しました。

223 ：仕様書無しさん：2007/11/07(水) 22:42:29

内部構造が複雑だろうが単純だろうが、使い手が中身を意識する必要がない状態をつくること
それを「抽象化」って呼ぶんだけど、そうそううまくはいかないね

224 ：仕様書無しさん：2007/11/07(水) 22:54:42

>>222
>「複雑に絡み合っている」～「変更が容易」という部分が良く分かりません。
俺は
「それぞれのタンクが自身の責務だけを果たすのだから、
　変更にかかるリスクを軽減できる」
という解釈をしてるんだが。
　変更したいタンクの利用者なら、別のタンクに交換すればいい、
または利用方法を変えればいい。タンクそのものの動きを変えたければ
そのタンクの内側だけを変更すればいい。

　複雑に絡ませることが出来る＆変更も容易にできるってことだろ。

225 ：仕様書無しさん：2007/11/07(水) 23:17:39

オブジェクト指向とは、無邪気な幼児の落書きみたいなもの。
大きくて便利なメモリという名の画用紙に向かい、クレヨンの代わりにキーボードを
使って電気信号を書きなぐっているようなもの。
書いてる本人は嬉しいだろうが、傍から見てると、何を書いているやら訳の分からない
不思議な抽象画だ。それを見て喜んでいるのは馬鹿親ぐらいか。
ピカソが描くなら抽象画も芸術となろうが、幼児のものはただの落書き、お絵書きだ。
オブジェクトといっておきながら、現実にものがあるわけではない。勝手に脳内で俺様
イメージを膨らませ、イメージとイメージを繋ぎ合わせて、悦に浸っていらっしゃる。
妄想だよね。本当のオブジェクトは現実世界にあるんだぜ。ピカソの絵も絵画として
現実世界に存在するから価値があるんだ。
ま、夢見ることもたまには大事なことだけどさ。もっと現実をみようよ。

226 ：仕様書無しさん：2007/11/07(水) 23:39:47

幼児に芸術性のある抽象画を描くのは無理だ。おとなしく粘土でもこねてろ。

227 ：仕様書無しさん：2007/11/07(水) 23:50:53

芸術だと思うのが思い上がり
オブジェクト指向ぐらいは、誰だってできるし
もう、十分普及している。

228 ：仕様書無しさん：2007/11/07(水) 23:50:57

>>225
お前の文章、オブジェクト指向だけじゃなくて
ソフトウェア開発全般に対してあてはまるぞ。
単語を「構造化プログラミング」に置き換えても文意が通ってしまう。
でも限られたＣＰＵとメモリで計算させにゃならんのだから、
何らかの特徴抽出は必要だと思うんだが。（オブジェクト指向に限らず）

229 ：仕様書無しさん：2007/11/08(木) 00:27:02

>>224
タンクとタンクを結ぶ管の、複雑な絡み方を変えるのは容易ではないかもしれないが、
タンクそのものの交換は容易って事かな。

システムの複雑さはナントカ指向によるものではないですよね。
>>182だと、「複雑に絡み合っている」という言い切り方が、「オブジェクト指向にすると複雑になる」と読めたので。。。

230 ：224：2007/11/08(木) 01:11:15

個人的な話だが、「複雑」というと、いまやってる仕事と照らし合わせてしまう。
C で書かれた構造体＆関数だらけのプログラムの修正なんだが、
いわゆるカプセル化の概念が全く無い。

ＯＯにある程度慣れた後でこういうコードを修正するのはちょっと辛い。
というのも、構造体によって変数がグループ化されているだけだから、
その一つを書き換えようにも、どこで初期化されてどこで参照されるのか
いちいち確認しないといけない。
　「ちょこちょこしたデータ操作はクラスが適当にやってくれる」
ってだけで、どんだけ楽してるのか再確認させられる。

　まぁ、そのコードの構造化がヘタクソというのも一因ではあるが。

231 ：仕様書無しさん：2007/11/08(木) 02:29:42

おじゃばを相手にするのはもうやめようや
無能からかってもしょーがねーし
自ら「さま」なんぞを付けておきながらタンクで自爆する程度の奴だぞ
挙句の果てに逆ギレ
どーしよーもねーじゃん、こんな奴

232 ：仕様書無しさん：2007/11/08(木) 04:32:10

>>231
いいこといってるのに
なんでそんな変な口調なのか

233 ：仕様書無しさん：2007/11/08(木) 05:39:46

おじゃばはたとえ話をするととたんにgdgdになるからなぁ。

234 ：仕様書無しさん：2007/11/08(木) 09:04:07

おい、失礼なこと言うなよ
たとえ話をするとｇｄｇｄだと？
たとえ話を「しなくても」ｇｄｇｄの間違いだろ

235 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/08(木) 10:10:46

>>220
上辺だけの的を外した説明だとの認識はあるのか。
それなら上辺だけでない的を射た説明をしてみればいいんじゃね？

>>221
到達指標を自分で設定すればいい。
抽象化の概念だけなら説明出来るだろう。

>>222
224と229が説明している。
また229の言う通り、正確に言うとシステムの複雑さはOOのためではなく、見通しの悪さがOOの特徴となる。

236 ：仕様書無しさん：2007/11/08(木) 11:32:30

自分がまともな説明出来ないことは認めたわけですか
素直に謝れよ
くだらんコテだな

237 ：仕様書無しさん：2007/11/08(木) 11:35:01

補足がなければ理解できないor補足があっても理解できないなら
例えとしては不合格

まずは補足してくれたヤツに感謝しろよアホコテ

238 ：仕様書無しさん：2007/11/08(木) 22:44:12

おじゃばが言うように新宿中村屋のチキンCurryはすごいらしい。
なんで、ここのCurryがすごいのかと言うと、ここのチキンCurryのメニュー名は
Haskell B. Curryというんだよ。とにかく中村屋でHaskell B. Curryを食え！

239 ：仕様書無しさん：2007/11/08(木) 23:52:16

また自演

240 ：仕様書無しさん：2007/11/09(金) 00:47:06

具としてチキンだけが束縛されてて、他は好きなのが選べるってわけか

241 ：仕様書無しさん：2007/11/09(金) 11:16:39

人格障害者

242 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/09(金) 22:01:28

>>236
読んでないのか、読んでいて間違えているのか考えると、読んでないと考えた方が自然だ。
なぜならそんなに難しい事は書いてないからだ。少しは読めよ。

>>237
237が読んでないとしても、236と同様の間違いをしているのを考えると、
236と237が同じ人間だと考えるのが自然だ。また分身の術か？

243 ：仕様書無しさん：2007/11/10(土) 00:09:42

泣き言ならチラシの裏に書いてくれます？

つーかお前の文章って何故そんなに冗長なの？
どうやったらそんな文章を書けるようになるの？
不思議

244 ：仕様書無しさん：2007/11/10(土) 00:16:53

おじゃばって、小学生の頃に、学校の先生に人の話を聞きなさいと
って、いわれなかったっか？

245 ：仕様書無しさん：2007/11/10(土) 01:41:24

冗長さがjavaの回りくどさとマッチして、そこだけは名は体を表してるな、おじゃばは。

246 ：仕様書無しさん：2007/11/10(土) 02:06:43

ひ～や～くぅ～ぶ～んんんん？んんはぁ～～～～～～いぃっけぇぇんにぃぃ～～～～にぃぃぃぃぃ～～～～～～～～しぃぃ～～～～～～～～～かずぅぅうぅぅぅぅぅぅうぅぅううううぅぅぅぅうぅぅぅぅぅうぅぅぅぅぅぅぅぅっうUeうew

247 ：仕様書無しさん：2007/11/10(土) 13:47:38

>>246
お前、キチガイだろ！

248 ：仕様書無しさん：2007/11/10(土) 14:41:17

先ほどの書き込みに不適切な表現がありましたことをお詫び申し上げます。

249 ：仕様書無しさん：2007/11/10(土) 14:54:16

ココはおじゃば＆コテ叩き、そして、キチガイスレです。

土日の主役はおじゃばに代わってキチガイ>>246が主役になります。

250 ：仕様書無しさん：2007/11/10(土) 15:21:21

>>249
伊賀知己の場合は、人気がないから
一人でさわいでいるだけだろう。誰も相手にしてないし。

251 ：仕様書無しさん：2007/11/10(土) 16:04:20

>>230
上手い人は、どんな言語でも、ＯＯに近いことをやっていたけど、やっぱ１％にも満たないのが現実。
実際、そういったことがあって、馬鹿が糞コード書かないようにってことで、オブジェクト指向ってのが生まれたんだし。
それを実体験で理解できたことは良いことだよ。
まぁ結局へたくそは、何使っても、だめなんだけど・・・。

252 ：仕様書無しさん：2007/11/10(土) 16:44:36

>>251 自分のこと言ってるだけあって説得力あるな。
特に、まぁ結局へたくそは、何使っても、だめなんだけど・・・。
自己嫌悪におちいりもんもんとした日々を送ってるんじゃないか？

253 ：仕様書無しさん：2007/11/10(土) 17:02:01

釣って釣られてまた釣って。
人生釣ってなんぼ。釣られたら終わりでやんす。

254 ：仕様書無しさん：2007/11/11(日) 00:29:31

なぜオブジェクト指向は普及しないのか

● オブジェクト指向はバカには理解できない
→ つまりバカはオブジェクト指向設計ができない
→ しかしプログラマのほとんどはバカ
→ 従ってほとんどのプログラマがオブジェクト指向設計ができない
→ 従って普及しない
以上

255 ：仕様書無しさん：2007/11/11(日) 07:50:01

バカほどオブジェクト指向を語りたがる

以上

256 ：仕様書無しさん：2007/11/11(日) 13:21:13

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　頭が悪い子の独演会

257 ：仕様書無しさん：2007/11/11(日) 14:25:43

苛めいくない！。
みんな、おじゃばに182の訂正・続きをしてもらおうぜ！

余計なあおりなしな！
淡々とやってもらおう。

258 ：仕様書無しさん：2007/11/12(月) 04:01:57

>>254
オブジェクト指向はプログラマーももちろんだけど、
それ以上に設計者こそ理解しなけりゃならん。
設計も含めた開発作業の中で「唯一」正解があるのは業務仕様であって
設計は唯一正解なんてのはないし。
より良い設計か、間違ってるかのどっちか。

オブジェクト指向があまり得意でない設計者や実装者は
共通関数を集めたスーパークラスを作って
クラス抽出や抽象クラスが無い設計にしたりする。

抽象的な名詞を使ったクラス設計をできるのが、
オブジェクト指向を理解してるってことだと思うなあ。

259 ：仕様書無しさん：2007/11/12(月) 05:28:28

>257
それが一番のイジメじゃまいか

260 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/12(月) 11:42:15

>>257
訂正は無い。
なぜなら229は俺に対する確認であって、235はそれに対する回答だからだ。
良く読めば分かると思うが。

>>258
いるいる、共通関数集めてクラスにする奴。
あと、C++で何でもで#defineにする奴。

261 ：仕様書無しさん：2007/11/12(月) 21:22:47

何でもで？

262 ：仕様書無しさん：2007/11/12(月) 21:34:25

C++で#defineとか言ってる時点でお察し

263 ：仕様書無しさん：2007/11/12(月) 22:22:39

はいはい、電波さんに障らないでね。危険ですよ。噛み付きますからね。
餌も与えないように。餓死するくらいちょうどよいんだから。

264 ：仕様書無しさん：2007/11/12(月) 22:25:46

はーい

265 ：仕様書無しさん：2007/11/13(火) 00:27:08

何で(･∀･)もで

266 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/13(火) 09:16:15

うへ

267 ：仕様書無しさん：2007/11/13(火) 11:18:10

お前も冗長じゃないレスできるんだな！
やればできるじゃないか！

268 ：仕様書無しさん：2007/11/13(火) 21:14:19

何で(･∀･)もで、おじゃば、うヘ

269 ：仕様書無しさん：2007/11/13(火) 22:21:16

Part4時代の結論として、おじゃばは頭が弱い子

放置が肝心

270 ：仕様書無しさん：2007/11/13(火) 22:37:40

おじゃば、お座り、お手！

271 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/13(火) 22:42:45

冷えた飯に、ぬるいボンカレーかけて出された気分。

272 ：仕様書無しさん：2007/11/13(火) 22:50:31

それさりげに結構うまいから

相変わらず例えがヘタだな

273 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/13(火) 23:11:00

じゃ冷えて、べとついたカキフライは？

274 ：仕様書無しさん：2007/11/13(火) 23:20:17

OOのできる香具師ってのは、結局ところ、全体のクラス群の設計がびしっとできる香具師だろ。
OOPLマンセーしてるだけの香具師じゃOO見習いだろ。

家を作ったときに若い大工と話したんだが、その大工が自分は家の個別のところは作れるが、
でも、家はちゃんと作れないですよ、家を作れないと大工としては半人前だとか言ってたぞ。
OOだって同じだよな。

275 ：仕様書無しさん：2007/11/13(火) 23:27:32

>>273
俺の弁当のカキフライって、そんな感じだぞ！
ついでに、昨日の残り物ときている、あひゃひゃひゃー

276 ：222=229：2007/11/13(火) 23:41:13

>>235 レスどうも。
>224と229が説明している。
>>222=>>229で、229は>>224を読んでの解釈なので、
直接235の解釈として書かれているのは>>224だけですね。

で、そのタンクはオブジェクト指向で言うところの何ですかね？タンク＝クラス？メソッド？
タンクをつなぐパイプ（あるいは中を流れる液体）が「メッセージ」で、タンク自身の機能が「振る舞い」辺りですかね？

タンクを「関数」とか「サブルーチン」とかに置き換えても通じそうですね。
とすると「見通しの悪さ」はどこから来るんでしょう？
パイプの絡み方＝システムの複雑さは「指向」と無関係とすると、深いクラス階層とかの話・・・？

このタンク、引きずるのは止めたほうがいいですか？

277 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/14(水) 09:16:37

>>274
違います。そんな事は言っていません。

>>275
それ、でかいカキフライ？小さいカキフライ？

>>276
タンクはクラス、パイプはメソッド。
見通しの悪さは、継承されていると、使用したクラス内に目的の処理が書かれていない事による。

278 ：仕様書無しさん：2007/11/14(水) 09:50:41

いや、274は別におじゃばの話をしてるわけじゃないだろ･･･
なんでも自分のことだと思う自意識過剰なとこはなんとかしろよ。
そんなだと教えてる後輩に陰で「あいつガキだからよ～」とか
いわれてそうだなぁ。

279 ：仕様書無しさん：2007/11/14(水) 10:14:59

ガキだから～
より
キチガイだから～
とか言われてる可能性のが高い希ガス

280 ：仕様書無しさん：2007/11/14(水) 12:58:40

>>277
おじゃばはAndroid、http://code.google.com/android/
が出てやほーーーーって基地ってる最中か？
$10 million のawardやるから基地るのもわかるぞ

281 ：仕様書無しさん：2007/11/14(水) 20:33:22

クラス分析もできんくせに
Javaを採用するベンダーのプロパーが多すぎる
場合によっては業務要件すら固まってないのに
言語選定するし

282 ：仕様書無しさん：2007/11/14(水) 20:45:21

それ調達とかインフラ構築のスケジュールの関係でしょうがねんだ

283 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/14(水) 21:49:24

>>278,279
うへ

>>280
それそれ、一応見てみるつもりだ。280応募するのか？
ただ、いろいろ面倒な事があるから、応募は出来ないかもしれないがな。

284 ：仕様書無しさん：2007/11/14(水) 23:16:21

>>283
おれはJavaさっぱりだから、指くわえてるだけだ。
賞金がすごいから、おじゃばの周囲には燃えてる香具師居るんじゃないか。

285 ：仕様書無しさん：2007/11/14(水) 23:27:05

10億ってマジ？
何作ればいいのよ

286 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/14(水) 23:46:40

ああ、アンドロイドなんてコンセプトが古いんだよ。
昔の人はなんでも言いなりになる奴隷をほしがった。
その代用としてアンドロイドを考え出したんだけど
２１世紀の現代ではアンドロイドなんか欲しがるやつは居ないね。

287 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/14(水) 23:47:20

ドラえもんのポケットさえ手に入れればドラえもんいらないだろ？

288 ：仕様書無しさん：2007/11/15(木) 00:00:19

それより、その芋をくれよ

289 ：仕様書無しさん：2007/11/15(木) 00:00:48

芋電球、生きてたのか

290 ：仕様書無しさん：2007/11/15(木) 00:02:08

ロボットじゃないよ、アンドロイドだよ

291 ：仕様書無しさん：2007/11/15(木) 00:02:27

ポケットと話してもつまらんから、やっぱりかわいいアンドロイドはひつやう。

292 ：仕様書無しさん：2007/11/15(木) 00:08:47

ココ電はオナホール派。俺はダッチワイフ派ということでおk？

293 ：仕様書無しさん：2007/11/15(木) 00:10:11

電球が居てなぜかほっとするｗ
おじゃばだけだと痛々しい空気になる。

294 ：仕様書無しさん：2007/11/15(木) 00:32:54

本音としては両方居ないほうがいい

295 ：仕様書無しさん：2007/11/15(木) 00:33:00

ダメな奴を見て安心すんなよ

296 ：仕様書無しさん：2007/11/15(木) 19:50:45

おじゃば氏とココ電球氏は同じスーパークラスを持ちますか？

297 ：仕様書無しさん：2007/11/15(木) 20:13:09

ちがうクラスですが、同じグローバル関数とグローバル変数を同じ名前の関数で使っています。

298 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/15(木) 21:55:17

グローバル変数クラスを作ればそれらしくなるのでわ

299 ：仕様書無しさん：2007/11/15(木) 21:56:19

はいはい
君の出番はもう終わりだよ

300 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/15(木) 21:57:32

おじゃばをどっかよそのスレに誘導して押し付けたほうがよくないか？

301 ：仕様書無しさん：2007/11/15(木) 22:46:50

struct おじゃば電球{
ココ電球　芋；
おじゃば　カレー；
おじゃば電球();
おじゃば電球(おじゃば);
おじゃば電球(ココ電球);
}；

302 ：仕様書無しさん：2007/11/15(木) 23:06:49

コンパイルエラー

303 ：仕様書無しさん：2007/11/15(木) 23:49:19

>>300そのほうがマシ。あいつ芋すら持ってないもん。

304 ：仕様書無しさん：2007/11/16(金) 01:31:43

コテってなんで自演するん？

305 ：仕様書無しさん：2007/11/16(金) 03:11:55

人格障害で他人と会話ができないから

306 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/16(金) 22:07:15

電球生きてたのか。
しかし298の発言を見る限り、OOはマスターしていないようだな。

俺と電球の共通点なんて殆どないぞ。
言語的に共通点となるCも、電球は反構造化で、俺は構造化。
同じグローバル変数なんて考えられんな。

307 ：仕様書無しさん：2007/11/16(金) 22:36:56

お前のほうが遙かに空気が読めないことだけはよくわかった

308 ：仕様書無しさん：2007/11/16(金) 22:51:14

うん！つまりあれだ、空気ちょっとよんだが関係ないって態度取る奴。

309 ：仕様書無しさん：2007/11/16(金) 23:08:12

>>306
共通点は、お互いの土台がCOBOLということだ
そして、２人ともCOBOLに関しては仙人グラマーレベルってことだ

310 ：仕様書無しさん：2007/11/16(金) 23:17:04

同じCOBOLをルーツとする２人だが相反する方向に逝ってしまった。
おじゃば：　COBOL　－＞　理解は全くしていないがOOマンセー
芋電球: COBOL　－＞　OOなんて屁だぜ、やっぱ俺俺流PGスタイルサイコー

311 ：仕様書無しさん：2007/11/16(金) 23:19:38

ｺﾎﾞﾗは間抜けってのを証明したおふたりってことか

312 ：仕様書無しさん：2007/11/16(金) 23:45:17

>>311
おいおい、誰だって歳をとればぼけて来るんだから、そんなこと言うなよ。
二人とも、汎用機全盛の大昔より今もPGしてるんだな。
きっと、今の２,３０のPGが生まれる前からPGしていると思われ。

313 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/17(土) 03:16:30

あほですか
俺は今メンテだから俺流スタイルではない
つうか変なソース直すの大変

314 ：仕様書無しさん：2007/11/17(土) 03:34:58

うん。君はアホだと思うよ。

315 ：仕様書無しさん：2007/11/17(土) 03:50:52

ココ電はアホだが笑えるけど、おじゃばは痛々しいバカだよなぁ。

316 ：仕様書無しさん：2007/11/17(土) 14:38:36

でで電球
>変なソース直すの大変
それ、おまえの書いた俺流スタイルコード直すよりはるかに楽だよ

317 ：仕様書無しさん：2007/11/17(土) 15:56:00

どうせ理解できないし「独自の解釈」しちゃう馬鹿がいるから、
いっそのこと普及しないでほしい
利用価値を掲げて煽られると本当冷や汗出るよ
しかしOOも理解できないなんてどんだけ猿なんだよ死ねよクソども

318 ：仕様書無しさん：2007/11/17(土) 15:58:10

クソはもともと生きてないから死にようがない

319 ：仕様書無しさん：2007/11/17(土) 16:11:50

>>317
来ましたね、土日の基地ガイ

320 ：仕様書無しさん：2007/11/17(土) 23:57:50

今日も一人でシコシコ自作自演か

哀しい人生送ってる人なんだね

321 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/18(日) 00:14:41

例題：　１から９までの数字を表示するプログラムを作れ
市況板で正解者いたぞ

322 ：仕様書無しさん：2007/11/18(日) 00:38:34

echo "１から９までの数字"

323 ：仕様書無しさん：2007/11/18(日) 01:00:39

糸冬

324 ：仕様書無しさん：2007/11/19(月) 00:17:31

おじゃばをおちょくれる用に努力するためにSIPでも勉強しようかなと思う。
職場に資料あるからやってみようかと。
一応専門分野だし(一応言っておくが携帯じゃないよ)。

325 ：仕様書無しさん：2007/11/19(月) 00:53:26

俺の遊び場のC++相談室が1000逝ってないのにdat落ちした、orz

このスレを見ている人はこんなスレも見ています。(ver 0.20)
◆◆曲名がわかりません！ｽﾚｯﾄﾞin洋楽板Vol.104◆◆ [洋楽]
浦和パルコについて語ろう [通販・買い物]
【十字架】キリスト教談話室part374【主の愛】 [心と宗教]
C++相談室 part58 [プログラム]
【COBOL】コボラー集まれ！！！【事務処理】 [プログラム]

COBOLスレはおじゃばと電球って分かるが
浦和パルコ、キリスト教スレへ逝ってるの誰だよ？
ひょっとしておじゃばは浦和住民にしてアーメン経信者か

326 ：仕様書無しさん：2007/11/19(月) 08:14:06

やっぱり宇都宮出身者か

327 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/19(月) 22:56:36

まず、コボラーと言うのはCOBOLしか出来ない人を言う。つまり、俺も電球もコボラーではない。
次にCOBOLをバカにする人は、COBOL以外の単一言語しか出来ない人が多い。
なぜなら多数の言語が出来る人間は、言語に優劣をつける必要がないからだ。
そして単一言語しか出来ない人は、コボラーと本質的には変わらない。

つまり、COBOLをバカにする奴は、コボラーと同じだと言っていい。

328 ：仕様書無しさん：2007/11/19(月) 23:42:55

・・・・・・はぁ？

329 ：仕様書無しさん：2007/11/19(月) 23:44:11

' _ '

330 ：仕様書無しさん：2007/11/20(火) 00:07:16

ここって、COBOL/COBOLerスレだっけ？

331 ：仕様書無しさん：2007/11/20(火) 00:40:08

冗長コテ向け

ヘタな文章とは――

・書き手の言いたいことが明確でなく、主張が伝わってこない
・内容の構成や順序が整理されておらず、わかりにくい
・主張を裏付ける情報がなく、論理的に納得できない
・難しい用語が定義されないまま使われ、意味がわからない
・長い文が続くうえ、冗長な言い回しが多く、読みにくい

332 ：仕様書無しさん：2007/11/20(火) 01:01:40

> まず、コボラーと言うのはCOBOLしか出来ない人を言う。つまり、俺も電球もコボラーではない。
まず、根拠を提示しましょう。
> 次にCOBOLをバカにする人は、COBOL以外の単一言語しか出来ない人が多い。
根拠を提示するのを忘れないようにしましょう。
> なぜなら多数の言語が出来る人間は、言語に優劣をつける必要がないからだ。
妄想や主観を一方的に述べても根拠にはなりません。
> そして単一言語しか出来ない人は、コボラーと本質的には変わらない。
勝手な決めつけをするのはやめましょう。

> つまり、COBOLをバカにする奴は、コボラーと同じだと言っていい。
上の段落をどう解釈しても論理的に繋がりません。

全体的に何を主張したいのか、よくわかりません。
0点です。もっとがんばりましょう。

333 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/20(火) 09:08:43

>>332
> まず、根拠を提示しましょう。
俺は少なくとも、C/C++、Javaが出来る。電球は俺の知る限りでもアセンブラとCが出来る。
だから、COBOLしか出来ないコボラーではない。

> 根拠を提示するのを忘れないようにしましょう。
> 妄想や主観を一方的に述べても根拠にはなりません。
根拠は提示している。妄想や主観と言われても根拠は根拠だ。

> そして単一言語しか出来ない人は、コボラーと本質的には変わらない。
コボラーの問題点は「向上心の喪失」だ。COBOLを覚えてしまってそれで十分と思って、それ以上
学習しなくなるのが問題と言える。Cしか出来ないC厨も言語が変わっただけで向上心がないのは一緒だろう。

> 全体的に何を主張したいのか、よくわかりません。
「つまり、COBOLをバカにする奴は、コボラーと同じだと言っていい。」と言っているだろう。
読んでいるのか？一行読むと前の文章を忘れるのか？

まず、理解する気がない人には採点は無理だ。

334 ：仕様書無しさん：2007/11/20(火) 09:36:55

>>333
お前がC/C++できるっつても誰も納得しないと思うぞ。
Javaもかなりあやしぃしな。ん、そうするとCOBOLer以下だな。

たしかにコボラーではないな。それには同意しよう。納得。

335 ：仕様書無しさん：2007/11/20(火) 10:53:02

お前真性のアホだろ
「複数言語が出来る＝コボラでない」
この定義はどこから出たんだよｗ
その根拠を提示しろと言われてるのをスルーして
何事も無かったかのように「だから、」とか言われても困る

336 ：仕様書無しさん：2007/11/20(火) 12:55:49

>>1
ダブルオーセブン

337 ：仕様書無しさん：2007/11/20(火) 15:43:33

たとえコボラーであってもおじゃばがC/C++知ってるっつ浅いレベルなら
JCLだってDL/Iだって人によってはSQLだって知ってる。
カタプロだって切れるのもいる。
それくらいわかってから「俺はコボラーじゃねえ」言えこのタコが。

338 ：仕様書無しさん：2007/11/20(火) 16:25:14

>>324
つ　http://www.atmarkit.co.jp/fnetwork/tanpatsu/21fiveminsip/01.html

このスレに、おじゃば、電球以外でProのCOBOL使い居るのか？

339 ：仕様書無しさん：2007/11/20(火) 17:44:31

>>338
俺、COBOL使ってたよ。1年半くらい前までCOBOLerの中で仕事してた。
オブジェクト指向は無かった。

340 ：仕様書無しさん：2007/11/20(火) 21:04:29

おじゃば氏のレスは「つまり」とか「なぜなら」でつないでいる2つの文章の関連性が分かり難いんです。
また、なにか指摘が入ると、1レス目と違うことを急に付け足すので、「どっちなの？」って感じてしまいます。

あと、つねに断定的な口調なので、事実を述べたいのか、自分なりの解釈や意見を述べたいのか分かりにくいです。
「～と思う」とか「～ではないだろうか。」ぐらいの方が反発も少ないと思います。

ところで何故いきなり、COBOLerの話になったんでしょう？
「自分はコボラーではない」という主張は >>325に対するものだとして、
このスレでCOBOLをバカにするレスってありました？

341 ：仕様書無しさん：2007/11/20(火) 21:12:22

>>340
いや、前に「～と思う」ばっかやって馬鹿にされたんでやめたのよ。
極端から極端に走る、程度を知らないからバカなんよ、おじゃばは。

342 ：仕様書無しさん：2007/11/20(火) 22:28:43

>>340
確かにCOBOLの話は出てるが、COBOLerの話(COBOLerをバカにする話)は出てないのに、
何でおじゃばがCOBOLerの話を熱く語るのか解らんが、
吾思うに....
こぼるさまだった時にさんざんバカにされ（時代遅れの古典言語しかできないCOBOLerとかバカにされたのかな）、
それがトラウマになりCOBOLの話題になると勝手に暴走モードに入り、自分はCOBOLerじゃない、
涙ぐましい努力をしてCOBOLだけでなく自称C/C++も出来るおじゃばさまになたんだと言いたいんじゃないか。
そして、いつしかCOBOLerを蔑むように人間になってしまった。

343 ：仕様書無しさん：2007/11/20(火) 22:33:58

最後の文修正
そして、いつしかCOBOLerを蔑むような人間になってしまった。

>>339
自分はCOBOLerと仕事したことがないから分からんが、
実際のCOBOLerってどんな感じ

344 ：仕様書無しさん：2007/11/20(火) 23:11:39

>>309 がCOBOLerを引っ張り出してきて、おじゃばはそれに敢えて乗っかってるだけだろ。
分かっててやってるおじゃばは相当なMなんだろな。

しかし、そのおじゃばに敢えて釣られてるヤツと、本当に釣られてるヤツがいるな。
本当に釣られている一部の低脳が騒ぐから「COBOLer」って単語が一人歩きしてるじゃねぇか。
そうだろう？ >>335 >>337

345 ：仕様書無しさん：2007/11/20(火) 23:19:46

1 + 2 は 3である。

346 ：仕様書無しさん：2007/11/21(水) 00:33:54

んなこたーない

347 ：仕様書無しさん：2007/11/21(水) 00:51:11

> 事実を述べたいのか、自分なりの解釈や意見を述べたいのか分かりにくいです。

何度も既出だが、現象としての事実以外に客観性を持つ事実など存在せんのだから
なんらかの意見は全て誰かの解釈に拠るものに決まってるだろ
だからいちいち意見に「と思う」なんてつけたりしないの
いい加減覚えろ

348 ：仕様書無しさん：2007/11/21(水) 00:53:53

それはさておき妄想を客観的事実のように語られるとウザいわけで

349 ：仕様書無しさん：2007/11/21(水) 01:30:04

ひょっとして、COBOLer→向上心無し→オブジェクト指向普及しない。
とつながるの？

350 ：仕様書無しさん：2007/11/21(水) 12:12:32

キチガイ常駐スレ

351 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/21(水) 21:33:10

>>349
やべ、初めて先読みされた。
この段階で良く分かったな。タダモノじゃない。

352 ：仕様書無しさん：2007/11/21(水) 22:25:09

ひゅー、ひゅー、今日は寒いな、身にしみる寒さだよ
寒い日に寒いレス読むと、しばれるよ、おじゃば

353 ：仕様書無しさん：2007/11/21(水) 22:27:30

こたつが恋しいけど電気毛布で我慢なのです

354 ：仕様書無しさん：2007/11/21(水) 23:48:23

おじゃばがC++できるって？
一年だが半年前に暇なんで勉強するとかやってなかったっけ。

あれから何回か納品したんかい？

355 ：仕様書無しさん：2007/11/22(木) 00:09:17

#defineとか言ってるぐらいだから

356 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/22(木) 01:35:18

Java使いにもコボラーコード書くのいるぞ
自覚が無いだけこまったもんだ

357 ：仕様書無しさん：2007/11/22(木) 01:47:55

コボラコードもだめ、OOPもだめって
お前はどんなコーディングスタイルなんだよ

358 ：仕様書無しさん：2007/11/22(木) 07:11:26

Javaで一番許せないのが

if(hoge.equals("hage"))

359 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/22(木) 09:32:47

>>354
したよ。

>>355
ああ、俺も#defineを完全排除したいのだが、文字列の場合が分からない。
数値は当然、enum使っているが、文字列の場合はどうするんだ？教えてくれ。

>>356
つーか電球、COBOLは出来ないだろう？

>>358
それはCと比べてと言う事か？C++と比べてと言う事か？

360 ：仕様書無しさん：2007/11/22(木) 09:41:11

strcmpと何が違うのか

361 ：仕様書無しさん：2007/11/22(木) 11:57:54

== が使えんとか
演算子のオーバーロードが出来んとか
そんなんじゃね

362 ：仕様書無しさん：2007/11/22(木) 13:31:21

すみません
#ifdef _DEBUG_ ～ #endif
みたいなことを Java でしたいのですが
どうすればよいのでしょうか？

363 ：仕様書無しさん：2007/11/22(木) 14:05:22

>>362
アスペクト

364 ：仕様書無しさん：2007/11/22(木) 14:54:36

>>356
下記の人だろ

#define PI 3.14
おじゃば：enum { pi = 3 }; // 以下切捨て
COBOLer(小生）: const double pi = 3.14; // 以下切捨て

#define アホ　おじゃば
おじゃば：????????.....orz
COBOLer: const std::string あほ("おじゃば");
COBOLer: const char * cost あほ =　"おじゃば";

C/C++の質問は
【初心者歓迎】C/C++室 Ver.44【環境依存OK】 [プログラム]
で受け付けております。やさしい先生方が答えてくれますよ。
ただし、この程度のこともわからずに#defineを完全排除と言い、そして、COBOLerを蔑む
ような自惚れたアホはお断りします。

365 ：仕様書無しさん：2007/11/22(木) 22:28:01

雑談スレはここですか？

366 ：仕様書無しさん：2007/11/22(木) 23:16:42

>>363
ありがとうございました

367 ：仕様書無しさん：2007/11/23(金) 11:39:06

へー、何回か納品したんかい。
でもやっぱり、普通にC++嫌い？
やっぱりおじゃばが苦手といった、newとかdeleteとかどう？慣れた？

368 ：仕様書無しさん：2007/11/23(金) 13:39:45

stlとかboost使うとあまり、deleteとか使わないなぁ。スマートポインタ任せ。

369 ：仕様書無しさん：2007/11/23(金) 13:44:36

ま、仕事じゃnewすら許されずにmalloc系関数使うことになるんですけどね！

370 ：仕様書無しさん：2007/11/23(金) 15:19:29

>>367
たった半年で何回か納品って･･･
あ、そうか、納品のやり直しを何回かさせられたのか。納得。

371 ：仕様書無しさん：2007/11/23(金) 15:37:24

1：自分メインで複数同時にやった。
2：サブで複数関わった。
3：下請けで複数の仕事があった。

4：社内向けの小プログラムをやった。

5：バッチプログラムを組んだ。

∞：趣味で作ったプログラムがなぜか納品された。

372 ：仕様書無しさん：2007/11/23(金) 15:45:14

自慢かよshit!!

373 ：仕様書無しさん：2007/11/23(金) 18:04:38

>>371
0:納品、返品が何回も繰り返された

374 ：仕様書無しさん：2007/11/23(金) 19:01:22

7：偽装プロジェクトで納品した事にした。

斜め↑：偽装プロジェクトで納品した事なのに、担当者の誤りで実際に使われた。

375 ：仕様書無しさん：2007/11/23(金) 21:03:06

>>371
＞∞：趣味で作ったプログラムがなぜか納品された。
デバッグツールとか便利ツールなら良くあった。
それに対する機能拡張要望対応に工数が削られても
プロジェクト全体で使える工数が増えないから、
社内の人すら公開するのやめた。

客の便利ツールに対する要望対応の時間　＞　便利ツールで縮まる開発工数
上の人間は何を考えてやがる。
リリース予定に無いモンをリリースすんじゃねぇよ。

便利ツールが存在することは何人足りとも知られてはならない・・・

OO関係ないに愚痴なったｗｗｗｗ
でもスレタイ忘れて投下

376 ：仕様書無しさん：2007/11/23(金) 21:37:04

>>375
その辺の便利ツールは「秘伝のたれ」とでもしておくべし。
つぎたしつぎたしで、ブラックボックスつか一子相伝にする。
そーやってコボラーの人たちは仕事を守ってきたんだ。

377 ：仕様書無しさん：2007/11/24(土) 02:07:51

OOの利点で再利用とか言ってるのは幻想だよな。
OOは責務分析が本筋なので、
業務が変われば完全再利用ができないのは当然なんだけど、
OOブームでいい加減なことを言う書籍が多すぎ。

「世の中はOOで言い表せます」　←「とか言う書籍があるため混乱するのです」
と書籍間で喧嘩。朝日と産経かよ。
どっちも仕事の役にたたんっつーの。

C++/Javaの言語仕様を理解してるPGは多いけど、
「何があるのか」という責務分析・設計ができてりゃ、
再利用なんてありえんってのは分かるもんだけどな。
部品取り程度で。

ってことを上役に説明しても、「前の再利用できるから工数削減で」とか言うし。

378 ：仕様書無しさん：2007/11/24(土) 02:42:05

>>377
業務の責務とクラスの責務をはき違えてる点でクラス設計に失敗している気がする。
クラスの再利用は多くの場合において可能。
そのための継承だったり多態性だったりするわけで。
それを部品取りというのはいくら何でも過小評価ではないかい？

379 ：仕様書無しさん：2007/11/24(土) 02:53:00

ビジネスロジックはあれだが、ユーティリティクラスは再利用できる場合が多いな。

380 ：仕様書無しさん：2007/11/24(土) 04:10:34

それをフレームワークというんじゃない？（以下堂々巡り）

381 ：仕様書無しさん：2007/11/24(土) 04:18:04

>>378
クラスの再利用が多くの場合において可能、
とか、ありえんだろ
>>379が書いてる通り、再利用できるものなんて
せいぜい基本部品の共通化程度
作業のほとんどは業務仕様をどこまでAPに反映させるかがメインだし

382 ：仕様書無しさん：2007/11/24(土) 04:38:07

>381 はCOMを知らんようだ

383 ：仕様書無しさん：2007/11/24(土) 04:44:05

COMで業務仕様を再利用できるとは初耳だ

384 ：仕様書無しさん：2007/11/24(土) 05:13:30

OOで再利用なんて昭和の本だけだろ
保守と拡張性に関するメリットを指摘するのが今の流れ

385 ：仕様書無しさん：2007/11/24(土) 08:49:47

現実にはどこぞの製品のクラスを使うためのクラスを作っているだけのこと。
UIに届くまでね・・・。

クラスの再利用なんてしているか？コピペか削ったり追加してつかうのが
大半だろ？

386 ：仕様書無しさん：2007/11/24(土) 12:04:04

>>378のような新入社員はしょうがないとしても、
分析も検証もせずに「Javaだから再利用できる」というトンデモ仮説で
別業務を進めようとするPMは存在するからな

387 ：仕様書無しさん：2007/11/24(土) 12:41:56

たいていは業務をソフトにあわせるだけでうまくいくのに

388 ：仕様書無しさん：2007/11/24(土) 12:43:45

大抵はハードをソフトにあわせるだけで上手くいくのに

389 ：仕様書無しさん：2007/11/24(土) 12:47:17

大抵はIT化を諦めるだけで上手くいくのに

390 ：仕様書無しさん：2007/11/24(土) 13:22:19

コピペか削ったり追加、<-これを簡単にできるのがOOの最大の利点だろ。
これをクラスの再利用と言うんだよ。部品取りじゃ乞食と思われるぞ。

あとな、OOの利点はコンサルが繁盛するということだ。

391 ：仕様書無しさん：2007/11/24(土) 13:33:49

再利用って、全く違うプログラムに別のプログラムの部品を持っていくことだけじゃねえぞ
>>378の方がまだわかってる感じするな

392 ：仕様書無しさん：2007/11/24(土) 13:35:24

教科書的にはコピペが減るのが再利用の利点のようだが

393 ：仕様書無しさん：2007/11/24(土) 13:42:48

>>390
コピペ・追加・削除がクラスの再利用、
ってそれ、なんていうオレオレ？

394 ：仕様書無しさん：2007/11/24(土) 15:09:08

>>393 & お前ら
広い意味でのクラスの再利用と信じろ！　
いいか、基底から派生させるのもコピペの一種なんだよ！暗黙のコピペとも言う
文句いうなら、先ずはお前の

クラスの再利用　とは何なのか述べろよ

395 ：仕様書無しさん：2007/11/24(土) 15:33:32

いや、クラスの再利用ってソースの変更をしないで行う事によって保全性を
保つって意味合いがあるんじゃなかったっけ？

だから、クラス別にファイルを持っているしインターフェース部分をきっちりする。

当然コピペ・追加・削除は保全されていないことになるので没。

ＣＯＭはそれをバイナリレベルで実現。

396 ：仕様書無しさん：2007/11/24(土) 15:36:30

まず宗教じみた日本語をどうにかしてくれ

397 ：仕様書無しさん：2007/11/24(土) 15:51:12

>>394のオレオレ定義はどっからきてんだ？

398 ：仕様書無しさん：2007/11/24(土) 16:22:32

>>397
長年の人生経験からだ

399 ：仕様書無しさん：2007/11/24(土) 16:23:59

OOをちゃんと理解してる奴が作れば再利用性はある。というか再利用できる部分と
再利用できない部分をクラス階層的にも意識して作り後々の拡張もし易くする。
再利用できないなんていってる奴は自分の下手糞さを自ら暴露してるようなもの。

400 ：仕様書無しさん：2007/11/24(土) 16:25:08

>>396
このスレを見ている人はこんなスレも見ています。(ver 0.20)
【十字架】キリスト教談話室part374【主の愛】 [心と宗教]

神の子イエスか、池田犬作に帰依すればOK

401 ：仕様書無しさん：2007/11/24(土) 17:25:08

>>399の力説と>>381の内容の違いがわからん

402 ：仕様書無しさん：2007/11/24(土) 17:30:10

再利用の定義を勘違いしてるやつは多い
コボルでいうところの流用と同じことをしたいがために、
クラス単位で部品取りすることを再利用と思ってるパターン

403 ：仕様書無しさん：2007/11/24(土) 17:35:18

人間万事再利用が馬

404 ：仕様書無しさん：2007/11/24(土) 17:38:36

>>401
綺麗に解りやすく清書したのが>>399だよ、きっと、なっ>>399

>>402
クラスはモジュール（複数の部品を組み合わせたもの）、で
部品は関数単体じゃね　違う？

405 ：仕様書無しさん：2007/11/24(土) 17:43:32

少なくともオブジェクト指向では手続きとデータとひっくるめて
ひとつの部品と思う

406 ：仕様書無しさん：2007/11/24(土) 17:45:35

一人芝居か

407 ：仕様書無しさん：2007/11/24(土) 17:48:55

おさん・熱弁の人・俺・キチ
4人はいるな

408 ：仕様書無しさん：2007/11/24(土) 17:51:42

人間万事再利用が下手

409 ：仕様書無しさん：2007/11/24(土) 17:58:03

おさん：>>402
熱弁：>>399
俺:>>407
キチ:　となると、自分がキチか

>>405
部品はクラス単位といいたいのか
それとも、クラス内の一部の手続きとそれ用のデータのみを指して部品と言ってるのか

410 ：仕様書無しさん：2007/11/24(土) 18:11:37

「すくなくとも」あるクラスの関数をコピって余所へ持っていくことは
あまりしないし(従って、クラス中の関数のみを切り取って部品とは呼ばないだろうし)、
おそらくいわゆる再利用の定義からもはずれると思う

411 ：仕様書無しさん：2007/11/24(土) 18:15:51

duplicate code

412 ：仕様書無しさん：2007/11/24(土) 18:44:49

関数のみでも十分部品でしょ
リサイクルできるものはなんでもそう
汎化なんてのは分析段階では出てこないんだから、
設計段階になって、「あ、この関数確かあったわ。ここにあれ持ってくるか」
ってのが普通だと思うんだけど

413 ：仕様書無しさん：2007/11/24(土) 18:49:43

話ひろげすぎじゃね？
「オブジェクト指向には再利用性があるかないか」
ここに戻ろうぜ
クラスの関数だけ余所に持っていくことを
以って「オブジェクト指向には再利用性あり」って
結論づけたいのか？

414 ：仕様書無しさん：2007/11/24(土) 18:54:21

結局ちゃんと説明できるやつは居ない。

415 ：仕様書無しさん：2007/11/24(土) 18:55:54

おさん
熱弁
俺
キチ
ゆとり

416 ：仕様書無しさん：2007/11/24(土) 19:00:04

コピペを再利用と呼ばないで！

417 ：仕様書無しさん：2007/11/24(土) 19:26:07

再利用性はあるんだろうけど、他の指向と比べてどうかってことだろ。

再利用ってのは他システム・他プログラムへ持っていくことなのか、
同一システム・プログラム内で繰り返し使うことも含めるのか？

418 ：仕様書無しさん：2007/11/24(土) 19:41:43

同一システムは考慮外でしょ
というより同じことを書くなよ

新規PJの作るときに枯れたライブラリを使うこととなんら変わらない
それがなぜかOOだと再利用しやすいという幻想を信じてるバカコンサルが
現場に負担をかけてるだけのこと

419 ：仕様書無しさん：2007/11/24(土) 19:46:28

クラスの利用性を上げるのにOOは各種の機能が用意しているのだから
利用度を向上するように汁ってことだ。

>>416
クラス(単位）の再利用って、言い換えればクラスのコピペと同じだぞ。

420 ：仕様書無しさん：2007/11/24(土) 19:54:01

>>418
利用と再利用の違いってなんだ。
1度だけ使うのか利用で、何回も使うのは再利用と言うのか？
再利用の場合、元の物を変化させて利用するのも含まないのか？

421 ：仕様書無しさん：2007/11/24(土) 20:05:12

>>418
あくまで一般論の話するぞ
同一システム内どころか、同一プロジェクトで
クラスを継承してA,B業務作ったりA,B画面つくったりすることも
「再利用」なんだよ
それに、OOは呼び出しもとの再利用が出来る分ライブラリしか
使えない環境より有利だわな
OOの再利用性に過度な期待は禁物ってのは確かだが、
間違いなく再利用性もあるし有用でもあるのよ

422 ：仕様書無しさん：2007/11/24(土) 20:07:13

この調子だと月曜日にまたおじゃばが祭りに乗り遅れたと嘆くな。

423 ：仕様書無しさん：2007/11/24(土) 20:07:29

>>420
おまぃ学生か？
状況によって変わるだろ
そのままパクる場合もあれば、「ここはちょい作り直し」とかもあるだろ
「再利用だ！」「いやこれは再利用とは言わない！」とかって何のこだわりだよ

424 ：仕様書無しさん：2007/11/24(土) 20:11:05

fopenは死ぬほど再利用してきた訳だが
これをただの関数としか見れない香具師と
オブジェクトだと理解できている椰子の違いだろうな

425 ：仕様書無しさん：2007/11/24(土) 20:13:00

あれ、変数や構造体は(一応)オブジェクトだけど関数はオブジェクトだっけ？
自身ないんで424以外の人教えてちょんまげ。

426 ：仕様書無しさん：2007/11/24(土) 20:24:57

>>425
つ　Functor

>>423
こだわってるのは>>418だろ
おれは、利用と再利用は利用すると言う意味で同じなんだから
とにかく利用度(利用性）を上げるように汁といいたいんだ。

427 ：仕様書無しさん：2007/11/24(土) 20:25:00

OOの利点として謳われてる再利用の意味は、
他システムに持っていきやすいという意味の方が大きい
これを>>377は幻想だ、とか共通部品しか再利用できんって言ってるわけじゃん

他システムのクラス設計の際に、
汎化は必要なさそう（汎化しない方がラク）ってことが分かりきってる場合に
過去に作ったクラスを利用するためにわざわざ汎化することで工数がかかる、
なんてことになれば本末転倒じゃん

そういう場合は関数だけパクってくる、とかの部品取りってことになるでしょ

428 ：416：2007/11/24(土) 20:30:40

>>419
コピペと、既にあるものを呼び出すのは違う。って言いたいの。
同じ定義を２箇所に書くヤツがいるからヤダ。

429 ：仕様書無しさん：2007/11/24(土) 20:32:41

関数だけパクってこれるようなクラスはそもそもそのクラスの設計が間違っているな。

430 ：仕様書無しさん：2007/11/24(土) 20:41:12

と、学生が申しております

431 ：仕様書無しさん：2007/11/24(土) 20:43:02

>>429
俺は、関数パクってきてそれをいじってクラスに組み込むってやってるぞ
お前はやってないのか？怒らないから正直に言いなさい。

432 ：仕様書無しさん：2007/11/24(土) 20:49:36

> OOの利点として謳われてる再利用の意味は、
> 他システムに持っていきやすいという意味の方が大きい

おまえの脳内だけだろ

433 ：仕様書無しさん：2007/11/24(土) 20:49:39

>>431
やってないなぁ。別のクラスの関数を自分のクラスに組み込むってことは
その関数がどんな考え方で、どんなメンバ変数が必要で、どんなメンバ関数
や外部関数を使ってて、って理解しなけりゃならない。そんなことするぐらい
なら一から作るか、そのクラスごと持ってくるね。そのためにはもともとの
クラスの粒度が小さく作られていることが前提だけどね。

434 ：仕様書無しさん：2007/11/24(土) 20:54:03

関数だけもっていきたいなら、はじめからユーティリティクラスにするなり
ファンクタにするなりするだろ
そうしないで、コピペしてクラスに組み込む理由はなんなのよ

435 ：仕様書無しさん：2007/11/24(土) 20:56:31

>>433
お前頭良いんだな。
俺なんかアルゴリズムのところよくパクって来てるぞ。
インターフェース部解ればOKで、難しいアルゴリズム理解しなくて良いからな。

436 ：仕様書無しさん：2007/11/24(土) 20:58:50

お前迷惑なやつだな

437 ：仕様書無しさん：2007/11/24(土) 21:01:18

>>434
違うんですよー
欲しいのは関数で実装されてるアルゴリズム部分が欲しいんですよ
関数を100％コピーするなんて、バカな俺でもあまりしないのら。

438 ：仕様書無しさん：2007/11/24(土) 21:02:10

>>433
おまぃ、言ってることがヘンじゃないか？
検討もせずに最初から過去システムの再利用を全て否定してることになるだろ

関数を調べるのが嫌だから関数だけ持ってくることをしないのなら、
クラスをまるごと持ってくれば内部の理解をしなくてもいいのか？
違うだろ

439 ：仕様書無しさん：2007/11/24(土) 21:04:21

Generics？

440 ：仕様書無しさん：2007/11/24(土) 21:07:19

>>438
よいクラスはインターフェース設計がしっかりしていてそれ自体は
ブラックボックスとみなせるから、通常は内部の作りまで理解する
必要はない。だけど、クラスの一部だけ切り取って流用したいとな
れば話は別だ。あたりまえの話じゃないか？

441 ：仕様書無しさん：2007/11/24(土) 21:10:05

使ったことないのに畳水練で語る馬鹿が多すぎ

442 ：仕様書無しさん：2007/11/24(土) 21:10:25

お前ら、きれいごと言わずに本当のこと話すんだ
コピペ及びそれに近い行為マンセーだろ
自分でコード書くんじゃなくて、ネットで探してきてコピペしてんだろうが

443 ：仕様書無しさん：2007/11/24(土) 21:10:50

つーか、ファイル処理・ＤＢ処理・文字列処理は関数化して
ラッピングしたクラスを色々使うものだと思うんだが。

444 ：仕様書無しさん：2007/11/24(土) 21:13:32

要はテンプレートとか使ってメタプロしないと解決できないレベルの
再利用についていってるわけか
何作ってるかしらんけど、そんなニッチをもってしてオブジェクト指向の
再利用性全般について一般的な結論をだそうとしても無意味じゃね？

445 ：仕様書無しさん：2007/11/24(土) 21:15:23

>>442
その同じコードを毎回ネットで探すヤツ。

446 ：仕様書無しさん：2007/11/24(土) 21:15:47

>>441
おれは風呂水練だ、水があるから呼吸の練習は出来るお

447 ：仕様書無しさん：2007/11/24(土) 21:23:45

突貫工事で急ぎで仕上げるときはコピペしながら作るケースもあるけど
あとでメンテナンス大変になるの分かってるから
リファクタリングはちゃんとする習慣にしてる

448 ：仕様書無しさん：2007/11/24(土) 21:24:09

俺は水泳は苦手だな

449 ：仕様書無しさん：2007/11/24(土) 21:25:39

水道管工事なら任せろ

450 ：仕様書無しさん：2007/11/24(土) 21:35:44

おまいらって、プロジェクトが替わると、クラスは毎回一から作ってののか？

451 ：仕様書無しさん：2007/11/24(土) 21:39:35

クラス設計レベルからパクるよ
もちろん簡単にいけそうならだけど

452 ：仕様書無しさん：2007/11/24(土) 21:44:20

大体プロジェクトが替わると言語も替わるしね

453 ：仕様書無しさん：2007/11/24(土) 21:59:50

いざ再利用！ってときに、「オブジェクト指向で良かった」ってことはある？
または、「オブジェクト指向なら良かったのに」って思ったことは？

オラは無い。

454 ：仕様書無しさん：2007/11/24(土) 22:02:50

つか、なんも考えないで作ったクラスが再利用できるはずないじゃん
再利用するためにつくるクラスには、最初からそういう狙いがあるのよ
これ基本な

455 ：仕様書無しさん：2007/11/24(土) 22:06:48

再利用じゃないけど
オブジェクト指向だったらよかったのに、ってのは結構ある
特にオーバーロードはすぐにそう思う

456 ：仕様書無しさん：2007/11/24(土) 22:16:22

再利用再利用ってお前ら本当になーんも勉強してないのな。バカばっか。
お前らみたいなクズの作ったプログラムに付き合わされるこっちの身にもなれよ。

457 ：仕様書無しさん：2007/11/24(土) 22:18:40

おまえ、このスレがどんなスレだかわかってないようだな

458 ：仕様書無しさん：2007/11/24(土) 22:57:24

キチガイPGを隔離するスレ

オーバーロードって便利だよな。ところでオーバーライドとどう違うんだ
確か、横に変化するのがオーバーロードで縦に変化するのがオーバーライドだよな

459 ：仕様書無しさん：2007/11/24(土) 23:11:17

死ねば？

460 ：仕様書無しさん：2007/11/24(土) 23:17:23

要隔離キチガイ: >>459

461 ：仕様書無しさん：2007/11/24(土) 23:25:06

要隔離キチガイ: >>460

462 ：仕様書無しさん：2007/11/24(土) 23:32:16

二人とも茶でも飲んでもちつけ

463 ：仕様書無しさん：2007/11/24(土) 23:37:23

>>458の続き、

利用するのがオーバーロードで再利用するのがオーバーライドだ

464 ：仕様書無しさん：2007/11/24(土) 23:50:12

わかったから死ね

465 ：仕様書無しさん：2007/11/24(土) 23:58:44

死ねキチ、死ね以外何か言ってみろ

466 ：仕様書無しさん：2007/11/25(日) 00:05:07

死ぬな

467 ：仕様書無しさん：2007/11/25(日) 00:07:14

うん

468 ：仕様書無しさん：2007/11/25(日) 00:09:01

なにこの、ほのぼのスレ

469 ：仕様書無しさん：2007/11/25(日) 00:53:09

ぼのぼのスレ

470 ：仕様書無しさん：2007/11/25(日) 02:24:21

いじめる？

471 ：仕様書無しさん：2007/11/25(日) 11:58:37

なんで最初にオーバーロードが出て来るんだよ。
継承でなんでも解決しようとするヘタクソなクラス設計はいいかげん止めろ。

オブジェクト指向プログラミングと構造化プログラミングの
決定的な違いはコンストラクタだろうが。

472 ：仕様書無しさん：2007/11/25(日) 12:22:16

むきになりすぎ

473 ：仕様書無しさん：2007/11/25(日) 12:33:06

ムキーッ

474 ：仕様書無しさん：2007/11/25(日) 12:40:07

オーバーロードと継承は関係ないだろ

475 ：471：2007/11/25(日) 12:46:50

馬脚で正直すまんかった（´・ω・`）

476 ：仕様書無しさん：2007/11/25(日) 12:49:15

むきになる　＝　ごだわる、職人だね

今日はオブジェクト指向プログラミングと構造化プログラミングの違いについてか
それはなアクセス制御で出来るか出来ないかだ。
コピペを再利用というのが構造化

477 ：仕様書無しさん：2007/11/25(日) 18:27:33

コピペと構造化は関係がないでそ。
てか構造化プログラミングわかってる？

478 ：仕様書無しさん：2007/11/25(日) 21:43:40

オーバーロードや継承やら基本を分かってない人は
まず言語仕様を覚えてね
クラス分析、クラス設計はその後ね

479 ：仕様書無しさん：2007/11/25(日) 22:22:00

>>477-478
先ずは、おじゃばか電球に弟子入りしろ

480 ：仕様書無しさん：2007/11/25(日) 22:24:00

おじゃばや電球の弟子になるぐらいならこれ読んで自習するよ！！
ttp://en.wikipedia.org/wiki/Object-Oriented_Software_Construction

481 ：仕様書無しさん：2007/11/25(日) 23:21:59

おじゃばや電球の弟子なりたくないと！　信じられんぞなもし
その本は情報工学の土台がしっかりしている人ならお薦めするが、そうでなかったら薦めんぞ。
大学の情報工学科でしっかり基礎を学んだか？そうでないなら、情報工学全般の勉強からはじめろよ
そうそう、おじゃばは博士（情報工学）、電球は博士（電子工学）レベルの教育を大学（院）で受けてると思う。

482 ：仕様書無しさん：2007/11/25(日) 23:37:47

自演乙

483 ：仕様書無しさん：2007/11/25(日) 23:39:37

その本には情報工学や計算機科学の基礎なんて必要ないし
そんなコメントが出てくるのは読んでない証拠だなおじゃばよ

484 ：仕様書無しさん：2007/11/25(日) 23:55:08

>>483 先生

オブジェクト指向プログラミングと構造化プログラミングの
決定的な違いは何ですか？

485 ：仕様書無しさん：2007/11/26(月) 00:08:28

結局再利用は基盤部分のみしかできないということでいいよな

486 ：仕様書無しさん：2007/11/26(月) 00:12:07

月曜日か....

>>485 基盤部分って何よと言われはしないか

487 ：仕様書無しさん：2007/11/26(月) 00:12:46

業務仕様とは関係の無いクラス

488 ：仕様書無しさん：2007/11/26(月) 00:17:36

先生方、おススメの本やサイトがあたたら教えてください。？

489 ：仕様書無しさん：2007/11/26(月) 00:19:57

素直にJPAの使い道がわかりませんっていえば？

490 ：仕様書無しさん：2007/11/26(月) 00:21:41

>>488
新聞

491 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/26(月) 20:47:00

また祭りに乗り遅れたようだ。まあ仕方ない。

>>364
>define アホ　おじゃば
>おじゃば：????????.....orz
>COBOLer: const std::string あほ("おじゃば");
>COBOLer: const char * cost あほ =　"おじゃば";
メンバー変数が初期化出来ないって内容なんだが、3行目はconstなら初期化出来るって事か？
コンパイルエラー出るんだが。
Test.h
------------------------------------------------
class Test{
public:
　　const string DEF1("10");
　　const string DEF2 = "10";
};
------------------------------------------------
両方ダメだぞ？staticを付けてもダメだ。どこに書くんだ？

492 ：仕様書無しさん：2007/11/26(月) 21:08:27

>>491
あいやー......
おじゃば喜べ。もうすぐ始まる祭りの主人公はおじゃばだから確実にに参加できるぞ。
よかったな、おじゃば。
取りあえず、おじゃば　>>471 を-1回読め

493 ：仕様書無しさん：2007/11/26(月) 21:16:17

しまったーーーーーー
俺、おじゃばに釣られちゃった。
>>492を書いてから気づいたよ、orz
おじゃばって、釣うまいな。今頃、俺を笑ってるところかな、＞＜

494 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/26(月) 21:26:44

OOの再利用性については、前にも言ったが、ソース修正時の再利用性を言っている。
つまりOOで作った部品を他のプロジェクトで使うというより、仕様変更になった時に作り直す部分が
少なくて済むという事だ。

比較的、大きなプロジェクトになると、段階リリースになる事が多い。
最初は最低限の機能を提供して、徐々に拡張して行くと言う方式だ。
拡張するに当たり、場合によっては大きな変更が入る可能性もある。
つまり、データ量が増えたのでpostgresからORACLEにしてくれとか、処理が遅いのでファイルから
共有メモリに変更してくれとか、sshの接続が遅いのでコネクションプーリングしてくれなどがある。
適切にOOで作られている場合、構造化に比べて修正量が非常に少なくて済む。
構造化なら運が悪ければ作り直しだ。
修正量が少ないと言う事は、修正時の再利用性が高いと言う事になる。
また、元の仕様に戻す事も簡単だ。多くの場合は使っているクラスを元に戻すだけでいい。
つまり以前のコードも無駄にならない事が多い。これも再利用性が高いと言う事になる。

495 ：仕様書無しさん：2007/11/26(月) 21:45:34

再利用性の高いものを作るコツも教えてくれよ

496 ：仕様書無しさん：2007/11/26(月) 21:49:20

冗長なだけで現実性に欠ける例ばかり

497 ：仕様書無しさん：2007/11/26(月) 21:51:02

>>495 おじゃばに弟子入り汁

498 ：仕様書無しさん：2007/11/26(月) 21:56:27

いや、キーワードだけ聞いてあとは調べるつもりだから

499 ：仕様書無しさん：2007/11/26(月) 22:05:34

>処理が遅いのでファイルから
>共有メモリに変更してくれとか、sshの接続が遅いのでコネクションプーリングしてくれなどがある。

おじゃばのクライアントって、上記のように具体的な改善方法の指示までするのか！
ただ単に　してくれ　＝＞　するの間違い？

500 ：仕様書無しさん：2007/11/26(月) 22:59:28

顧客から繰り出される曖昧な要求を
技術的に一意な表現に翻訳してくれてるだけ

501 ：仕様書無しさん：2007/11/27(火) 08:48:11

OOの再利用は同一システム内の話であればそれなりに通用するけど、
書籍等や「再利用」という言葉だけだと、
他システムに再利用する、という意味があるからな
そこでそこだけに反応しているPMなどが無茶を言うって話でOKだろ？

502 ：仕様書無しさん：2007/11/27(火) 08:50:57

>>499
業務分析能力が低いんだろ
通信量やDB容量などを最初に分析してないからそういう馬鹿な作り直しが発生する

503 ：仕様書無しさん：2007/11/27(火) 09:11:32

アホコテの行動パターン

１．また後付けの言い訳がある
２．指摘をスルーする
３．おれが設計したわけではないと逃げる
４．しばらくいなくなる

504 ：仕様書無しさん：2007/11/27(火) 09:28:15

>>494
再利用なら、疎結合であればOOでも構造化でも作業量に差はないよ。

505 ：仕様書無しさん：2007/11/27(火) 10:10:29

>>503

５．他人の振りして書き込みを続ける

506 ：仕様書無しさん：2007/11/27(火) 11:39:00

　　　　　　　　　　　　　　　　　相変わらずひでぇ自作自演っぷりだな

507 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/27(火) 17:54:07

>>492,493
釣り？意味が分からん。
ちなみに釣りじゃなくてメンバー変数の初期化が、出来る方法があるのか知りたいだけだから、
知っていたら教えてくれ。

>>495
再利用性が高い物を作ろうと意識する必要はない。
状態をフィールド変数（メンバー変数）に、動作をメソッド（メンバー関数）にするように心掛ける。
慣れないうちはクラスを「～する人」と捉えるといいかもしれない。
例：OutputWriter（出力する人）、Tokenizer（トークン切り出しする人）
ただし、それではダメな場合もあるので参考程度にしてくれ。
クラスを動作として捉えるのはNG。
OOでは再利用性が高い物を作ろうと意識していなくても、上記基本原理を守っていれば、
変更が入る度に再利用性の高い物になっていくのが特徴だ。
余計な事は考えずに、必要最小限の機能を実装すればいい。

508 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/27(火) 18:24:22

>>499
450が回答してくれている通り。

>>501
その通り。

>>502
確かに業務分析が甘い場合もあるが、それしか考えられないのか？

>>504
Cで予期せずPostgresからORACLEに変わった時も同じか？

509 ：仕様書無しさん：2007/11/27(火) 20:13:25

Cでも綺麗に作り込んでいれば問題ねーよ
問題があるならお前の作り方がヘタなだけ

つーか嬉々として例にあげてるが
DBがころころ変わる案件なんざ滅多にねーよ

510 ：仕様書無しさん：2007/11/27(火) 21:18:04

>>508
O/Rマッパーでも書いとけ。
そして公開しろ。

511 ：仕様書無しさん：2007/11/27(火) 22:04:57

>>507
結構基本的なことだと思うが。まぁstatic constの方しか使わんけど。
知らんことを知らんと言えるようになったのは進歩だが、
「C++使いの定義」云々言う前には、もうちょいC++勉強して来い。
あとそれから、ちょっとはググれ、な？

---------- Test.cpp --------
#include <iostream>
#include <string>
using namespace std;
class Test{
public:
Test():DEF1("10"){};
~Test(){};
const string DEF1;
static const string DEF2;
};
const string Test::DEF2 = "20";
int main()
{
Test tmp;
cout << tmp.DEF1 << endl;
cout << tmp.DEF2 << endl;
return 0;
}

>>508
＞Cで予期せずPostgresからORACLEに変わった時も同じか？
予期してなけりゃどっちでも同じ。
予期しててもどっちでも同じ。
どっちが予期しやすいかは別問題。

512 ：仕様書無しさん：2007/11/27(火) 22:46:32

コミュニケーション能力が欠如している奴は、
やはり文章力の欠如として現れる
冗長で独りよがりで以下略
誰とは言わんがな

513 ：仕様書無しさん：2007/11/27(火) 22:55:40

書籍やネットでも、いまだに他システムへの再利用のことが書いてあったりする
こういうのはどうすりゃいいんだ？

514 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/28(水) 00:44:00

>>442
コードはそうだね。
構造は自分で作るけど

515 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/28(水) 00:47:36

再利用のセンスは個人差が激しい
ファイル入出力の部分見ればセンスあるかないか一発で判る。

516 ：仕様書無しさん：2007/11/28(水) 01:04:23

あぼーんが多いな

Java本なんかで書いてある他システムへの再利用は無視するのがベター。
クラス設計をまともに出来る時間がある業務ならいいけど、
超短納期の場合や共通部分の抜き出しなんかをやっても意味がない場合は、
上の方に書いてある通り部品取り程度にしか遺産は使えない。

つか、Cの人からすると、DLLで再利用してんじゃん、
って話で、「OOだから再利用しやすい」、なんてことはないんだよね。

517 ：仕様書無しさん：2007/11/28(水) 01:11:00

再利用だけど、状況によるよな。

変えちゃならない根幹部分に仕様変更が入ったりしたらもう・・
（もちろん絶対に変わらないって双方合意（書面上も）取れてる部分が、いともあっさりとか）
終いにゃ仕様書直す野面倒だからクラス増やすなとか、もうねアフォかと・・・

518 ：仕様書無しさん：2007/11/28(水) 02:04:15

どこにでもある風景のようで安心しました

519 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/28(水) 09:48:29

>>509
進歩のない奴だな。それは思考停止したダメ上司が言う言葉だぞ。
奇麗に組めない人が、何で奇麗に組めないのかとか、奇麗に組めるようにするにはどうすればいいのか
考えた事はあるのか？

滅多にない？
事業自体が新規で、小規模で始めて、成功したら大規模にする場合は？
規模の違う顧客が複数付いた場合は？
マシンやソフトのライセンスやサポート（切れ）の関係で、変更しなければならなくなった場合は？
その他にも営業的な問題（多くのDBをサポートしたい）や、経営的な問題（事業統合、縮小）、
単に顧客のワガママなど色々あると思うが。

>>510
俺はJDBC派

520 ：仕様書無しさん：2007/11/28(水) 10:17:04

と、実務でやったこともない奴が妄想で言われてもなぁ。

521 ：仕様書無しさん：2007/11/28(水) 10:28:02

dbmsの変更なんていまどきCOBOLベンダだって想定内だ。
>ttp://www.microfocus.co.jp/manuals/SE22/books/dbcsql.htm
なにもOOPじゃなきゃっつ理由にはならんよ。

522 ：仕様書無しさん：2007/11/28(水) 10:37:53

>519
いずれも現実性に欠ける例だな
もうすこし日常的な例を準備してからわめけと

523 ：仕様書無しさん：2007/11/28(水) 12:39:51

「OOならば再利用性が上がる」その理由は？

524 ：仕様書無しさん：2007/11/28(水) 12:45:44

OCPを満たしていれば再利用性は上がる

525 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/28(水) 20:26:12

>>511
薄々気が付いていると思うが、宣言時に初期化が出来ないのかと言う質問だよ。
やっぱり出来ないって事かな？

予測してなければ同じ？
ちなみにCのPro*Cと、JavaのJDBCは知ってるか？

>>522
現実性に欠ける？
多分、途中から参画したり、自分の担当しか見ていないから、そういう事が起きても気づかないのだろう。
日常的に起きている事だ。もう少しプロジェクト全体や、会社全体の観点で見てみるといい。

>>523
494で解説済み。

526 ：仕様書無しさん：2007/11/28(水) 20:29:22

OOとかはどうでも良くて、要はLSP(DbC)等の原則を満たしているかどうかが大事なように思える
これなら抽象型とかメッセージングとかプロトタイプとか流儀が変わっても通用するし

527 ：仕様書無しさん：2007/11/28(水) 20:33:42

代数や幾何を勉強したことがあるか？
という程度の問題。

なくても、生活はできるけど、それを仕事にはできない。

528 ：仕様書無しさん：2007/11/28(水) 20:56:49

>>525
おじゃば、教えてもらって礼はなしで本当の知りたいことを今まで言わずに
こんなレスか。お前の性格でてるな。
>薄々気が付いていると思うが、宣言時に初期化が出来ないのかと言う質問だよ。
>やっぱり出来ないって事かな？

もう、誰もお前には教えてくれんぞ

529 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/28(水) 20:58:16

>>527
あほか
ポリゴンとかで使うだろ。

530 ：仕様書無しさん：2007/11/28(水) 21:00:27

＞現実性に欠ける？
＞多分、途中から参画したり、自分の担当しか見ていないから、そういう事が起きても気づかないのだろう。
＞日常的に起きている事だ。もう少しプロジェクト全体や、会社全体の観点で見てみるといい。

はぁ？
糞上司の妄言ってレベルだな

531 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/28(水) 21:04:01

>>515の答えを書くが
部品化のセンスのあるやつはファイル入出力を一個のサブルーチンにしている。
センスの無い馬鹿はファイル入出力の箇所に来るたびに　同じような　open　-　closeを延々と書いている。

んでもって　open-close馬鹿ほどオブジェクト指向にはまってる（理解はしていない）傾向が強い。

532 ：仕様書無しさん：2007/11/28(水) 21:09:14

>>525
>>494は
OOは再利用性が高い←OOなら修正量が少なくて済むからだ
という主張だよナ？
じゃあ何故OOなら修正量が少なくて済むの？
OO固有の概念なり性質と結び付けて説明してホスィ。

533 ：仕様書無しさん：2007/11/28(水) 21:09:30

>>531
電球、といわれても、そのセンスのある一個のサブルーチンを
コードで示してもらわないとわからん
つまりだ、百聞は一見にしかずだ。

534 ：仕様書無しさん：2007/11/28(水) 21:11:44

>>532
>>525の最初のレスにあるように
おじゃばは核心を言わないから、聞いても無駄

535 ：仕様書無しさん：2007/11/28(水) 21:13:13

RAIIを使えとか、詳細を公開するなとかそういう意味なんだろう

536 ：仕様書無しさん：2007/11/28(水) 21:16:53

>531
んな当然レベルの話をさもオレすげぇみたいに書かれると寒いんですが

537 ：仕様書無しさん：2007/11/28(水) 21:17:26

>>525
＞薄々気が付いていると思うが、宣言時に初期化が出来ないのかと言う質問だよ。
＞やっぱり出来ないって事かな？

おじゃばがC/C++も良く分かってないことが良く分かるレスだな。

538 ：仕様書無しさん：2007/11/28(水) 21:23:48

>>537　そして、性格もな

539 ：仕様書無しさん：2007/11/28(水) 21:24:56

まぁ、今までやったプロジェクトで作ったクラスが再利用されたことなど、
一度も経験したことないな。

オブジェクト指向であっても、結局今までどおり、
そのプロジェクト限りの一品もので終わるから、
結局、完成するならなんでもいい

540 ：仕様書無しさん：2007/11/28(水) 22:02:54

N、I、Hなどはフロアが違うと別会社だからなあ
社内で資産を共有する発想が無いのか、
結局毎回デスマだし

541 ：ココ電球（∩T∀T)ノ[芋] 　 ◆tIS/.aX84. ：2007/11/28(水) 22:52:00

オセロの中にあるんじゃね？

542 ：仕様書無しさん：2007/11/28(水) 22:54:56

ココ電は相変わらず投げっぱなしだなぁ

543 ：仕様書無しさん：2007/11/28(水) 23:16:33

とういうか、おじゃばはDB変わってもJDBC使っているので変更せずにすむぜ。
Java凄いぜ！いぇい！と言いたいだけじゃないのか？

所で、DB変更した場合そんなに設計変更するのか漏れはSQL文の方言の見直し
位なわけだが、そんなに見直しするの？
純粋Cでも全体を見回すほどの変更があるのか疑問なわけだが・・・。

そもそも、DBチューニングで吸収する分類じゃないか、漏れはそういう風に
もっていくけど。

544 ：仕様書無しさん：2007/11/28(水) 23:39:07

>>525
＞ちなみにCのPro*Cと、JavaのJDBCは知ってるか？
Pro*Cは知ってるがJDBCは知らん。想像は付くがな。

その違いは言語で提供されてるフレームワークの問題で、
構造化とオブジェクト指向の問題じゃねぇよ。

そもそもPro*Cが構造化的に微妙なんであって、
共通インターフェースを用意したけりゃODBCかなんか使え。

>>543
興味で若干触っただけなんで、あんま詳しく知らんのだけど。
ちょいと前は埋め込みSQLのサーバごとの方言がキツくて
移植はすんごい手間だった、とかな感じだった気がしたが、
最近はそうでもないの？

545 ：仕様書無しさん：2007/11/28(水) 23:58:06

仕事でやってる場合は、DBが変わるなんて状況になれば、
実際にコードの修正がほとんどなくても、
全部テストやりなおしの、全コードの見直しで、
問題ないことを証明せにゃならん。

546 ：仕様書無しさん：2007/11/29(木) 00:07:16

DBがころころ変わるのが前提なら
最初から全部動作するように製造＆テスト
コード変更無しで切り替えれるようにしておく

547 ：仕様書無しさん：2007/11/29(木) 00:09:42

しかしDBが頻繁に変わるようなプロジェクトは
まともにテストが自動化されていないという

548 ：仕様書無しさん：2007/11/29(木) 00:51:09

>>539
末端クラスしか使ってないからそうなる

549 ：仕様書無しさん：2007/11/29(木) 06:34:50

>>101
ディスコ/クラブ＝サブカルチャー＝ヒッピー＝アランケイ/ジョブス=OO

550 ：仕様書無しさん：2007/11/29(木) 08:15:09

Pro*Cを選択してる時点で終わってる
oo4oでインターフェース統一しておけばDBが変わっても
業務側はSQLの方言対応のみで済む

アホコテがいうPro*Cは採用した時点で全部書き直しが発生する
OOとかの問題ではないし、
根本的にアホコテがC/Pro*Cを知らずにいい加減なことを書いてるのがわかる

ついでに言えば、
なぜアホコテは自分が嫌われるのかを自問自答しろ

551 ：仕様書無しさん：2007/11/29(木) 08:55:04

技術力よりプライドの方が大きすぎる奴だからなあ

552 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/29(木) 09:22:01

>>528
それは済まなかった。長文で解説してもらったのに悪かった。
DEF2はともかく、DEF1の使い方は知らなかったから、511には礼を言っておこう。ありがとう。

>>530
つーかどんな仕事してるんだ？

>>531
サブルーチンってクラス？メソッド（関数）？

>>532
OOの最も重要な要素は「抽象化」だ。
例えば入出力を抽象化する事によって、ファイルやリモートファイル（通信）やメモリにも対応する。
DB操作（検索、登録、更新、削除）を抽象化する事によって、各種DBやファイル等にも対応する。
構造化の場合は外部IFの所のみ抽象化しているが、OOの場合は基本的に全てのクラス単位で
抽象化されている。そのため変更が容易となる。

553 ：仕様書無しさん：2007/11/29(木) 11:11:06

おまえは説明をもっと具象化しろ。

っつと蛇口タンク出しちゃう馬鹿だからいいですもう。

554 ：仕様書無しさん：2007/11/29(木) 19:57:03

>つーかどんな仕事してるんだ？
この問いは貴様に返して差し上げよう
まともな実務経験のある人間のレスとは思えんのでな

555 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/29(木) 19:57:51

>>537
で、メンバー変数の宣言時初期化は結局出来るのか、出来ないのか？

>>539
一度もないって事はないだろう？
つーか、仕様変更が入った時に良く分かるんだよ。それがないって事は作り逃げか？

>>543
ORACLEのPro*Cから、Postgresのlibpqに変更してみ。

>>544
つーか、JDBC知らないのでなくて、Java知らないのだろう？
残念ながら、Java知らないようでは話にならない。
JavaもJDBCと同じように「想像がつく」と言うなら、そんな言い訳する前に勉強した方がいい。

>>550
俺がPro*Cを知らないと言う根拠はあるのか？
INDICATORの使い方と、makefileの書き方でも説明すればいいかな？
あと、言語の問題でないというなら、libpqとかも知っておく必要があるのではないかな？
それでもPro*Cだけが特殊だと言えるのか？

556 ：仕様書無しさん：2007/11/29(木) 20:10:45

お前がJDBC理解してるようには到底思えんが
その辺りはスルーして差し上げたほうが良いでしょうか？

557 ：仕様書無しさん：2007/11/29(木) 20:26:28

>>ORACLEのPro*Cから、Postgresのlibpqに変更してみ。

具体的だな。おじゃば自身又は身の回りでやったの。
でもまあ、正直そこまでやったら、仕切りなおしだろ？

まあ、なぜか構造体をDBと読んでいてそれを、本当のDBを使って処理を
行うようにするというのも世にあるわけだが。

おじゃば、手心は必要ないぞ。それ位なら、ちょっとあっち逝けばそれ位できる自信はあったりする。
ORACLEのPro*CもPostgresのlibpqも全くしらないのだが、やれといえばやるがな。

558 ：仕様書無しさん：2007/11/29(木) 20:28:26

話題がしっかり鈴木高弘の十八番ﾈﾀになっているあたりが
笑えた

559 ：仕様書無しさん：2007/11/29(木) 20:37:23

>>556
そりゃ、544のODBCという言葉をスルーしている事から明らかだろう。

560 ：仕様書無しさん：2007/11/29(木) 21:27:51

>>555
俺、>>537や>>511先生じゃないが
C++入門レベルの俺でも知っていること（と思う）を教えてくれって、
すげー恥ずかしいぞ。まさしく>>537の言うとおりだぞ。
これでも、見てね。礼はイランからね。

#include <iostream>
#include <string>
using namespace std;
class Test{
static const bool ojabaCppBeginner = true;
public:
const string DEF1;
static const string DEF2;
Test():DEF1("10"){};
~Test(){};
bool isOjabaBeginner() const{ return ojabaCppBeginner; }
};
const string Test::DEF2 = "20";

int main()
{
Test tmp;
cout << tmp.DEF1 << endl;
cout << tmp.DEF2 << endl;
if(tmp.isOjabaBeginner() ) cout << "おじゃばはど素人、人に聞く前に勉強しろ" << endl;
return 0;
}

561 ：仕様書無しさん：2007/11/29(木) 22:46:23

もうアホコテの独善トークはどーでもよくね？
OOの話題に戻そうや

562 ：仕様書無しさん：2007/11/29(木) 23:25:27

これまでの流れで分かったこと
・OOの謳い文句の一つである再利用だが、実は同一システム内でしか適用されにくい
・インターフェースを統一すればよい、などと誰でも分かってることをひしこいてに言うと嫌われる
・例えば、のあとに続く文章にろくなことは書かれていない
・容易になる容易になる、との連呼に根拠はない　あったとしても？「おれが根拠」
・Pro*Cとlibpqという、プリコンパイラとインターフェースの違いも分からん奴がいる
・誰か知ったか馬鹿にO○○を教えてあげれ　マジで知らんようだ
・ヤフーでググレカス

563 ：仕様書無しさん：2007/11/29(木) 23:32:14

>> おじゃば
560 みたいな無能がでしゃばるから教えてやる。
C++ では宣言時初期化は不可能だ。
唯一可能なのは enum ハックだけだ。

564 ：仕様書無しさん：2007/11/29(木) 23:36:40

「定義」と「宣言」が分かっていない

565 ：仕様書無しさん：2007/11/29(木) 23:54:13

>>563先生、おいらが一生懸命>>560のコード書いたのに
先生、やだな、ほんと、おじゃばが勉強しなくなるよ。

>>おじゃば
しょうがないな、答えはenumハックと>>560に示すようにstatic のint,bool等のクラス定数はOK
ほかは定義時しか出来ん
あとは>>563先生に聞いてくれ

566 ：仕様書無しさん：2007/11/30(金) 07:25:27

ほんと、このスレ見てると
再利用性（笑）
としか思えないなぁ。

567 ：仕様書無しさん：2007/11/30(金) 08:09:38

実際再利用性(ｗだろ。
某MSの某VC++の某糞MFCで作っても再利用(ｗだからな。
新人であればあるほど再利用(ｗを素晴らしく活用していることになる。

ぶっちゃけ、OOは糞コード作るなよ(怒。という意味合いでしかない。

568 ：仕様書無しさん：2007/11/30(金) 10:22:06

今日の自分は明日の他人だ

これ基本な

569 ：仕様書無しさん：2007/11/30(金) 12:25:40

長文のクセにOOに全く関係ないけど・・・

>>563,>>565,おじゃば
おじゃばだけなら放っとこうかと思ったけど。

定義は宣言の1つのカテゴリーであって、
「クラス定義内におけるメンバ変数の宣言で初期化子を持てるのは、
　定値な整数型と列挙型の静的メンバだけ」
という話。

で、「クラス定義内の定値な整数型と列挙型の静的メンバの宣言」は定義ではない。
他のケースだと初期化子付けると勝手に定義になるかエラーになるかなので、
慣例的に宣言が定義である場合は「宣言する」とは言わずに「定義する」と言うから
「C++では、原則宣言時初期化(宣言する時に初期化する)は出来ない」ってのは間違えてはないと思う。
# 規格だと「定義する」もまとめて「宣言する」って書いてあったり、分けてたり色々だったよーな･･･

>>563のenumだけってのは、古い規格だとそうだったよーな。どうだっけ？

>>565
コード書くには問題ないと思うけど、もうちょいガンバレ。
class Test{
　　int i; // コレ、定義な
　　const string DEF1; // こっちも定義な
　　static const string DEF2; //コレは定義じゃない
　　・・・
};

間違えてたら誰かフォロー頼む。

570 ：仕様書無しさん：2007/11/30(金) 19:18:34

おれ、>>565
>>569先生ってすごいな。ありがとーーーー熱烈感謝

用語の意味を正しく（厳密に）理解し、そして、正しい用語を用いなければならないと分かってても、
おいら、俺俺なんちゃって理解を、俺俺なんちゃって用語・表現で説明するからね。
>>569先生を少しは見習わないといけないな。

>定義は宣言の1つのカテゴリー
知らんかった。

>「クラス定義内におけるメンバ変数の宣言で初期化子を持てるのは、
>　定値な整数型と列挙型の静的メンバだけ」
これが正しい用語を用いた説明か...俺には無理だな。

>「クラス定義内の定値な整数型と列挙型の静的メンバの宣言」は定義ではない。
enumも含まれたのか....
おいらはstatic変数（除く初期化付きconst整数型）は宣言と理解し、だから、使うときは要定義（正しい用語？）と理解してたよ。
static const string DEF2;　//要定義、初期化もそこで汁、
static const bool ojabaCppBeginner = true; // staticなのに実体がいらないなら定義不要、そのまま使える、楽ー

>>563のenumだけに関しては、昔はそうだったのですかとしか言えません。

571 ：仕様書無しさん：2007/11/30(金) 20:10:11

新キャラ登場か？

572 ：おじゃばさま ◆GxjxF3yEw6 ：2007/11/30(金) 20:49:38

>>556
業務でJavaやっていてJDBCを知らない人は、ほとんどいない。
そんな事を知らないということは、556はJavaを知らないと言う事になる。

>>559
JDBCの事を言っているのか？ODBCの事を言っているのか？
ODBCをスルーしたのは外部IFとして抽象化された例だからだ。

>>563
やっとすっきりしたよ。THX

>>569
定義
struct TABLE {
　　int id;
};
typedef unsigned int uint;

宣言
struct TABLE tbl;
uint ans;

>>560,565,570
マジボケなのか、釣りなのかイマイチ分からんな。

573 ：仕様書無しさん：2007/11/30(金) 20:57:05

>>572
>宣言
>struct TABLE tbl;
>uint ans;
これは定義っぽい。というかいわゆる「宣言定義」だな。

574 ：仕様書無しさん：2007/11/30(金) 21:17:12

>>おじゃば
感謝するあいて>>569もじゃないのか？

>>569がお前の知りたいことを完全に教えてくれてるんだが...
それなのに半端にしか教えていない>>563にしか感謝しないとは
やっぱ、これがおじゃばの性格？
ついでに>>560をコンパイルしてみたか？

575 ：仕様書無しさん：2007/11/30(金) 21:27:17

>>おじゃば
>>569が
class Test{
　　int i; // コレ、定義な
　　const string DEF1; // こっちも定義な
　　static const string DEF2; //コレは定義じゃない
　　・・・
};
と言っているが、定義じゃない　static const string DEF2;
は何というんだ？

576 ：仕様書無しさん：2007/11/30(金) 22:26:26

>>569
ウソが混じってる。
列挙型と列挙子(か列挙体か)を誤解してるだろ？
列挙体と列挙子はデータメンバではないから、
クラス定義の列挙子の宣言は定義で、かつ初期化子が付く。

列挙型の静的メンバの宣言っつのはこういうのだろ。
static const enum en eValue = ENUM;

577 ：仕様書無しさん：2007/11/30(金) 22:46:33

おじゃばの実務経験報告まだー？

578 ：仕様書無しさん：2007/11/30(金) 22:48:57

>>576
そうなのか！
俺は>>569の列挙型の静的メンバの宣言はenumハックことを言っていると思った。

579 ：仕様書無しさん：2007/11/30(金) 22:58:00

>>572
>typedef unsigned int uint;
めっちゃ宣言

580 ：仕様書無しさん：2007/11/30(金) 23:24:12

もはやオブジェクト指向とはほど遠い低レベルな議論しかしてないな・・・

581 ：仕様書無しさん：2007/11/30(金) 23:32:51

そうだな。それがおじゃばのレベルってことだ。

>>572,おじゃば、>>579だってよ。ダメポ

582 ：仕様書無しさん：2007/11/30(金) 23:54:19

おまいらこっちでやれ　ばかもの
C/C++の宿題を片付けます 100
http://pc11.2ch.net/test/read.cgi/tech/1195668114/

583 ：仕様書無しさん：2007/12/01(土) 00:32:26

宿題にはしゃいで正直すまんかった

584 ：仕様書無しさん：2007/12/01(土) 19:31:31

>>572
＞ODBCをスルーしたのは外部IFとして抽象化された例だからだ。
おじゃばの言う外部と内部って何よ？
関数の内部と外部じゃないの？

>>552より
＞構造化の場合は外部IFの所のみ抽象化しているが、
＞OOの場合は基本的に全てのクラス単位で抽象化されている。
おじゃば的にも外部IFの抽象化は構造化としてあるのだろ？

にもかかわらず、より構造化的な記述に近いODBCをスルーして、
構造化に反するグローバル変数やgoto(またはそれに近い記述)が
当然のように出てくるPro*Cを例として推してくる意図は何だ？
その意図が俺には分からん。

585 ：563：2007/12/01(土) 23:50:10

>>582 すまんがこれで終わりにするから礼だけ言わせてくれ。

>>569 勉強になった。サンクス。

[まとめ]
↓クラス定数を型情報込みでヘッダ定義できる
class Foo{ static const int v = 0; };
int の部分はbool,short,unsigned,long,列挙型等でも構わない。

Foo::v のポインタは取得できる(実体はあるってこと？)。
しかしこいつをconst_castして書き換えようと試しても、
アクセス違反が発生するか、無視されるようだ（コンパイラに拠る）。

ＯＯと関係なくてスマソ

586 ：仕様書無しさん：2007/12/02(日) 04:17:09

スレを流し読みしたが、
オーバーライドとオーバーロードを混同してる奴がいたり、
プリプロセッサとインターフェースの違いが分からんコテがいたり、
Cのお勉強をしだしたりと、
素人だらけの忙しいスレだな

587 ：仕様書無しさん：2007/12/02(日) 10:28:30

>>584
>ODBCをスルーしたのは外部IFとして抽象化された例だからだ。
逆に言っちまえば、話の根幹としてCではDBの切り替えが難しい
といっていた事なので、おじゃば自身がODBCでは移植性があると
認めて、議論を終了なわけだが。

そーいったつもりで逝ってるわけじゃないよね？

588 ：仕様書無しさん：2007/12/02(日) 18:13:01

>>586
オーバーライドとオーバーロードってどう違うんだ、教えて！、ペコリ
素人じゃなかったら、教えられるよね。それとも、素人の一人ですか、>>586

589 ：仕様書無しさん：2007/12/02(日) 19:54:30

三流煽り乙

590 ：おじゃばさま ◆GxjxF3yEw6 ：2007/12/03(月) 20:12:48

>>574
なんか勘違いしているようだが、俺が知りたかったのは宣言時に文字列を初期設定出来るかと言う事で、
enumやintが初期化出来るのは知っているし、定義と宣言の意味も知っている。
真面目に長文を書いた569には言いにくいが、定義と宣言の意味が無茶苦茶だ。
実際には混同したり間違って使われる事も多いので、何かを誤解したのだろう。本人も自信ないようだし。
簡単に言うと、実際にメモリ領域が確保されないのが定義で、確保されるのが宣言だ。
実例は前述の通り。
ただ構造体は定義と宣言を同時に行う事も出来る。
struct TABLE {
　　int id;
} tbl;

>>584
内部と外部は内部設計と外部設計の事だ。
通常、外部設計と言うのは他のプロジェクト等と接続するための、インタフェースの設計になる。
今回の場合はDBを他のプロジェクトと見て、DBとのインタフェースを外部設計と言っている。

前にも言ったが、構造化でも変更を考慮して意図的に設計されている部分では、OOと修正量は変わらない。
ODBCはまさにそれなので外した訳だ。Proc*Cは外部変数の要素が出てくるが、今回の論点とは関係ない。
外部変数扱いでなかったとしても、修正が困難な事には変わりないだろう。

591 ：仕様書無しさん：2007/12/03(月) 21:27:59

typedef struct TABLE {
　　int id;
} tbl;

592 ：仕様書無しさん：2007/12/03(月) 21:41:56

冗長な話は置いていて
みんな enum ってどう読んでる？
いーなむ？

593 ：569：2007/12/03(月) 21:42:02

>>590
＞簡単に言うと、実際にメモリ領域が確保されないのが定義で、確保されるのが宣言だ。
笑えねぇよ。マジ笑えねぇ。
笑えないほど大間違い。
むしろ逆。しかもソレはC言語の話。

しょうがないから最後に俺が規格から転載してやる。
お前がCについてもC++についても入門レベルなのは分かった。
コレでC++については引っ込んどけ。
まだ何か言いたかったら、先に規格読んでこい。ネットで誰でも見れる。

JIS3010 (C言語)
6.7 宣言
(中略)
意味規則宣言は、幾つかの識別子の解釈及び属性を指定する。
識別子の定義（definition）とは、宣言のうち次のものをいう。
－オブジェクトに対しては、そのオブジェクトの記憶域を確保する宣言
－関数に対しては、関数本体を含む宣言
－列挙定数又は型定義名に対しては、その識別子の（唯一の）宣言

JIS3014 (C++)
3.1 宣言及び定義
(中略)
宣言は、次の場合を「除いて」、定義（definition）という。
－関数本体を指定せず関数を宣言している場合
－ extern指定子又は《結合指定》を含んでいて、《初期化子》も《関数本体》も含んでいない場合
－クラス宣言の中で静的データメンバを宣言している場合
－型定義宣言、《using宣言》又は《using指令》の場合

手書きだからtypoがあるかもね。

594 ：仕様書無しさん：2007/12/03(月) 21:50:06

>>590
なら、お前に回答教えた>>563に感謝返しで
>>585の
"実体はあるってこと？"や"const_castして書き換えようと試しても、
アクセス違反が発生"の理由を答えてやれよ

>簡単に言うと、実際にメモリ領域が確保されないのが定義で、確保されるのが宣言だ。
俺、これ知らんかった、再確認の意味をこめて聞くが、C/C++の場合はこれ本当か？

595 ：仕様書無しさん：2007/12/03(月) 22:13:21

>>590　おじゃば
あほな俺でも>>593を読んで
>>593=569 >>こえられない壁>> おじゃば　と分かった。
これから、おじゃばの話はものすごく信用にならない可能性があると肝に銘じて読むことにするよ。

当然、おじゃばは>>593は間違いというんだろ、なら、>>593のように明確な根拠示せ！
よっとして、>>590の宣言・定義はJavaのことを言っているのか？

596 ：569：2007/12/03(月) 22:37:59

ついカッとなってやった。
今は反省している。

スレ違いも甚だしいので、出来れば流してやってください。
(除：おじゃば。おじゃばは良く読め)

あと規格名はJIS X 3010と3014だな。
X抜けてた。スマソ

597 ：仕様書無しさん：2007/12/03(月) 22:38:02

オブ脳である必要はないってじっちゃんがいってた

598 ：仕様書無しさん：2007/12/03(月) 22:53:18

>>596
このスレはまともにOOのことなんか話してないから、気にするな
俺を筆頭に勉強になった香具師も多いと思う。

おじゃばは、PG実力はさておき、釣に関しては超一流だぞ、
スレを見れば解るように、釣られて多くの香具師がおじゃばの相手をしてるだろ。
何が言いたいかというと、>>590は釣りってこと
>>588と>>590を比較すると、一目瞭然だろ、おじゃばのつりの腕！

599 ：仕様書無しさん：2007/12/04(火) 10:08:12

手元のC言語の辞書を引いてみた。

定義：識別子によって名前付けられたオブジェクト(変数)や関数の為に
記憶域の確保を行う宣言
宣言：略)識別子によって名前付けられたオブジェクト(変数)や関数の為に
記憶域の確保を行う宣言が定義である。

安物です。ありがとうございました。
でも分かりやすいよね。

一般サイトだと宣言って逝ってるけど。
教授の授業サイトだと定義とキチンと言っている。

600 ：仕様書無しさん：2007/12/04(火) 17:56:03

>>585
やー、おいらですよ、まだ、覚えてる？
先生には、無能なおいらからのinfoなのでまるっきり参考にならんと思うけど、
ここでも読んでね。

http://www.libjingu.jp/trans/bs_faq2-j.html#in-class
試した結果とここで書いていることが異なるなら、文句は...書いた人にでも言ってね。

601 ：仕様書無しさん：2007/12/04(火) 19:23:35

タイトル：OOスレ7 なぜオブジェクト指向は普及しないのか
【糞スレランク：Ｂ＋】
直接的な誹謗中傷：20/600 (3.33%)
間接的な誹謗中傷：59/600 (9.83%)
卑猥な表現：7/600 (1.17%)
差別的表現：29/600 (4.83%)
無駄な改行：5/600 (0.83%)
巨大なＡＡなど：5/600 (0.83%)
同一文章の反復：1/600 (0.17%)
by 糞スレチェッカー Ver1.12 ttp://kabu.tm.land.to/kuso/kuso.cgi?ver=112

中途半端なランクだな

602 ：585：2007/12/04(火) 21:08:48

>>600
ふ～む、なるほど。サンクス。
どうやら、俺の試したコンパイラではアドレスを取得できたが、
そもそもそれは本来コンパイルエラーになるべきものだったってことか。

　ちなみに無能と言った意図が伝わって無いみたいだから補足して書いておく。
　おじゃばはメンバ変数の宣言時初期化と言っていたが、
知りたがっていたのは非static 非const メンバ変数の初期値をclass定義
に埋め込めるかどうかだった。それなのに const メンバ変数の
コンストラクト時初期化や static const 変数の初期化方法を提示するのは
明らかに質問の意図をはきちがえてるってことだろ。
細かい言語仕様を熟知しているのは尊敬に値することだが
そこまでの知識が無いヤツを非難してたら台無しだろう。
だから無能だと言ったわけだ。

603 ：仕様書無しさん：2007/12/04(火) 22:04:17

>なんか、非static 非const メンバ変数の初期値をclass定義
>に埋め込めるかどうかだった。
おじゃばはこれをメンバ変数の宣言時初期化と俺俺表現してたのか

うーん、俺には想像できない質問の趣旨だったんだな

604 ：仕様書無しさん：2007/12/04(火) 22:05:00

いんや。

>>359辺りが発端で、おじゃばが
「#defineの変わりに使えるような文字列のメンバってどうすんの？」
つったからconst stringやらstatic const stringやら出てきたわけで。
そっからずっとstaticだったりconstだったりの話。

おじゃばが知りたかったのは「クラス定義内でstatic constな文字列の
初期化書いていーの？」ってことだろ？
>>590でおじゃば自身
＞intが初期化出来るのは知っているし
と言ってるし、外してないと思う。
static constじゃないintはクラス定義内で初期化出来ないから。
クラス定義内でなければ、さすがに知らんってことは無いだろ。
それかおじゃばの日本語が怪しいかどっちか。

605 ：おじゃばさま ◆GxjxF3yEw6 ：2007/12/04(火) 22:43:38

>>593
負けた、俺の完敗だ。
ずっと逆で覚えていたようだ。勉強し直してくる。

606 ：仕様書無しさん：2007/12/04(火) 23:11:10

おじゃば、その潔さはなかなか良いぞ。

言語に関するわからないことは、ム板でしたほうが良い
教えることが大好き先生がいっぱいいるからな。

607 ：仕様書無しさん：2007/12/05(水) 00:11:10

>>605
今渡ばかりはどんな言い訳するか期待していたんだが、ことごとく裏切ってくれるなw

608 ：仕様書無しさん：2007/12/05(水) 00:20:28

あれだけ引き延ばして無知晒しまくったアホに
潔いって評価はどこから・・・

609 ：仕様書無しさん：2007/12/05(水) 00:32:59

いつもの事だろ。

「構造化でも変更を考慮して意図的に設計されている部分では、OOと修正量は変わらない。
ODBCはまさにそれなので外した訳だ。」

議論って何って話。

610 ：仕様書無しさん：2007/12/05(水) 19:26:51

Perlの文字コード変換ライブラリと、
C/C++/gcc/Win32でカーネル開発やmozillaに貢献は、
果てしない技術レベルの壁がある。
まぁ文字コード関係も、大きな努力と集中力を要する
大変な作業であることも確かだが…。
Webの大部分はパブリッシング、デザインの世界だからね。
技術先行でやってるとこなんてごくわずかで、今後コモディティ化が
進めば技術者にとってはより住みにくい世界になるだろうね。

611 ：仕様書無しさん：2007/12/05(水) 20:40:35

どこのスレの誤爆？

612 ：仕様書無しさん：2007/12/05(水) 21:34:53

誤爆じゃなくて意図的なマルチポストかと

613 ：仕様書無しさん：2007/12/05(水) 22:39:57

Perlの文字コード変換ライブラリと、
C/C++/gcc/Win32でカーネル開発やmozillaに貢献は、
果てしない金儲けの壁がある。世の中銭よ
銭稼げドカタども

614 ：仕様書無しさん：2007/12/06(木) 14:18:43 BE:210432342-2BP(1500)

>>611
小飼弾スレが似たような流れになってたようななってかったような

615 ：仕様書無しさん：2007/12/06(木) 19:34:27

で、何故普及しないんだっけ？

616 ：仕様書無しさん：2007/12/06(木) 21:21:07

プログラマでは普及はしてるだろ？
コーディングではみんな意識はして作ってるんじゃない？

617 ：仕様書無しさん：2007/12/07(金) 22:14:05

実体化って哲学用語なんだよな。プログラマと哲学って相性悪そうだな。

618 ：仕様書無しさん：2007/12/08(土) 00:52:31

http://d.hatena.ne.jp/JavaBlack/20070805

* なぜオブジェクト指向は嫌われているのか？:http://alfalfa.livedoor.biz/archives/51079543.html

憂鬱本なんかの屑本を鵜呑みにして、失敗している人が多いからでは．類書は他にも多数．*1

619 ：仕様書無しさん：2007/12/08(土) 11:04:34

懐かしｗ
そのアーカイブのスレ、ここの過去スレだな

620 ：仕様書無しさん：2007/12/08(土) 14:29:30

で、OOってやっぱりダメだよな

621 ：仕様書無しさん：2007/12/08(土) 18:37:04

OOは「使えない」

622 ：仕様書無しさん：2007/12/08(土) 22:07:33

クラス設計を共通化しすぎると修正したときに影響範囲が膨大になる
「おまえのいうとおり設計したらえらいことになったぞ！」
とつるしあげにされる

623 ：仕様書無しさん：2007/12/08(土) 22:59:19

「OOは使えない」と言うのは、OOが万能じゃないから
分らなくもないが、逆に何が使えるの？
何と比較して使えないと言っている

624 ：仕様書無しさん：2007/12/08(土) 23:00:58

>>623
DSDM

625 ：仕様書無しさん：2007/12/08(土) 23:09:04

それは手法

626 ：仕様書無しさん：2007/12/08(土) 23:09:46

OOはじゃばぽんがいるかぎり普及はない

627 ：仕様書無しさん：2007/12/08(土) 23:13:20

>>623 >>625
オブジェクト指向開発プロセスも含まないのか？このスレ

このスレって

オブジェクト指向開発プロセス
オブジェクト指向分析
オブジェクト指向設計
オブジェクト指向プログラミング

のどれでもいいんだろ？

628 ：仕様書無しさん：2007/12/08(土) 23:20:19

>>627
実質、オブジェクト指向プログラミングのみ
ここは、ほかはやったことのない底辺が集うところ

629 ：仕様書無しさん：2007/12/08(土) 23:22:15

オブジェクト指向分析とか設計とか、オカルトだから。

630 ：仕様書無しさん：2007/12/08(土) 23:22:47

含めるのは構わないが、じゃ逆に聞くが
DSDMとOOは相反する物なのか？

631 ：仕様書無しさん：2007/12/08(土) 23:22:50

正確には「OOが使えない。」

632 ：仕様書無しさん：2007/12/08(土) 23:22:55

OOは銀の弾丸じゃないわけで、
分岐の多い場合なんかパターン化できないので
OOはさして役に立たないという現実も設計が悪いで片付けるのではぁ？となる。

633 ：仕様書無しさん：2007/12/08(土) 23:29:43

>>628 なるほど納得。話が噛み合わないわけだ。

634 ：仕様書無しさん：2007/12/08(土) 23:41:56

>>631
OOが使えない奴が多いのでOO自体使い物にならない

635 ：仕様書無しさん：2007/12/08(土) 23:54:51

「午後はＯＯ。思いっきりデスマ」

636 ：仕様書無しさん：2007/12/08(土) 23:57:17

>>628=>>633
結局そうやって逃げていく
OOが使えないなら、OOの批判してもしょうがないだろう

637 ：仕様書無しさん：2007/12/09(日) 00:53:28

ＯＯの開発プロセスは所詮理想論だからダメなわけ。

現実見たらあんな開発プロセスで上手く回るわけがないし、
ランボーさんもブーチさんも羽生田さんも本位田さんも
そんなことは分かってるだろうけど、
所詮「開発プロセス押し売りビジネス」に乗っかって
良さそうなものに見せて、はやらせて、第一人者としてメシを食ってただけだろうね。

世の中、良いものが流行るわけじゃなくて、
上手に商売した結果で何が流行るか決まるだけ。

ＯＯの先駆者たちは、開発の現実なんて知らなくても、商売の現実は良く分かってたってことだ。

638 ：仕様書無しさん：2007/12/09(日) 01:38:10

実際の現場では、結合度が高すぎてエンバグ出しまくりなナンッチャテOOが大流行

639 ：仕様書無しさん：2007/12/09(日) 01:59:09

で、そうなったのは設計が悪いと言い張るOO厨(ｗ。

640 ：仕様書無しさん：2007/12/09(日) 04:06:25

プログラムは分かり易さ（保守性）が一番なわけで、俺にはもうOO無しではいられない。
データ変換のスクリプトとか、Webの単純なリクエスト処理みたいな、やっても結局1つの
クラスにしかならなさそうなものまで、とにかくOOって主張するのもどうかと思うが、
大概の処理は、いろんなクラス（やそのインスタンス）で組み合わせて作るのは当り前で、
クラスにはしないとしても、モジュール分割はするだろ？　 OOは単なるモジュール分割
以上の便利な機能を提供してくれてるわけだから、これを使いこなさない手はないと思う。
つか、ちゃんとOOの特性理解してうまく設計してくれよ。アホか。

641 ：仕様書無しさん：2007/12/09(日) 07:44:02

ただの関数コールもメソッドとか言うのを止めてくれれば良いのに。

642 ：仕様書無しさん：2007/12/09(日) 12:48:04

>>640
>プログラムは分かり易さ（保守性）が一番なわけで、俺にはもうOO無しではいられない。
それは、主観か客観か？
客観だとした場合、何の方法諭で作ったプログラムと比べて分りやすい？
このスレは主観のみで、OOの利点や欠点を書く奴ばかりで、論理的では無い（by ガリレオ)

643 ：仕様書無しさん：2007/12/09(日) 12:58:26

まず、「わかりやすさ」と「保守性」を以下のように定義する。

　わかりやすさ　：　対象言語の仕様と一般的なライブラリ以外の前提知識を持たない状態から、
　　　　　　　　　　　　あるプロジェクトのソースコードを読んだ際に理解するまでの時間を相対的に評価して、
　　　　　　　　　　　　その時間の短い場合を「よりわかりやすい」とする。

　保守性　　　　　：　対象言語の仕様と一般的なライブラリ以外の前提知識を持たない状態から、
　　　　　　　　　　　　あるプロジェクトのソースコードに有用な変更を加え実装するまでの時間を相対的に評価して、
　　　　　　　　　　　　その時間の短い場合を「よりわかりやすい」とする。

OOと構造化プログラミングについて、上記の定義を元に比較をすると面倒なので、
とりあえずOOウマーとしておく。

QED

644 ：仕様書無しさん：2007/12/09(日) 13:17:12

>>643の定義だとOOの方が保守性は低そうだな。
OOで変更が簡単になるのは内部構造が分かってる状態からでこそじゃない？

バグフィクスにせよ機能追加にせよ、内部が分からない状態で、
動作の状況から見て関係するソースコードにたどり着くは構造化の方が早い。
何でかっていうと、構造化は原則動きが目に見える「機能」を元に
モジュールを分割するから。

645 ：仕様書無しさん：2007/12/09(日) 13:31:47

>プログラムは分かり易さ（保守性）が一番
間違い。

プログラムは利益が出るかどうかが一番。
プログラムは技術者のオナニーの道具じゃねーぞ。

646 ：仕様書無しさん：2007/12/09(日) 13:35:21

>>644
そこでアスペクト指向ですよ

647 ：仕様書無しさん：2007/12/09(日) 13:53:16

>>643
定義は分った、比較するのが面倒も分るが
比較するのが構造化プログラムと抽象過ぎると思う
普通にPOAで作った場合は、確かにそうかも知れないが
構造化でも、複合で設計しDOAを適用して作った場合はどうだ？

>つか、ちゃんとOOの特性理解してうまく設計してくれよ。アホか。
構造化でうまく設計出来るのか？　それが出来なければ結局、客観的だと言う事

どっちの方法諭でも、正しく設計出来れば甲乙付けがたいと思うが

648 ：643：2007/12/09(日) 14:05:42

>>647
申し訳ないが、俺は>>640じゃないんだ。
定義もOOウマーもほとんど根拠はない。

ただ、OOの方が主語（オブジェクト）・動詞（メソッド）・目的語（引数）・補語（名前付き引数）と、
自然言語に近い形での構文が作りやすいので、個人的には好きだといいたい。

649 ：仕様書無しさん：2007/12/09(日) 14:07:33

>>648
ＯＯと構造化以外の方法を知らないの？
で、構造化がダメでＯＯが良し、ってまさに信者そのものだよ。

650 ：仕様書無しさん：2007/12/09(日) 14:23:31

>>648
確かに、自然言語に近いのは主観的根拠になる

>>649
OOと構造化を比べてるのは、現実的だと思う
実際に適用例が少ないマイナーな方法諭では
正確性に問題が残る

651 ：仕様書無しさん：2007/12/09(日) 14:28:03

>>650
ＯＯと構造化をあらゆる個所で比較して常にＯＯが最良と思ってない？

ＯＯはオーバーヘッドを大きくして将来の変更に備えるだけなので
その分失敗時のリスクも大きくなるし、将来に変更がほとんど無かったり
変更で極端に儲からないプロジェクトでは、最悪の手法だってことは分かる？

652 ：仕様書無しさん：2007/12/09(日) 14:29:26

>>651
その理解は間違ってますよ。

653 ：仕様書無しさん：2007/12/09(日) 14:30:34

>>652
具体的にどうぞ。

>>651 の論点は

オブジェクト指向開発プロセス ←これ
オブジェクト指向分析
オブジェクト指向設計
オブジェクト指向プログラミング

だということは分かる？

654 ：仕様書無しさん：2007/12/09(日) 14:34:52

それとよくある誤解は、OOは大規模開発で有用で、小規模だと無用だとか。

655 ：ガリレオ：2007/12/09(日) 14:39:12

>>651
おれは、>>642=>>647だ
>どっちの方法諭でも、正しく設計出来れば甲乙付けがたいと思うが
が俺の意見、つまり適用範囲によって優位性は変わると思っている

656 ：仕様書無しさん：2007/12/09(日) 14:41:54

>>655

お。すまんね。勘違い。

>>654

「再利用」によるメリットがそもそもほとんど無いと分かっているプロジェクトでＯＯ使おうなんて愚の骨頂。

「再利用」が発生するのは継続性だったり規模だったりに依存するから、
大規模で有用、継続性のあるプロジェクトで有用と言われる。

オブジェクト指向「プログラミング」だけがＯＯと勘違いしてるヤツ痛すぎ。
ＯＯの本質は、再利用が発生する場合、その開発プロセスで開発全体のコストが下げられる点。
ＯＯＰはただの道具だって理解して欲しい。

657 ：仕様書無しさん：2007/12/09(日) 14:48:45

OOは基本的にフレームワークを使うためのものだ

658 ：仕様書無しさん：2007/12/09(日) 14:51:10

>>657
オブジェクト指向開発プロセス
オブジェクト指向分析
オブジェクト指向設計
オブジェクト指向プログラミング
使い捨てソルジャープログラミング　←　それはここ

659 ：仕様書無しさん：2007/12/09(日) 14:58:11

>>658　
修正：OOは基本的にフレームワークを作ったり使うためのものだ

660 ：仕様書無しさん：2007/12/09(日) 17:16:51

また再利用が蒸し返されてるが、他にOOのメリットってないの？

あと、構造化 vs OO みたいな構図で比較する奴も多いが、
OOが構造化を基礎として成り立っていると説明する文章も見たことあるぞ。

661 ：仕様書無しさん：2007/12/09(日) 17:32:32

>>645
プログラムが利益生むかどうかはプログラマが決めることじゃねぇっつうの。それは仕様の話。やっぱアホだ。

662 ：仕様書無しさん：2007/12/09(日) 17:37:56

>>661
保守が重要かどうかはプログラマが決めることじゃねぇっつうの。それは要求事項の話。やっぱアホだ。

663 ：仕様書無しさん：2007/12/09(日) 17:51:08

保守性は常識レベルで重要だろ。それが将来も含めた全体利益につながることが想像できないのか？　アホだな。

664 ：仕様書無しさん：2007/12/09(日) 17:57:54

>>663
それしか知らないということをわざわざ表明しなくてもいいよ。
そういうケースだけ経験して他のプロジェクトに行ってヘタに頑張ると暴走するだけだから大人しくしてた方がいいよ。

所詮、「どこに金をかけるか」の判断からはずいぶん遠い仕事してるみたいだし。

665 ：仕様書無しさん：2007/12/09(日) 17:59:16

さすがにものすごい想像力だな。アホは。

666 ：仕様書無しさん：2007/12/09(日) 17:59:50

保守を重視するよりも、いち早く開発して顧客にインパクトをアピールして、次にでかい金を取るのが重要という位置付けの開発もあるけどな

667 ：仕様書無しさん：2007/12/09(日) 18:00:56

>>665 アホはｵﾏｴだよ。>>666 読める？

668 ：仕様書無しさん：2007/12/09(日) 18:01:54

利益のために、安い賃金でドカタを酷使する　これ、OOの鉄則

669 ：仕様書無しさん：2007/12/09(日) 18:02:10

国とか研究機関の予算で取る場合、保守よりも年度内に研究成果が出せるものが重要というものもあるな

670 ：仕様書無しさん：2007/12/09(日) 18:03:06

あぁ、俗に言うブラック会社か。ナンマンダブ。

671 ：仕様書無しさん：2007/12/09(日) 18:04:13

ブラックは研究予算取れないよ
つーか、ＯＯ信者って何でこんなに頭悪いんだろう・・・

ＯＯの素晴らしさは、３流プログラマの心をがっつり掴むことができて信者だらけにできた点だな

672 ：仕様書無しさん：2007/12/09(日) 18:07:00

「国」とか、「研究機関」とか、・・・そんなのどーでもいい。つまらん奴だ。

673 ：仕様書無しさん：2007/12/09(日) 18:08:00

「保守性は常識レベルで重要だろ。それが将来も含めた全体利益につながることが想像できないのか」

ﾜﾛﾀｗ
ｽｺﾞｲ妄想だなｗ

674 ：仕様書無しさん：2007/12/09(日) 18:09:07

必死だな。

675 ：仕様書無しさん：2007/12/09(日) 18:09:59

http://journal.mycom.co.jp/series/stratesys/013/index.html

「企業の経営者あるいは経営者レベルにある人に対して、「オブジェクト指向」という言葉でアピールすることはほとんど得るものがない」

保守性上げても金にはならないよ。常識。

676 ：仕様書無しさん：2007/12/09(日) 18:17:40

読解力無いのか？良く読め。そもそもOOって開発手法なのに。

677 ：仕様書無しさん：2007/12/09(日) 18:33:08

人月で仕事をやってると、技術力の高さって関係ないからね。
むしろ低いくらいが利益でるみたいな。
客がコンサルみたいの雇って、仕事の内容が水準に達しているかチェックさせるとか
そのくらいやってもいいと思うけど、大手SIer相手だと、それは禁じ手らしいし。
まじめにやるより客の品質に対する無知につけこんでぼろい商売をやってたほうが儲かるのは
あたりまえだよね。
アメリカだと、そもそもSIerというのが存在しないから、状況が違うらしいけど。

678 ：仕様書無しさん：2007/12/09(日) 18:44:55

まぁ、そういうのが精神的に大丈夫な人もいるが、受け付けない人もいる。
いけいけどんどんで金さえもらえればっていうのは、何か釈然としない。

679 ：仕様書無しさん：2007/12/09(日) 18:51:48

世の中にはデスマウェルカムなM体質の人もいるぐらいだから。人それぞれ。

680 ：仕様書無しさん：2007/12/09(日) 19:19:40

中途半端な役割分担がデスマの原因。
主語の無い曖昧な日本語表記による仕様書不明瞭もデスマの原因。

681 ：ガリレオ：2007/12/09(日) 19:22:16

よく分らん議論だな、言いたいのは
OOは保守性も含めて、費用対効果良いか悪いかの議論か？

あと、>>675はOOが費用対効果に影響しないという考えで良いのか？

682 ：仕様書無しさん：2007/12/09(日) 19:23:49

製品仕様書を元に各部署で勝手にガード処理入れてるのがエンバグの原因。

683 ：仕様書無しさん：2007/12/09(日) 19:35:48

オブジェクト指向開発プロセス
オブジェクト指向分析
オブジェクト指向設計
オブジェクト指向プログラミング
使い捨てソルジャープログラミング　←　>>676

684 ：仕様書無しさん：2007/12/09(日) 19:37:39

３行でまとめるとこうだろ

現実：保守が最優先というケースばかりではない
信者：保守が最優先に決まってるだろＯＯﾏﾝｾｰ
健常者：(　ﾟдﾟ)ﾎﾟｶｰﾝ

685 ：仕様書無しさん：2007/12/09(日) 19:54:50

保守性高い方が一般的に出来上がりも品質もいいと思うが。
両者は反比例するもんじゃないだろ。

686 ：仕様書無しさん：2007/12/09(日) 19:58:46

保守性と品質は比例するだろうけど、初めから過度な保守性を目指すのは初期に多大なコストを必要とする
品質は最初から将来の変更への対応を考慮することによる保守性だけで高めるものでもなくリファクタリングの方がマシな場合もある

687 ：仕様書無しさん：2007/12/09(日) 20:01:27

OOが普及しないのは、このスレにいるような
変なOO信者がOO適用が不適切なケースでも
OO持ち出したがって結果としてデスマ化したりして
OOのよくない面も目立ってるからだよ。

適材適所にきちんとOO使えばすごく効果的なのに・・・
もったいない。

688 ：仕様書無しさん：2007/12/09(日) 20:03:11

保守性ってプログラマのちょっとした気遣いや優しさの現れだったりするんだよな。
糞が書いたプログラムは設計とは関係なしに腐ってる。仕事をなめてる。死ねと思う。

689 ：仕様書無しさん：2007/12/09(日) 20:15:34

>>685
品質は利益と関係ないって言ってるんろ? 上のほうの人。

690 ：ガリレオ：2007/12/09(日) 20:22:14

>>684
なるほど、保守性は俺もケースバイケースだと思う
俺の主観だがVer３以降ぐらいで、保守性に対する
OOの優位性が発揮でき、費用対効果はVer６ぐらいで
同等か優位になると思う。
問題はアプリがいつまで続くかが、はっきりしないこと
だから、お互いに相手の意見も理解出来と思えないのか？

691 ：仕様書無しさん：2007/12/09(日) 20:27:01

デスマの原因の多くをスパゲッティが占めてんだがな。

692 ：仕様書無しさん：2007/12/09(日) 20:36:23

なんで「保守性が高いけど開発で手間がかかる」って前提になってるのか不思議。
保守性の高いコードはたいがい開発でも効率いい。

693 ：仕様書無しさん：2007/12/09(日) 20:37:35

>>692
>>690 のとおりだろ。費用対効果で優位性が出るのは運用に入って、何度かバージョンアップした頃。
最初は手間がかかるよ。

694 ：仕様書無しさん：2007/12/09(日) 20:39:20

無意味にデザパタ適用しまくると、クラス数もステップ数も数倍に膨れ上がるな

695 ：仕様書無しさん：2007/12/09(日) 20:47:49

顧客が「今回、ここの要素は一つで良いです。一元管理したいので、一つでなければダメです。」
でsingleton適用、３ヵ月後、
顧客は「ここの部分、冗長性のためマルチに動くようにする要望が出てきて、なんとか対応して欲しいんですけど」

スパゲッティ一丁！

696 ：仕様書無しさん：2007/12/09(日) 20:58:44

手間がかかるっていうか、ソフトウェアってそもそもそんなもんだろ。
場当たり的にやっつけで作ってると、あとでしっぺ返しくらうのは目に見えてる。
保守の不要なソフトってまずありえないし。

697 ：仕様書無しさん：2007/12/09(日) 21:02:25

OOは、データ部分の複雑化に対応できるが、
条件式の複雑化には対応できない。

結局、本来なら関係ない値が条件に必要になって
結局グローバル変数で受け渡しして処理したりとか、

OO信者はそーいう場合設計が糞といっておしまいだが。

698 ：仕様書無しさん：2007/12/09(日) 21:03:10

>>696
>保守の不要なソフトってまずありえないし。

20レスくらい上でそれが否定されてるわけだが・・・
こうしてループするんだな

つーか、
「このバージョンは８０００万だけで作るがこれはモックアップだと思え！
これでデモンストレーションしてから５億取るからそのつもりで！
今のバージョンは保守はどうでもいいから最短速度で必要な機能だけ最速で作れ！
ＲＦＰはもう出てる！時間ないぞ！」
みたいなケースは良くある。

699 ：仕様書無しさん：2007/12/09(日) 21:19:32

国とかの話が出てたが、企業の本社研究部門とかだと、
保守を気にする仕事よりは、試作のプログラムが多い。
デモやショー向けのとか先端技術評価用とかのプロトタイプみたいなの。

トータルな品質よりは、いかに早くそれなり動くものを提供出来るかが勝負。

それを参考に商品化する各事業所はもちろん品質優先だけど。

700 ：仕様書無しさん：2007/12/09(日) 21:24:48

経営側、営業：

　　 (´-`).｡ｏO(営業成功すれば幾らでも金取れるし、とりあえず動けばなんでもいいんだけど・・・)

OO信者プログラマ：

　　 (ﾟДﾟ) <ﾌﾟﾛｸﾞﾗﾑは保守できる綺麗さが必須！金？営業？そんなのかんけーねぇ！ちょっと待ってろ！ｵｯﾊﾟｯﾋﾟｰ >

701 ：仕様書無しさん：2007/12/09(日) 21:44:15

ここのスレの1/3は自演坊主の自己主張で出来ています。

702 ：仕様書無しさん：2007/12/09(日) 21:50:48

>>701
少なくともOO否定書いてる人たちは自演じゃないってこと分かってるし、
その人たちに対してはｵﾏｲがただの認定厨にしか見えない。

そんな変な印象操作までしようとするから信者とか書かれるわけ。

703 ：仕様書無しさん：2007/12/09(日) 21:51:49

OO否定は言い過ぎた。場合による、という意見書いてる人というほうが正確。

704 ：仕様書無しさん：2007/12/09(日) 21:53:37

まあ、保守性が新規開発では不要だなんて開発した事無い学生の台詞だろ。
開発している物が大規模になればなるほど、開発期間中に既に保守フェーズに入ってしまうパートが多く出るって事を知らないのさ。

705 ：ガリレオ：2007/12/09(日) 21:56:03

>>698-700
言ってる事は分るが、未来の事は誰にも分らない
最初はプロトタイプだから、一定の品質で大丈夫だと言われても
そのあと、プロトタイプをもとに作らされるだったら
始めらか、保守も含めて費用対効果を考えるのは正しい方向だと思う
（あと、使い捨てアプリだと言われ作ったら、その後も使うようになるケースとか）
とにかく、これは時間が経過しない、どっちが正しいか分らない問題だと思う

疑問に思ったので聞かせてほしいが、保守がなければOOは無用と思っているのか？
また、保守があればOOで作るべきだと思うのか？

706 ：仕様書無しさん：2007/12/09(日) 21:59:44

あれ、俺否定派なんだけど、肯定派になろうかな・・・ま、どっちでもいいけど。

707 ：仕様書無しさん：2007/12/09(日) 22:04:16

>>705
予算のかけ方の問題。
時間勝負の場合に、悠長に将来性を考えた設計に時間をかけられても困るだけ。

>未来の事は誰にも分らない

経営者や会社の方針わかってるPMは分かってるよ。というか、結局方針次第だから。
ヘボ経営者やヘボ役員なら、再利用できないシステムを再利用しようとすることもあるし、
その逆もある。どちらも見た。

>最初はプロトタイプだから、一定の品質で大丈夫だと言われても
>そのあと、プロトタイプをもとに作らされるだったら
>始めらか、保守も含めて費用対効果を考えるのは正しい方向だと思う

それ、デスマの典型。最初からプロトタイプと割り切って作って後から再利用してもデスマだし、
プロトタイプの予算と期間で、保守性まで検討してもデスマ化。
無能PMが良くやる。

>疑問に思ったので聞かせてほしいが、保守がなければOOは無用と思っているのか？

保守だけじゃないけどね。規模が大きくても再利用性は有用だから。
再利用性が効果をもたない場合、OOは無用の長物。

>また、保守があればOOで作るべきだと思うのか？

逆に保守があってもOOじゃなくてもおｋ。別の方法もある。

って全てオブジェクト指向"プログラミング"じゃなくて、OO開発プロセスのことな。

708 ：仕様書無しさん：2007/12/09(日) 22:06:32

長年やってると、保守性は自然と考えるようになる。むしろそれを無視して作るのが難しい。
やっつけでいいと言われても、どうしてもそういう作り方になってしまう。
考え方も整理されて作る時間もその方が早い。二者択一みたいな考え方にはなれない。

709 ：仕様書無しさん：2007/12/09(日) 22:07:50

研究機関や本社研究所と共に新規製品開発等したこと無い専門卒Javaソルジャーだろ。 >>704
一生保守が付きまとうような誰でもできる猿仕事やってろよ。

710 ：仕様書無しさん：2007/12/09(日) 22:08:28

>>708
どうせここには素人と部外者と学生しかいないよw

711 ：仕様書無しさん：2007/12/09(日) 22:10:46

>>709
おまいは例えば30000のモジュールを30000人で一斉同時に作るとでも思っているのか？
どんな新規開発でも保守が入るのを知らないのはおまい。

712 ：仕様書無しさん：2007/12/09(日) 22:13:03

>>711
だからそれは研究的な新規開発じゃなくて、その後の製品化フェーズ。
30000人も研究所にいねーからｗｗｗ

713 ：仕様書無しさん：2007/12/09(日) 22:14:22

大量開発部分を担当してるという表明はソルジャーの表明なわけだが・・・・・・

714 ：仕様書無しさん：2007/12/09(日) 22:15:06

>>712
だからおまいは、保守の意味を製品化のセカンド作品製作用とか、顧客対応とかと勘違いしてるんだろ？？

715 ：仕様書無しさん：2007/12/09(日) 22:15:42

そりゃ保守の必要な仕事しかやってこなかった奴にとっては
絶対保守は必要だろうな。経験上は。
そんな奴にいくら保守が無いケースがあると力説しても
実感が湧くわけないよ。

716 ：仕様書無しさん：2007/12/09(日) 22:16:45

>>714
ｵﾏｲは国の予算で時限付き研究開発とか経験してないだろ。

717 ：仕様書無しさん：2007/12/09(日) 22:16:59

商品としてのソフト開発をした事の無い奴に、保守の意味を教えても分からないのと同じだな？

718 ：仕様書無しさん：2007/12/09(日) 22:17:39

商品としてのソフト開発しかした事の無い奴に、保守の無いケースを教えても分からないのと同じだな？

719 ：仕様書無しさん：2007/12/09(日) 22:18:30

>>715
保守が無いケースって・・・お勉強用の使い捨てプログラムか？
仕事なめてるだろ、もっかい学校出直せ。

720 ：仕様書無しさん：2007/12/09(日) 22:18:39

ああ、国家予算の研究開発では、動かない物作っても、誰にも責任無いしな。

721 ：仕様書無しさん：2007/12/09(日) 22:19:49

>>719
やっぱり５０億の研究予算とるプロジェクトとか経験したことないただのソルジャーだな。
７KのITドカタ仕事一生やってろ。

722 ：仕様書無しさん：2007/12/09(日) 22:20:47

>>720
外部評価員とかいう言葉知ってる？もうちょっと世の中のことも勉強した方がいいよ。

723 ：仕様書無しさん：2007/12/09(日) 22:21:59

あるよ

724 ：仕様書無しさん：2007/12/09(日) 22:22:52

で、そんなレアなケースで保守は要らないと主張してる馬鹿はほっておいてさ。
本題に戻そうよ。

725 ：仕様書無しさん：2007/12/09(日) 22:24:50

さすがに、５０億の研究予算とるプロジェクトとかに係わるような人は、
このスレにいりびたって日頃のストレスをご発散されているんですね。

726 ：仕様書無しさん：2007/12/09(日) 22:25:04

なんだか、いつかどこかで見たデスマの風景を思い出すな。

PM：「今回、保守はいいから、来月までにこの機能絶対完成させろ!」

１ヵ月後

ソルジャー：「ここは Factory Method パターン使わないと将来の保守性が!設計に時間が必要でした!」

PM：「バカ!」

727 ：仕様書無しさん：2007/12/09(日) 22:27:30

保守性を考慮するのってそんなに時間かかるもんなん？

728 ：仕様書無しさん：2007/12/09(日) 22:29:55

下手な熟考休むに似たる。
ってか、サボってた言い訳だお

729 ：仕様書無しさん：2007/12/09(日) 22:32:45

>>722
だからその評価員の評価のあいだだけ動いてればおkなんだろうにw
動かないって言うのはそういうことw

730 ：仕様書無しさん：2007/12/09(日) 22:36:12

>>729
評価員の意味全く知らないということはよく分かった。
動かない場合（というか研究予算つけたのに成果が出ない場合）の責任が押し付けられるってこと。
実際の動作の評価は実証実験などを通してさらに広く公開して継続的に行うんだよ。

だから品質は高く、しっかり動くけど、機能変更は無く、ということになる。
無知を晒すのもほどほどにしとけ。

731 ：仕様書無しさん：2007/12/09(日) 22:38:57

機能変更が無いことが保証されてんのか？　なんてうらやますぃ。さすが国家プロジェクト。

732 ：仕様書無しさん：2007/12/09(日) 22:40:15

特に税金使うと、とんでもなく評価がうるさくなる。（さらに証拠としての書類も激しく面倒）
これ国の予算使ったことある奴なら誰でも知ってると思うけど。
はっきり言って、民間の方が「動かなくて良い」と思えるくらい
税金使うと成果の評価が大変になるよ。

733 ：仕様書無しさん：2007/12/09(日) 22:42:19

もうさ、スレ違いの延々な書き込み止めて。

734 ：仕様書無しさん：2007/12/09(日) 22:43:48

>>727
初期投資ゼロで保守コストが減らせると思う？
もしそう思うならプログラマ辞めたほうがいいと思う。

735 ：仕様書無しさん：2007/12/09(日) 22:44:11

毎日ストレスまみれで可哀想な人なんだよ、ちょっとぐらい許してやって。

736 ：仕様書無しさん：2007/12/09(日) 22:47:09

>>734 なんで保守コストが初期投資なんだ？頭悪いのか？　国家プロジェクトの人見習えっ！

737 ：仕様書無しさん：2007/12/09(日) 22:47:27

>>734
いち機能の実装に関する保守性を考慮するのに１ヶ月もさすがにイランだろ

738 ：仕様書無しさん：2007/12/09(日) 22:47:37

結局OO信者は、何故オブジェクト指向が普及しないのか、って完全に理解不可能ってことだな

739 ：仕様書無しさん：2007/12/09(日) 22:48:58

>>736
日本語全く読めてないね。
initial cost と running cost って書けば理解できる？

running cost を下げるために initial cost を上げてるだけなんだよ。分かった？

740 ：仕様書無しさん：2007/12/09(日) 22:49:43

宗教信者にその宗教がなかなか布教してかないのが何故だか理解できるわけなかろうに。

741 ：仕様書無しさん：2007/12/09(日) 22:50:48

>>690 は中立な人っぽいけど、この人ですら

「OOの優位性が発揮でき、費用対効果はVer６ぐらいで同等か優位になると思う。」

と書いてるんだよ。最初にコストがかかってるって理解できない信者大杉。
話が噛み合わない。

742 ：仕様書無しさん：2007/12/09(日) 22:50:49

コアなアイドルファンにそのアイドルがなぜメジャーになれないのか理解出来ないのと同じだな。

743 ：仕様書無しさん：2007/12/09(日) 22:54:47

ギャーギャーうるさいんだよ。御託はいいから根拠を示せ。数値で示せ。客観的な論拠を述べろ。もしくはもう寝ろ。

744 ：仕様書無しさん：2007/12/09(日) 22:57:05

骨董品の知識も無く価値も分からない人たちが、骨董品について品評しているみたいな感じ？

745 ：仕様書無しさん：2007/12/09(日) 22:59:46

「最初にコストがかかってるって理解できない信者大杉。」

うちのチームにいる「OOだと開発が楽になるんです！」と言い張って期間無視で設計しまくりたがる香具師どうにかしてくれ・・・（ ´Д⊂ヽ

746 ：仕様書無しさん：2007/12/09(日) 23:01:45

>>739
なんだよそのバカっぽい文章。保守性を考慮すれば初期コストがかかる？
お前プログラム組んだことないだろ？こんな奴がほんとに国家プロジェクトやってんのか？
日本の将来も暗いな。

747 ：仕様書無しさん：2007/12/09(日) 23:01:49

ＯＯだと設計に時間がかかるって事が理解出来ない。
それはまさか、ＯＯの学習まで一緒に期間に組み入れてはいまいか？

748 ：仕様書無しさん：2007/12/09(日) 23:03:46

>>746-747
本格的に設計したことないでしょ？
たぶん誰かが作ったクラスライブラリを使ってるだけなのに設計した気になって「OOは楽チン」とか言ってない？

749 ：仕様書無しさん：2007/12/09(日) 23:06:24

オブジェクト指向方法論OMT　の１０ページ目の１２行目読め。

「オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである。」
とはっきり書いてあるから。
これ理解してない信者はマジでただのバカ。

750 ：仕様書無しさん：2007/12/09(日) 23:09:40

http://www.ijinden.com/_c_04/James_E_Rumbaugh.html

「オブジェクト指向開発による主な利益は開発時間の短縮ではない。
オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである」

「オブジェクト指向方法論ＯＭＴ」より

オブジェクト指向開発の最も顕著な利益は、コンピュータ・システムの構造が人間に分かり
易い形に構成されるという点にある。このことはそのシステムの変更時や、そのシステムを
土台にした次のシステムの開発時に威力を発揮する。つまり、最初に作ってそれでおしまい
ではなく、「継続的な改変と成長の過程にこそ生きたシステムがある」という観点に立ったとき
に初めてオブジェクト指向開発の本領が発揮されるのである。このことは通常の一回限りの
受託開発では往々にして忘れられるか理解されないことが多く、特にマネージャクラスが
わかっていないとプロジェクトは予算と納期の狭間で深刻な困難に直面することになる。

751 ：ガリレオ：2007/12/09(日) 23:11:57

>>741
ん？俺には正しく理解できないが
俺は、OOが最初にコストかからないと思っていると思っているのか？

>「OOの優位性が発揮でき、費用対効果はVer６ぐらいで同等か優位になると思う。」
費用対効果がVer６ぐらいで同等か優位になると言うのは
OOが最初にコストがかかって、そのコストが回収出来るのがVer６ぐらいだと書いたつもりだが
ちなみに費用対効果は、支出した費用に対して得られる効果のことだから
優位になると言うのは、初期コストが回収出来ると言うこと

752 ：仕様書無しさん：2007/12/09(日) 23:11:58

>>749
本に書かれたことを闇雲に盲信するのもどうかと思うが・・・慣れの問題じゃね？
慣れればOOの方が全体的な工数は短縮されるケースが多いよ。うまくやれればの話だけど。

753 ：仕様書無しさん：2007/12/09(日) 23:13:19

通常って、初回は原価割れで落札しといて
後から機能追加で儲けるビジネスモデルだろ

754 ：仕様書無しさん：2007/12/09(日) 23:15:53

いや、もともと設計には時間がかかる物なんだよ。
ＯＯだけが特別時間がかかる物でもないんだけどね。
それを、専門書にＯＯの設計云々書いてあるからって、言い訳にすんなってことさ。

755 ：仕様書無しさん：2007/12/09(日) 23:17:05

>>751
ﾊｹﾞﾄﾞｳだよ。最初にコストがかかって、そのコスト回収できるのが後のバージョンの頃ってこと。

>>752
盲信はどっちだよ。
本格的にOOやってりゃ現実に最初に多大なコストがかかるって実感するし理解するだろ。

で、プロジェクトが続くか分からないし、逆に続いた場合プロジェクトが成功しててしっかり
作り直せる程潤沢な予算が出る可能性もあるのに、
「あえて最初にコストかける」というリスキーなことはやらないという判断もあるよ。

756 ：仕様書無しさん：2007/12/09(日) 23:17:47

「オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである」

>>754 「と比べてより」という日本語は理解できる？

757 ：仕様書無しさん：2007/12/09(日) 23:19:20

>>756
それでも単なる言い訳。
開発現場でそれ言ったら、殴られるw

758 ：仕様書無しさん：2007/12/09(日) 23:19:29

聖典に"従来の開発方法と比べてより時間のかかるもの"なんて書いてあるのを指摘されて信者が苦しくなってきたなｗ

本を信じるな、とか、慣れ、とかｗ

759 ：仕様書無しさん：2007/12/09(日) 23:20:26

教典を書き換えるしか無いなw

760 ：仕様書無しさん：2007/12/09(日) 23:21:46

だんだん信者のOOが「現場で覚えたオレオレOO開発」になってきた点について

761 ：仕様書無しさん：2007/12/09(日) 23:22:51

本好きなお前らにこの本をお薦めする。
ttp://www.amazon.co.jp/dp/4334033415/ref=nosim?tag=asiamoth-mt-22&link_code=as3&creativeASIN=4334033415&creative=3999&camp=767

762 ：仕様書無しさん：2007/12/09(日) 23:23:20

新参が集まってスレが活性化してきた

763 ：仕様書無しさん：2007/12/09(日) 23:28:02

多分、４～５人が活発に書き込んでるだけだと思われ。

764 ：仕様書無しさん：2007/12/09(日) 23:28:04

で、おじゃばが「祭りに参加できなかった」発言か？w

765 ：仕様書無しさん：2007/12/09(日) 23:31:20

すまん、全部俺が自演した。反省はしていない。
じゃ、そろそろ寝るから。

766 ：仕様書無しさん：2007/12/09(日) 23:38:30

乗り遅れた感が。
俺は構造化大好き人間だが、「OOはコストが掛かる」という話は微妙だと思う。

個人的には
「保守性、拡張性を考えた設計、実装は、それらを考えない場合よりコストがかかる」
という意見。
で、「OOでは保守性、拡張性を常に考える」ので
「他の手法でそれらを考えない場合」に比べてコストが掛かるのだと思う。
同じレベルで作れば、構造化でも同じぐらいにコストが掛かる。

そういう意味で、OOだからコストが掛かってるわけでは無いのでは？

767 ：ガリレオ：2007/12/09(日) 23:40:28

>>755
勘違いしてた、すまない

ついでに、議論を正常に戻すために質問したい
保守コストを減らすのは、OOが良いのか？
他の方法諭で作った、言語に依存しないDLL・COM・CORBAと比べて
保守コストが飛躍的に下がるのか？
同等か、少し優位ぐらいならOOの学習コストをどう考える？

768 ：仕様書無しさん：2007/12/09(日) 23:42:25

設計にコスト掛けないとデバッグにコストがかかるからトントン・・・いやそれ以上？

769 ：仕様書無しさん：2007/12/09(日) 23:45:11

>>766
正しいけど、OOは保守性を考えるのが必要条件になってるから、「必ず」コストがかかる。
他はどっちでもいいのでコストをかけない選択肢もある。
保守性を考えればどの方法でもコストはかかる。

ただし保守がどうでも良いケースで、「必ずコストがかかる」OOを選択するのはバカ、という話。

ところが、信者はそのコストを認めたくなくて
聖典はウソだとか慣れだとか、俺のところは違うとか、そんなケースは無いとか、
もうめちゃくちゃな話になってるわけ。

770 ：仕様書無しさん：2007/12/09(日) 23:51:26

何、保守コストを減らしたい。そんなの簡単だよ。君のプロジェクトのプログラマ全員に、
スティーブマコネルのCode Complete第2版の上下巻を読ませ理解させなさい。
1月かけても構わん。何？そんな暇もお金もない？チッチッチッ、それこそ初期コストと
いうものだよ。
今後そのプログラマ達が稼ぎ出すであろう莫大な利益は考えたら安いものだよ。
いわば先行投資だ。それだけの価値があるのだよ。私を信じなさい。

771 ：仕様書無しさん：2007/12/09(日) 23:53:34

>>770
あんな今までの経験メモみたいなの読んでも、何も得られなかったがな。
普通にマやってりゃ誰でも思ってる事書いてあるだけだよ。

772 ：仕様書無しさん：2007/12/09(日) 23:55:12

>>769
OOは保守性を考えるのが必要条件・・・なのか？　そんなの無視して結構無茶してるの多いぞ。

773 ：仕様書無しさん：2007/12/10(月) 00:00:21

>>771
だから特に新人に読ませて欲しいのだよ。プログラマが数年かけて経験的に得るであろう知識を
1万円ちょっとのお金と1月やそこらの期間で得られるのだからな。相当なコスト削減だろう。

774 ：仕様書無しさん：2007/12/10(月) 00:03:03

新人が先人の経験からのセオリーを素直に受け入れるなら苦労しねえよw

775 ：仕様書無しさん：2007/12/10(月) 00:20:54

>>767
全然横槍だけど。
大して変わらんと思う。
でも、現場の勘ではやってるけど、機能分割ベースの、抽象化された
モジュールの設計実装(一部でモジュール指向とか言われてるヤツ)って
体系化されてないからさ・・・。（注目される前にOOに食われた）
最近の流れじゃKKDに頼っちゃいけない部分が確かにあるのよ。

776 ：ガリレオ：2007/12/10(月) 00:45:39

>>775
有り難う、特定の人に聞いていないから、誰でも良かった
俺が具体的に想定してたのは、DOAでの開発で
DOAでのモジュール分割を、言語や方法諭に依存しない
形で行なった場合に、OOの優位性を聞きたかった

けして、勘や度胸にたよったものではないのだが．．．

777 ：仕様書無しさん：2007/12/10(月) 07:38:31

またヘンなコテが・・

778 ：仕様書無しさん：2007/12/10(月) 23:22:45

>>776
最初に言っておくと、データ指向は良く知らん。
ソフ開かなんかの勉強でチョロっと見た程度。

基本的には、DLLは手続きの集合で構造化的なもの、
COMはオブジェクトでオブジェクト指向的なものじゃ無いの？
ごめん。CORBAは知らないわ。

さておき。
初心者的な知識で返す返す申し訳ないけど、
DOAってデータベースのような構造が変わらないデータをシステムの中心に置いた考え方で、
機能追加や仕様変更とかでデータ構造がコロコロ変わるような要件には、
そもそも向いてないんじゃないの？

例えばGUIアプリであるとか、まだ規格がドラフトなプロトコルの実装であるとか。

DOAが適したシステムの開発においては、OOの優位性はそれほどは無いと思う。
ただまぁ、継承だのオーバーロードだの、OOのサブセット(?)で解決出来る問題なら、
変更の影響の範囲を縮小することが出来る場合もあるかも知れない。

779 ：仕様書無しさん：2007/12/11(火) 22:52:12

このスレも終了？

780 ：仕様書無しさん：2007/12/11(火) 23:01:46

はい、終了です。

781 ：仕様書無しさん：2007/12/11(火) 23:15:03

終了っつーか自演で引っ張ってるだけだからな

782 ：仕様書無しさん：2007/12/12(水) 21:46:25

おじゃば節がもう見れないと思うと

・・・ドーデも良いな。
うざいだけだし。

783 ：ガリレオ：2007/12/12(水) 22:17:55

>>778
亀レスですまない

俺の書き方が悪かった
俺が知りたかったのは
設計方法に依存しない
ミドルウェアの機構を使った場合と
OOとの比較で保守性・拡張性の
利点・欠点を、どう思うのか知りたかった
OOが保守性・拡張性が良いのは分っているが
ミドルウェアである程度補えるなら
方法諭の良し悪しを論じる事の意味は．．．
その辺も、他人の考えを知りたい

784 ：ガリレオ：2007/12/12(水) 22:22:49

>>778
あと、データを中心に簡単にDOAの説明を書いとく
イメージを掴んで貰えれば嬉しいが

・POA（機能中心アプローチ）・・・一応「機能」となっているが
　もともとコンピュータは入力データを加工してデータを出力するしかできない
　このデータの加工が機能となる、この機能は出力データの為にある
　つまり、POAは出力データを中心にモジュール分割する方法

・DOA（データ中心アプローチ）・・・出力データは変更・削除・追加が起こりやすいと言う
　POAの弱点から、より安定した入力データに着目したモジュール分割がDOA

ついでに、分っていると思うが
・OO（オブジェクト指向）・・・基本的にはDOAと同じ入力データ中心だと思っている
　ただDOAが、DBで言うテーブル毎にモジュール分割するのに対して
　OOは、設計時にテーブル（クラス）と実行時にレコード（オブジェクト）とより
　詳細なモジュール分割が可能になっている

785 ：仕様書無しさん：2007/12/13(木) 19:37:23

ガリレオ＝おじゃばさまの変装か？

786 ：仕様書無しさん：2007/12/13(木) 21:39:31

>>783
なんか勘違いしてるようだから言っておくと、
モジュールを単純にDLLやらCOMやらに変えたところで
保守性は上がらんぞ？
単にコンパイルしなくても使えるだけ。
言語に依存しなくなる、とは言っても良いかもね。(ちょっと極端だけど)

結局DLLやCOMの特徴は、それを作る時の設計方法による。
プロセス指向なりデータ指向なりオブジェクト指向なり。

787 ：ガリレオ：2007/12/14(金) 00:23:29

なるほど、質問の前提条件である
DLL・COM・CORBAには保守性があると考え方自身が
違うと言うことか、それならまず俺の考える保守性を説明させてもらうと

どのようなモジュールが保守性がが高いのか？その定義は
予期せぬ仕様変更・追加に対して
　・修正個所の極小化
　・影響範囲の極小化
　・修正の容易さ
だと思う、別の言い方をすると「変更・追加にコストを掛けないで済む」ということ

ではOOが他の方法諭より保守性が高い理由は
　・修正個所の極小化・・・継承
　・影響範囲の極小化・・・カプセル化
　・修正の容易さ　　　・・・多態性など（ちょっと微妙かな）
という機構が準備されているから、ではDLL・COM・CORBAの保守性は？
　・修正個所の極小化・・・独立モジュールだから修正個所はモジュール内に限定できる
　・影響範囲の極小化・・・これも、独立モジュールだから影響個所がモジュール内に限定できる
　・修正の容易さ　　　・・・無し
となる、これだけだとOOが有利に思えるが
言語レベルでのモジュール結合には、独立性(保守性)を低くする
グローバル変数などがあるから、圧倒的に有利だとは言えない
俺は同じぐらいの保守性レベルだと思っている

788 ：仕様書無しさん：2007/12/14(金) 00:30:15

＞予期せぬ仕様変更・追加に対して
＞　・修正個所の極小化
＞　・影響範囲の極小化
＞　・修正の容易さ
＞だと思う、別の言い方をすると「変更・追加にコストを掛けないで済む」ということ

銀の弾丸の話は先生から教わってないのか

789 ：ガリレオ：2007/12/14(金) 00:48:57

比喩のつもりだろうが、何が言いたいのか分らない
言いたい事があるのなら、相手に分るように論理的に書け

790 ：仕様書無しさん：2007/12/14(金) 00:55:56

理想論もそこまで逝くとただの妄想って話

791 ：仕様書無しさん：2007/12/14(金) 09:25:58

>>787
CORBA知らない子です。
○ DLL
DLLに関しては完全にNO。
例を挙げるとDLLとDLLを使うプログラムで共通の外部変数を定義出来る。
極論を言うと、何も考えずに作ったCのプログラムの全ての関数を
それぞれ別々のDLLにすることが出来る。
これだと保守性が上がるどころかむしろデバッグし辛くて保守性が下がる。

○ COM
COMはオブジェクト指向におけるクラスに近い。
(てかそもそもCOMの思想ってオブジェクト指向に基づいてんだっけ？)
インターフェースが既にある程度規程されているため、
あまり考えなくても、幾らかの保守性の向上が期待出来るかも知れない。
意識しないうちにオブジェクト指向かソレっぽい何かの考え方を
強制されているとも言えるかも知れないけど。

ただし、インターフェースが決められているため、
全てのモジュール(クラス)をCOM化することは出来ない。
(やりゃあ出来るのか・・・？)

792 ：ガリレオ：2007/12/15(土) 15:06:09

>>791
>例を挙げるとDLLとDLLを使うプログラムで共通の外部変数を定義出来る。
それは確か、Win１６の話か？Win３２では手続き(マッピングとか)を踏まないと使えないと思うが

>極論を言うと、何も考えずに作ったCのプログラムの全ての関数を
>それぞれ別々のDLLにすることが出来る。
>これだと保守性が上がるどころかむしろデバッグし辛くて保守性が下がる。
たしかに、作り方によってはいくらでも保守性を下げることは可能だと思う
俺の言いたいのは、同じ条件（同じスキルの人間）で作った場合
OOの保守性が、ミドルウェアを使った場合より優位性がどれだけあるのか？
と言うことが疑問だった

ちなみに、DLL・COM・CORBAは俺の記憶が間違っていなければ全てC言語（C++ではなく）で作れる
つまり、OOは必須では無い（もちろんOOの方がより機能を発揮出来るが）

793 ：仕様書無しさん：2007/12/15(土) 22:12:28

なんだ。
何か話がかみ合わないと思ったら実装に限った話か。
それもOOPがどうという話ではなくて、
OOPLとDLLを比べてんのかな。

ケースバイケースだとは思うけど一般論で言えば、
継承とかオーバーロードとかで多機能な分、
DLLよりOOPLの方が保守性をより高く実装出来ると思うよ。
変更の影響の範囲を狭めたり、変更箇所を減らしたりと言った辺りで優位。
モジュール(DLLやクラス)の内部構造がシンプルであり、
かつモジュールの外部インターフェースが変わらないような変更の場合には、
どちらでも大差ない。

バグフィクス時の原因箇所の特定のような件は設計によるので割愛。

ただし、>>643-644
多機能な分、全体(もしくはモジュール)を俯瞰出来る程度に
中身を知るまでは、OOPLの方が大変かも知れない。

794 ：仕様書無しさん：2007/12/16(日) 01:10:18

DLL...とOOがなぜ比較されなきゃならんのだ？

795 ：ガリレオ：2007/12/16(日) 14:55:23

>>793
>ケースバイケースだとは思うけど一般論で言えば、
>継承とかオーバーロードとかで多機能な分、
>DLLよりOOPLの方が保守性をより高く実装出来ると思うよ。
>変更の影響の範囲を狭めたり、変更箇所を減らしたりと言った辺りで優位。
一般論は分る、影響・変更個所を極限化出来るのも分る。しかしその為には
OOの学習コストが掛かるし、それが正しく出来ているか判定は難しい
しかしミドルウェアを使用した場合、影響・変更個所を極限化は出来ないが
OOより明確に限定出来る。また「修正の容易さ」はOOが本来システムが問題解決に
必要としないOOの為の手続き（メタクラスとか）が、他の方法諭より多いと言う問題点もある
（もとろん、その手続きが保守性を上げるのだが）

>>794
主だった方法諭（POA・DOA・複合設計・契約・OO）では、いかにモジュール分割化をするかで
差別化？されている（もちろんホーワ系みないな例外もあるが）
結局モジュールレベルより、詳細な部分では構造化の「順次・反復・分岐」しかない
これは俺の主観だが、ノイマン型コンピュータが続く限りアルゴリズムレベルでは構造化しかないと思っている
ちょっと話はそれたが、このモジュール分割と言う事で
方法諭のOOと、システムとしてモジュール分割を提供するミドルウェアを比べたかった

796 ：仕様書無しさん：2007/12/16(日) 15:04:43

>>795
関数型言語って知ってる？

797 ：仕様書無しさん：2007/12/16(日) 16:24:51

それがどうかしましたか？

798 ：仕様書無しさん：2007/12/16(日) 16:30:18

＞結局モジュールレベルより、詳細な部分では構造化の「順次・反復・分岐」しかない
＞これは俺の主観だが、ノイマン型コンピュータが続く限りアルゴリズムレベルでは構造化しかないと思っている

無知晒しすぎ

799 ：仕様書無しさん：2007/12/16(日) 16:32:03

どうしてもかならずプロジェクト中盤でクラス構成に無理が生じて、クラス
再編成することになってしまうのだが、その工数が馬鹿にならん。

800 ：仕様書無しさん：2007/12/16(日) 16:50:59

>>796
関数型言語を手法だと思っているのか？

801 ：仕様書無しさん：2007/12/16(日) 16:53:26

>>800
手法と言語が独立だと思っているのか？

802 ：仕様書無しさん：2007/12/16(日) 16:53:51

＞結局モジュールレベルより、詳細な部分では構造化の「順次・反復・分岐」しかない

いい加減コボラは絶滅しろよ

803 ：仕様書無しさん：2007/12/16(日) 16:57:35

チューリングマシンとかラムダ計算でググれば？

804 ：仕様書無しさん：2007/12/16(日) 17:07:58

>>801
構造化言語が手法と思っているのか？

805 ：仕様書無しさん：2007/12/16(日) 20:48:36

>>795
根本的に間違えとる。
DLLは単に実装の形態。
モジュールの実装に「DLLを使うかどうか」が比べられる対象は、
「OOPLのクラス(OOA/D/Pでのクラスではなく)を使うかどうか」程度のもの。
結局DLLを使うにしても、どのモジュールをどのようなDLLにするか、の部分で、
AOやらOOやらの方法論、というか設計ポリシーに頼ることになる。

＞方法諭のOOと、システムとしてモジュール分割を提供するミドルウェアを比べたかった
詳細設計と言えど設計手法(OOP)と実装手段(DLLやOOPL)を比較するのはナンセンス。

仮にDLLが詳細設計手法を提供するとして、DLLの内部についてもDLLを使うのか？
DLLが多階層的にDLLを使用するシステムなんてメンテナンスしたくないが。

806 ：仕様書無しさん：2007/12/16(日) 21:21:32

>>805
をいをい、現実的にはDLLがDLLを読み込んでいるだろ？
しっかりつくれば、システムレベルのDLLで済むけどな。

807 ：仕様書無しさん：2007/12/16(日) 21:47:25

ＯＯ開発プロセス
ＯＯ設計
ＯＯプログラミング

のどれが対象かを明記しようぜ。
まぁこのスレの大半は一番下のソルジャーだから、自然と一番下が前提だろうけど。

808 ：仕様書無しさん：2007/12/16(日) 22:04:38

>>806
でもソレって、他人が作ったか昔自分が作ったかで
しかも比較的バグの枯れてるDLLじゃね？

809 ：仕様書無しさん：2007/12/16(日) 22:34:46

>>808
無論そうだが？
・・・マジな話、一から自分で作ったDLLって怖くね。

810 ：ガリレオ：2007/12/18(火) 00:13:49

レスくれた人ありがとう

>>796
>関数型言語って知ってる？
>>798
>＞結局モジュールレベルより、詳細な部分では構造化の「順次・反復・分岐」しかない
>＞これは俺の主観だが、ノイマン型コンピュータが続く限りアルゴリズムレベルでは構造化しかないと思っている
>無知晒しすぎ
>802
>＞結局モジュールレベルより、詳細な部分では構造化の「順次・反復・分岐」しかない
>いい加減コボラは絶滅しろよ

同一人物か？、多分LISPとかの非手続き型言語の事を言っていると思うが？
関数型言語はそんなに詳しくないから、知っている範囲で答えると
たしかに、宣言型言語は「反復・分岐」を必要としないが
宣言型言語（非手続き型言語）は、ノイマン型コンピュータの欠点を言語レベルで補う
非ノイマン型コンピュータをシュミレーションするものだと思っている
違っているか？俺の言っているノイマン型コンピュータ上での方法諭とは違うと思うが
俺も知らないことが、まだまだあるのでノイマン型コンピュータで
「順次・反復・分岐」以外の良い詳細設計があったら教えて欲しい。

あと要望だが、もう少し具体的に書いて欲しい、別に間違っていても構わないし
揚げ足をとったりする気もない、関数型言語とか知っているのだから
知識はあるだろう、それを元に詳しく書いて欲しい

811 ：ガリレオ：2007/12/18(火) 00:14:44

続き

>>805
>根本的に間違えとる。
最初にそう書かれるとびっくりするな(笑)
>DLLは単に実装の形態。
>モジュールの実装に「DLLを使うかどうか」が比べられる対象は、
>「OOPLのクラス(OOA/D/Pでのクラスではなく)を使うかどうか」程度のもの。
>結局DLLを使うにしても、どのモジュールをどのようなDLLにするか、の部分で、
>AOやらOOやらの方法論、というか設計ポリシーに頼ることになる。
極端な例で悪いが、例えばアセンブラで作った場合はどうだ？
一つのEXEで作った場合と複数のDLLで構築した場合は？
もちろんアセンブラだから、直接的な方法諭の適用もできないが
明らかにDLLで構築した方が、保守性・再利用性などが高くなる
このような、特徴があっても比べるのはナンセンスなのか？

812 ：仕様書無しさん：2007/12/18(火) 01:21:46

DLLって単に「動的」ライブラリってだけじゃないの？
何をこだわってるのか分からん。

813 ：仕様書無しさん：2007/12/18(火) 02:20:33

手続き言語でプログラム書いても、そのままバイナリに落ちるわけじゃなし
ノイマン型と設計の関係がわからん

814 ：仕様書無しさん：2007/12/18(火) 02:25:07

シュミレーションｗ

815 ：仕様書無しさん：2007/12/18(火) 21:33:55

>>811
＞一つのEXEで作った場合と複数のDLLで構築した場合は？
中略
＞このような、特徴があっても比べるのはナンセンスなのか？

ナンセンスだと思うよ。
「極端」と言っているので、微妙な点に目をつむれば、アセンブラとDLLの比較はまだアリだと思う。
なんでかというと、アセンブラは言語で「実装手段」であるので、805から言葉を持ってくれば、
カテゴリは「実装手段(DLLやOOPL)」の方に入るだろ？

例に例で返すと話がズレがちなんで微妙なんだけど、
俺には、「OOPとDLLはどちらが保守性を確保し易いか」と言うのは
「構造化プログラミングとC言語はどちらが保守（ry」と言っているのと
同列に見えている。

816 ：仕様書無しさん：2007/12/18(火) 23:26:44

そもそもDLLは保守性のために作られた仕組みじゃないしな、地獄まねくし。
そーいったらOOPもそうだけど。
ただ、hoge.cppのほうがコンパイル後のhoge.dllよりは
たしかに保守性は高いだろうｗ

817 ：仕様書無しさん：2007/12/21(金) 00:52:50

おもいっきり話がおかしいよな

オブジェクト指向的にDLLをクラスっぽく組めば、OOっぽく作れるし、
機能分類まるだしならそういう風に組める

どうやって作るかが前提のはずなのに、
DLLだからこうなる、OOだからこうなる、
と断定的に言っても意味ないだろ

818 ：仕様書無しさん：2007/12/29(土) 22:50:01

まだやっていたのか

悲惨なスレｗ

819 ：仕様書無しさん：2007/12/29(土) 23:08:43

悲惨なすれであることは同意するが、
一番悲惨なのはおじゃばだ。

820 ：仕様書無しさん：2007/12/31(月) 07:12:10

ボケがいなくなって解散したみたいなスレだな

821 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/07(月) 19:14:51

あけおめ。
やっとアクセス規制が解除された。

822 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/07(月) 19:38:31

OOとDLL/COM/CORBAを比較するのはおかしい。理由は805の言う通りだ。
話の内容を見ると、OOとDLLではなく、クラスとデータ結合型の関数を比較したいのかな？
それなら納得出来るが。

823 ：仕様書無しさん：2008/01/07(月) 20:58:52

おめーさんは一生アク禁されてればよかったのに。

824 ：仕様書無しさん：2008/01/07(月) 21:54:47

あ、死んだんじゃないのか。

825 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/08(火) 21:45:29

なんだもう終わりか？
CORBAの話でもするか。

826 ：仕様書無しさん：2008/01/08(火) 21:56:00

新しい話題振れよ

827 ：仕様書無しさん：2008/01/08(火) 22:06:06

さすがコミュニケーション不全者は言うことが違うな。
半月ほども放置されてたスレ＆話題で「もう終わりか」もねぇだろ。
既に終わってただけだ。

828 ：仕様書無しさん：2008/01/08(火) 23:37:15

さすが、おじゃば空気読めているぜ・・・。
ここでマトモな対応取ったら反応に困る所だ。

829 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/09(水) 09:49:31

では全然関係ないが、職場でのコミュニケーションについて話すか。
最近、隣や周囲の人とチャットやIMで話す人がいるが、これっておかしくないか？

830 ：仕様書無しさん：2008/01/09(水) 10:42:57

記録が残って便利じゃん

831 ：仕様書無しさん：2008/01/09(水) 11:35:12

おかしいと思う理由を提示しろよ
アホコテ

832 ：仕様書無しさん：2008/01/09(水) 14:21:24

ここで会話してる奴よりはマトモだろ

833 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/09(水) 19:49:04

>>831
会話なら数秒で終わるのに、チャットだと数分かかるから効率が悪い。
無表情でキーを打っているが、チャット上では顔文字満載で怒ったりギャグ言ったりで、気味が悪い。

834 ：仕様書無しさん：2008/01/09(水) 21:20:38

知るか

835 ：仕様書無しさん：2008/01/09(水) 23:37:35

おじゃばが、完全にスレタイするーするのが始めてだな。
悪いものでも食ったか？

836 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/10(木) 09:48:28

リアルでは無表情でチャットでは感情豊かな人の特徴としては、チャット依存度が高い人だと言う傾向がある。
つまり、勤務中リアルに会話する時間より、チャットで会話する時間の方が遥かに長いと言う事だ。
人間は無意識のうちに感情に表情を連携させているが、実は経験によって刷り込まれた情報によって
動いているのではないだろうか。つまり、笑いの感情を抱いたら、この筋肉を動作させろと言うように。
チャットで表情を操作するのは無意味だ。チャット依存度の高い人は、この表情筋肉の動作が顔文字入力に
変更されているのではないだろうか。
つまり、顔文字率が高い人ほど、無表情だと言う原理になる。
ってどうよ。

837 ：仕様書無しさん：2008/01/10(木) 11:29:14

おじゃばとは会話したくないだけじゃないのか。

838 ：仕様書無しさん：2008/01/10(木) 11:32:25

納得

839 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/11(金) 11:51:08

つまり表情はインタフェースで、感情はフィールド変数と言う訳だ。
そして筋肉を操作するのがメソッドとなる。
チャット依存者はそのメソッドが、顔文字にオーバーライドされていると言う事になる。

840 ：仕様書無しさん：2008/01/11(金) 11:53:42

こういうアホとは顔つきあわせて会話したくないだろうな
その気持ちはよくわかる

841 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/11(金) 20:38:29

(´-`).｡ｏＯ(なんでだろう？)

842 ：仕様書無しさん：2008/01/11(金) 23:15:53

携帯メールと一緒だろ
俺の彼女も絵文字やたらと使うけど、
絵文字に合わせて表情変えながら携帯いじられてたらちょっと引く
でも絵文字で気持ちは伝わるしな

おじゃばが分かってないのは時間差のことだろうな
会って話をすれば自分が自分自身を表現するけど、
メールやチャットならその文面が自分自身を表現することになる

リアルで穏便に話が進むけど、メールだと冷たい印象与えまくり、
とかどんだけ人間関係無視だよ

843 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/16(水) 09:04:38

そうか、携帯メールからの流れを忘れていた。
確かに電車で携帯メールを打つ場合は、恥ずかしいから無表情になるな。
携帯メールの影響と考えるのが、最も自然だな。
携帯メールに慣れた人は、距離に関係なく文字でコミュニケーションを取るのに抵抗がないと言う事か。
と言う訳で、解決だな。

844 ：仕様書無しさん：2008/01/16(水) 10:08:56

>1
表記覚えるのが難しいから

と話を戻してみる

845 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/16(水) 20:47:04

つーか、オブジェクト指向は普及している。
大体、新人にはJavaから教える事が多いので、最初からオブジェクト指向と言う場合も多い。
さらに優秀な技術者なら、JavaやC++をマスターしているだろうから、ベテランもオブジェクト指向だ。
Javaから入った人が中堅やベテランになりつつある現在、オブジェクト指向を学ばなかった人は、
一部の例外を除き、Javaから入ったオブジェクト指向を使いに置き換わるだろう。

846 ：仕様書無しさん：2008/01/16(水) 21:01:33

新人研修でやった内容なんて業務に参加する頃にゃ忘れてるって

847 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/16(水) 21:11:11

いや業務がJavaやC++なんだよ。教えるってのは研修でなくて実践。
すでにCの利点って言われてた「早さ」も、C++（STL）に奪われつつある。
Cってより、C/C++（C++でもいいよ）の案件の方が多いんじゃないか？

848 ：仕様書無しさん：2008/01/16(水) 21:12:26

新人にはJavaから教える事が多い <- 間違いだろ？
新人はOOを学校で学んで来ているので、JavaやOOは教えない場合が多い。

849 ：仕様書無しさん：2008/01/17(木) 09:43:21

>>848
おまえ就職したことないだろ

850 ：仕様書無しさん：2008/01/17(木) 11:36:26

オブジェクト指向方法論は普及しつつある（理解されてはいないけど）が
JAVAはどう見てもマイナー言語化してるだろ
５年ほど前のJAVA流行期に比べたら業務案件数どんどん減ってきてるぞ
社員募集でもJAVA経験者優遇/募集は非常に少ないな

ｲﾝﾃﾘｼﾞｪﾝｽのｷｬﾘｱｺﾝｻﾙにも確認してもらってるからほぼ間違い無いかな
需要はあるみたいだけどそういうところはほとんどJAVA開発のみの会社だね

851 ：仕様書無しさん：2008/01/17(木) 15:05:14

>>850
javaって最近凋落激しいからな
やっぱ、java凋落の最大原因は　おじゃばさま ◆GxjxF3yEw6 だろ
優秀な開発者に案件は依頼したほうが良いと解ってきたんだよ
javaって低能、ゆとり開発者の巣窟だからな

852 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/17(木) 19:57:28

>>850
減ってきたと言うよりは、ブームは過ぎて、定着してきたと言う所だろう。
Javaメインの会社が増えて来たのは、Cで出来る事の殆どがJavaで出来るようになったからと言える。

>>851
つーか、851はJava出来ないのか？
もし3年以上PGやっていて、Cしか出来ないなら、ずいぶんゆとりだな。

853 ：仕様書無しさん：2008/01/17(木) 20:30:12

だろう(推測)→増えて来た(断定)→言える(結論)
　　　　　　　 ↑
この辺にあるはずの根拠はどこに書いてあるの？

854 ：仕様書無しさん：2008/01/17(木) 20:31:30

おじゃばのえらい所：ＣとＣ＋＋とＣ＋＋(ＳＴＬ)をきちんと区別(自分の中で)しているところ
おじゃばのわるい所：ＣとＣ＋＋とＣ＋＋(ＳＴＬ)をきちんと区別(自分の中で)しているところ

855 ：仕様書無しさん：2008/01/17(木) 20:33:26

Java案件って携帯アプリとサーブレットがほとんどじゃね？
ニッチだとは言わないけど、業務の幅はそんなに広くないだろ。

856 ：仕様書無しさん：2008/01/17(木) 20:43:48

>>852
PG丁稚奉公はじめて、もう、３年だが
Cの仕事しかさせてくれないんだ.....orz

857 ：仕様書無しさん：2008/01/17(木) 21:29:33

>>856
会社の仕事がすべてじゃないだろ

858 ：仕様書無しさん：2008/01/17(木) 22:17:08

別にわざわざ家で仕事で使わんJava触らんでもええやん。
マやってく上でJavaなんぞ出来ないからって何の問題も無いし。

859 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/18(金) 10:13:42

>>853
>JAVA流行期に比べたら業務案件数どんどん減ってきてるぞ
>需要はあるみたいだけど...
流行期から数は減るが、ある一定以上の数が残るのは、流行期から安定期に入った特徴と言える。

>...JAVA開発のみの会社だね
以前はJava開発のみの会社はほとんどなかった。
実際はJava開発のみではなく、Cやスクリプトメインの会社がJavaメインになっただけだと思うが、
「ほとんどない」→「需要を満たすだけの数がある」と言う事は、増加したと言える。

>>854
STLを知らない者は、C++を使えるとは言えず！！

>>855
データを入力してDBを更新するような、Cで行われていた普通の業務プログラムは、殆どJavaに変更可能。
Javaにする利点は、マシンやOSのサポートが切れても修正が殆ど必要ないと言う点だ。

860 ：仕様書無しさん：2008/01/18(金) 11:21:48

そんな必死になるなよｗ
企業間案件でJAVAがどれくらい出てるか知ってるの？
完全に先細りだよ
JAVA特化した会社はニッチに適応してるだけ
しかもJAVAでなくてはできない案件はほとんど無い(JINI関係くらいか？絶滅しそうだけど）

COBOLは一時市場を席巻したので現在も引き続き案件があるし
枯れた技術を望むユーザーからの新規案件もある
しかしJAVAにはその土台が無い状態での先細り
.NETが本線になるかは知らんがJAVAと違い案件増大中

861 ：仕様書無しさん：2008/01/18(金) 11:23:47

OOは言語に依存しないからな
何でもいいよJAVA以外なら

862 ：仕様書無しさん：2008/01/18(金) 20:45:49

>>859
ところでおじゃばはC++使えるの？

863 ：仕様書無しさん：2008/01/18(金) 21:00:43

>>859
お前の根拠って主観か
sourceは？

864 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/18(金) 21:07:20

>>856
ではそのCをどの程度マスターしているか判定してやろう。
まず3年目と言えば言語レベルの問題は、全てクリアしているのが標準的と言える。
つまり、
1.処理（演算、関数呼び出し）、判断（if）、繰り返し（for）が使える。
2.関数が使える、作れる。構造体が使える。ポインタが使える。
3.標準入出力が使える。ファイル操作が使える。
4.リスト構造体、再帰が使える。
5.関数のポインタが使える。
ここまで出来ていれば、まあよくやってると言っていい。

これに加えて次の処理を、1つ以上マスターしているのが望ましい。
1.メーカーのDBアクセスAPIが使える。
2.fork()/exec()が使えて、マルチタスク、デーモンプログラミングが出来る。
3.ソケット関数が使えて、ポーリング処理が出来る。
もし3つが出来るなら、Cはほぼマスターしていると言っていい。

865 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/18(金) 21:33:20

>>860
Java案件はたくさんあるが、この際、そんな事はどうでもいい。
OOを学習する上でJavaは適切だ。Cを覚えた後にC++をやると、構造化の知識が邪魔をして、
OOを理解するのが困難になる。Cをマスターした後にJavaをマスターすれば、C++やC#の習得も楽になる。
だからJavaをやって損はない。
また俺はCOBOLも使える。ただあれは初心者でも2カ月でマスター出来る言語だから、
大して優位だとは言えない。つまりCOBOL出来る人よりJava出来る人の方が偉い。

>>862
俺はC++をマスターした。
昔、Cしか知らなかった頃、C++をやった時は挫折して、こんなの人間の理解出来る言語じゃないと思ったが、
Javaを習得した俺は1年でほぼ完璧にC++をマスターした。
教えてほしいか？

866 ：仕様書無しさん：2008/01/18(金) 22:03:08

マスター（笑）

867 ：仕様書無しさん：2008/01/18(金) 22:14:18

>>864
＞1.メーカーのDBアクセスAPIが使える。
今時CでDBアクセスなんてイラン。

＞2.fork()/exec()が使えて、云々
Windowsはどーすんだよ。

＞3.ソケット関数が使えて、ポーリング処理が出来る。
普通はselect使って、ポーリングなんてせずにブロッキングさせとく。
待ちながら他の処理するなら、普通はスレッド使う。

で、前述の1～5は、まぁ頑張ってるヤツなら1年で終わる。
かかって2年だろ。
基本情報処理に毛が生えた程度じゃねぇか。
実はおじゃば、C言語も微妙なんじゃねぇの？

＞俺は1年でほぼ完璧にC++をマスターした。
マスター(笑)
この間からちょっとぐらい規格に目は通して来たんか？

868 ：仕様書無しさん：2008/01/18(金) 22:31:06

基礎中の基礎を並べてマスターとか言われても困るんだが
ツッコミ所が多すぎて

869 ：仕様書無しさん：2008/01/18(金) 23:11:43

じゃあ俺もマスターかｗ

870 ：仕様書無しさん：2008/01/18(金) 23:14:42

>>867
＞3.ソケット関数が使えて、ポーリング処理が出来る。

それおじゃばの弱い所スルーしる。

>実はおじゃば、C言語も微妙なんじゃねぇの？

それは確定事項なんでスルーしる。

>この間からちょっとぐらい規格に目は通して来たんか？

する位なら前の自爆はないだろう。
おじゃばの知ったかぶり位はスルーしてやってくれ。

871 ：仕様書無しさん：2008/01/18(金) 23:19:12

>>865
おいおい、大丈夫かよ？
Java案件は大量にあるがそれって何に比べての大量だよｗ
激しく減少中だろ

OOを学習する上でJavaは適切？
それもナンセンスOOを学ぶには言語不要
ｴﾝﾄﾞなんて何もかまわんよ？

それに最適かどうかで言うなら
サーバープログラムなんてﾌｫｰﾄﾗﾝかPL/Iで書くべきだよな？最適だからｗｗｗ

なんかおじゃばはまじめにjavaやってる人の足を引っ張ってるな
どの言語でもｳｨｻﾞｰﾄﾞならすごいと思うが
言語に固執するPGが使えないのはどこでも同じか・・・

872 ：仕様書無しさん：2008/01/18(金) 23:26:04

ｽﾚﾁだな
おじゃばはおどうでもいいよ

OOが普及しないのは教えるのに時間がかかるのと
効果が掃除に目に見えないからだろ
それなら即見える言語学習に充てられるのが実情
大学でやっておいてほしいね

873 ：仕様書無しさん：2008/01/18(金) 23:26:55

俺、日本語でおｋ
orz

874 ：仕様書無しさん：2008/01/18(金) 23:29:03

>>871
＞それもナンセンス
＞OOを学ぶには言語不要
＞ｴﾝﾄﾞなんて何もかまわんよ？
個人的には、OO勉強するときゃC++だけは避けたい・・・
まぁ個人的に避けたいだけなんだが

875 ：仕様書無しさん：2008/01/18(金) 23:30:56

>>872
ここはOOスレを騙ったおじゃばと戯れるスレだから

876 ：仕様書無しさん：2008/01/19(土) 13:46:37

>>853
http://slashdot.jp/article.pl?sid=08/01/18/070215

877 ：仕様書無しさん：2008/01/19(土) 14:07:34

>>865
うん、教えてください。

878 ：仕様書無しさん：2008/01/19(土) 15:45:50

>>865 C++マスターさま、
template <typename T> と template <class T> の違いを教えてください。
あと、typename と class の使い分けはどのようにしたらいいか分かり易く教えてください。

879 ：仕様書無しさん：2008/01/19(土) 15:58:29

STLといってもコンテナ使えりゃ十分だとか、stringあれば十分っていう
人も多いんじゃないか。
おじゃば的に他にどんなＳＴＬのクラスや機能使っているのか知りたいわけだが。

880 ：仕様書無しさん：2008/01/19(土) 16:01:28

C++マスター現るｗ

881 ：仕様書無しさん：2008/01/19(土) 16:24:00

auto_ptr も便利だな。というか、むしろshared_ptrの方か。
STLもいいけど、Boostもね。

882 ：仕様書無しさん：2008/01/19(土) 20:03:59

■質問
ここで語っているOOPは何のOO?
Alan Kay流？Bjarne Stroustrup流？William Cook流？
テンプレにもないのでさっぱりわからん

883 ：仕様書無しさん：2008/01/19(土) 20:08:58

OOo

884 ：仕様書無しさん：2008/01/19(土) 20:11:36

流派は特に限定してない

885 ：仕様書無しさん：2008/01/19(土) 21:07:22

>>882
OMTしかありえない

886 ：仕様書無しさん：2008/01/19(土) 21:23:06

>>885
つまり、クラス指向(Bjarne Stroustrup流)の開発手法についてのみを扱うということですか・・・

887 ：仕様書無しさん：2008/01/19(土) 21:33:26

>>886
OMTはんなこと無いけど？

888 ：仕様書無しさん：2008/01/20(日) 15:01:28

結局どこまでいっても言語仕様

889 ：仕様書無しさん：2008/01/20(日) 15:30:27

言語覚えさせる前に教えれば良いんだよ

890 ：仕様書無しさん：2008/01/20(日) 17:44:21

>>887
ごめん、Wikipedia見てはったりかました。
この場合のOMTって何？

891 ：仕様書無しさん：2008/01/20(日) 18:12:23

JavaScriptのクラスを使わないプロトタイプベースのOOってどれになんの？

892 ：仕様書無しさん：2008/01/20(日) 18:14:55

クックだろ条項

893 ：仕様書無しさん：2008/01/20(日) 18:53:00

ニポンノコトバデオケデス

894 ：仕様書無しさん：2008/01/20(日) 19:19:33

クック＝手続きによる抽象化（Procedual Data Abstruction）によるOOP

895 ：仕様書無しさん：2008/01/20(日) 20:57:25

このスレは当然、俺俺OO流だろ

896 ：仕様書無しさん：2008/01/20(日) 21:19:24

>>890
オブジェクト指向方法論OMTだけど
wikipedia見たならネタだとわかってくれ・・・ｗ
UMLの前身だけどまぁほとんどUMLと変わらない

数百万のツールがいくつか出てたけどｴﾝﾄﾞはみんなC++だったな
日本ではあまり日の目を見なかったけど
90年代前半は世界の開発屋とか研究機関ではそれなりに使われてたんだけどね
俺はVC++コード吐くやつ使ってたが日本語入れると死ぬので使いにくかったなｗ
UMLでも何でもOOは言語知らないやうほど理解が早い気がしないでもない

897 ：仕様書無しさん：2008/01/20(日) 23:25:00

つーかOMTって、UMLで用いる表現方法の一つとして
組み込まれたようなもんだと思う。

898 ：仕様書無しさん：2008/01/20(日) 23:52:13

羽生田さん？

899 ：仕様書無しさん：2008/01/20(日) 23:53:53

けーすつーるとか、思いだした

900 ：仕様書無しさん：2008/01/21(月) 01:17:07

Ｃプログラマ必須テキストです！

http://mori.eco.to/

901 ：仕様書無しさん：2008/01/21(月) 18:25:12

OOって、ま、なんかプログラム開発の主義みたいなところあるからな
社会でいうなら資本主義、社会主義みたいな感じだな。

902 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/21(月) 19:54:10

>>867
DBアクセスいらないってどういう事だ？
Windowsは基本のC言語とはちょっと違うから除外した。
スレッドやメモリマップドI/Oなども基本ではないので除外した。
習得期間に関しては、社会人は言語知識以外も覚える事はあると思うので、長めに設定した。
また記載したのは「C言語をマスターしている」と言える一般的なレベルを示した物で、
これがC言語の全てだとか、俺のC言語知識の全てだと言う訳ではない。
また日々進化する俺にとっては、去年の俺はもはや俺ではない。

>>867-869
自分が出来るからと言って、それを標準にしてはいけないな。
未経験で入った3年目のPGなら、これだけ出来ればほめてやってもいいと思うぞ。
で、856はどこまで出来ているんだ？

903 ：仕様書無しさん：2008/01/21(月) 20:12:49

基本だけ理解できたら
「C言語をマスターしている」
ですかｗｗｗｗ
おめでたいですねｗｗｗｗｗｗ

904 ：仕様書無しさん：2008/01/21(月) 20:50:29

3年かかってその程度なら(ﾟ⊿ﾟ)ｲﾗﾈ

905 ：仕様書無しさん：2008/01/21(月) 22:01:18

>>902
こんな感じだ

1.処理（演算、関数呼び出し）、判断（if）、繰り返し（for）が使える。
　　使ったことあるYo
2.関数が使える、作れる。構造体が使える。ポインタが使える。
　　使ったことはあるYo、簡単なのなら作れるよ
3.標準入出力が使える。ファイル操作が使える。
　　標準入出力ってシリアル通信だろ、ファイル操作ってEEPROMへのデータ書き込みだろ
　　自分で関数つくらにゃならんからな
4.リスト構造体、再帰が使える。
　　再帰なんて使ったらスタックあっという間になくなるんだよな。バカか？
5.関数のポインタが使える。
　　関数ポインタはISRで使うよな

1.メーカーのDBアクセスAPIが使える。
　　DBってイラネ、何につかんだ？
2.fork()/exec()が使えて、マルチタスク、デーモンプログラミングが出来る。
　　もはや別世界だな
3.ソケット関数が使えて、ポーリング処理が出来る。
　　ソケット関数、そんなの用意してくれてるって何て幸せなんだ
　　必要ならNICマニュアル読んで自分で作れよ
4.マニュアルを読んでペリフェラル操作PGができる
　　はい

906 ：仕様書無しさん：2008/01/21(月) 22:06:09

>>902
突っ込みどころが山盛りだな。

＞「C言語をマスターしている」と言える一般的なレベルを示した物
いんや。精々入門レベル。
どっかの「C言語入門」に大抵書いてある内容だろ。
おじゃばの言う「マスター」って入門程度でマスターなの？

俺としては「マスター」と言えば、幾つかのコンパイラのクセが分かってて
ある程度はC89/C99や処理系依存の切り分けが出来るレベルで最低ラインだな。
個人的には、そのレベルは5年前には通過してたが、未だに
「C言語をマスターした」などとはおこがましくて言える気がしない。
まだまだ知らんことがたくさんある。

おじゃばの「C++をマスター」「Javaをマスター」も底が知れる。

まぁおまけで。
＞DBアクセスいらないってどういう事だ？
「今時」で言えば、C言語でDBアクセスなんて時代遅れだ、ということ。
それこそJavaでも使うべきで、メインで必要な技術はSQL周りとDB制御の知識だろ。
さらに言えば、C言語でDBアクセスを勉強したところで、
C言語でプログラムを作成するノウハウはあまり得られない。

＞スレッドや（略）基本ではないので除外した。
forkやexecはPOSIXで規程されているものです。
またスレッドもPOSIXで規程されているものです。(pthread)
スレッドは近いインターフェースでWindowsにおいても使用出来ます。
forkやexecはWindowsでは使用出来ません。

俺にはスレッドよりforkやexecが重要な理由が分からない。

907 ：仕様書無しさん：2008/01/21(月) 22:22:12

>>905
そらCしかやらせて貰えないないわｗｗｗ

908 ：仕様書無しさん：2008/01/21(月) 22:29:47

>906
＞俺としては「マスター」と言えば、幾つかのコンパイラのクセが分かってて

禿同
これが朝飯前の話じゃなとか言えてはじめて「マスター」だと思う

自称「マスター」（笑）さんは好きにすればいいと思うけどね

909 ：仕様書無しさん：2008/01/21(月) 22:56:56

とりあえず派遣の面接で言語マスターなんて言う奴が居たら即はじく
ほぼ確実に馬鹿だからな

910 ：仕様書無しさん：2008/01/21(月) 23:36:36

オナニーマスターの俺がきますたよ。

911 ：仕様書無しさん：2008/01/22(火) 00:18:02

>>910
極めたと思ったらそこで進化は止まる。
今夜はもっと冒険してみてはどうかね？

912 ：仕様書無しさん：2008/01/22(火) 00:19:26

マスターベーションは何をどうマスターすればマスターできますか？

913 ：仕様書無しさん：2008/01/22(火) 00:31:43

・亮子で抜ける

914 ：仕様書無しさん：2008/01/22(火) 00:47:23

谷は神

915 ：仕様書無しさん：2008/01/22(火) 03:44:37

できる奴ほど自分がいかに出来ないかを分かってるような気がする
自分が知らない技術が無数にあるのを理解してるというか
でもこれって自信が無いってことじゃないんだよね

916 ：仕様書無しさん：2008/01/22(火) 07:40:12

>>906
Windowsでスレッド使う所で、shellexecuteやcreateprocessで別プロセスで処理しているのは珍しくない。
ＯＳ使用上、そういった手法よりもスレッド使用が推奨されているだけどね。
おじゃばは、Ｊａｖａ得意という話だが同期処理も何故かそっとしておいてほしい人なので
おじゃばの仕様上、そこら辺詳しくいってもスルーされるか、別の話題にそらされるのでマジレスの必要は無い。

917 ：仕様書無しさん：2008/01/22(火) 19:48:13

>>871
なんか言っている事が微妙に変だ。
オマエ技術者じゃなくて、営業か偽コンサルだろ。

>>878
classを使ってください。

>>879、881
string、map、vector
これだけで使う価値は十分ある。
auto_ptrは要らない。多人数で作ると混在したりして最悪。Cでリソースを気にするのは慣れている。
Boostも便利だが、標準じゃないのが問題。STLに組み込まれるのを待つ。

918 ：仕様書無しさん：2008/01/22(火) 20:15:41

C++って結局ぷち強力なC的なコード書かれてオシマイな例がﾃﾗ多ｽ

919 ：仕様書無しさん：2008/01/22(火) 21:27:22

>>917
よう、ドカタ君！

920 ：仕様書無しさん：2008/01/23(水) 02:33:02

オブジェクト指向普及は結構結構なんだが・・・
初心者はなんでも継承したがるから困るぜ

嘘ジェクト指向勘弁してくれ

921 ：仕様書無しさん：2008/01/23(水) 05:42:40

そこが言語は普及してるけどOOは普及してないと判断される理由だろうね
理解できてない奴がたくさんいても普及とは言わないしね

922 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/23(水) 09:27:07

>>903
で、全部出来るのか？
そんなに難しい事ではないが、全部出来る人は結構少ないぞ。
少なくとも905は全部は出来ないようだが。

>>905
組み込みに特化し過ぎだ。
専門知識があるのは結構だが、別世界とかイラネで片付ける前に、習得しておいたらどうだ？

>>906
4のリスト構造体と、5の関数のポインタは、入門書レベルには載ってない。
DB、デーモン、ソケットは、業務で実際にやったことがないと知らない人も多いから、
3つとも経験があれば、入門レベルとは言わない。

>>908
コンパイラの癖とかローカルネタは流動的なので

>>916
Windowsの場合はスレッドが標準だが、UNIX系の場合はまだスレッドに根本的な問題が残っているため、
標準とはしなかった。C言語の場合は一応、UNIX系が標準なので、そちらを書いた訳だ。

923 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/23(水) 10:03:27

>>918
それはC++ではない。
少なくてもC++では、classとコンテナを使う。これだけでもソースコードはCとは別物になる。

>>919
871の偽コンサル君かな？
数行の文章で俺にばれるようならコンサル失格だな。営業かPG見習いに戻れば？

924 ：仕様書無しさん：2008/01/23(水) 10:46:13

>>923
871だけどそんな頭の悪そうな反応しないよ・・・

俺はOMT期のOO研究からPG/SEに移行した土方PG/SEだよ
OMTの前はASMのPGだけどな
C++、VC++、JAVA、その他非OO言語もやってるよ

OOの本質は分析フェーズにあるんだよ
言語なんか何でもいい
むしろ分析、設計フェーズでは言語を考慮しないほうが好ましいよ

詳細設計SEとPGに要求するのはどの言語が指定されても対応できる能力

で、871への回答は無いのか、まぁいいけどさ

ｽﾚ本題に戻ると普及しないのはいきなりOOPで使おうとするからかな
未経験でOOPについての知識無しの人間が納期に追われながらOOPを見につけるのは
それなりに大変だからな。仕事外で勉強する必要があるがOOPについて短期で使えるように
なる明快な書籍っていまだに見かけないな

925 ：仕様書無しさん：2008/01/23(水) 11:14:24

流動的なネタは把握しなくてもマスター（笑）

これは迷言ですね

926 ：仕様書無しさん：2008/01/23(水) 13:15:17

おじゃばはチヤホヤされたいだけ。
２ちゃんねら相手に知ったかこきたいだけ。

927 ：仕様書無しさん：2008/01/23(水) 13:39:19

>>924
javaデザインパターンとか、憂鬱本は・・だめか

928 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/23(水) 20:39:06

>>924
C++とJavaが出来るなら、土方（見習い？）PGではないだろう。
何でそんな自虐的な呼び方をするんだ？

言語は何でもいいと言えるのは、多くの言語が使える人だ。
入社3年目の人には言語は必要だ。Cしか知らない人にクラスとかオブジェクトとか言っても
イメージ出来ないだろう。

871の回答？質問らしき物が見当たらないが。

いや未経験のPGが一人で納期に追われる自体、破綻していると言える。
普通は経験者がいて、その人が作ったソースを理解する所から始めるだろう。
良い師匠に恵まれれば、未経験からでも問題ない。
まあ多くの場合は、経験者が忙しくて新人を放置しがちだが。
つまり、924がOJTで新人教育すればいいんだよ。

929 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/23(水) 20:48:37

>>925
流動的なのでネタなので、マスターしていると言う標準の定義から外したと言う事。
知っていれば良いにこしたことはないが、いつまでも、どこでも通用する物ではない。
ちなみに、俺が各コンパイラの癖を知らないと言う事ではない。
多分、俺ほど各コンパイラの癖に悩まされた人は少ないだろう。

930 ：仕様書無しさん：2008/01/23(水) 21:30:37

>>924
>OOの本質は分析フェーズにあるんだよ
>言語なんか何でもいい
>むしろ分析、設計フェーズでは言語を考慮しないほうが好ましいよ
お前良い事いうな。その通りだ
てか、ドカタはOOPLがOOの全てだからしょうがないよ。
俺のところなんかOO分析、設計してるのにC言語でコーディングでなんてあるからな

>>922
おじゃば、おれはハードを作る製造業だから組み込みに特化になるんだよ
C出来るんだろ、なら、組み込み習得しておいたらどうだ？

931 ：仕様書無しさん：2008/01/23(水) 22:25:12

>>929
>ちなみに、俺が各コンパイラの癖を知らないと言う事ではない。

コンパイラの癖って、オプションスイッチで制御できない動きってことだよね？
後学のためにその各コンパイラの癖とやらを教えて。

932 ：仕様書無しさん：2008/01/23(水) 23:48:33

悩むほどの癖ってどういうものなの？

933 ：(・∀・)：2008/01/24(木) 01:38:10

関数、オブジェクト、クロージャ
http://d.hatena.ne.jp/brazil/20060131/1138692196

↑非常に簡潔で分かりやすい。
クロージャについて参考になった。

934 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/24(木) 09:58:22

>>930
言語を想定していない設計書なんてカスだよ。こういう設計書は見た目だけ良くて中身がないのばかりだ。
開発期間の2/3をかけて、こういう設計書を作り逃げする連中がいるが、あれだけは止めて欲しい。
ただ、オブジェクト指向分析・設計と、オブジェクト指向プログラミングは直接の関連はないから、
C言語で作るのは問題ない。

俺はアセンブラは出来ないが、組み込みは出来る。
通信系のルーターと言えば、組み込みで処理性能が最も重視される分野の一つだ。

>>931、932
一番悩まされたのは、64ビット版Solaris（SUN Studio11）での数値演算ライブラリ使用だ。
一見そんなの使わないと思うかもしれないが、直接の使わなくても、perlにSSHを組み込もうとすると
避けられない。まずコンパイルが通らない。無理に修正してコンパイル通しても、まともに動かない。
いくらオープンソースでも、数値演算とSSHのライブラリのバグを見つけるのは絶望的だ。
ライブラリの説明書にも書いてあるが、基本的にCの数値演算ライブラリにはバグが残っている。
つまり、Solaris64の数値演算ライブラリには気をつけろと言う事だ。つーか、誰か修正して。

935 ：仕様書無しさん：2008/01/24(木) 11:43:51

ツッコミ待ちというかレス乞食というか
わざと仕込んでるとしか思えん今日この頃

936 ：仕様書無しさん：2008/01/24(木) 13:09:57

>>934
ライブラリのバグの疑い（笑）、の話じゃなくて、
早く「各コンパイラの癖」とやらを教えてよ（笑）

937 ：仕様書無しさん：2008/01/24(木) 13:12:03

ていうか、ツッこむぞ、我慢できない。
「perlにSSHを組み込もうとする」って何？
そういう言語を作ろうとした、と？

938 ：仕様書無しさん：2008/01/24(木) 14:12:18

確かに我慢できないな

＞ただ、オブジェクト指向分析・設計と、オブジェクト指向プログラミングは直接の関連はないから、
直接関係ないから言語依存しないんだよ

たぶんやってるのはOOPのみでしかも
OOP風なレベルじゃないかな

939 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/24(木) 19:57:06

>>936
一番苦労したのはこれだ。しかも未解決。有用な情報だろ？
対処出来る問題や、コンパイラの小技なんてどうでもいい事だが、そんなのが知りたいのか？
それともg++からVC++に移植する時の注意点とかかな？

>>937
何？perlのモジュールだよ。
コンパイル済みのperlしか使った事ないのかな？CPANとか知らないのか？

>>938
前にも言ったが、
OODには明確な定義がなく、OOPの利点を設計分野にも生かそうと言う程度の物だ。
OODは通常の業務には向かず、シミュレーション分野などの特定の分野で効果を発揮する。
OOPが出来ないと言う事は、OOPの利点を生かせないと言う事だから、OODが出来る訳無いし、
OODは普通の分野では効果的でない。
で、オブジェクト指向の本質はOODで、OOPを知らなくても問題なくて、OODを知ってると偉いのか？
何か怪しいな、経歴のC++やJavaは「業務で使ってコーディングした」業務経験だろうな？
学校で課題やったとか、本読んだとかは経歴に入らないぞ。

940 ：仕様書無しさん：2008/01/24(木) 20:00:07

> 何？perlのモジュールだよ。
> コンパイル済みのperlしか使った事ないのかな？CPANとか知らないのか？

自分の日本語が不自由なのを棚に上げるのはやめような

お　馬　鹿　さ　ん　☆

941 ：仕様書無しさん：2008/01/24(木) 20:02:41

頼むから、>>939 みたいにレス番号つけてくれ
連鎖あぼーんできない

942 ：仕様書無しさん：2008/01/24(木) 20:03:31

このスレそれ以外のレスないから見なけりゃイイと思うよ

943 ：仕様書無しさん：2008/01/24(木) 20:10:05

おじゃばの文章って結論に至った経緯や根拠をすっとばして結論だけを断定調で書くもんだから、
説得力がなく、どうにも同意しづらいんだよなぁ。そもそも趣旨がよくわからん。
もし、「俺ってすごいだろっ」て自慢したいんだったら、こんな書き方じゃ逆効果だと思うんだが。
人に要領良く説明するスキルは大事なコミュニケーション能力の一つだと思うんだけど、おじゃば
の仕事場じゃあまり必要とされてないのかな？
それともやっぱり、釣り・・・なのか？　釣りにしてはアレだし。

944 ：仕様書無しさん：2008/01/24(木) 20:12:19

>>939
> 何？perlのモジュールだよ。

それは「perlにSSHを組み込もうとする」などではなくて、
せいぜい「perlからssh接続しようとする」というだけのこと。

> 対処出来る問題や、コンパイラの小技なんてどうでもいい事だが

元はコレ。

>>929
> 多分、俺ほど各コンパイラの癖に悩まされた人は少ないだろう。

いやあ。どんな凄いこと語ってくれるのかと思ってさ。
そこまでコンパイラの癖とやらに悩まされたと言うのなら。

> それともg++からVC++に移植する時の注意点とかかな？

その話から各コンパイラの癖とやらの逸話が聞けるかどうか楽しみだね。

945 ：仕様書無しさん：2008/01/24(木) 20:14:13

>>934 アンブラを知らずにコンパイラの癖をご存知だと？

946 ：仕様書無しさん：2008/01/24(木) 21:31:37

>>934
バグのことを癖と呼ぶのかい？
キミの癖に悩まされる人も多そうだね。

947 ：仕様書無しさん：2008/01/24(木) 22:00:14

>>939
おじゃばって、ひょっとしてコーディング専門？

948 ：仕様書無しさん：2008/01/24(木) 22:51:12

>>939
＞それともg++からVC++に移植する時の注意点とかかな？
出来ればVCからgccのC言語が良いな。
gcc/g++のが対応してる範囲が広いし、独自拡張も多いので。
それと俺がメインでC言語使ってるから、純粋に注意点があれば聞きたい。

949 ：仕様書無しさん：2008/01/25(金) 05:58:45

上の方で誰かが書いてあるけど、
OOは分析した結果をそのまま実装へ落とせるのが利点でしょ。
この時点では言語は全く関係ない。
もちろん言語選定を先にやるのが普通だけどね。

逆に、クラス分析、クラス設計もせずにコーディングに突入する（≒OOが普及してない）から、
コテハンのような末端主義があるんだろうね。

言語が変わったら、というようなほとんど発生しないことを言っても意味が無いような気がするし、
そもそも言語のせいにしてる時点で技術者としてはダサくね？

950 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/25(金) 09:45:23

>>940
日本語が不自由？間違ってないだろ？何言ってんの？

>>943
それは943が過去のOOスレを読んでないからだろう。
特に指定しない限りOOはOOPを指す事にしたことや、OODとOOPの違いや、OODの利点や欠点などは、
過去スレで何度も議論されている。まあ過去スレ全部読めとは言わないが、根拠が聞きたければ
範囲を絞って質問してくれ。

>>944
940と同じ人か？
つーか、perlがコンパイル時にモジュールとして、様々な機能を取り込めると言うのを知らなかっただろう？
知っていたら、perlにSSHを組み込むで話は通じる。

おいおい、Solaris64で数値演算ライブラリに問題があるってのはすごい情報だぞ。
Solarisで32ビットから64ビットに移行すると言う話は良くあることで、もし数値演算ライブラリや
SSH組み込みのperlを使っていたら、動かなくなる可能性があると言う事だ。
軽く見積もって痛い目に会う人が多いからな。
32から64に移行した時の問題点を聞かれた場合のネタにもなる。

951 ：仕様書無しさん：2008/01/25(金) 11:27:58

＞様々な機能を取り込めると言うのを知らなかっただろう？

何この断定

＞perlにSSHを組み込むで話は通じる。

通じません
ライブラリとか一言相手が理解しやすくなる単語を付けれんかね

＞根拠が聞きたければ

お前は憶測を根拠にしたつもりになってるだけじゃん
そろそろ病院逝ったら？

952 ：仕様書無しさん：2008/01/25(金) 12:03:21

>>950
じゃあ質問

＞特に指定しない限りOOはOOPを指す事にしたこと

これいんついての具体的な根拠を示してくれ

953 ：仕様書無しさん：2008/01/25(金) 12:26:16

ひとりよがりな奴だって事だな。

954 ：仕様書無しさん：2008/01/25(金) 13:09:47

>>950
> つーか、perlがコンパイル時にモジュールとして、
> 様々な機能を取り込めると言うのを知らなかっただろう？

なんのことやらさっぱり。perlをインストールするときに、
perlをmakeする時に、何かをどうこうするっての？　意味不明。

もし、そのまんまの意味で、そういうのがあるんなら謝る。不勉強は俺のほうだった。

モジュールを使うだけのこと、モジュールを準備するだけのことを、
まさか、「perlに様々な機能を取り込める」と言ってるのではあるまい？

> おいおい…（中略）…ネタにもなる。

なんのことやら。もとはコレ。

>>929
> 多分、俺ほど各コンパイラの癖に悩まされた人は少ないだろう。

いつになったら各コンパイラの癖とやらの逸話が聞けるのだろうか。
アセンブラも知らない人間に対し、さらに、困らせるような現象とは。

955 ：テステス：2008/01/25(金) 16:20:38

人口無能走らせるテスト

956 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/25(金) 19:21:44

>>945
アセンブラは出来ないが、ビット演算やバイトオーダーなどを知らない訳ではないぞ。

>>946
バグでも仕様書に書いてあれば癖になるんだぞ。知っているだろう？

>>947
それは実装技術に詳しいから、俺がそれしか出来ないと思いたいのかな？

>>948
VCってのはCLIでC++って事かな？CLIのCかな？GUIは無理だぞ。

>>949
分析結果をそのまま実装に落とせる？
OODって機能設計以前の話で、クラス設計は詳細設計でOOPの分野だぞ。
いまいち意味が分からない。OODって具体的に何の事を言っている？
設計書で言ってみな。クラス図じゃないよな？

957 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/25(金) 20:09:30

>>952
OOスレ6の>>2
>推奨ルール
>・単にオブジェクト指向と言った場合は、詳細設計分野のオブジェクト指向プログラミング（OOP）と解釈してください。
>・機能設計分野を指す場合はオブジェクト指向設計（OOD）と明記してください。
>・単にデザインパターンと言った場合は、GoFのデザインパターンと解釈してください。

>>954
perlでは標準でたくさんのモジュールが組み込まれている。
CGI::Cookieとか、「::」が付いた関数群だ。
標準で組み込まれているモジュールの他に様々なモジュールを組み込むことが出来る。
組み込むのは、perlのソースセットをダウンロードして、組み込むモジュールのソースもダウンロードして、
展開後、confiureなどで組み込むモジュールを指定して、makeファイルを作成し、コンパイルし直す。
ここで困るのが各モジュールの依存関係だ。SSHなどを組み込もうとすると、SSHで使っている、
他の関連するモジュールも要求される。Apacheをコンパイルした事のある人は分かるだろう。
これが非常に大変なので、perlでは自動的に関連するモジュールをダウンロードしてコンパイルしてくれる
CPANと言うサイトがあるほどだ。まあ、SSHはCPANでもダメだったが。
CPAN行くと大量のモジュールがある事が分かるだろう。

958 ：仕様書無しさん：2008/01/25(金) 20:22:52

>>956
おじゃば先生、バイトオーダーって何？

959 ：946：2008/01/25(金) 20:44:55

>>956
仕様なのかバグなのかハッキリしてほしいんだが、よく「既知のバグ」とか書いてある類のものか？
結局、バグに悩まされたってことかね。

具体例がこれだけじゃ「俺ほど各コンパイラの癖に悩まされた人は少ないだろう。」なんて言えないと思うけど。

960 ：仕様書無しさん：2008/01/25(金) 21:17:57

>>957
その推奨ルールは別にテンプレでもなんでもないな
俺は同意しない

961 ：仕様書無しさん：2008/01/25(金) 23:00:31

>>956
948だが、CLIでもネイティブでも良いけど、C言語でよろしく。

962 ：仕様書無しさん：2008/01/25(金) 23:14:57

長文失礼。

>>956
>>アンブラを知らずにコンパイラの癖をご存知だと？
>アセンブラは出来ないが、ビット演算やバイトオーダーなどを知らない訳ではないぞ。
コンパイラの癖は結構コンパイル時の最適化などで出ることが多いからだろ。

例えば有名な例だと、switch-caseはgccやVCでは、最適化でテーブルジャンプに置き換えられる。
が、テーブルジャンプは速いけどバイナリが大きくなるので、
組込み系専門のコンパイラだと条件分岐のままでコンパイルされることが多い。
メモリのチープな組込みでgccのクロスコンパイル環境使う時は、若干注意が要る。
ま、この例はコンパイラのオプションで変えれたはずなんで、>>931には当たらんね。

コレは機械語レベルの話なので、アセンブラで比較しないと分からない。
のでアセンブラが分からんと言うことは、こういう類の癖は実地で見たこと無いってこった。
ビットがどうこうとかは、まぁ処理系依存ではあるけど、癖の話とはあまり関係ないと思うよ。

>通信系のルーターと言えば、組み込みで処理性能が最も重視される分野の一つだ。
大体組込みでカリッカリの処理速度チューニングするヤツがアセンブラ出来無いわけ無いだろ。
最終的には、速度のためにアセンブラレベルで1ステップを削り、
ハードコスト削減のために実行バイナリ、使用メモリを数バイトずつ削って行くような世界だぞ？
特に通信インフラなんてまさにその世界だ。(俺の専門はMACだけど)
組込みやっててアセンブラ分からんとか言うんなら、組込み的に大した仕事して無いよ。

OO全然関係ないけど、組込み屋としてこの発言は流せん。
組込みのアプリ作ってるだけの人ならそんなに言わんけど。

>>958
おじゃばじゃなくてすまんが、バイトオーダーはエンディアン。
エンディアンはビッグとかリトルとかあって、あとはググレ。

963 ：仕様書無しさん：2008/01/26(土) 03:15:12

CPANで取り込だりコンパイルするのはあくまでモジュールであってPerl自体のコンパイルじゃないんだが。
大体CAPNで取り込んでもuseしないと使えないし。PHPのPEARしかり、RubyのGemsしかり。
極端に言うとCのincludeやJavaのimportと同じ類のもの。
なんでこんなに偉そうに語るのかさっぱりわからない。
おじゃば、人の話を聞かないだろ？　つうかドキュメントも独自解釈しちゃうタイプだろ？
ま本人は気づいてないんだろうが・・・こんなYKもいるんだな。

964 ：仕様書無しさん：2008/01/26(土) 03:18:49

ちっ KYだった orz...

965 ：仕様書無しさん：2008/01/26(土) 03:47:40

ルーターやスイッチのソースをアセンブリ以外で書いたこと無いな
>>692の言うとおりだよ

組み込みじゃCで書いたら遅いのでアセンブリ言語で書き直しなんてよくあること、
OSの乗ってない組み込み系だと最適化の強いコンパイラもめったに無いしな

最近は「組み込み」の範囲も広がりまくりんぐでなんとも言えんが・・・
ただOOは使ってないなｗ
ｽﾚﾁですまん、俺も黙ってられなかったｗｗｗ

966 ：仕様書無しさん：2008/01/26(土) 04:21:50

たかがSSHモジュールをぶっこんで依存関係を整えてリコンパイルする程度のことを
さも大変でしたとか語られても正直ひくわ
どんだけレベル低いんだお前は

そもそも「コンパイラの癖」とは別次元じゃん
もしかしてかなり頭悪くね？
ただ問題の切り分けができてないだけならまあいいけどさ

967 ：仕様書無しさん：2008/01/26(土) 08:47:03

一言居士の奴はどんなところでも疎まれるな
このアホコテはいい例だわ
内容がどうあれ相手の発言に対して何か言ってやらないと気がすまない
周囲は「また妄言吐いてるわ、このバカ」と思い、
中にはわざわざ親切にそれを指摘してるのに、
『このオレサマに意見しやがってええええええ！！！！！』
と脊髄反射

968 ：仕様書無しさん：2008/01/26(土) 15:27:22

おじゃばの反応は尋常じゃない。
話が伝わって無さ過ぎるか、実績が無さ過ぎるか、
それともあえて意図的に我田引水しているのか。
いずれにせよ、相手をした俺が悪かったようだ。

969 ：仕様書無しさん：2008/01/26(土) 16:26:14

実績無いか有ってもコーダレベルだろ

970 ：仕様書無しさん：2008/01/27(日) 03:45:14

中堅プログラマなら誰でも知ってるようなことをえらそーにしゃべるのがなぁ・・・
なんだろ？この板は初心者の集まりとでも思ってるんだろか？お茶葉は。

971 ：仕様書無しさん：2008/01/27(日) 10:43:29

でも、おじゃばにしてはすごい進歩だぞ。
以前は裏づけの無い適当なＷｅｂ記事を
切り貼りしたような内容で実務どうなんはスルーしていた。
今回は経験上の事を言っている。
つまりようやく、正気への第一歩を踏み出したわけだ。

972 ：仕様書無しさん：2008/01/27(日) 11:34:51

経験上というか妄想じゃないか？

もし経験なら相当無駄な現場経験を積み続けている気がする・・・

973 ：仕様書無しさん：2008/01/27(日) 13:25:14

おじゃばの人気に嫉妬心が何故かわいてこない

974 ：仕様書無しさん：2008/01/27(日) 13:56:52

さんざんレスを溜めておいて、思い出したようなそぶりで登場し、
>>958-973のレスの核心はいつもどおりスルーして、
>>956でやってみせたような的外れな一言レスを披露する姿が、
いとも簡単に想像できる。

975 ：仕様書無しさん：2008/01/27(日) 14:13:04

レス溜めるってか、おじゃばは土日来ないよ

976 ：仕様書無しさん：2008/01/27(日) 15:15:19

>>975
おじゃばって家にまともなPC,インターネット接続環境がないんだ
流れに流れて、今、ベトナムでPGしてるらしい

977 ：仕様書無しさん：2008/01/27(日) 15:21:10

>>974
おじゃばが都合の良いレスしか返さないのは仕様だからな。
コンパイラの癖なんてやるのは、最近はゲーム位じゃねーか？

それと数値演算のライブラリー作成とか。

978 ：仕様書無しさん：2008/01/27(日) 16:37:29

どっちかっていうとCコンパイラの癖を気にするのは組込み系じゃない？
PCだとgccとVCが幅利かせててあんまり選択肢ないし。

出だしが「一般的にCをマスター云々」から始まってるから、
多くのCの仕事はマスターってほど使えなくても出来るって話で、
別にCだけじゃなくて他の言語の仕事でもそうでしょ。

979 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/28(月) 19:58:12

>>962
まず俺がやってると言っている分野は、ルーターでもルーティングテーブル見てパケット分けるような
部分だから、962の言うような実行コードを直接解析してチューニングするような所ではない。
それを大した仕事ではないと言うなら、そうなのだろうが、速度が重要な組み込み分野には違いない。
962の認識だと組み込みアプリに入るのかな？

>>963
つーか、解説したのに何で文句を言われなきゃならないんだよ。
includeしてコンパイルするのは、「組み込む」って言うだろ。
963がperlのモジュールを知らなかっただけじゃねーか。勉強になって良かっただろう。
で、KYって何だよ？

>>966
お前のその発言が、経験浅いのが丸出しなんだよ。
やったことないんだろ？やったことある人には出ない発言だよ。
やったことないのに、簡単とか言うなよ。

980 ：仕様書無しさん：2008/01/28(月) 20:18:09

こういう風に、おじゃばが激昂するのは大抵自分の不利になってきたときです。
あと、100スレもすれば馬脚をあらわしますので、仕様上のご注意をお読みの上
正しくお使いください。

981 ：仕様書無しさん：2008/01/28(月) 20:55:48

相変わらずトンチンカンというか、決め付け丸出しというか。
発言の根拠を示したり、正面からレスを返すことすらできない。

そして予想通り、
「アンブラを知らずにコンパイラの癖をご存知だと？」をスルーし、
「そもそも「コンパイラの癖」とは別次元じゃん」をスルーしたようです。

982 ：仕様書無しさん：2008/01/28(月) 21:26:23

java屋にコンパイラの話をさせてもしょうがないぞ
ここはVMの癖を語ってもらったほうがいいんじゃね

983 ：仕様書無しさん：2008/01/28(月) 22:16:49

以前「人を動かす」て本を読んだことがある。
書いてあることにおじゃばんの反応がみごとに当てはまる。
「人は自分への批判反論に対して激しく反発する」みたいなこと。他のコーチングの本にも同じ様なことが書いてある。
内心はともかく、こう感情を剥き出してくると少々極端な気もする。議論するつもりならなおさら。

仕事でこんな人と付き合うことになったら、うまくなだめながら付き合わないとね。

984 ：仕様書無しさん：2008/01/28(月) 23:04:04

新卒だけどJAVAメインの会社で働く事になった
おじゃばみたいのがいるかと思うと今から憂鬱だ

985 ：仕様書無しさん：2008/01/28(月) 23:22:38

>>979
そのH/WやS/Wの構成が分からんから、アプリなのかどうかは判断付かないが、
「組込みの仕事としては(ここ重要。今度はスルーするな)」大した仕事じゃないな。
んで、アセンブラ使わないのは分野っつーかシステム構成とレイヤの問題だろ。
俺が似たようなことやった時は、スイッチングはH/W制御用演算装置とアセンブラでやったし。

>>981
おじゃばの弁護するわけじゃないが。

>>アンブラを知らずにコンパイラの癖をご存知だと？
>アセンブラは出来ないが、ビット演算やバイトオーダーなどを知らない訳ではないぞ。
トンチンカンだが、とりあえずスルーはしてないっぽい？トンチンカンだが。

それとアセンブラ関係ないコンパイラの癖もあるんで、幾らか知ってることもあるだろ。
例えば、一部のCコンパイラでは、マクロ関数の引数を勝手に「()」付けて展開することがある。
#define func(x) if(!x){puts("WARNING!\n");}
func(a==0)　→　if(!(a==0)){puts("WARNING!\n");} に展開される。
勝手なことすんな、と言いたい。まぁあんま問題にはならないけどね。

あと個人的にはコンパイラのバグはコンパイラの癖と言っても良いと思う。

「SUN Studio11の数値演算ライブラリ」ってのがmath.h周りの話なら、
math.hって一応標準だし、コンパイラのバグで、「癖」と言ってもいいかも。
「SUN Studio11が提供してるC言語標準で無い数値演算ライブラリ」なら
単なるライブラリのバグで、コンパイラは全然関係ない。

なんか長文になるな・・・。すんまへん。

986 ：仕様書無しさん：2008/01/28(月) 23:30:03

>>985
そういった、理性的な発言はこのスレ的にありがたいけど、
おじゃばはそういった理性的な発言の尻馬にのるから、
そのうち不快な思いをするぜ。

おじゃばの論理組み立てがなってなくて、
こっちがおじゃばの発言を纏めて補足もしたら、
そうそうといって、いい顔しやがった事があった。

987 ：仕様書無しさん：2008/01/28(月) 23:41:17

s/( ：おじゃばさま ◆GxjxF3yEw6.*?)(^\d{1,3})/あぼーん\n\n$2/gs;

988 ：仕様書無しさん：2008/01/29(火) 00:07:55

> お前のその発言が、経験浅いのが丸出しなんだよ。
> やったことないんだろ？やったことある人には出ない発言だよ。
> やったことないのに、簡単とか言うなよ。

やってもないのに批判する馬鹿がどこに居るんだよ
お前のその発言が馬鹿丸出しなんだよ

もし本当にあの程度が難しいと思うなら
お前冗談抜きで相当頭悪いんだな
ただセンスがない系かもしれんけど
どっちにしろこの業界やめたほうがよくね

989 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/29(火) 09:27:19

>>967,968
独り言か？

>>969-972
前にも言ったが、一般的にマスターしていると言うレベルを提示しただけで、Cがそれで全てだとか、
俺の知識がそれだけだと言っている訳ではない。
俺の言う「マスターしている」はCで一般業務に耐え得るレベルで、入社3～5年目ぐらいの標準的な
レベルを言ったのだから、「中堅プログラマーなら知っている」と言われても、その通りとしか言えない。
元々、入社3年目の人が違う言語を勉強する前に、Cをどこまでマスターしているかの判定だっただろう。
処理系の3つは3年目でマスターしていれば優秀だし、5年目でマスターしていれば普通だろう。
全部マスターしていれば、別の言語もやってみろと言う事だし、マスターしてなければ先にそっちを
やれって事だ。

>>980
それは違うな。
「やった事がある」と言わせるための煽りだよ。

990 ：仕様書無しさん：2008/01/29(火) 11:08:08

マスター大安売りだな
世界中のギークな連中の失笑を買ってまで拘るべき外来語なのか

991 ：仕様書無しさん：2008/01/29(火) 11:40:20

そのレベルでマスターとか言い出したら摘み出すだろ
常考

992 ：仕様書無しさん：2008/01/29(火) 12:48:05

そうですね♥ご主人様♪

993 ：仕様書無しさん：2008/01/29(火) 17:19:38

>>939
ねぇ、おじちゃん、関数のポインタってどういうふうに使うの？

994 ：仕様書無しさん：2008/01/29(火) 19:29:16

次スレのタイトルは
OOスレ8 なぜマ板ではバカ放置が普及しないのか
だな。
参照する奴が絶えないから、という答えはありかも。

995 ：仕様書無しさん：2008/01/29(火) 20:08:15

何言ってんだオメー
新参は黙ってろ

ネタには全力で食いつき
アホはおもちゃにして遊ぶ
それがマ板

996 ：仕様書無しさん：2008/01/29(火) 20:48:50

まぁ暇だしな
コーディングは配下の土方に任せておけばいいし

997 ：仕様書無しさん：2008/01/29(火) 21:07:12

俺は、料理をしない評論家より、凄腕のコックの方を尊敬するな。

998 ：仕様書無しさん：2008/01/29(火) 21:18:41

マスターなんて言うから悪いンだろ。
○○ができれば業務に耐えうる→○○出来なきゃ業務に耐えない
最低限のレベルってことじゃないか。
マスターて言うと、「極めた」とか、高度に使いこなしている。と取れるからな。

999 ：仕様書無しさん：2008/01/29(火) 21:33:45

ジェダイの騎士は、フォースを使える者が、パダワン、ナイトを経て、
ジェダイ評議会での決定により、ようやくマスターの称号を得られるのだ。
マスターとは、それぐらい崇高で威厳ある言葉なのだ。軽々しく使ってはならん。
そんなマスターにお願いごとができるのは、日本では清水健太郎ぐらいのものだ。

1000 ：仕様書無しさん：2008/01/29(火) 21:36:19

おじゃばはお馬鹿マスター

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。