消えてなくなれよ >オブジェクト指向

1 ：デフォルトの名無しさん：2007/12/28(金) 15:13:40

closure で十分じゃんよ

2 ：デフォルトの名無しさん：2007/12/28(金) 15:17:54

>>1
クローじゃーってなあに？

3 ：デフォルトの名無しさん：2007/12/28(金) 17:43:05

オブジェクト指向⊃クロージャ

4 ：デフォルトの名無しさん：2007/12/28(金) 18:42:39

TMで十分、コンビネータで十分と言ってるのと変わらん。

なんでもできるのはいいことじゃない。
人はときには縛ってあげないと間違った道を選んでしまうんじゃよ。

5 ：デフォルトの名無しさん：2007/12/28(金) 18:50:39

てｓｔ

6 ：デフォルトの名無しさん：2007/12/30(日) 04:03:01

そんな貴方にアスペルガー指向プログラミング。

7 ：デフォルトの名無しさん：2007/12/30(日) 15:50:00

クロージャでクラスを模す事は出来るけど、一々それをコーディング
するのは面倒だし、出来たコードはコンパイラの支援も受けられず
非効率的。事前にクラスシステムをクロージャで用意しておくので
あれば、それはオブジェクト指向言語と変わらん。

8 ：デフォルトの名無しさん：2008/01/04(金) 02:08:24

OOスレ7 なぜオブジェクト指向は普及しないのか
http://pc11.2ch.net/test/read.cgi/prog/1192703383/

9 ：デフォルトの名無しさん：2008/01/04(金) 20:02:42

>>1はオブジェクト指向がコーディングスタイルの一種だと
勘違いしている。

10 ：デフォルトの名無しさん：2008/01/04(金) 20:50:42

>>1 ではないが >>9
> オブジェクト指向がコーディングスタイルの一種
ではない理由を説明してくれ。

11 ：デフォルトの名無しさん：2008/01/04(金) 23:17:25

>>9ではないが、
コーディングスタイルは言語仕様が確定された上で、どのように表現するかの問題で、
オブジェクト指向は言語仕様の中にあるものだから、明確にコーディングスタイルとは異なる。

12 ：デフォルトの名無しさん：2008/01/05(土) 00:27:51

単なるコーディングスタイルならOOPLなんて言葉存在しとらんだろしな

場面を絞れば制約のための工夫／広義のコーディングスタイルでも十分な設計できる事もあるからな
OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める馬鹿もいるし。いるっていうか、お

13 ：デフォルトの名無しさん：2008/01/05(土) 01:18:17

>>9 じゃないけど
Lisp系の言語にとってはOOなんて只のコーディングスタイル
の問題なんだが…

14 ：デフォルトの名無しさん：2008/01/05(土) 01:19:29

アンカー間違えた >>10

15 ：デフォルトの名無しさん：2008/01/05(土) 04:59:22

まあ C++ もコーディングスタイルの問題に済ませることもできるな。

でも、オブジェクト指向を仮定するといろいろな手法が導けるので、
コーディングというレベルでなくて、システム設計とかのレベルで考えるとメリット、デメリットがあるよな。
要するにチーム全員がオブジェクト指向を理解できるという仮定でシステム設計をするメリット。

ただ逆に、オブジェクト指向を理解できないプログラマというのが存在することを
考慮できるか否かが問題だとおもう。
構造型プログラミングの理解できないプログラマは排除できるのだが、オブジェクト指向を理解できない
プログラマを排除できないのが今の世の中。

16 ：デフォルトの名無しさん：2008/01/05(土) 11:12:00

>>13
それこそまさに>>12が
> OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める
の典型例と思われ。

17 ：デフォルトの名無しさん：2008/01/19(土) 14:02:19

そう言えばさ、オブジェクト指向って現場で役に立ってる？
オレオレオブジェクトまかり通ってて実質的には足枷になってる
ケースの方多い気がするんだけど…

つか、思ったことない？
「アフォはクラス設計するんじゃねぇ！！！」

18 ：デフォルトの名無しさん：2008/01/19(土) 14:05:48

>>17
> 「アフォはクラス設計するんじゃねぇ！！！」

このセリフには、本来オブジェクト指向は現場で役に立つという前提があるように思えるのだが。

19 ：デフォルトの名無しさん：2008/01/19(土) 14:07:03

JavaだろうがC#だろうが全然オブジェクト指向じゃないコードは書けるよ
ていうか書く人がいる

20 ：デフォルトの名無しさん：2008/01/19(土) 14:20:19

>>18
「そのように考えていたときが俺にもありました」って、過去形な

21 ：デフォルトの名無しさん：2008/01/19(土) 14:24:18

>>20
ならば、「アフォはクラス設計するんじゃねえ！！！」のかわりに
「クラス設計するんじゃねえ！！！」と言うべきじゃないかな。

22 ：デフォルトの名無しさん：2008/01/19(土) 18:20:46

効率の良いクラス設計の方法論って無いの？

23 ：デフォルトの名無しさん：2008/01/19(土) 18:24:36

>>19
いるねー。ほとんどのメソッドがstaticな人とか。

24 ：デフォルトの名無しさん：2008/01/19(土) 18:31:12

万能クラスを作ってしまうってのが一番多いな

25 ：デフォルトの名無しさん：2008/01/19(土) 18:32:47

>>24
本当に万能なクラスなら、ぜひソース公開してほすいｗ

26 ：デフォルトの名無しさん：2008/01/19(土) 18:48:03

かなり万能ですよ
ただし必要に応じて中にコードを追加するので成長し続けます

27 ：デフォルトの名無しさん：2008/01/19(土) 19:31:34

ときどき癌化するんだよな

28 ：デフォルトの名無しさん：2008/01/21(月) 01:20:57

Ｃプログラマ必須テキストです！

http://mori.eco.to/

29 ：デフォルトの名無しさん：2008/01/21(月) 02:44:58

>>25
神様クラスのことだろ
クラスは全部これを継承しろっていう

30 ：デフォルトの名無しさん：2008/01/22(火) 23:54:26

しかし、その神々しさに畏怖して誰も使わない罠。

31 ：デフォルトの名無しさん：2008/01/23(水) 02:46:53

万能クラスと万能ネギはどっちがより万能ですか？

32 ：デフォルトの名無しさん：2008/01/24(木) 18:06:17

概念的には万能クラスの方が万能だが、
それで飯をジェネレートできねーなら俺は万能ネギとりますねぇ。
あ、でも万能クラス一個あれば仕事全部やってくれんのかな。

揺らぐなぁ。

33 ：デフォルトの名無しさん：2008/01/28(月) 14:17:49

××があればほとんど全ての問題は解決する。

というキャッチフレーズに乗せられた人の如何に多いことか。
さあ、君も××に当てはめる言葉を考えて遊んでみよう！

34 ：デフォルトの名無しさん：2008/01/28(月) 14:35:06

お金があればほとんど全ての問題は解決する。

35 ：デフォルトの名無しさん：2008/01/30(水) 00:27:48

時間があればほとんど全ての問題は解決する。

36 ：デフォルトの名無しさん：2008/01/30(水) 00:31:18

真実の愛があればほとんど全ての問題は解決する。

37 ：デフォルトの名無しさん：2008/02/03(日) 06:28:58

愛＞金
飯＞愛
金＞飯

38 ：デフォルトの名無しさん：2008/02/03(日) 13:26:31

推移律が定義できないので順序構造が成り立たない件

39 ：デフォルトの名無しさん：2008/02/04(月) 01:23:23

・飯は食べないと何もできなくなるし病気とか治らない
　ただし大金を掛ける必要はない。
・お金があればほとんど全ての問題は解決する。
・時間があればほとんど全ての問題は解決する。
　だが効率が悪ければ十分な金は得られない。
　効率良く真実の愛を得る方法もない。
・真実の愛があればほとんど全ての問題は解決する。
・お金があれば、ほとんどの真実の愛についての問題は解決する。
　ただし、金で買えない愛もある。
　また、効率を重視し過ぎると真実の愛と立ち向かえない。

以上の過程から重み付けを線形に評価すると、
金≦真実の愛（妥協含む）＞時間＞飯（ただし必須であることには変わりがない）

試みとしてはこんな程度だろうか。当然まだtransitibityを網羅できてる訳じゃなく、要素考察の礎に過ぎないが。

40 ：デフォルトの名無しさん：2008/02/04(月) 18:54:55

>>39
グラフ構造にしたほうがよくないか？

41 ：デフォルトの名無しさん：2008/03/07(金) 21:23:50

>>34, 35
無限大の金と時間があれば, 物理法則に抵触しない限り
何だって解決出来ると思うんだよもん
# 心の問題は別かもしれんが...

42 ：デフォルトの名無しさん：2008/03/07(金) 21:50:54

無限の性能を持った仮想のマシンを使って
無限の時間をかけて計算するってことなら
昔の数学者がやってたが
どうせなら無限の金より無限の才能が欲しい気がしなくも無い

43 ：デフォルトの名無しさん：2008/03/07(金) 21:54:46

「消えてなくなれ」というフレーズがジャンプの漫画みたいで恥ずかしい

44 ：デフォルトの名無しさん：2008/03/08(土) 00:27:21

　　　　　　ﾊ,,ﾊ
　　　　　（ﾟωﾟ )　　男割します
　　　　／　　　＼
　 ((⊂ 　）　ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ｀J

45 ：デフォルトの名無しさん：2008/03/10(月) 23:12:45

ごめん聞いていい？
javascriptってオブジェクト指向？

46 ：デフォルトの名無しさん：2008/03/10(月) 23:33:56

>>45
クラスは無いけどオブジェクト指向だよ。

47 ：番組の途中ですが名無しです：2008/03/11(火) 02:11:52

なんでこんな糞スレがいつまでも残ってんだよ。

オブジェクト指向そのものについては、ここ読んどけ。
http://d.hatena.ne.jp/sumim/20040525/p1

48 ：デフォルトの名無しさん：2008/03/11(火) 08:04:06

var HogeClass={
fuga:function(){
},
hage:function(){
}
};
constructor/destructorが使えるのかどうかは不明
ああこれはstaticmethodだけか

49 ：デフォルトの名無しさん：2008/03/26(水) 02:52:02

var hoge = {};
と
var hoge = new Object();
が等価
function が関数オブジェクトで引数を取れ、クラス代わりに使える
var hogeclass = function(a, b) {
this.a = a;
this.b = b;
};
var c = "hoge", d;
var hogeobj = new hogeclass(c, d);
//alert(hogeobj.a); //=> "hoge"

>>48
> ああこれはstaticmethodだけか

ちと違うような。

50 ：デフォルトの名無しさん：2008/04/19(土) 23:08:10

OO = クラスが無限増殖するだけの糞手法

51 ：デフォルトの名無しさん：2008/04/22(火) 16:16:29

フロー制御やコーディング手法というのは、構造化プログラミングの話だろ
オブジェクト指向は、ライブラリ構築手法だと思うんだが

それはともかく>>4が、マゾであることは、火を見るより明らかなんだ
なんせ、縛って欲しい人なんだぜ

52 ：デフォルトの名無しさん：2008/04/28(月) 07:24:57

>>48はクラスとグローバルオブジェクトの違いがわかっていないアフォ

53 ：デフォルトの名無しさん：2008/06/24(火) 02:04:15

オブジェクト指向的に美しいプログラムとか、
オブジェクト指向的に正しい記法とか、

それで生産効率が下がったら目も当てられないよなぁ

54 ：デフォルトの名無しさん：2008/06/24(火) 05:47:52

>>53
下がった例なんてあるの？

55 ：デフォルトの名無しさん：2008/06/24(火) 18:52:13

OCPとかLSPとかを忠実に守ると、
爆発的にクラスは増えるし、ウザいことこの上ないな
適度にグローバル変数とか使ったほうが、生産効率上がることが多い

56 ：デフォルトの名無しさん：2008/06/26(木) 11:03:14

釣るなよ

57 ：デフォルトの名無しさん：2008/07/11(金) 10:43:53

オブジェクト指向って、プログラマの半分は理解してないでしょ？

58 ：デフォルトの名無しさん：2008/07/12(土) 14:12:44

理解していない奴？
95～98%くらいだと思うけど。

59 ：デフォルトの名無しさん：2008/07/12(土) 18:12:04

なんだその程度か

60 ：デフォルトの名無しさん：2008/07/19(土) 01:03:57

理解できてる人間なんて世界中に100人も居るだろうか?
って最近思うよ。

俺はもちろん理解できていないが、他人が理解できているかどうかは分かるつもり。
OOという言葉と概念を知って20年近く経つけど、
「この人はＯＯが理解できている」なんて思わせる人間には一度もあったことないよ。

61 ：デフォルトの名無しさん：2008/07/19(土) 08:47:47

>>60
まずは、近所のコンビニまで出かけることに挑戦しよう。
そしたら次は駅前まで買い物だ。
こうやって順に慣らしていくことで君もヒキコモリを卒業できる。

62 ：デフォルトの名無しさん：2008/07/19(土) 09:52:21

>>60
少し違う。ＯＯ自体には宗派(笑)が少なくとも三つある。教祖が三人以上いるつうことだ．
そしてそれぞれの宗派の理解度は層を成して存在する。
当然ながら、それぞれの最上位の理解者は教祖様（笑）だよ。

宗派は何ですか？

63 ：デフォルトの名無しさん：2008/07/19(土) 23:24:01

＞宗派は何ですか？
えーと、スンニ派（多数派）はどれなんでしょうか？

64 ：デフォルトの名無しさん：2008/07/20(日) 23:23:52

いったいどの宗派を信じればメシアが救ってくれるのだろう。
エッ、自力本願だから自分で努力するしかないの？そんなあ・・・(w

65 ：デフォルトの名無しさん：2008/07/21(月) 13:56:57

禅宗系だと、OO知れば知るほど何も判らなくなっていくんだろうな
色即是空
空即是色
一生悩み続ける運命

66 ：デフォルトの名無しさん：2008/07/22(火) 08:09:49

>>65
で、頓悟するわけですよ。「OOとは結局、糞コンサルと糞教祖の金脈でしかないのだ」とね。

67 ：デフォルトの名無しさん：2008/07/22(火) 11:22:32

>>62
三系統の“オブジェクト指向”を「北斗の拳」に例えてみる
ttp://d.hatena.ne.jp/sumim/20080416/p1

68 ：デフォルトの名無しさん：2008/07/23(水) 00:02:31

迷えるプログラマ達よ。あなたはOOを信じますか？

69 ：デフォルトの名無しさん：2008/07/23(水) 04:21:53

OOは宗教か技術かと問われれば、俺は宗教だと答えるね。

70 ：デフォルトの名無しさん：2008/07/23(水) 04:42:51

OOは企業の陰謀だよ
企業の陰謀にちょうどよかったから利用されたのさ

71 ：デフォルトの名無しさん：2008/07/24(木) 10:34:43

オブジェクト指向は必要ないと？　　　　んなー

72 ：デフォルトの名無しさん：2008/07/24(木) 12:39:49

必要なところだけ使えばいい。

73 ：デフォルトの名無しさん：2008/07/24(木) 18:47:21

OOはどの経典を読んでもわかるようでわからない。
いくら説明されても空の意味がわからないのと同じようなものかもしれない。
しかし、空の意味がわからないと悟れないのでわかるしかない。
同じようにOOがわからないとプログラマは救われないのである。
修行するぞ、修行するぞ・・・・・・・・

74 ：デフォルトの名無しさん：2008/07/24(木) 22:47:01

経典やら宗派によって概念が違うみたいだからね。

75 ：デフォルトの名無しさん：2008/07/27(日) 14:37:41

言葉では説明できない。だから本読んだだけでは駄目。
OOは教えることはなく、各人がOOを学び得ることを目的とする。
・・・やはり宗教だね。

76 ：デフォルトの名無しさん：2008/07/27(日) 18:04:02

>>75
まさに自分で修行して悟らなければいけない小乗仏教の世界だなあ？
すると創始者のアラン・ケイは釈迦か？(w
じゃあ、また写経（サンプルプログラムを打ち込む）でも始めるか？
心が落ち着くなあ・・・・落ちつかねえよ(w

77 ：デフォルトの名無しさん：2008/07/28(月) 08:49:06

なんかまたSmallTalkの本が出てたけど、変わりばえしないね。
あいかわらず宗教臭いし著者が出してるライブラリの宣伝っぽい。
立ち読みだけでパスした。

78 ：デフォルトの名無しさん：2008/07/28(月) 14:36:02

ぶっちゃけ、そんなに難しくはない

79 ：デフォルトの名無しさん：2008/07/28(月) 14:58:49

良かったね。で、それを周りの人間全員に教えることは出来るのかい？。

80 ：デフォルトの名無しさん：2008/07/30(水) 09:30:14

たこ焼きの鉄板を使って、
材料を入れて
たこ焼きを作る

こんな感じ

つまり、鉄板をクラスで作り引数材料を加工してたこ焼きインスタンスの出来上がりだよね。

こんな感じの説明する人いるけど、混乱するでしょ。　はあ？　って。

81 ：デフォルトの名無しさん：2008/07/30(水) 11:28:20

>>80
その説明でよくわかるぞ。

たこ焼きの作り方が・・・(w

82 ：デフォルトの名無しさん：2008/07/31(木) 02:05:41

タイ焼きで説明した例は目にしたことあるよ

重要なのはオブジェクト指向の設計であって
オブジェクト指向のコーディングじゃないよ

オブジェクト指向のコーディングをオブジェクト指向の設計だと
勘違いしてる人をたまに見かけるけど最悪だよね

83 ：デフォルトの名無しさん：2008/07/31(木) 05:54:02

形にばかりこだわって本質に目を向けないものは真の悟りを得られないと　φ(・＿・”）ﾒﾓﾒﾓ
えーと・・・・・どこの宗派かな？

84 ：デフォルトの名無しさん：2008/07/31(木) 09:16:15

オブジェクト指向をキッチリ理解していないと、
オブジェクト指向のコーディングなんてできん。

ってことですよ

85 ：デフォルトの名無しさん：2008/07/31(木) 14:30:57

オブジェクト指向って、オブジェクト指向の設計を肉付けしながら、
コーディングしてるから、コーディングも設計も同時進行なのであった。

86 ：デフォルトの名無しさん：2008/07/31(木) 18:18:15

オブジェクト指向言語の文法をしっかり記憶してオブジェクト指向を理解した気になる。
長いこと記憶重視の受験勉強していればそういうことになるよな。
だれか「試験にでるオブジェクト指向」とか「ここだけ押さえれば大丈夫。オブジェクト指向の傾向と対策」とかいう
本をだしてやってくれ（笑）

87 ：デフォルトの名無しさん：2008/07/31(木) 19:55:54

>>85
それは・・・オブジェクト指向の目標の一つであったかと思うが。
本当にそれが実現しているのかい？
「自分だけ」という状況でも立派なもんだが。

88 ：デフォルトの名無しさん：2008/08/01(金) 01:13:26

利用する側から作るので、クラスやプロパティやメソッドが先に列挙され、インプリメントが後から埋まるよ
前者を設計、後者をコーディングと呼んでるよ

名前も重要だよね
IOPtrって何を担当するクラス？想像しやすいネーミングにしようよ

89 ：デフォルトの名無しさん：2008/08/01(金) 20:40:31

>>77
黒くて厚い本？スモールトークの真髄というわりにはライブラリを使った話ばかり。
文章もなんだか無理に分量を稼いでるかんじだし。同じぐらいの厚さのスクイークの
白い本のほうがいいと思った。

90 ：デフォルトの名無しさん：2008/08/09(土) 17:10:58

消えて無くなれ？
魔法か何かで本当にオブジェクト指向消すことができたらどうなるのかなあ？
オブジェクト指向が無くなればオブジェクト指向で開発したプログラムは存在しなくなるから
世の大半のプログラムは無くなるなあ？
そりゃあえらいこっちゃ・・・・・・・

91 ：デフォルトの名無しさん：2008/08/09(土) 18:08:20

>>90
> 世の大半のプログラムは無くなるなあ？

組み込み舐めんなVC++厨。

92 ：デフォルトの名無しさん：2008/08/13(水) 00:22:36

組み込みって、スイッチのオンオフに毛が生えた程度でしょ？

93 ：デフォルトの名無しさん：2008/08/14(木) 20:51:59

毛がボーボーで元のスイッチが見えません

94 ：デフォルトの名無しさん：2008/08/15(金) 02:43:09

エーンベデッド
エンベーデッド
エンーベデッドおおー

95 ：デフォルトの名無しさん：2008/08/28(木) 02:19:08

スイッチのオンオフに毛が生えていないノイマン型コンピューターは全滅した！

「ぐふふ、これで勝ったと思うなよ。ぐふっ」
いんてる　の　しにがお　は　やすらか　だった……。

96 ：デフォルトの名無しさん：2008/08/29(金) 09:12:55

>>95
組み込みってノイマン型なん？

97 ：デフォルトの名無しさん：2008/08/29(金) 09:16:32

あ、ノイマン型ではないってことか。　もめん。

98 ：デフォルトの名無しさん：2008/08/29(金) 22:53:22

消えてなくなれよ>オブジェクト指向わからない奴

99 ：デフォルトの名無しさん：2008/11/09(日) 18:24:28

>>98
激しく同意！　（←セリフ古いなｗ）

オブジェクト指向のメリットとして重要なものに、SE/PGテロの撲滅がある。
意図的に難読化、スパゲッティ化したプログラムで利権維持と工数水増しを図ろうとする
部落団体に支援されている派遣請負SE/PGの追放。
これは、クライアント企業の担当者や経営幹部、更には派遣元会社にも設計ドキュメントや
ソースコードが理解困難になる仕組みを悪用して寄生し、正規社員も苦虫を噛むテロ行為。

オブジェクト指向による高度な抽象化を行えば、上流から下流へは粒度だけの違いになり、
役員や幹部にも判りやすい記述になるので、従来のSE/PGのテロ行為が無力になるという
とても大きなメリットがある。

100 ：デフォルトの名無しさん：2008/11/09(日) 19:55:27

>>99
おまいマじゃないな。

101 ：デフォルトの名無しさん：2008/11/09(日) 20:56:24

まあ俺みたいな天才じゃないとオブジェクト指向を使うのは難しい

102 ：デフォルトの名無しさん：2008/11/09(日) 21:05:10

>>99
お前マじゃないし、しかもかなりできの悪い人間と見た。
底辺より悪いんじゃないか？

103 ：デフォルトの名無しさん：2008/11/09(日) 21:06:34

先生、ネタにそういう反応は無粋です

104 ：デフォルトの名無しさん：2008/11/09(日) 21:08:55

>>99
作為的にソースを理解困難にする事とオブジェクト指向とは何の関係もないよ
ソースにコメントを記述するだけで実際動作しているコードが読みにくくなるだろ

105 ：デフォルトの名無しさん：2008/11/09(日) 21:22:48

>>104
はははｗ、確かに偽コメントは「マ」にとって最高のオナニーだし威力あるだろうなｗ
ソースを保存し終えた途端に不敵な笑みを浮かべ、「グフフ・・・」と笑ってる「マ」の
姿は不気味で異様ｗ　他人事として見るなら面白い。

106 ：デフォルトの名無しさん：2008/11/09(日) 21:36:47

OOで実装するのはいいと思うが、
OOで設計するのはどうかと思う。
レベルが低い奴にやらせると、抽象化が不十分なモデルを組んできて、
しかも仕事の流れ上、それに逆らえなくなってしまう…。

107 ：デフォルトの名無しさん：2008/11/09(日) 22:41:22

なんか手順が違うな
要件が不足してるから不十分なモノができるんだろ？

108 ：デフォルトの名無しさん：2008/11/10(月) 07:43:14

>>106
そうそう。「実現不可能な実装のやりかけ」を設計と称して押しつけてくるw

109 ：デフォルトの名無しさん：2008/11/10(月) 09:08:03

オブジェクト指向は悪の枢軸

110 ：デフォルトの名無しさん：2008/11/10(月) 09:14:06

マルチパラダイム言語で使用可能な道具の一つ
って程度でいいよ
無くなれとまでは言わんけどOOが全てっていうのはちょっと

111 ：デフォルトの名無しさん：2008/11/10(月) 22:11:29

わざわざクラスにしなくていいものまで
クラスにしなければいけないキモさが嫌だ
かといってオブジェクト指向コードとそうでないコードが
混在してるのも読みづらくて仕方ない
つまりオブジェクト指向そのものが生理的に受け付けない

112 ：デフォルトの名無しさん：2008/11/10(月) 22:54:15

>>111
おまえオブジェクト指向理解してないだろ

113 ：デフォルトの名無しさん：2008/11/11(火) 16:44:38

C++で構造体の配列をつかわず、
クラスのvectorつかうって普通？

114 ：デフォルトの名無しさん：2008/11/11(火) 17:07:03

C++では配列は要素数固定なので
それで困る場合は vector 使うのが当然だろう。

115 ：デフォルトの名無しさん：2008/11/11(火) 21:50:06

Javaみたいな"融通の効かない"OOPLだと
デリゲートがなくてちょっとした亜種でも派生する必要がある
無駄なクラス増殖はいずれDRY原則の破綻を招く

プログラミングの入り口がJavaの人って、どんな言語でも無駄にクラス作りまくる傾向があってウザい
JavaのOO思想をOOのあるべき姿として布教されてるうちは「OOは生産的」論には賛同しねえ

よく見るJavaOO脳のミス
・安易に継承しまくってクラス増殖→仕様変更に弱くなる(熟練でもよくある)
・特殊な状況でも無理矢理デザパタを馬鹿正直にあてはめる(慣れてきた人によくある)

116 ：デフォルトの名無しさん：2008/11/11(火) 23:47:05

>>115
過剰継承もオープンプロテクトの一技法なんですね、わかります。

117 ：デフォルトの名無しさん：2008/11/12(水) 04:56:25

オブジェクト指向って元々は、基本的に同じ性質を持つ複数の実体を個別に扱う
ことを容易にするという発想から発展してきたんだけどなー。多数の個人情報とか
多数の契約書とか、多数の図形とか。。。
クラス定義はそのオブジェクト指向を表記するための便宜上の概念なんだけど、
オブジェクト指向の情報源は真っ先にクラス、継承などから説明して混乱を与えて
いるよな。

118 ：デフォルトの名無しさん：2008/11/12(水) 08:46:01

>>116
お前の世界だけの造語使われても意味がわからん…

119 ：デフォルトの名無しさん：2008/11/12(水) 11:51:43

>>115
>JavaのOO思想をOOのあるべき姿として布教
そんなこと言ってる脳足りんがいるんですか？

120 ：デフォルトの名無しさん：2008/11/12(水) 12:40:31

>>119
いくらでもいるだろ…
新人教育やってる奴に目を向けてみろ

121 ：デフォルトの名無しさん：2008/11/12(水) 12:42:50

C++やOcaml的な使える所だけOOというのがあるべき姿…と

122 ：デフォルトの名無しさん：2008/11/12(水) 20:54:26

>>121
どこにそんなことが書いてあるのか小一時間(ry

123 ：デフォルトの名無しさん：2008/11/12(水) 21:01:34

小一時間お茶しますか?

124 ：デフォルトの名無しさん：2008/11/12(水) 21:10:37

OOって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな

125 ：デフォルトの名無しさん：2008/11/12(水) 21:30:08

マクロって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな

126 ：デフォルトの名無しさん：2008/11/12(水) 22:24:31

マクロの挙動は定義を見れば分かるが、
テンプレートだの多重継承だの多用した結果
コンパイラ様が出すコードを想像するなど変態の技だ
だいたい、STLをまともにコンパイルできるコンパイラ
なんてないんじゃね？（笑）

127 ：デフォルトの名無しさん：2008/11/12(水) 22:34:58

>>123
可愛い女の子なら

128 ：デフォルトの名無しさん：2008/11/13(木) 01:32:13

STLやるぐらいなら
自分で言語作るわ

129 ：デフォルトの名無しさん：2008/11/13(木) 07:18:59

STLとオブジェクト指向の関係って？

130 ：デフォルトの名無しさん：2008/11/13(木) 11:09:13

OOPLとしても使用可能なC++の標準ライブラリの、さらに一部。

…関係ないと言えよう。

131 ：デフォルトの名無しさん：2008/12/28(日) 21:04:22

もうC++はOOPもできるテンプレート志向言語とか公言して良いんじゃないか

132 ：デフォルトの名無しさん：2009/02/17(火) 15:37:47

リレー回路はオブジェクト指向だよね

133 ：デフォルトの名無しさん：2009/02/17(火) 17:17:47

全然。

134 ：デフォルトの名無しさん：2009/02/23(月) 18:01:14

>>133
メッセージを伝えたら、バルブの開け閉めやら、過電流保護やら、照明やらしてくれるんだぞ

135 ：デフォルトの名無しさん：2009/02/25(水) 11:32:29

ハードウェアすべてが該当する件について

136 ：デフォルトの名無しさん：2009/02/25(水) 15:13:27

要はfacadeとかinterfaceというものなんだろうけど
それってOOPなの？

137 ：デフォルトの名無しさん：2009/02/25(水) 19:20:27

>>135
テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
分解して取り出せば別の用途に使えるが、取り外されたスイッチは既にテレビの電源スイッチじゃない

リレー回路のスイッチは、ポンプだろうがバルブだろうが関係ないONとOFFを制御するだけ

138 ：デフォルトの名無しさん：2009/02/25(水) 19:25:04

なんというgenericity…

139 ：デフォルトの名無しさん：2009/02/26(木) 10:45:19

>>137
>テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
ラジオの電源スイッチにも使えますね。

140 ：デフォルトの名無しさん：2009/02/26(木) 12:02:04

>>139
それは、ラジオの電源スイッチで、テレビの電源スイッチじゃない
仮に、テレビとラジオの機能を持った機械のスイッチだとすれば、それは、テレビの電源スイッチとは言えない
ラジオ機能付きテレビ(もしくは、テレビ機能付きラジオ)の電源スイッチだ

141 ：デフォルトの名無しさん：2009/02/26(木) 20:46:40

リモコンそのものはインスタンス。
Sharpのテレビを買ってきたら、付属するリモコンはその機種にしか使えない。
Sonyのコンポを買ってきたら、それに付属のリモコンはそれにしか使えない。

リモコンという抽象があって、リモコン付きの機械という抽象がある。
こういう考え方はどうでしょう？

142 ：デフォルトの名無しさん：2009/02/26(木) 21:53:16

>>141
抽象度が甘い気がする

むしろ、アンプやスピーカーなどバラバラに買ってくるコンポとか
AVシステムの方がオブジェクト指向だよね

143 ：デフォルトの名無しさん：2009/02/26(木) 21:58:55

現実の物引っ張ってきてオブジェクト指向だって言い張るのと、
それをオブジェクトモデルとして捉える(捉えられる)ことは違うんじゃないかな

144 ：デフォルトの名無しさん：2009/02/26(木) 22:09:08

リモコンはユーザインターフェースだけにインタフェースだね(そのまんま

ところで甘いっていうのはどういう程度を指すの
論理学の言葉を使えば弱いとか強いとかあるよね
ベン図で考えると狭い、広いとも言える

さて抽象度が甘いというのは
1.適用できる範囲が広すぎる
2.さらに汎化できる余地がある
どちらを指すのでしょうか？

145 ：デフォルトの名無しさん：2009/02/26(木) 22:49:56

>>144
2.だよ

146 ：デフォルトの名無しさん：2009/02/26(木) 23:08:19

リレー回路は、インターフェイスを継承して新しいインターフェイスも作れるし
動作内容も変更できるよ
そもそも、ハードワイヤードなプログラムだから

147 ：デフォルトの名無しさん：2009/02/27(金) 00:03:40

>>142
それはコンポーネント指向っていうんだお

148 ：デフォルトの名無しさん：2009/02/27(金) 00:17:35

>>137
あのな, on/off を伝えるメッセージ発信源としてかんがえるんだ
つか、オブジェクト指向ってハード屋がやってきたことの

＊＊＊＊＊劣化コピー＊＊＊＊＊

以外の何者でもない！！！

149 ：デフォルトの名無しさん：2009/02/27(金) 00:33:33

オブジェクト指向の利点は仕様をそのままクラスに反映できるってただそんだけだと思うな
ひねった抽象化したりしたらその時点で詭弁を使いだすイカレタ同僚と変わらないわけで
抽象化すればするほど利点が消えていくと思う

情報の共有化っていうの？
自分は他の誰かと仕事してるって感覚を身につけないと
一生わからんままテンプレート弄ってるＣ＋＋厨房と同じ道たどると思う

150 ：デフォルトの名無しさん：2009/02/27(金) 00:39:51

すっぽすっぽ先生の論文読んでから出直してください

151 ：デフォルトの名無しさん：2009/02/27(金) 12:06:45

あれだ、100％理解しないといけないと思ってるやつが駄目だ。

152 ：デフォルトの名無しさん：2009/02/27(金) 18:44:55

なんかへん

153 ：デフォルトの名無しさん：2009/02/27(金) 18:58:47

OO原理主義というか、シミュレーション主義なやつらがクソ。
現実世界をコード化、みたいなことに固執するやつら。

すなおにOOPしてればいいのに。

154 ：デフォルトの名無しさん：2009/02/27(金) 20:11:49

>>148
つ Software IC

155 ：デフォルトの名無しさん：2009/02/28(土) 02:26:55

現実世界はどうでもいいから
仕様書とクラスが１対１になっていればいいよ
サブのクラスはサブでコメント書いておきゃいいけど
とりあえず仕様書とプログラムがまったく一致してないような設計はダメだ
仕様書に書いてある物体ぐらいはオブジェクトにしてないと
オブジェクト指向の意味がまったくない

156 ：デフォルトの名無しさん：2009/02/28(土) 02:59:49

ようは入力の受付窓口と出力の出口の形を明確にする方法だろ？
と入門2ヶ月の俺が知ったかぶってみる

157 ：デフォルトの名無しさん：2009/02/28(土) 05:42:15

>>1
csosureたててんじゃねーぞ

158 ：デフォルトの名無しさん：2009/02/28(土) 05:44:11

オブジェクト指向を徹底すると可読性が著しく下がる件

159 ：デフォルトの名無しさん：2009/02/28(土) 06:03:08

>>158
それは君がヘッポコだから

160 ：デフォルトの名無しさん：2009/02/28(土) 10:47:55

オブジェクト指向の最大の功績は・・・
素人をプログラミングから遠ざけたこと。

OOPLだと、思いつくまま適当に書けばそれなりに動くプログラムが書きにくい。
だから、昔だったら自分でプログラムしたであろうような事でも
プロに依頼して、金を恵んでくれる。

そう考えると、シェルスクリプトで何でもかんでもできてしまう
UNIX/Linuxは職業プログラマの敵なのだ。

161 ：デフォルトの名無しさん：2009/02/28(土) 11:34:06

自称オブジェクト指向マスターって
引数中心で考えることを避ける人が多いような感じがする
しかもそういう人は「そこで発生させるべきでない副作用」をあちこちに散りばめる

162 ：デフォルトの名無しさん：2009/02/28(土) 11:45:41

副作用はCの文化だろｗ

163 ：デフォルトの名無しさん：2009/02/28(土) 12:13:47

ミスリード工作乙

164 ：デフォルトの名無しさん：2009/02/28(土) 14:50:40

>>161
それ、ただ単にOOが体得できてない「自称」OOマスターでしょ。

165 ：デフォルトの名無しさん：2009/02/28(土) 15:34:45

オブジェクト指向をもう少し機能や適用を限定させればいいんじゃないかな。
なんでもかんでもクラスにしないでこれはクラスにしなければダメだというものだけクラスにする。

166 ：デフォルトの名無しさん：2009/02/28(土) 16:11:49

おもしろいよね。
一人でプログラム組んでるときはC++の何でもできるってすごくうれしいのに
チームでプログラム組むことになるとマルチパラダイムの弊害が猛烈な勢いで襲い掛かってくる。

167 ：デフォルトの名無しさん：2009/02/28(土) 22:41:43

>>166
あのさ、class ってのが良くない
他人が作った class はドキュメントさえしっかりしてれば一応使えるけど,
現実には, ドキュメントはないわ, 抽象はでたらめだわ… で, どうしろとorz
Unix 系の C ライブラリの方が遥かにかわええわ!!!

168 ：デフォルトの名無しさん：2009/02/28(土) 23:14:39

「ええわ」でなく、「かわええわ」なのがふいんき(なry)でてる
70点

169 ：デフォルトの名無しさん：2009/02/28(土) 23:50:56

>>164
検討違いなツッコミどうも。
その自称オブジェクト指向マスターを沢山産んだのはオブジェクト指向自身なんだよ
カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ
本来意図されていた意味と違うとはいえ、カプセル化という言葉を広めてしまったオブジェクト指向の罪は重い
TDDがBDDに生まれ変わったように、オブジェクト指向も新しい何かに生まれ変わるべきだろう

170 ：デフォルトの名無しさん：2009/03/01(日) 00:07:07

>>169
> カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ

んだんだ！！！

オブジェクト内変数は呈の良いグローバル変数以外の何者でもない
get* とか set* の * にオブジェクト内変数名が使われているような
メソッドを大量に書く奴は、クラスを抽象化する時点で敗北してる

オブジェクトを現実世界のメタファーとして抽象する奴等は
*死* *ね* *ば* *い* *い* と思うよ

171 ：デフォルトの名無しさん：2009/03/01(日) 05:23:51

なるほど、そのへっぽこって君のことだったわけか。そりゃ見当が外れてた。

余計な副作用を残すのって、OO初心者がよくやる間違いだよね。
それを称してOOの罪というところがマヌケっつーか、、、、アホ？

172 ：デフォルトの名無しさん：2009/03/01(日) 05:24:42

>>170
で、そのオブジェクトはグローバルに参照できるの？www

173 ：デフォルトの名無しさん：2009/03/01(日) 10:53:10

>>170の適切な突っ込みにホッとした。

174 ：173：2009/03/01(日) 10:53:50

×>>170の適切な突っ込みにホッとした。
○>>172の適切な突っ込みにホッとした。

175 ：デフォルトの名無しさん：2009/03/01(日) 13:27:21

>>172
>>170ではないけど

>で、そのオブジェクトはグローバルに参照できるの？www
それはできないけど
メンバを大量に作るとグローバル変数と変わらない動作をするってのは俺はわかる
１クラスが異常にでかいソースにあたったときに苦労した

void setEdit()
{
　　transXXUnkoUnko(m_Bom);
}

void setEdit(int bom)
{
　　transXXUnkoUnko(bom);
}

単純に書くとこんな違いになるんだけど前者は追えるけど
後者はまったく追うことができない

176 ：デフォルトの名無しさん：2009/03/01(日) 14:07:15

>>175
しかし参照による相互作用はオブジェクト内におさまるよね？
プログラム全体がグローバル変数でガチガチに結合されるのと、
一応はオブジェクト単位に分離できるのとで、どっちがマシだと思う？

177 ：デフォルトの名無しさん：2009/03/01(日) 14:09:32

>>175
> void setEdit()

セッターがこのシグネチャってのは全く理解できないんですが。

> void setEdit(int bom）

1つのセッターで1つのメンバ変数にアクセスすることのどこが「大量」なのかサパーリ。

178 ：デフォルトの名無しさん：2009/03/01(日) 14:25:08

>>172
グローバルに参照したいから get* とか set* なんてアクセッサ作ってるんだろ
じっさいに名前空間切り替えることもせずに無節操にアクセスしてるしwW

179 ：デフォルトの名無しさん：2009/03/01(日) 15:52:53

おっとまた>>178が頓珍漢な返答を！

180 ：デフォルトの名無しさん：2009/03/01(日) 17:09:12

>>176
そりゃたしかにグローバルにしてしまうよりはいい
でも、そういうダメなものとどっちが・・・って議論をしたいんじゃなくて
そもそもこれってどーなのよ？
って言いたい

181 ：デフォルトの名無しさん：2009/03/01(日) 17:35:03

>>180
これ、とは？

182 ：デフォルトの名無しさん：2009/03/01(日) 17:45:53

昔、4つか5つの処理があれば何でもできると聞いたが、
オブジェクトはなんでこんなにややこしいの？

183 ：デフォルトの名無しさん：2009/03/01(日) 17:57:46

>>182
オブジェクトがややこしいんじゃなくて、
君の脳細胞が未分化なだけ。

184 ：デフォルトの名無しさん：2009/03/01(日) 17:58:33

>>180
それがわかれば、あとはオブジェクトの粒度を適切に設定すればいいんだ、ということに気付くはずだが？

185 ：デフォルトの名無しさん：2009/03/01(日) 18:11:03

つぶどってなんなんだぜ

186 ：デフォルトの名無しさん：2009/03/01(日) 18:13:37

>>184
粒度の問題なのか？と問いたい
だったらグローバル変数・関数だって小さいうちはアクセスしやすいし便利なだけだろ？
ただ、そのプロジェクトでの増加量を誰も予測できないから
やっぱりおかしくなってしまうわけで

俺がどう考えてるかというと
基本的にはメンバ変数ってのはダメなんだと思う

187 ：デフォルトの名無しさん：2009/03/01(日) 18:17:48

！？

188 ：デフォルトの名無しさん：2009/03/01(日) 18:18:55

クラスとインスタンスの違いが分かってない子の気配。

189 ：デフォルトの名無しさん：2009/03/01(日) 18:41:36

>>171
一人でコード書いてりゃいいニートと一緒にしないでくれよ
仕事でプログラム組む時は複数人でやるのが当たり前
お前の理想は現実とはかけはなれてる。そこわかってる？

190 ：デフォルトの名無しさん：2009/03/01(日) 18:49:31

>>184
他人が書いたコードも君は全て責任持って修正できる？

191 ：デフォルトの名無しさん：2009/03/01(日) 19:14:34

>>184
そこに明確な基準は無いよね
重要な部分を個々の考えに任せる時点でダメ

192 ：デフォルトの名無しさん：2009/03/01(日) 21:39:13

メンバ変数が追えないというヤツは関数内やファイルスコープ内の静的変数にもハマるだろう。

193 ：デフォルトの名無しさん：2009/03/01(日) 22:52:03

>>186
メンバ変数とグローバル変数とは全然違うぞ...

クラス内では、まるでグローバル変数のように見えるけどな

194 ：デフォルトの名無しさん：2009/03/01(日) 23:13:36

オブジェクトがたった一つなら、名前空間内のグローバル変数だけど、複数あったら事情が違うが。

195 ：デフォルトの名無しさん：2009/03/02(月) 00:04:59

>>191
個々の考えと言ってるうちは、何も理解してない
ということになってしまう。

196 ：デフォルトの名無しさん：2009/03/02(月) 00:07:54

だけど実際はクラスは大きくなってしまうわけで
そうなるとグローバル変数と変わらない動きをする
グローバル変数も管理できていれば問題はおきないってのは一緒なんだよね

でかいだけじゃなくて、１つのクラスを３つぐらいの使い方ができたり、
呼ぶ場所によって挙動を変えてるようなのもかなり複雑でまずい

197 ：デフォルトの名無しさん：2009/03/02(月) 00:16:27

>>196
int a, b;
としたとき、aとbの数値は連動するの?
a = 1;
としたら、bも1になってるの?

巨大化するクラスは、何かがおかしいと思うの...
俺みたいなニートなプログラマが気まぐれで作っているならともかく、プロが仕事で作っているのに1つのクラスが巨大化したら駄目でしょう

198 ：デフォルトの名無しさん：2009/03/02(月) 00:34:12

>>195
明文化された明確な基準のソースを示した人でなきゃそのセリフは吐けないはずだけど…
そうでないのに何コレ

199 ：デフォルトの名無しさん：2009/03/02(月) 00:38:36

グローバル変数と変わらないって言ってる意味が全く分からん
アクセサ経由でメンバ変数にどこからでも参照できるから、みたいなアホな意見？

200 ：デフォルトの名無しさん：2009/03/02(月) 00:42:03

staticか非staticかに関わらず複数メソッドから直接見える変数が存在することがダメって話…かと思いきや
違うのか
ちがわなければ同意

201 ：デフォルトの名無しさん：2009/03/02(月) 00:42:50

>>199
違うんだよ
１つのクラス内の関数同士の話

202 ：デフォルトの名無しさん：2009/03/02(月) 00:43:41

>>199
メイン関数まで内包してるような
超巨大クラスを想像しろ
メソッド同士が呼び出しあって動作する

203 ：デフォルトの名無しさん：2009/03/02(月) 01:03:54

>>201-202
怖い、怖いです...
冬なんですから怪談話は止めてください

204 ：デフォルトの名無しさん：2009/03/02(月) 01:08:53

ローカル変数もスコープ内のどこでも使えるから一緒ですか分かりません

205 ：デフォルトの名無しさん：2009/03/02(月) 01:11:38

オブジェクト指向を知らないまま、オブジェクト指向した末の惨劇ですね

206 ：デフォルトの名無しさん：2009/03/02(月) 01:48:54

信者共はあえてアホレスのみを捕まえて袋叩きにしたあと、
痛いとこついてるレスまでついでにまとめて
理解できない奴が悪いで済ませようとしてるけど

それでオブジェクト指向の暗黒面が消え去るわけじゃないだろ…

207 ：デフォルトの名無しさん：2009/03/02(月) 01:58:39

>>204
同じようになるよ
超長い関数で一番上でまとめて宣言されると
どこで使ってるかマジで不明

使う場所で適切に用意→破棄してくれと言いたい
でもＣ言語だとダメなんだっけ？

っていうかその前に長い関数作るなよと言いたい

208 ：デフォルトの名無しさん：2009/03/02(月) 03:36:46

ラッパークラスなんか超長い関数と同じ
生成期間も無駄に長い

209 ：デフォルトの名無しさん：2009/03/02(月) 05:41:58

ループカウンタとかどこで定義しようが何も問題無いだろ

210 ：デフォルトの名無しさん：2009/03/02(月) 05:49:46

忘れっぽいからさ。
使うところの近所で定義してもらわないと型とかあっさり忘れるんだわ。
老化が始まると全部関数の頭で定義なんてマジしんどい。

211 ：デフォルトの名無しさん：2009/03/02(月) 07:38:46

結局、メンバ変数を叩いてる人は、自分がプログラミング初心者ですと告白している、ということでFA？

212 ：デフォルトの名無しさん：2009/03/02(月) 09:07:23

>>211
とりあえずFPやってみろ

213 ：デフォルトの名無しさん：2009/03/02(月) 09:12:52

>>212
俺はMiranda, Gofer, SML, HaskellとFPやってきたが、>>211に同意だ。
OOを叩いている側の人間に明らかな技量不足が見える。

214 ：デフォルトの名無しさん：2009/03/02(月) 09:15:29

毎回アンチをひとまとめにして叩いてるあなたが言っても
自演にしか見えにゃーど

215 ：デフォルトの名無しさん：2009/03/02(月) 09:19:39

>>213
自由変数&mutableベッタベタだったのか…

216 ：デフォルトの名無しさん：2009/03/02(月) 09:23:18

>>214
技量不足以前に妄想性人格障害か。お大事に。

217 ：デフォルトの名無しさん：2009/03/02(月) 09:26:28

気軽にOOPを持ち込もうとして混乱する者どもの存在は分かった。

218 ：デフォルトの名無しさん：2009/03/02(月) 09:27:28

>>215
へー、Mirandaでどうやってmutableを実現するのか、説明してよwww

219 ：デフォルトの名無しさん：2009/03/02(月) 09:28:44

このスレには
他人のクラスの粒度どころかライセンス的に修正不可なソースまで修正できる自称スーパープログラマ(笑)
が沢山いるみたいだな
BREWとかどうすんのマジで

220 ：デフォルトの名無しさん：2009/03/02(月) 09:33:25

>>218
できないから移行(挫折)したんだろ？w

221 ：デフォルトの名無しさん：2009/03/02(月) 09:34:43

メンバ変数ってまでに広げたら、それこそ状態量を持つオブジェクトすべて指すようになってしまうな
流石にそれは極論だと思うので、もう少し範囲を狭めて考えてみる。
「グローバル変数と同じ」という性質を「何処で誰が触っているかわからない」ということだと仮定すれば
恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。

222 ：デフォルトの名無しさん：2009/03/02(月) 09:38:08

>>221
だとしても、そのオブジェクト自体がグローバルに参照されていなければ
メンバ自体がpublicでも「何処で誰が触っているかわからない」状態にはならないよね。

223 ：デフォルトの名無しさん：2009/03/02(月) 09:39:49

>>221
> 恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。

じゃなくて、もっとひどい。

>>201
> １つのクラス内の関数同士の話

↑このように、クラス、という静的な単位で困っている様子。

食べることが悪いんじゃない。
食べ過ぎることが悪いんだ。

メンバ変数が悪いんじゃない。
メンバ変数が多すぎたり、
クラス内の関数が多すぎたりでかすぎたりするのが悪いんだ。

224 ：デフォルトの名無しさん：2009/03/02(月) 09:55:22

そうか、全然読めてなかったよ

折角クラス内だけにスコープを止めても、そのクラス内がカオスだったら
人間が把握できない程度に複雑になる可能性があるという点ではグローバル変数と同じ
と解釈した

「とりあえずクラスにすりゃなんとかなるじゃんｗ」っていうような安直なOOPに対する批判なのかな？

225 ：デフォルトの名無しさん：2009/03/02(月) 10:02:21

逆にアンチOOPに訊きたいのは、

プログラム全体が1つのクラスになってしまうような巨大クラスは問題だ、という主張なんだよな？
まあ、それはそれでいいけど、

(1) そもそもクラスにしないで関数や手続きとして実装しても同じ問題になるし、
関数や手続きとして実装してうまくいくのなら、それをそのままクラスにしても、
それなりにうまくいくのでは？

(2) その巨大クラスのインスタンスは何個できるの？
もしインスタンスが多数できるのなら、参照関係の複雑さも多少は整理されているのでは？

ぜひ答えてほしい。

226 ：デフォルトの名無しさん：2009/03/02(月) 10:17:48

多少複雑さが軽減されるからといって、
把握できないぐらいのものが把握できないぐらいのものに変わっても意味ないよね。
OOPを使って複雑なものを人間が把握できる程度まで落し込めるような使い方じゃないと、
同じどころかOOAのコストの分だけ損になると思うよ。
こんな考え方でもアンチOOPになるんですか？

227 ：デフォルトの名無しさん：2009/03/02(月) 10:18:09

アンチはしらんが、どっちで実装しても同じならわざわざ手間のかかる
手段をとらなくていいのでは？

228 ：デフォルトの名無しさん：2009/03/02(月) 10:47:09

>>227
手間かけていないから巨大クラスになるんじゃねーの？

229 ：デフォルトの名無しさん：2009/03/02(月) 17:57:38

巨大クラスを作るってのは、オブジェクト指向が必要だとか不要だとか言う前に
構造化プログラムとは何かから始めないと駄目だと思うの

230 ：デフォルトの名無しさん：2009/03/02(月) 22:37:31

>>229
> 構造化プログラム
以前の問題で、
「自分が何をしなければならないか？」
の、分析ができてないんとちゃうん？

「作らんとあかん物の分析をやってない」
としか思えんのよ

231 ：デフォルトの名無しさん：2009/03/02(月) 22:55:58

つまりほとんどのプログラマはOO以前に構造化すら満足に出来てないと。

232 ：デフォルトの名無しさん：2009/03/02(月) 23:03:21

やはり構造化よりオブジェクト指向の方が頼りにされていたクライアんトとの戦いで
おれは納期に遅れてしまったんだがちょうどマネージャがわきはじめたみたいでなんとか耐えているみたいだった
おれは家にいたので急いだところがアワレにもCプログラマがくずれそうになっているっぽいのが携帯で叫んでいた
どうやらプログラマがたよりないらしく「はやくきて～はやくきて～」と泣き叫んでいるチームメンバーのために俺はオブジェクト指向を使って普通ならまだ出来ない時間できょうきょプログラミングすると
「もう出来たのか！」「はやい！」「きた！オブジェクトきた！」「メインプログラマきた！」「これで勝つる！」と大歓迎状態だった

233 ：デフォルトの名無しさん：2009/03/02(月) 23:03:41

クラス勉強し始めた初心者ですが、正直何でFunctionだけじゃダメなのか分かりません。

・Functionだけでも資産は後に再利用できる
・1ページの表示で同じクラスオブジェクトを複数作成する必要がない
・いちいちオブジェクトを生成するのが面倒

それでもオブジェクトの方が便利と言う方・・お話聞かせて頂けませんか？

234 ：デフォルトの名無しさん：2009/03/02(月) 23:20:41

>>232
日本語でどうぞ

235 ：デフォルトの名無しさん：2009/03/02(月) 23:22:06

>>233
そのコメントみてるとたぶんwebやってるんだろうけど
それくらいならオブジェクト導入してもしなくても良かろう

236 ：デフォルトの名無しさん：2009/03/02(月) 23:26:25

クラスが巨大になりすぎるからとかいってるやつって、
関数が巨大になりすぎたり、グローバル変数をポコポコ作ったりするやつでそ

237 ：デフォルトの名無しさん：2009/03/02(月) 23:27:02

>>233
ﾒﾝﾄﾞｲ。
とりあえず憂鬱なプログラマのためのオブジェクト指向開発講座を読んで、
なじまないと感じたなら以後はオブジェクト指向言語を避けろ
オブジェクト指向言語で無理に関数だけでプログラム組んでも馴染まないしな
言語の思想にあった手法を取るのが一番

避けようのない状況ならご愁傷様

238 ：デフォルトの名無しさん：2009/03/02(月) 23:31:26

>>236
> 関数が巨大になりすぎたり、グローバル変数をポコポコ作ったりするやつ
が、OO したつもりになると
「クラスが巨大になりすぎるので OOって意味ねぇ！！！」
言ってるじゃね？

239 ：デフォルトの名無しさん：2009/03/02(月) 23:34:04

コボラーのように罵られる存在になりたくないから皆必死にOOを守ろう

240 ：デフォルトの名無しさん：2009/03/02(月) 23:50:04

とりあえず比較的年配の方々で、やたら「オブジェクト指向」連発する人間は
信用できない。

241 ：デフォルトの名無しさん：2009/03/03(火) 00:57:51

>>235, >>237
アドバイスありがとうございました。
ActionScriptもいつの間にかClassが使用され
周りの言語は、全部オブジェクト指向を取り入れて行っているような気がしてなんだか焦りますね。
そのうち、オブジェクト指向出来ない人は、ハイさようならになりそう。

「憂鬱なプログラマのためのオブジェクト指向開発講座」もちょっと読んでみることにします。

その他、効率の良いクラスの設計の仕方など、参考になる本はありますでしょうか？

242 ：デフォルトの名無しさん：2009/03/03(火) 01:08:43

>ActionScriptもいつの間にかClassが使用され
昔というか最初からClassだったよ
直接見えなかっただけで

243 ：デフォルトの名無しさん：2009/03/03(火) 04:12:48

今も昔もプロトタイプベースだよね＞AS
クラスベースちっくに書いたりパフォーマンスを得るために
文法とか内部実装とか工夫しているだけであって。

244 ：デフォルトの名無しさん：2009/03/03(火) 06:28:52

>そのうち、オブジェクト指向出来ない人は、ハイさようならになりそう。

っつーか良く出来たフレームワークは
オブジェクト指向を特に意識しなくても
だれでも使える構成になってたりするが

245 ：デフォルトの名無しさん：2009/03/03(火) 06:31:19

あー使う側の立場だけ考えるとそうだけど作る側ならあれだね

246 ：デフォルトの名無しさん：2009/03/03(火) 11:17:55

>>242, >>243
ああ・・・そういえば、インスタンスを作成するって昔からありましたね。＞AS
クラスを意識させない方向だっただけなんですね。

247 ：デフォルトの名無しさん：2009/03/03(火) 12:39:39

>>241
　「オブジェクト指向でなぜ作るのか」が比較的わかりやすくていい。

あとは、これとか。
ttp://kmaebashi.com/programmer/object/index.html

これかな。俺も勉強始めたばかりなんでなんだが…。
ttp://www.stratagenom.com/06_blog/01_object/

248 ：デフォルトの名無しさん：2009/03/03(火) 12:54:26

>>246
インスタンスを生成するのはクラスベースの専売特許ではない。
プロトタイプベースでもインスタンスは生成できる。

249 ：デフォルトの名無しさん：2009/03/03(火) 13:33:11

>>247
一個目のリンク先、わりと意欲的な文章だと思う。
OOPが分からない人々に対して、まず最初に、
インスタンスについて強調するのは大事だと思う。

250 ：デフォルトの名無しさん：2009/03/03(火) 16:04:15

>>246, 248
というかそもそもAS1、AS2にクラスなんてあったのか。
AS2のclass宣言はprototype云々を書く手間を省くだけの
省略記法程度のものだと思っていたんだが。

251 ：デフォルトの名無しさん：2009/03/03(火) 17:32:59

>>248
インスタンスの無いプログラミング言語なんて無いだろう...

252 ：デフォルトの名無しさん：2009/03/03(火) 17:46:58

>>251
primitive typeの値は普通インスタンスとは呼ばない。

253 ：デフォルトの名無しさん：2009/03/03(火) 17:52:15

え゛？

254 ：デフォルトの名無しさん：2009/03/03(火) 17:55:49

>>252
おいおい...

255 ：デフォルトの名無しさん：2009/03/03(火) 17:57:36

>>251
Cには、オブジェクトはあるがインスタンスはない。

256 ：デフォルトの名無しさん：2009/03/03(火) 18:05:58

>>255
インスタンスは意識してプログラムしないと碌な事がないよ
特にC言語の場合...

257 ：デフォルトの名無しさん：2009/03/03(火) 18:20:25

schemaとinstance、classとobject、typeとvalue、他にもあるかな。

定義無しでインスタンスという単語を使いたいのであれば、ざっくり
いって上記の組の右の単語を「インスタンス」の一言で括った程度
のものではないかと。
単語の使い方としての慣用は確かにあるけれども、きちんとした
定義無しに言語内での有無を論じられるようなものではないよ。

258 ：デフォルトの名無しさん：2009/03/03(火) 20:02:39

メモリ上の具体的な「オブジェクト」と、OOの「オブジェクト」は意味が違うだろ
後者は前者を内包することはあるが、一緒にして語ってる時点でおかしい

259 ：デフォルトの名無しさん：2009/03/03(火) 20:04:22

インスタンスとエンティティの違いについて教えてくだされ

260 ：デフォルトの名無しさん：2009/03/03(火) 20:11:31

classとentity

261 ：デフォルトの名無しさん：2009/03/03(火) 20:19:11

>>257
>きちんとした
>定義無し
だからこそ
>言語内での有無
は「言語仕様にあるか、ないか」しか言えない。
あれだ、「Javaにもポインタがある」つってる奴と一緒。

262 ：デフォルトの名無しさん：2009/03/03(火) 20:40:33

インスタンスって、オブジェクト指向云々に関わらず
メモリ上で実行されているプログラムそのものの事を言うもんだと思っていたが

263 ：デフォルトの名無しさん：2009/03/03(火) 21:23:45

エンティティってなに？

264 ：デフォルトの名無しさん：2009/03/03(火) 21:52:39

オブジェクト指向をコーディングだけにあてはめようとする奴と、
分析・設計からを理解してる奴が話すと
当然ながら噛み合わないな

265 ：デフォルトの名無しさん：2009/03/03(火) 21:58:05

分析・設計から理解してると
普及するのは自然な事だと納得できるし、受け入れやすいんだがなあ

266 ：デフォルトの名無しさん：2009/03/03(火) 22:06:19

北大路欣也

267 ：デフォルトの名無しさん：2009/03/03(火) 23:04:27

１つの機能に関するファンクションを
パッケージにできるだけでもありがたいのにな。
忌み嫌うわけが逆にわからん。

268 ：デフォルトの名無しさん：2009/03/03(火) 23:57:30

>>267
それはただのモジュール化との違いを説明できんのか

269 ：デフォルトの名無しさん：2009/03/04(水) 00:09:36

機能と状態をセットでパッケージ化できるわけで。

270 ：デフォルトの名無しさん：2009/03/04(水) 00:30:16

オブジェクト指向は、ウェブページだと利点を生かし切れない場合も多い気がする

271 ：デフォルトの名無しさん：2009/03/04(水) 00:33:19

構造化プログラミングの体質のままオブジェクト指向を導入すると、
必要とは思えないのは当たり前だ。
ジジババがネットの必要性を感じないのと同じ。

272 ：デフォルトの名無しさん：2009/03/04(水) 00:34:38

Webページのオブジェクト指向ってなんだ？Webプログラミングのことか？

273 ：デフォルトの名無しさん：2009/03/04(水) 01:03:56

>>268
検索機能なんかを考えればわかるのでは?
単純にモジュール化しても、ただの関数の集まりとしてしか扱えない上に、肝心な検索結果を保持する場所は人任せになる
クラス等を利用すれば、検索結果を中心に関数をモジュール化でき、検索結果の保存場所をどうするのか利用者が気にする必要が無くなる

274 ：デフォルトの名無しさん：2009/03/04(水) 01:20:04

>>273
それはただの抽象データ型でしょ
あとクラス使わないと出来ないなんてことはない。
例えば C言語のストリーム入出力だってファイルアクセスの関数を
モジュール化でき、ファイル管理データ(FILE型構造体)の保存場所を
どうするのかを利用者が気にする必要がなくなってる。

275 ：デフォルトの名無しさん：2009/03/04(水) 01:45:41

>>272
ホームページ作成でPHP等でオブジェクト指向を取り入れること

276 ：デフォルトの名無しさん：2009/03/04(水) 02:13:09

>>274
さらに付け加えれば、非標準ながら
fdopenやfmemopenによって多態性も実現できていると言える。

277 ：デフォルトの名無しさん：2009/03/04(水) 03:42:01

オブジェクト指向の必要性なんて、「IntelliSenceしやすくなる」で十分すぎるだろ。

278 ：デフォルトの名無しさん：2009/03/04(水) 03:59:45

あまりオブジェクト指向関係ないと思うよ。
型付けが静的か動的かの違いの方がでかいでしょ。

279 ：デフォルトの名無しさん：2009/03/04(水) 06:49:18

>>274
だよな
>>269 >>273 は
>>247 を読んでないよ

280 ：デフォルトの名無しさん：2009/03/04(水) 06:51:25

>>270
一番の原因は毎回接続しなおしてること
実際はCookieでごまかしてるが
httpのプロトコルが糞で
オブジェクト指向の普及を妨げてる

281 ：デフォルトの名無しさん：2009/03/04(水) 07:03:36

>>263
ぐぐれかす

282 ：デフォルトの名無しさん：2009/03/04(水) 07:27:57

PL上の概念としての「インスタンス」の話をしているときに分析設計での「インスタンス」を持ち出されてもw

283 ：デフォルトの名無しさん：2009/03/04(水) 07:35:42

いや～、HTTPをクソ呼ばわりするのは結構蛮勇が必要だと思うな。
何に対して憤っているかよく判らないけど。ステートレスなところ？

284 ：デフォルトの名無しさん：2009/03/04(水) 07:40:16

>>280
ひょっとしてHTTPリクエストを出す度にsynパケットが飛んでると思ってる？

285 ：デフォルトの名無しさん：2009/03/04(水) 11:17:39

Cでもできる系の話は聞き飽きた。
そりゃ、できるだろうよ。
C++の最初の実装はC Frontなんだし。
大事なのは、俺様ルールでバラバラな実装をするのか、
言語仕様による統一的ルールでやるのかということだ。

286 ：デフォルトの名無しさん：2009/03/04(水) 12:04:27

>>274
ファイルを扱うためには、少なくともFILE型が必要である
FILE型を扱うためには、専用の関数が必要である

それらの関数をFILE型に閉じ込めておければ便利だと思わないか?
file++とか、file--とか、file + nとかで、ファイルポインタを制御し
*fileでファイルポインタの位置にアクセス出来きたりした方が便利な気がしないか?

まあ、*をオーバーロードしちゃ美味くないけどな

287 ：デフォルトの名無しさん：2009/03/04(水) 12:38:59

>>273 >>286は根本的にオブジェクト指向が分かっていない
コンポーネントにどういう責務を持たせるかが重要なのであって、
「ユーティリティクラスみたいなのがあれば便利だよね」、
とか言いだすのはインターフェースの切り出しができない奴の典型

288 ：デフォルトの名無しさん：2009/03/04(水) 12:51:26

>>287
何を言っているのか判らない...

検索オブジェクトが検索結果を持たないのが責務って事?
ファイルオブジェクトは、ファイルを扱わないのが責務って事?

289 ：デフォルトの名無しさん：2009/03/04(水) 13:19:31

出た！　それでは、
根本的にオブジェクト指向が分かっている>>287さんに色々語ってもらいましょう。

290 ：デフォルトの名無しさん：2009/03/04(水) 13:39:26

phpって、元々classを使うことを前提に作られてない点がJavaなんかとは違うよね？

こういうスクリプト言語が大普及しているから、オブジェクト指向使わない・・や
必要性を感じない人が多いんだと思う。

291 ：デフォルトの名無しさん：2009/03/04(水) 14:29:51

emacs lispなんてもうね…

292 ：デフォルトの名無しさん：2009/03/04(水) 16:29:57

ひどいオブジェクト指向の例なら、Perl 5に勝てるものはいないだろ。

293 ：デフォルトの名無しさん：2009/03/04(水) 16:41:36

>>290
単にカジュアルプログラマへの動機付けの問題であればそれも
答えとしては十分なんだけど。
設計論に対する意見の違いもあるし、プログラマの世代差とか
属人的な要素も絡んで実際はそこそこ根深い話だと思う。

1980年代だったか月刊ASCIIでオブジェクト指向を取り上げた
記事を読んだときには今でいうちょっと前のWeb2.0とかクラウド
みたいな胡散臭さをプンプン感じた記憶がある。
「次の波はこれ！ソフトウェア危機もこれで一発解決」みたいな。

294 ：デフォルトの名無しさん：2009/03/04(水) 16:49:32

オブジェクト指向って別に効率的じゃないじゃん。

295 ：デフォルトの名無しさん：2009/03/04(水) 16:53:01

かつて、「オブジェクト指向」という単語は「再利用」という単語と強く結びついていた。
特に出版界で。

296 ：デフォルトの名無しさん：2009/03/04(水) 17:24:46

>>294
効率的だし再利用によってプログラミングの生産性は劇的に向上する、
と「期待されていた」んだよ。

「21世紀には社会で必要とされるプログラマ数が世界人口を超える」

そんな危機意識が語られていた時代もありました。

297 ：デフォルトの名無しさん：2009/03/04(水) 18:46:49

オブジェクト指向の話題では、大別すると２つの内容になる
ひとつはここにも多数存在する、言語うんぬんの話
もうひとつはオブジェクト指向根幹の分析・設計の話

オブジェクト指向の最大の利点は、
分析から設計、コーディングまでの設計外観を統一できるということ
分析や設計にオブジェクト指向を利用してこそ、
オブジェクト指向対応の言語を使うメリットがある
そういうことを理解してない奴が、言語うんぬん言いだす

一番の問題は、分析者・設計者がオブジェクト指向を利用していないくせに、
要件定義の時点でなぜかオブジェクト指向言語を採用してること

298 ：デフォルトの名無しさん：2009/03/04(水) 19:03:15

オブジェクト指向って一つの作業を一つ又はいくつかのオブジェクトだけを使って行えるようにする為のもんだろ。
だからある程度の汎用性を持たせられるインターフェース、実装を考えれば使いまわしができる。
そうすると長期的な生産性が上がるってことだったと思うんだが。

だから適当に作ったり下手くそな設計だと逆に使いにくくて当然。

299 ：デフォルトの名無しさん：2009/03/04(水) 19:03:53

>>297
> 分析から設計、コーディングまでの設計外観を統一できるということ
できねぇよ

少なくとも, 時系列のデータを扱う場合、単純に、
「お前らが言うオブジェクト設計」
を、やったら負けだと思う
関わった中では、とろくて使いもんにならんものが………

ハード屋よろしく
「ブロック図書いて、各ブロックの機能要素求めて、タイミングチャート
書いて、デッドロック要素見つける」
程度の事前検証ゐしないと、納期までにまともな動作は期待できない

ものによったら、伝達関数とかまで出てくる現場ではあるんだが

300 ：デフォルトの名無しさん：2009/03/04(水) 19:07:18

>>298
インターフェースの設計が分かってないだろ
ある程度の汎用性を持つインターフェース、ってなんだそりゃ？
コンポーネント間でどうしても必要な場合に、
やり取りとしてインターフェースが存在するんだぞ

301 ：デフォルトの名無しさん：2009/03/04(水) 19:15:23

指向とは言うけど何が指向性を持っているかが不明

302 ：デフォルトの名無しさん：2009/03/04(水) 20:22:50

>>300
やり取りする為以外にインターフェース存在するのかよ。
今やりたいことを達成すればいい設計にするのか、
それとも今は必要無いかもしれんけど、この先使いまわす時に必要になる事も考慮するのかって事だよ。

303 ：デフォルトの名無しさん：2009/03/04(水) 20:57:02

300 のインターフェースは ttp://e-words.jp/w/E382A4E383B3E382BFE383BCE38395E382A7E383BCE382B9.html
298 のインターフェースは ttp://msugai.fc2web.com/java/interface.html

304 ：デフォルトの名無しさん：2009/03/04(水) 21:08:44

OOAとOODとOOPをごっちゃにして放言しているから収拾がつかない。

305 ：デフォルトの名無しさん：2009/03/04(水) 22:19:41

根本の考え方は、プログラムの生産性をより高めていこうってことで
言語の発展の流れとしてはごく当たり前で受け入れやすいと思うのに
まず「オブジェクト指向」って翻訳が悪い気がする
かといって良い言い方も思いつかないが

306 ：デフォルトの名無しさん：2009/03/04(水) 22:28:39

>>286
274は「Cでできるからオブジェクト指向言語なんて不要」と言っているようには見えないのだが。

307 ：デフォルトの名無しさん：2009/03/04(水) 23:21:31

>>302
拡張性の話とインターフェースの話を一緒にするから突っ込まれてることに気がつけよ
なんか、「JavaやってるんでOO理解してます」ってな奴が多すぎ

308 ：デフォルトの名無しさん：2009/03/04(水) 23:46:08

オブジェクト指向の真の意味を理解しているのは俺様だけだな、
っつーやつばかりだな。

309 ：デフォルトの名無しさん：2009/03/05(木) 00:55:29

てか、レベルの低いやつほど
『オブジェクト指向を馬鹿にしているやつは「Cでできるからオブジェクト指向言語なんて不要」なんて言っているから馬鹿なんだ』
なんて言うんだよな・・・
関数型言語とかもっと違う方向には目が向かないのかね、こういう輩は。
大体ソフトウェアの世界なんてまだまだ混沌としていて何が正しくて何が正しくないのか誰もわからないんだから、
あまり人が言っていることを馬鹿にしないほうがいいよ。
どうせまだ誰も正しいことなんてわかりっこないんだから。
少なくとも歴史が長い物理学よりはずっとやってることが原始的。

310 ：デフォルトの名無しさん：2009/03/05(木) 01:05:55

そこでわざわざ物理学を出すのはどうかと思う。
物理学に失礼すぎる。

311 ：デフォルトの名無しさん：2009/03/05(木) 01:37:46

>>310
そこの部分は、>>309の話の中で、彼の発言の趣旨から外れた一番どうでもいい部分。
何故そこを拾って取り上げようとするのかな？　もっと全体像をとらえようよ

312 ：デフォルトの名無しさん：2009/03/05(木) 03:12:58

>>311
自分だってどうでもいいと思ったから取り上げた。
そんなこと蛇足にすぎない、書かないほうがよかったぞという思いを込めて。

313 ：デフォルトの名無しさん：2009/03/05(木) 03:23:56

>>309

>てか、レベルの低いやつほど
>『オブジェクト指向を馬鹿にしているやつは「Cでできるからオブジェクト
>指向言語なんて不要」なんて言っているから馬鹿なんだ』
>なんて言うんだよな・・・

ここと、

>関数型言語とかもっと違う方向には目が向かないのかね、こういう輩は。

ここの話の繋がりを分かりやすく教えて下さい偉い人。
俺にはさっぱりだ。

314 ：デフォルトの名無しさん：2009/03/05(木) 07:39:10

>>309は岡村を知らないモグリ

315 ：デフォルトの名無しさん：2009/03/05(木) 15:44:08

>>314
岡村って知らないんだけど、何やってる人？

316 ：デフォルトの名無しさん：2009/03/05(木) 16:06:06

芸人長いことやってる

317 ：デフォルトの名無しさん：2009/03/05(木) 19:06:56

>>241
> 「憂鬱なプログラマのためのオブジェクト指向開発講座」もちょっと読んでみることにします。

>>247
> >>241
> 　「オブジェクト指向でなぜ作るのか」が比較的わかりやすくていい。

「憂鬱本」と「オブジェクト指向でなぜ作るのか」は、今となってはあんまり良くない。
ttp://d.hatena.ne.jp/JavaBlack/20080727/p1

> あとは、これとか。
> ttp://kmaebashi.com/programmer/object/index.html

これはオススメ。

318 ：デフォルトの名無しさん：2009/03/05(木) 19:36:57

カモノハシ本たけーよ。

319 ：デフォルトの名無しさん：2009/03/05(木) 19:40:57

オブジェクト化すると責任の所在がハッキリするよね

320 ：デフォルトの名無しさん：2009/03/05(木) 20:34:49

オブジェクト指向も設計実装の道具のはずなんだけど
理解が難しいのが問題では？
使いづらい道具は人は使わないですし本来道具は使いやすさが
重要だとおもうのですが

321 ：デフォルトの名無しさん：2009/03/05(木) 20:37:07

定義が曖昧なのも問題

322 ：デフォルトの名無しさん：2009/03/05(木) 20:59:59

オブジェクト指向ですら難しいという人はプログラマ向いてない。

323 ：デフォルトの名無しさん：2009/03/05(木) 23:34:06

オブジェクト指向の考え方は何となくわかるが、小さいプログラムだと今までのやりかたの方が簡単に組める。
どうしても必要にならないと本気で使おうと思わないんだよね。
高速に動かしたいところはやっぱりCになっちゃうし。
ま、確かに俺はプログラマ向いてないと思う。

324 ：デフォルトの名無しさん：2009/03/06(金) 00:13:47

オブジェクト指向は、必要なければ使わなくても良いんじゃないかな？
そういう人のために、オブジェクト指向使わなくても利用できる言語やスクリプトあるわけだし…
ま・・俺もむいてないけど、適度に出来る程度で十分な案件だけやってるw・・・全部一人でwww

325 ：デフォルトの名無しさん：2009/03/06(金) 00:47:20

オブジェクト指向は、必要なければ使わなくても良い

326 ：デフォルトの名無しさん：2009/03/06(金) 00:52:14

オブジェクト指向は、仕事に困らないのであれば使わなくても良い

327 ：デフォルトの名無しさん：2009/03/06(金) 01:30:28

ぶっちゃけC++やC#使えればよくて
オブジェクト指向を使う必要はない

328 ：デフォルトの名無しさん：2009/03/06(金) 01:33:15

まあ、stlやboost使える程度に知識があれば
厳密の意味でのオブジェクト指向なんて別にいらんよな。

329 ：デフォルトの名無しさん：2009/03/06(金) 01:35:16

オブジェクト指向ははったりで使う
仕事でそれ以上の意味はない

330 ：デフォルトの名無しさん：2009/03/06(金) 01:37:44

会議で黙らせる時に使う

331 ：デフォルトの名無しさん：2009/03/06(金) 02:42:27

最初にオブジェクト指向から入った人には
オブジェクト指向が普通で、そうじゃない物を使う人が変に見えるだろうな
意外とこういう人多いんじゃ無かろうか
それと、分業させるのがOOだと楽ってのもあるんだろうな

332 ：デフォルトの名無しさん：2009/03/06(金) 05:29:29

そうでもないみたいだよ

333 ：デフォルトの名無しさん：2009/03/06(金) 07:18:34

ここで言ってるOOって、結局は手続き型ベースのOOPLばっかりで、
関数型ベースや論理型ベースについては皆さん無知ってことで。

334 ：デフォルトの名無しさん：2009/03/06(金) 07:51:30

道楽じゃないんでね。

335 ：デフォルトの名無しさん：2009/03/06(金) 12:14:41

ほんとに、昨今のオブジェクト指向だけが正義みたいな風潮やめてほしいなぁ。

336 ：デフォルトの名無しさん：2009/03/06(金) 12:18:08

抽象化の手法はOOP派生のアプローチだけじゃないのは確かだけど、
現在主流となってる言語でできるのは大概それぐらいしか無いから仕方ないね

337 ：デフォルトの名無しさん：2009/03/06(金) 12:30:31

>>336
Haskellとかは全く違うスタイルなんだけど。

338 ：デフォルトの名無しさん：2009/03/06(金) 12:31:34

てか、F#とか最近流行ってるやん。
あれは関数型言語だからオブジェクト指向スタイルじゃないよね。

339 ：デフォルトの名無しさん：2009/03/06(金) 12:47:00

HaskellとかF#の案件がperlとかCとかJavaの案件以上にないと主流とは言えません

340 ：デフォルトの名無しさん：2009/03/06(金) 13:00:40

Haskellにもclassあるけどな。

341 ：デフォルトの名無しさん：2009/03/06(金) 13:03:02

340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。

342 ：デフォルトの名無しさん：2009/03/06(金) 13:03:53

340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。

343 ：デフォルトの名無しさん：2009/03/06(金) 13:04:55

340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。

344 ：デフォルトの名無しさん：2009/03/06(金) 13:07:07

>>340
なんという釣りｗ

345 ：デフォルトの名無しさん：2009/03/06(金) 13:26:19

ん？haskellにもtype classがあるだろ。class typeじゃないけどw

346 ：デフォルトの名無しさん：2009/03/06(金) 13:49:29

世の中の案件が全て消えてなくなればデジドカも消滅するしOOPも要らなくなる

347 ：デフォルトの名無しさん：2009/03/06(金) 13:59:38

プログラミング系の学校では、OOはどのくらいの行程で勉強し始めるのかな
学校ではやはりOOは重要みたいな教え方なんだろうか

348 ：デフォルトの名無しさん：2009/03/06(金) 14:01:41

わんわんにゃーにゃー共通化
名詞抽出
デザパタを覚えてそれを雛形にして当てはめましょう

349 ：デフォルトの名無しさん：2009/03/06(金) 14:02:13

>>347
それどころじゃない。
教科書（それも低レベル過ぎるやつ）
を入力させて教えた気になってる。
●馬の高●にある●ューティーの隣。

350 ：デフォルトの名無しさん：2009/03/06(金) 14:10:23

また言語論争か
OOは言語とは関係ないとあれほど

351 ：デフォルトの名無しさん：2009/03/06(金) 14:33:33

>>350
関係ないわけがない。
オブジェクト指向でプログラミングするために作られた言語はオブジェクト指向でプログラミングしたほうが自然にかける。
○○するために作られた言語は○○につかうのが一番自然なんだよ。
当たり前のこと。

352 ：デフォルトの名無しさん：2009/03/06(金) 14:37:11

人の作った「当たり前」は疑うべし

353 ：デフォルトの名無しさん：2009/03/06(金) 14:38:56

当たり前のことが出来ない言語は出来損ないの言語

354 ：デフォルトの名無しさん：2009/03/06(金) 15:14:31

プログラマとかってガンダムOOみても
「あ、オブジェクト指向」とか反射的に思っちゃうわけ？

355 ：デフォルトの名無しさん：2009/03/06(金) 15:16:34

javaやrubyなんて明かに意識して作られてるし
C++は斜め上だけど

356 ：デフォルトの名無しさん：2009/03/06(金) 15:17:20

C++だって20年くらい前はCにクラスがついただけのような素朴な言語だったぞ。

357 ：デフォルトの名無しさん：2009/03/06(金) 15:40:48

おれもはじめは「オブジェクト指向」ってヤツになかなか慣れなかった。
Ｃ言語にまだ「プロトタイプ」やら「void」が無かったころの人間なんで・・・

「オブジェクト指向」の何が嫌いかって、それはだな、
他人の書いたソースコードを追いかけるのに、上を見たり下を見たり
あっちこっち飛ばなきゃならんってこと。
プリンター用紙に印刷して赤ペンで印を付けながら卓上デバッグすんだぜ。
すんげ～～～大変だよ。

今はすぐれた統合開発環境ＩＤＥがあるから、キーボードのファンクションキーを押すだけで
ソースコードのあっちこっちへ飛ぶことができて楽に追っかけられるようになったが。
そうでも無けりゃやってられないよ、オブジェクト指向なんて。
言語単体だけじゃダメだ。オブジェクト指向言語は統合開発環境とセットで評価すべき。
そう思た。

358 ：デフォルトの名無しさん：2009/03/06(金) 16:12:03

なんで赤の他人が作った仕様書も残ってないクラスを解析するとか言う
トンデモな世界を当たり前のように語っているんだ？

359 ：デフォルトの名無しさん：2009/03/06(金) 16:14:47

コードが仕様書です（キリッ！！

360 ：デフォルトの名無しさん：2009/03/06(金) 16:41:37

>>357
つ　Smalltalk

361 ：デフォルトの名無しさん：2009/03/06(金) 16:45:37

>>357
それ、手続型でも同じですから。

362 ：デフォルトの名無しさん：2009/03/06(金) 16:47:59

>>358
オブジェクト指向と言いつつ、なんやかんやで
結局、そのクラスがどう言う実装してるかまで追いかけないと、
発生した障害が解決しないんだよね・・・

363 ：デフォルトの名無しさん：2009/03/06(金) 16:52:41

中身を意識させないためのカプセル化(笑なのに見る必要性がでてくるという本末転倒な
せめて明確な事前条件、事後条件、不変条件ぐらいは確立させてドキュメント化しておくべきなんだけど
そういう事に言及している解説書の少ないこと

364 ：デフォルトの名無しさん：2009/03/06(金) 17:22:09

>>362
幸せになりたいなら、他人のコードを追いかけないこと。
多少処理が重複して無駄が出来ても気にするな。

365 ：デフォルトの名無しさん：2009/03/06(金) 18:26:29

いいな、殿様ショウバイは。うらやましいよ。

366 ：デフォルトの名無しさん：2009/03/06(金) 19:20:08

>>357
規模が大きいと自分で書いたものまで分からなくなりますからｗ

367 ：デフォルトの名無しさん：2009/03/06(金) 20:09:28

結局、何で書こうと人間の頭で把握できなくなったらそこで終わりだしね。

368 ：デフォルトの名無しさん：2009/03/06(金) 20:18:59

ここにいる奴に存在するのか聞きたいんだけど、
UML書けない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。

369 ：デフォルトの名無しさん：2009/03/06(金) 20:21:37

ただのお絵かきにご大層な名前つけなくてもいいのに。

370 ：デフォルトの名無しさん：2009/03/06(金) 20:36:50

>>361
というのがまるっきり理解できない莫迦ほど
>>357 みたいなトンチキな批判を繰り返すんでしょ。

371 ：デフォルトの名無しさん：2009/03/06(金) 20:45:16

普通に考えてUMLのかけない奴なんていくらでもいるだろ
描く必要の無い人間の数と同じくらいいる

372 ：デフォルトの名無しさん：2009/03/06(金) 20:48:06

いや、Cは一ヵ所見ればいい。
単純な関数()+1とかでも底が見えないのがC++なのは事実。

373 ：デフォルトの名無しさん：2009/03/06(金) 20:50:10

UMLって別に大げさに考えるほどのものでもないけど、
必要なら描き方を覚えるぐらい誰でも出来るんじゃないの？

374 ：デフォルトの名無しさん：2009/03/06(金) 21:05:17

ここにいる奴に存在するのか聞きたいんだけど、
フローチャート書けない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。

375 ：デフォルトの名無しさん：2009/03/06(金) 21:37:44

>>374
何も見ないでは正確に書けないけど。

四角と矢印ぐらいならかける。

376 ：デフォルトの名無しさん：2009/03/06(金) 21:54:31

ここにいる奴に存在するのか聞きたいんだけど、
風呂に一週間以上入ってない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。

377 ：デフォルトの名無しさん：2009/03/06(金) 21:57:58

オブジェクト指向だけだと、Object-Oriented って形容詞句だから意味が定まらないよね
OOP か OOD か OOA か(まだある?)

378 ：デフォルトの名無しさん：2009/03/06(金) 21:58:56

ここにいる奴に存在するのか聞きたいんだけど、
86系のマシン語すら理解してない奴ってどれくらい居るの？
必要・不必要論は抜きとして。

379 ：デフォルトの名無しさん：2009/03/06(金) 22:00:25

>>1
closureって何なの？

380 ：デフォルトの名無しさん：2009/03/06(金) 22:45:00

>>368
ここにUML書ける奴どころか読める奴すらいないようだな
どいつもこいつも言語の話に終始
UMLでアクティビティやコンポーネントを見た上で、
インターフェースを設計してるなら言語の話なんかする必要ないからな
設計のままクラスとインターフェース作ればいいんだから

381 ：デフォルトの名無しさん：2009/03/06(金) 22:50:37

UMLどころかデザパタすらシラネ

382 ：デフォルトの名無しさん：2009/03/06(金) 22:55:02

ここにいる奴に存在するのか聞きたいんだけど、
Z読み書きできる奴どれくらい居るの？
必要・不必要論は抜きとして。

383 ：デフォルトの名無しさん：2009/03/06(金) 22:57:57

ＵＭＬ書ける出来る、と言ってるヤツの設計のまま作ると、
なぜか>>362とかみたいになるのだよ。

本当にオブジェクト指向で作ると安全で保守しやすいモノが出来るのか？

384 ：デフォルトの名無しさん：2009/03/06(金) 23:22:21

>>380
いや、そんな読めるとか読めないとか低レベルなことを気にしてるのはお前ぐらいのものだろｗ

385 ：デフォルトの名無しさん：2009/03/06(金) 23:25:41

UMLもデザパタも知らないけど>>362みたいにならないから設計の違いだと思われ

386 ：デフォルトの名無しさん：2009/03/06(金) 23:27:28

>>383
それは設計者の能力不足の問題であって、オブジェクト指向の問題ではないよな
オブジェクト指向はプログラマーよりも、むしろ分析者・設計者が学ぶべきことなんだよ

387 ：デフォルトの名無しさん：2009/03/06(金) 23:28:41

>>384
そんな低レベルなことを言われないようにお前はもっと学習しろ

388 ：デフォルトの名無しさん：2009/03/06(金) 23:48:01

カプセル化を今日Wikipediaみて再理解した
で、どうも府に落ちないことがあって、カプセル化と抽象化の違いをうまく説明できない
だれか恐ろしくわかりやすく文章化できるやついる？

389 ：デフォルトの名無しさん：2009/03/06(金) 23:50:57

抽象化＝インターフェース抽出
カプセル化＝利用する側から見えないこと

390 ：デフォルトの名無しさん：2009/03/07(土) 00:12:55

>>378
別に理解はしてないな。
マニュアル見れば使えはするが。

391 ：デフォルトの名無しさん：2009/03/07(土) 00:13:25

ここにいる奴に存在するのか聞きたいんだけど、
地図が読めない奴ってどれぐらいいるの？
たとえば、この記号。ちゃんとわかる？

　　　　＼　　　　　　　　　／
　　　　　＼＿　　|　　　＿／
　　　　　　　　彡彡彡
　　　　　　　　ミミミミ
　　　　　　　　ﾐﾐﾐﾐ
　　　　　　　　ﾉ　σ ヽ
　　　　　　　／　/ ﾟヽ　ヽ
　　　　　／　／／＼＼　＼　
　　　　　　　（　( 　　 ) .)
　　　　　＼　＼＼／／　／
　　　　　　　`　＼／　　'
＼　　　　　　　　＊←──この記号
　＼＿＿＿＿_／＼＿＿＿＿_／

392 ：デフォルトの名無しさん：2009/03/07(土) 00:16:19

結局は機械語で書くのが一番

393 ：オブジェクト指向神：2009/03/07(土) 00:18:52

次代のポストコボラの諸君
せいぜい頑張って我を信奉するがいい

394 ：デフォルトの名無しさん：2009/03/07(土) 00:22:33

気象予報士って13歳でも受かるんだな

395 ：デフォルトの名無しさん：2009/03/07(土) 00:38:49

JavaでOOPしようとするのは、Windowsのメモ帳つかってプログラミングするくらい頭悪いわけだよ
なんでプリミティブ型があるんだよバカだろ
オートボクシングは便利だけど、本来それ自体が必要ないものなんだ
どんだけJavaが糞なのかみんなもっと理解すべき
その面倒な分だけスキルが上がった奴もいるのだろうけど、それ以上に糞コードが蔓延して、たくさんの人間が不幸になったわけだ

さっさと純粋OOPLが政治的、ビジネス的に普及してくれれば全部解決だろjk

396 ：デフォルトの名無しさん：2009/03/07(土) 00:42:15

業務系やオープン系のような「仕事」のプログラミングだと
結局保守性の良いコードってのは
value class と strategy に分ける形式になっていく気がするんだが、

それならオブジェクト指向でなくていいんじゃねーの？っていう。

397 ：デフォルトの名無しさん：2009/03/07(土) 00:47:32

オブジェクト指向とかあんまり関係なくてさ、
要は情報隠蔽してインタフェース駆動のプログラミングをしましょう
ってだけじゃね？

private な field と public な accessor を分けることで value class の情報隠蔽を実現して、
interface と implement を分けることで strategy の情報隠蔽を実現する
だけでいいんじゃないのかと。
データと振る舞いを一緒にカプセル化するっていうのは、
発想として面白いけど正直プログラミングモデルとしては複雑性を増してるだけな気がする

398 ：デフォルトの名無しさん：2009/03/07(土) 00:48:21

ここにいる奴に存在するのか聞きたいんだけど、
いちいち他人様を馬鹿にしないと気がすまない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。

399 ：デフォルトの名無しさん：2009/03/07(土) 00:51:00

オブジェクト志向をいっさいつかわないということは1クラスに10万行くらい書いて納品するということ？
分担作業やりづれーよ
ていうかムリ

400 ：デフォルトの名無しさん：2009/03/07(土) 00:53:09

例えばJavaなら全部ユーティリティクラスにしてpublic staticなメソッド
だけで書けば分担作業出来るじゃん。

401 ：デフォルトの名無しさん：2009/03/07(土) 00:57:35

>>397
振る舞いを含めないのなら、カプセル化する意味ないんしゃない？
つまりゲッターとセッターの存在理由がないじゃん
コード量を5倍に増やしてるだけ
Step数的に必要？w

402 ：デフォルトの名無しさん：2009/03/07(土) 01:32:33

strategyパターンって何？それなんて高階関数？

403 ：デフォルトの名無しさん：2009/03/07(土) 06:58:47

>>395
Integer.toString(5);
とか馬鹿すぎ糞すぎアホ過ぎ

404 ：デフォルトの名無しさん：2009/03/07(土) 10:45:21

>>388
カプセル化　＝　抽象化

405 ：デフォルトの名無しさん：2009/03/07(土) 11:10:10

>>404
氏ね

406 ：デフォルトの名無しさん：2009/03/07(土) 11:38:40

>>404
カプセル化　＝　英語表音を取り入れたハイカラな呼び方
抽象化　＝　漢語表記にした東アジア的呼び方

407 ：デフォルトの名無しさん：2009/03/07(土) 13:26:57

カプセル化　＝　データ抽象　＝　抽象データ型　＝　ユーザーによるデータ型定義

408 ：デフォルトの名無しさん：2009/03/07(土) 14:23:42

>>404
抽象はAbstractionの訳として用いられるから、
カプセル化と抽象化をイコールで結ぶのは違和感がある。

409 ：デフォルトの名無しさん：2009/03/07(土) 14:25:57

カプセル化と抽象化は直交する概念だろ

410 ：デフォルトの名無しさん：2009/03/07(土) 14:55:55

カプセルか・・・
カプセルか・・・
カプセル怪獣！

411 ：デフォルトの名無しさん：2009/03/07(土) 15:02:16

カプセル化＝インタフェースとその実装との関係での話。
抽象化＝インタフェース設計での話。

412 ：デフォルトの名無しさん：2009/03/07(土) 15:10:06

抽象化　＝　いくつかの事物に共通なものを抜き出して、それを一般化して考えること
カプセル化　＝　要約化, 簡約化すること

413 ：デフォルトの名無しさん：2009/03/07(土) 16:02:31

なんでもかんでもクラスにしようとする香具師は死ねばいいのに

414 ：デフォルトの名無しさん：2009/03/07(土) 16:30:23

カプセル化の目的は抽象化だけではないし、
抽象化はカプセル化以外にもたくさんある。

415 ：デフォルトの名無しさん：2009/03/07(土) 16:31:42

[1] 授業単元：オブジェクト指向講座
[2] 問題文(含コード&リンク)：
1から9までの数字を縦横方向に同じものが並ばないように下記の例のように並べる
並べ方が全部で何通りあるかとその並びをすべて列挙する
[3] 環境：オブジェクト指向で解決すること
[4] 期限：明日まで
[5] その他の制限：
例
534681297
685293714
948367125
153472869
426538971
261759483
817945632
379126548
792814356

416 ：デフォルトの名無しさん：2009/03/07(土) 16:40:23

はいはい未解決未解決

417 ：デフォルトの名無しさん：2009/03/07(土) 17:10:01

私は素人なんですが、一言。

プロの人でもよく分かってないことが多いのなら、
ホビイストとか日曜プログラマと呼ばれる層にとっては
OOは邪魔なだけになりやすいですよね？

昨今はオブジェクト指向じゃないと自然に書けない・・・というか
オブジェクト指向を半ば強要するような仕様の言語が多いですけど、
ダイクストラ流の構造化だけしか要求しない言語だったら、
「HSPも中途半端にしかできない」、「シェルスクリプトしか組めない」、
「わしは昔BASICで色んなもんを作ったんじゃよ」なんていう
素人でもそれなりの物を作れるはずです。

ところが、今日では計算機技術全般がプロ用になってしまっているため
ワードやエクセルで適当にやってみて、それでダメだとすぐ自力解決を諦めてしまう。
その結果、そのまま泣き寝入りするか、プロに無駄金払う人が増えています。
やろうと思えば自分でできるはずのことだったとしても。

418 ：デフォルトの名無しさん：2009/03/07(土) 17:15:41

オブジェクト思考は天才

オブジェクト思考は天才

419 ：デフォルトの名無しさん：2009/03/07(土) 17:16:57

>>417
> プロの人でもよく分かってないことが多いのなら、
> ホビイストとか日曜プログラマと呼ばれる層にとっては
> OOは邪魔なだけになりやすいですよね？

あなたはプロで、現場のことを良く知っている、という前提ですか？
それともソースは2chだけというにわかさんですか？
後者なら、2chでオブジェクト指向がよく分からないと発言している人が素人だと私は言いますよ。

420 ：417：2009/03/07(土) 17:18:09

さらに言いますと、
プロの方にとってもOOが弊害になる場合が多々あるのではありませんか？
私の社内にいる情報系の人がC++で作ったプログラムを見て、
「何でこの程度のことをC++で書くんだろうか？」と疑問に思ってしまいました。

黙っている方が賢明だったかもしれませんが、見るに見かねて無駄を指摘し、
目の前でそのプログラムと同じことを、Bashの一行野郎でやってみせたら不機嫌そうでした。

何でもOOでやるのが当たり前、と考えるのは簡単なことを複雑にし、
普通の人の自己解決を妨げると同時に、プロにまで無駄を強いるのではありませんか？

421 ：デフォルトの名無しさん：2009/03/07(土) 17:19:56

>>419
いえ、OOが悪いと言ってるんじゃないですよ。
ただ、時と場合によるはずなのに、
「OOこそ専ら正義」であり、「それができない者もしくは好まない者は
プログラミングから排除されて当然」という風潮が変だと申し上げているだけです。

422 ：デフォルトの名無しさん：2009/03/07(土) 17:26:48

> 「それができない者もしくは好まない者は
> プログラミングから排除されて当然」という風潮

プログラミングから排除ってｗ　そんな風潮あるの？

申し上げましょうか。
OOPのメリットを知るには非OOPの苦痛を知らなければなりません。
そのためには、非OOPの業務経験が必要だと考えられます。

OOPがいつでも役立つなどと言うものは、
おそらくOOPを理解していません。

同時に、OOPを理解するものは、
OOPを理解しないものを排除したりはしないでしょうが、
代わりに、経験不足を見て取ります。

423 ：デフォルトの名無しさん：2009/03/07(土) 17:31:29

>>413だけど、

> OOPがいつでも役立つなどと言うものは、
> おそらくOOPを理解していません。
激しく同意
ほんと死ねばいいのにね

424 ：デフォルトの名無しさん：2009/03/07(土) 17:50:34

>>421
とりあえずOOPとOODやOOAは区別して話すべきだと思うけど。

OOPに関しては、開発インフラと言うのも無視できないと思う。

例えば案件がJavaでのWebアプリ開発だったとして、Javaという
言語はもちろん周辺のライブラリやフレームワークも一応OOPに
乗っ取ったデザインになっている。
結果として開発するにしてもOOPの流儀に則るのが一番楽だし、
そこを無理に外すとかえって大変だったりあとから保守する人が
面倒を被ったりする。

イチからスクラッチで開発するのならともかく、実際はそうした既存
のライブラリやフレームワークといったインフラの上で開発する場合
も多いのだから、こうしたインフラが現在ますますOOPに基づいて
整備されている以上OOPを理解しないと仕事では辛くなるのでは？
と思う事はあります。

425 ：デフォルトの名無しさん：2009/03/07(土) 17:52:10

>>422
たまたま私の周りにいる人たちが変なだけかも知れませんね。
私の会社は医療サービス業なので、直接的にはプログラミングと関係ありません。
しかし、今時いかなる業種であろうともコンピュータと無縁ということは許されませんので、
いわゆるプログラマやシステムエンジニアと呼ばれる人々ともある程度関わらざるを得ないわけです。

現場サイドだけで使うCSV形式のデータベースを処理するごく簡単なシステムを
社内の情報系職員に依頼したら、「できません」と断られました。
開発に手間がかかりすぎるので外部に依頼すべきというのです。
ようするに面倒くさいから逃げただけなのでしょう。
で、とある業者に見積りを出させたら、開発に十数万円、保守が月数千円ということでした。
バカらしくなってしまったので、WindowsのインストールされたPCに
GNU BashとGawkを入れて、自分で作りました。
本当はUNIXやLinuxでやるほうがスマートなのですが、社内になかったので・・・

私はプログラミングなんてできませんが、たまたまシェルスクリプトをかじったことがあるので
こんな方法で解決できましたが、そうでなければプロにボッタくられるところでした。
大規模なプログラムを設計するには便利な技術であろうとも、それをあらゆる場面で強要するのは
我々普通の人にとって迷惑でしかありません。
いや、迷惑をかけられていることすら気づかずに、本当は自己解決できる程度のことに
大金を払い、感謝すらするのです。

426 ：デフォルトの名無しさん：2009/03/07(土) 17:57:39

でっかい釣り針が何本もみえるスレだなw

>>425 なんてオブジェクト指向となんの関係もない話じゃん。あほくさ。

427 ：デフォルトの名無しさん：2009/03/07(土) 18:05:49

>>425
自分で出来る事をプロに頼むのが間違い

証明写真をプロに撮って貰うのか、3分間写真で撮るのかってのと同じ問題だ

428 ：デフォルトの名無しさん：2009/03/07(土) 18:06:10

ぼくはぷろぐらむがかけるんだぞ
そとにいたくしたらなんじゅうまんえんもするしごとができるんだぞ
すごいでしょ
ほめてよ

あっそ

429 ：デフォルトの名無しさん：2009/03/07(土) 18:06:13

「クラスのオブジェクトのプロパティがメソッドでインスタンスだからぁ～
ポリモーフィズムのインヘリタンスがカプセル化でぇ～」
とか語ってる暇があったら、非OO言語でゴリゴリ書いたほうがマシなことは沢山あるけどな。

素人さんたちが、それすらやらなくなったのは確かに退化だと思う。
その原因の一つが「プログラミングは普通の人には難しすぎる」という刷り込みで、
さらにその原因の一つがオブジェクト指向なのは間違えてないだろう。

だからと言ってオブジェクト指向を目の敵にするのは変だけどな。

430 ：デフォルトの名無しさん：2009/03/07(土) 18:25:51

>>425
というかCSV形式のデータをゴリゴリやるのに今更awkというチョイスが
よく判らない。趣味？

perlでもpythonでもrubyでも、CSVをComma-Separated Valuesとして
扱ってくれるライブラリを持っている言語を使って書いた方が書く人も
使う人もあとで読まされる人も楽だと思うけど。
別にライブラリだけ使ってその後は手続き的に書いても良いわけだし。

431 ：デフォルトの名無しさん：2009/03/07(土) 18:30:34

BASICだろうがCだろうがコードを書いてる間に関数レベルで抽象化はするし
どうせ、抽象化するならオブジェクト指向に対応した言語を使ったほうが楽じゃん

432 ：デフォルトの名無しさん：2009/03/07(土) 18:32:49

なんかちょっとする時はRubyの一択だな。
>>425もcygwin入れてもっとラクしたらいい。

433 ：デフォルトの名無しさん：2009/03/07(土) 18:33:13

>>415
(define (oremove o l)
(if (pair? l)
(if (eq? o (car l))
(cdr l)
(cons (car l) (oremove o (cdr l))))
l))
(define (perm s)
(define n 0)
(define (perml f l y)
(if (pair? l)
(for-each (lambda(x) (perml f (oremove x l) (cons x y))) l)
(f (reverse y))))
(perml (lambda (y) (display (list->string y)) (newline) (set! n (+ n 1))) (string->list s) '())
n)

(perm "123456789")
123456789
123456798
略
987654312
987654321
=>362880

(* 1 2 3 4 5 6 7 8 9)
=>362880

434 ：425：2009/03/07(土) 18:36:47

>>430
それはプロ的な発想でしょう。
私はプログラミングの素養などありません。
単純にコマンド並べて動くものしか理解できません。
だから、他の言語で書いたほうが楽だとおっしゃられても
私には楽ではありません。

後でソースを読む人なんているのでしょうか？
プロとおぼしき人といえば、
別の部署にあてにならないシステム管理者がいるだけです。
私の部署にはプログラムを組める人なんて皆無ですし。

そんな状況でお金をかけずに解決するには、bashとawkくらいしか思いつかなかったんですよ。
awkは古いとお思いでしょうが、perlより覚えることは少なく、単純なプログラムなら
可読性も高いでしょう。
素人にはうってつけではないでしょうか？

435 ：デフォルトの名無しさん：2009/03/07(土) 18:38:29

フレームワークつかっててさ。
えれー使いにくいAPIと、えれー使いやすいAPIってあるじゃん。

そては何でか？ってのを、自分なりに考えてみれば
見えてくるものもあるんじゃないかと。

436 ：デフォルトの名無しさん：2009/03/07(土) 18:42:07

>>434
それはオブジェクト指向だ

437 ：デフォルトの名無しさん：2009/03/07(土) 18:47:43

他人がOOPで書いたプログラムは迷惑で、プログラムを作ってくれる業者はぼったくりで
自分はOOを覚える気はないので目の届く範囲に持ってこないでください
ってこと？何が言いたいの？

438 ：デフォルトの名無しさん：2009/03/07(土) 18:52:23

>>434は自分を基準としてものを考えるな。
別に変なことを言っているとは思わないから。

439 ：デフォルトの名無しさん：2009/03/07(土) 18:59:19

>>434
とりあえず総論としては「勉強すれば？」といったところですが。

>それはプロ的な発想でしょう。
でしょうね。実際にCSVをゴリゴリいじった経験のある人は、多分最初に
CSVには色々方言がある事について考えると思います。
単純なパーサーでは読み込めたCSVファイルが、誰かがExcel等の
ツールでちょっと編集した途端に扱えなくなる事は良くある事です。

そういう経験のある人はトラブルの可能性を先読みしてお馬鹿なパーサー
を手作りする前に既存の良い実装を探して再利用すると思います。

>後でソースを読む人なんているのでしょうか？

あなたが退職したり異動した場合は？

>素人にはうってつけではないでしょうか？

今さら感がプンプンです。テキストファイルを切り貼りする程度であれば
学習する手間に大差はないと思います。

個人的な範囲ではsedはともかくawkは使う機会が駆逐されたな～。
ワンライナーもまずはruby、たまにsedぐらいなもので。

440 ：デフォルトの名無しさん：2009/03/07(土) 19:09:33

>>425
その時間に本来あなたがするはずであった業務は誰かが代わりをしてくれたのですか？
そうでなければあなたが自分の業務をさぼった時間で物を作った訳ですから全く評価されません
もしその時間とその成果物に見合うだけの追加費用をあなたが受け取ったのであれば
それはそれで結構なことですがそれは結局業者に払う金額と同じくらいであるべきだとは思いませんか？

441 ：デフォルトの名無しさん：2009/03/07(土) 19:17:52

気象予報士って13歳でも受かるんだな

442 ：デフォルトの名無しさん：2009/03/07(土) 19:29:46

「perlとawkの違い」
perlは簡潔明解で可読性が高い
初心者でも使いこなせる
だから、perlが普及するとプロの仕事が減ってしまう

#!/usr/bin/perl
$\ = "\n";

while (<>) {
chomp;
if (/^hoge.*/) {
print $_;
}
}

--------------------------------

#!/usr/bin/awk -f
/^hoge.*/{ print }

443 ：デフォルトの名無しさん：2009/03/07(土) 19:45:13

#!/usr/bin/awk -f
/^hoge/

444 ：デフォルトの名無しさん：2009/03/07(土) 19:55:57

grep使えって。

445 ：デフォルトの名無しさん：2009/03/07(土) 20:03:08

#!/usr/bin/perl
$\ = "\n";

while (<>) {
($Fld1,$Fld2,$Fld3) = split(' ', $_, -1);
if (/^hoge/) {
print $Fld3;
}
}

--------------------------------

#!/usr/bin/awk -f
/^hoge/{ print $3}

>>444
特定のフィールドを扱う処理だったらgrep使わんでしょ、普通
にしても・・・perlなんてワンライナーで使いたくねぇw

446 ：デフォルトの名無しさん：2009/03/07(土) 20:15:18

#!/usr/bin/perl
$[ = 1;
$, = ' ';
$\ = "\n";

while (<>) {
chomp; # strip record separator
@Fld = split(' ', $_, -1);
for ($i = 1; $i <= $#Fld; $i = $i + 1) {
$sum = $sum + $Fld[$i];
}
}

print $sum;

----------------------------------------

#!/usr/bin/awk -f
{ for (i = 1; i <= NF; i = i + 1) sum = sum + $i }
END{ print sum }

awkに比べてperlのなんとシンプルでエレガントなことかw

447 ：デフォルトの名無しさん：2009/03/07(土) 20:25:23

>>445
>特定のフィールドを扱う処理だったらgrep使わんでしょ、普通

だから>>442の作業だって。これなら何も考えずにgrep使う。

特定のフィールドを使うのであれば自分はruby使う。

ruby -ne 'puts $_.split[2] if $_ =~ /^hoge.*/'

ただ>>442の作業後に特定のフィールドを使いたくなったら、
流れ的にgrepとの合わせ技を使っていると思う。

grep "^hoge.*" | ruby -ne 'puts $_.split[2]'

>>446
ruby -ne 'print $_.split.join'

448 ：デフォルトの名無しさん：2009/03/07(土) 20:35:34

perlのオブジェクト指向の機能って、
無理やりとって付けたような感じで
変態的だよな

449 ：デフォルトの名無しさん：2009/03/07(土) 20:38:18

なんか話がオブジェクト指向から離れてきているようなキガス
まぁ、ワンライナーだったらAWKもありなんじゃね？
古かろうと新しかろうと使える道具が良い道具だから

本題に戻ろう。
昔大量に生息していたBASICオタみたいな種族が減少したのは厳然たる事実。
原因は良いアプリケーションがドッサリあるから、というだけではなさそう。
プログラミングできればそのほうが便利なこと自体、今も昔も変わりないのだから。
プログラミングが難しくなったから、と言えば身も蓋もないが、
バッチファイルすら書こうとしない、もしくは書けないのだらけなのは一体何だろうね？
粘着してたヤシは、よーするにオブジェクト指向のせいだ！って言いたいわけだろ？
さて、実際のところどうなんだろうね。

450 ：デフォルトの名無しさん：2009/03/07(土) 21:43:06

Smalltalk以外のOOは似非OOだろ

451 ：デフォルトの名無しさん：2009/03/07(土) 21:55:45

要するにSmalltalkの話はスレ違いってことか

452 ：デフォルトの名無しさん：2009/03/07(土) 22:09:49

>>448
>perlのオブジェクト指向の機能って、
>無理やりとって付けたような感じで

「感じ」じゃないです
無理やりとって付けたんです

>変態的だよな

「変態的」じゃないです
変態です

453 ：デフォルトの名無しさん：2009/03/07(土) 22:12:53

>>449
１．金にならんから
２．他人にやらせる（利益は自分がとる）
という風潮が広まったせい
プログラミングに限らないよ
世の中全部が（ｒｙ

454 ：デフォルトの名無しさん：2009/03/07(土) 22:23:33

サンデープログラマの人口統計なんてあるのかね。
パソコンユーザー全体に占める「割合」は明らかに小さくなったと思うけど、
絶対数が減ったかというと確信は持てない。

455 ：デフォルトの名無しさん：2009/03/07(土) 22:32:05

>>449
エンドユーザー言語とか簡易言語とかいう言葉があるけど、
実を言うとそんなのは存在していない。
正真正銘のエンドユーザーには使いこなせないものばかりだから。

エンドユーザーにとっての正義とは
1. 覚えることが少ない
2. とりあえず動く
3. 早い
4. 安い
ということだ。

プログラミングの諸技術の発展は、意図するか否かに関わらず
それと矛盾する方向に進んでいる。
その意味ではOOはエンドユーザーを無能化したと言っても間違えていない。

456 ：デフォルトの名無しさん：2009/03/07(土) 22:34:05

確かにOOは覚える価値はありそうだとは思うんだけどな。
最初に良く勉強しないと、良さを生かせないクラスがいっぱい出来て
後で泣く事になりそう。

個人的には、どこまで継承させて書くべきなのか…
別々のクラスとして書くべきなのかが分からん
また、どれをスーパークラスにするべきか・・等

この辺の考え方は、相違がありそう

457 ：デフォルトの名無しさん：2009/03/07(土) 23:12:56

>>456
>最初に良く勉強しないと、良さを生かせないクラスがいっぱい出来て
>後で泣く事になりそう。

OOに限らず大抵のプログラミング技術はこの手のトライアンドエラー
から学ぶ事って少なくないと思う。
実践無しに理論や文法・設計論等々を座学で学んで、いざコードを
書き始めたらいきなりスーパープログラマー、なんて例はあまり見た
事は無い。

458 ：デフォルトの名無しさん：2009/03/07(土) 23:19:10

あまりというか、そんなのはプログラム界の歴史に名が残る級の
真の天才でもなければ不可能じゃないの？

459 ：デフォルトの名無しさん：2009/03/07(土) 23:21:30

>>457
良いこと言うなぁ

高級言語使う限りパソコンが壊れる事なんてないし、適当にやってみるのが一番だよな
アセンブラで適当にやっちゃうとやばいけど...

460 ：デフォルトの名無しさん：2009/03/08(日) 00:33:18

>>459
いやいや、アセンブラで適当にやっても今時のパソコンならOSが守ってくれるぜ。

461 ：デフォルトの名無しさん：2009/03/08(日) 01:22:15

OOをプログラミング技術とか言ってる奴が大杉
OOは設計手法なんだよ

OOPは結局、言語仕様の話で終わるだろ
分析設計は機能分割の旧来手法なのに、
製造はOOPでするからメリットを享受できないんだよ

勘違いしてる奴がいるが、
OOを正しく活用するのであれば、
インターフェースとかクラスは設計段階ですでに決まってるわけで、
製造に入ってから考えるものでは無い

ここを分かってない奴がOOの話題になるとすぐ言語仕様の話をする

462 ：デフォルトの名無しさん：2009/03/08(日) 01:30:32

まーた得意げなお馬鹿さんだな。
わかってない奴ってお前さんのことじゃんw

仮にOOを「設計手法」と呼ぶとして、
どう考えても設計手法もプログラミング技術の一部だろう。

463 ：デフォルトの名無しさん：2009/03/08(日) 01:36:23

確かにOOについて論じるには
高いレベルでの話で考えなきゃならないけど、
実装時のアプローチについての話を完全に無視できるほど高いレベルの概念ではないね

464 ：デフォルトの名無しさん：2009/03/08(日) 01:37:19

>>462
設計手法がプログラミング技術の一部って、どんだけ新入社員だよｗ
それをいうならソフトウエア工学だろｗ

465 ：デフォルトの名無しさん：2009/03/08(日) 01:37:52

っていうか、このスレの意義を否定するようだが（っていってもネタスレだと思うけどw）
かつての構造化プログラミングがそうだったように、オブジェクト指向なんて
具体的実践はともかく概念そのものはたいして難しいわけでも量的に膨大なものでも
なく、普通の知能があれば誰でも理解できる程度のものだから、
あまり熱く語るのも傍目に恥ずかしいぞ。

466 ：デフォルトの名無しさん：2009/03/08(日) 01:39:26

大学生同士の罵りあいはもう見飽きました。
習いたてのことを言いたくてしょうがないのはわかるけど、
いい加減小学生みたいな真似はやめろよ。
もうほとんど大人なんだろ？

467 ：デフォルトの名無しさん：2009/03/08(日) 01:42:05

>>464
そういう無意味な分類学に意味があると錯覚しているのは
君が本質をわかってないからだろう。

まあいいやじゃあ何が「プログラミング技術」で何が「設計手法」で
何が「ソフトウェア工学」か定義できる？

468 ：デフォルトの名無しさん：2009/03/08(日) 01:49:59

>>467
少しは本を読むか調べるかしろ

469 ：デフォルトの名無しさん：2009/03/08(日) 01:53:19

>>468
しょうがない馬鹿だな。
じゃあ読んでしんぜるから具体的に誰の書いたなんて本にそれらが定義されてるの？

470 ：デフォルトの名無しさん：2009/03/08(日) 01:56:58

それなんてゆとり？

471 ：デフォルトの名無しさん：2009/03/08(日) 02:26:54

>>425
> とある業者に見積りを出させたら、開発に十数万円、保守が月数千円ということでした。
まぁまぁ妥当な金額だな。工数としては数人日ってところか。
ぼったくりなんてとんでもない。

472 ：デフォルトの名無しさん：2009/03/08(日) 02:55:42

プログラミングは簡単だろうけど、425の頭の中だけにある必要なシステムというものを
ヒアリングして要件と仕様を確定させてというのが一番時間かかるだろうね。

473 ：デフォルトの名無しさん：2009/03/08(日) 03:06:09

>>472
そんなことに金を取るのか！そんなこと営業活動の中に含まれるだろ！
そんなのに、金を出せるわけないだろ！

・・・何度、客にそんなこと言われて見積りでモメたことか・・・

474 ：デフォルトの名無しさん：2009/03/08(日) 04:45:11

見積り無料という言葉さえあるのに、そういう客がいるんだよねぇ。

475 ：デフォルトの名無しさん：2009/03/08(日) 08:21:13

無料だからってそれをやらずに進めると納品後にもめる罠
客はそれを予め狙ってるのかも知れない

476 ：デフォルトの名無しさん：2009/03/08(日) 09:17:15

そ、曖昧に済ましたところは後でたいてい揉める。全部文書にして残しておかないと結局やらされるはめになる。
しかもタダで。これはつらいよ。頼むほうは自分が理解できて頭の中では簡単だと思ってるから
プログラムも簡単にできると思ってる。あんたの頭の中のことなんか言ってもらわなきゃわかりませんて。

477 ：デフォルトの名無しさん：2009/03/08(日) 10:23:03

>>471
インターネット、メール、ワープロ、表計算以外は全て
「プロの人、お願い！」って時代だ。
エンドユーザ・コンピューティングなんて号令だけで、
実際には全然発展していない。
そこいらの普通のリーマンが「統計処理ならS言語だよね！」とか
「ネットから必要な情報だけを定期的に自動で取得させるシェルスクリプト組まなきゃ」
とか語ってるならエンドユーザ・コンピューティングが十分に浸透していると言える。
でも、現実はそうなってない。

簡単なことは自分でやれば良いのだが、いざとなると
どうやれば良いのか見当がつかず、嫌々業者に頼むことになる。
それで「ぼったくり」と感じる面はあろう。

478 ：デフォルトの名無しさん：2009/03/08(日) 10:23:11

>そんなことに金を取るのか！そんなこと営業活動の中に含まれるだろ！
>そんなのに、金を出せるわけないだろ！

そういう馬鹿は完成した後も金払い悪いんだよな

479 ：デフォルトの名無しさん：2009/03/08(日) 10:27:28

>>477
プロが仕事なくなって困らないように
客を馬鹿のままにしておきたいのが
見え見えですよね

480 ：デフォルトの名無しさん：2009/03/08(日) 10:43:48

道具が便利になるとそれを使うだけの人間のレベルは堕ちていくのは当然
そうならないために道具を不便なままにしておくという選択もあるんだよ

481 ：デフォルトの名無しさん：2009/03/08(日) 10:53:48

ないない

482 ：デフォルトの名無しさん：2009/03/08(日) 11:04:20

MSの場合バージョンアップとかで金とるために
わざと改良をゆっくり進めてるという噂はある

483 ：デフォルトの名無しさん：2009/03/08(日) 11:07:46

うわさっつーかそりゃ彼らのビジネスモデルだろ

484 ：デフォルトの名無しさん：2009/03/08(日) 11:10:05

他所の会社のを朴ってばかり
しかも機能はオリジナルより劣る
稼ぎは一番ウハウハですな

485 ：デフォルトの名無しさん：2009/03/08(日) 11:10:37

>>482
そんな事はない
奴らがやっているのは、十分利用できる旧バージョンをサポートしないという強硬手段で役に立たない新バージョンを売りつけるというビジネスモデルだ

486 ：デフォルトの名無しさん：2009/03/08(日) 11:42:56

時々何のスレか忘れるわ

487 ：デフォルトの名無しさん：2009/03/08(日) 14:35:47

サンデープログラマがOOは糞だというのは、
日曜大工で戸棚をつくってるオヤジが
５０階建ての高層ビルの工法を理解できないからといって
「こんなのは作り方を難しくしているだけだ、ぷんすかぷん」
と喚いているだけだと思えばある意味微笑ましい。

488 ：デフォルトの名無しさん：2009/03/08(日) 14:38:08

そのとおり。それが全て。

489 ：デフォルトの名無しさん：2009/03/08(日) 14:58:05

>>487
Java で開発してる現場で,
「今のニューヨークの時間を求めろ(本当に必要だった)」
って, 言ったら (JST - UTC) + (UTC - EST) の差分しか
考えないアフォが大量にいるんだが…

こんな連中を何とかしてもらえませんかね?

OO 以前の知識がなさすぎwW >現場のアフォども

490 ：,,・´∀｀・,,）っ-○◎●：2009/03/08(日) 15:03:34

>>489
夏時間か。めんどいな

491 ：デフォルトの名無しさん：2009/03/08(日) 15:10:08

Java使ってる時点でお察しください

492 ：デフォルトの名無しさん：2009/03/08(日) 15:16:54

>>489
なんか、いけ好かない野郎臭がする
人を馬鹿にするのなら、人に頼まず自分で作れば良いのでは?

493 ：デフォルトの名無しさん：2009/03/08(日) 15:25:54

>>489
アホなりの解決方法
w3m -dump http://24timezones.com/ja_jikantai/new_york_jikan.php 2>&1 | grep "EST"

494 ：,,・´∀｀・,,）っ-○◎●：2009/03/08(日) 15:31:53

>>493
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

495 ：デフォルトの名無しさん：2009/03/08(日) 15:38:07

プロならググって適切なサンプルコード見つけてコピペするのが基本。
自分で考えて作るなんて素人がやること。
趣味で楽しんでヤルなら、それでいいのだけど、
自分達で考えて作るなんて怖いこと、プロはやっちゃダメ。

プロなら、正しく動くものを組み合わせて、確実に動くものを作る。

それが、オブジェクト指向の極意だろ？

496 ：デフォルトの名無しさん：2009/03/08(日) 15:40:04

仕様は命題でソースコードはその証明っていうのが関数型の極意

497 ：デフォルトの名無しさん：2009/03/08(日) 15:42:23

最後の行で台無し

498 ：デフォルトの名無しさん：2009/03/08(日) 16:07:21

>>495
何?
それは、鶏と卵の話?
コピペ元のサンプルコードは誰が作るの?

499 ：デフォルトの名無しさん：2009/03/08(日) 16:58:33

>>498
言語設計者・ライブラリ開発者・フレームワーク提供者。
その周りのコミュニティ。

なのでドキュメンテーションが半端なライブラリ等はプロジェクトに
持ち込むべきじゃないし、ドキュメンテーション活動が活発なところ
からチョイスした方が楽が出来る。

500 ：デフォルトの名無しさん：2009/03/08(日) 17:37:45

>>499
そんなプログラムの作成法なんて、言うなれば残飯処理じゃん
美味しいところは、全部喰われた後じゃないか

501 ：デフォルトの名無しさん：2009/03/08(日) 17:59:22

>>500
料理人が良い食材を安定して供給してくれる漁師や農家を探すような
もの、と言ってくれ。

釣りや家庭菜園の楽しさは知っているが、それは本業じゃないんだ。

レシピもまずは基本に忠実に、その上での発想の妙だと思うぞ。
創作料理でも本当に美味い料理と単に珍妙な料理があるだろう？

というのは理想論で、大抵は卸された食材をルーティン通りに処理して
供する場末の定食屋である事が大抵な訳だが。

502 ：デフォルトの名無しさん：2009/03/08(日) 18:20:59

>>501
食器工場の作業員と陶芸家ってかwwww

俺だったら、陶芸家を目指したいねぇ

503 ：デフォルトの名無しさん：2009/03/08(日) 18:22:50

> 正しく動くものを組み合わせて、確実に動くものを作る。
確実に動くけど、正しく動くとは限らない罠w

504 ：デフォルトの名無しさん：2009/03/08(日) 18:38:34

>>502
理想は高いけど。厳しいぞ。
一応食器工場の作業員はたいていの人が目指せばなれるし海外に
押されていない限りは一応食える。でも陶芸家人生は、賭でしょ。

あと料理人が市販の素材が不満だとか言って田舎に店を構えて自ら
生産を始めるパターンも多いけど、大抵は品質でもプロの農家には
かなわず、ただ変なプライドや宗教じみた哲学等々がまとわりついた
トンデモ料理店に墜ちるケースが実に多い。

あるいは口八丁で「注文の多い料理店」を目指すところとか。

505 ：デフォルトの名無しさん：2009/03/08(日) 18:46:47

>>504
んなこたぁ判ってる
しかし、それが今の日本のソフトメーカーに足りないところだ

506 ：デフォルトの名無しさん：2009/03/08(日) 20:11:59

この特に分野はソフトウェアを無料だと思ってる
馬鹿の声がでかくなってるから、作業員ですら
まともな報酬を手に入れるのが難しい
陶芸家なんか成立しないよ

507 ：デフォルトの名無しさん：2009/03/08(日) 20:13:57

特にこの

508 ：デフォルトの名無しさん：2009/03/08(日) 20:20:04

>>495
そうやってソフトウェア作成を組み立て工場とみなしてしてしまったことが、
日本のソフトウェア産業が外国に勝てない原因だと思うよ。
組み立て工場の工員が何人集まっても、設計技術を持ってる国には勝てないんだよ。

509 ：デフォルトの名無しさん：2009/03/08(日) 20:27:10

>>490
めんどくも何もない! 何のための zone info だか…

>>492
いけすかんだろうよ.
今回は, コード書かせる側で関わってるんだから

>>496
> 仕様は命題
命題を命題として提出できない設計屋がどれだけ多いんだ?

>>502,504
> 理想は高い
OO を標榜している現場にいないぞ! 特に上の連中

# 去年の夏当りに今年の正月直前に入った閏秒が問題になるシステムの件で
# 「秒の定義を変えればいい!!!」と, のたまわった方もorz

510 ：デフォルトの名無しさん：2009/03/08(日) 20:29:23

要するに構造問題。

ちょっと前に毒吐いていたOOAD屋さんには、是非この構造を
分析してUML等々に落としていただきたい。ネタで。

511 ：デフォルトの名無しさん：2009/03/08(日) 20:34:34

ここむいはんですねわかります

512 ：デフォルトの名無しさん：2009/03/08(日) 20:41:52

あんまり作業量が減った感が無いのは気のせいだろうか？
まあ、GUI扱うのは楽になったが。

513 ：デフォルトの名無しさん：2009/03/08(日) 20:45:02

>>506
そりゃあんた、コピペに金払う奴が何処にいるんだ?

「ソフトはただと思っている連中が」と言うけれど、そんな人たちでも、買わなきゃ行けないソフトは買ってるでしょ

514 ：デフォルトの名無しさん：2009/03/08(日) 20:49:51

>>513
コピペに金払えとは言っていない。
コピペする能力に金払えと言っているんだ。
適切なコピペネタを探し出して取捨選択し、適切な場所に張り付ける。
しかも貼り合わせた周辺とのすりあわせも忘れない。
これはなかなかに高度なスキルだ。

フルスクラッチを有り難がる発想こそ日本人的だと思う。

515 ：デフォルトの名無しさん：2009/03/08(日) 20:49:55

>>512
減ってないと思う。つか、むしろ増えてる。
特に出来の悪いクラスライブラリを与えられた場合…

516 ：デフォルトの名無しさん：2009/03/08(日) 20:50:28

プログラミングは免許制にすべき

517 ：デフォルトの名無しさん：2009/03/08(日) 20:51:23

Javaは言語全体が出来の悪いクラスライブラリ

518 ：デフォルトの名無しさん：2009/03/08(日) 20:53:01

>>516
免許制というか資格制だな
資格独占職種にしないとだめだ

519 ：デフォルトの名無しさん：2009/03/08(日) 20:54:41

「業務独占資格」
だったorz

520 ：デフォルトの名無しさん：2009/03/08(日) 20:57:48

>>514
どんなに出来が良くても、コピペは所詮コピペなんだって

521 ：デフォルトの名無しさん：2009/03/08(日) 21:01:03

>>516
更新が面倒くさそうだなぁ。

おでこにもみじマークを貼り付けておいたら少しは周りも気を
配ってくれるかな？

522 ：デフォルトの名無しさん：2009/03/08(日) 21:03:47

>>519
医師も資格制にする前は下に見られていたが、資格制にしたとたん社会的地位が上がった。

523 ：デフォルトの名無しさん：2009/03/08(日) 21:05:28

>>520
おう。出来が良ければ、万々歳、クライアントも大喜びだ。
発注側もプロに頼むべきコピペとそうでないコピペの区別が
はっきりしていないんじゃないか？
それを一概にコピペだからタダみたいな発想だったら自分で
自分の首を絞めているな。

524 ：デフォルトの名無しさん：2009/03/08(日) 21:08:25

医者だって自分が作ったわけでもない薬を渡して医療行為とか言って金もらってるじゃん。

525 ：デフォルトの名無しさん：2009/03/08(日) 21:08:57

てか医者のほうがやってること簡単だろ。
プログラマだってもっと簡単な仕事で金もらってもいいんじゃね？

526 ：デフォルトの名無しさん：2009/03/08(日) 21:14:41

>>525
ソフトはタダ論と同じ構造だな。自戒を込めて。

外から見ていると中ではどれだけ面倒な事をしているか見えにくい
から思わず簡単だろとかタダでも良いとか考えちゃうんだよ。

実際はそうでもないわけで。

527 ：デフォルトの名無しさん：2009/03/08(日) 21:15:58

>>523
本質が見えてない

コピペで作る事を知っているから、安く買い叩かれるって事だ

528 ：デフォルトの名無しさん：2009/03/08(日) 21:21:29

>サンタフェ鉄道はシステム開発にMAPPERを使った。
>これは4GLを使ったソフトウェアプロトタイピングであり、
>エンドユーザーによるプログラム開発プロジェクトの例である。
>この場合の考え方は、鉄道の専門家にMAPPERの使い方を習得させる方が、
>プログラマに「鉄道操作の複雑な事情」を教えるよりも簡単だ、というものであった。

出典
http://ja.wikipedia.org/wiki/4GL

エンドユーザーが自分である程度やるようになったら
ヘッポコプログラマなんて要らなくなるだろうね。

529 ：デフォルトの名無しさん：2009/03/08(日) 21:25:24

>>526
> 外から見ていると中ではどれだけ面倒な事をしているか見えにくい
それ俺も思うわ
日頃は数式飛びまくりの仕事してるんだけど、たまに EC 系とか手伝うと…
『使ってる側から「めんどくさいからボタンとかやめてコマンド打たせろ」
って言ってくるとか、思んの？』とか………

530 ：デフォルトの名無しさん：2009/03/08(日) 21:30:50

>>528
エンドユーザがやらなくても必要ないと思う >ヘッポコプログラマ

531 ：デフォルトの名無しさん：2009/03/08(日) 21:33:29

>>512
簡単な作業は誰でもできるから、競争力つけるには安く売るしかない。
↓
安い作業で売り上げを増やすには、大量の仕事をこなすしか無い。

ってこと。

532 ：デフォルトの名無しさん：2009/03/08(日) 21:40:41

サンタフェといえば宮沢りえ
当時は衝撃的だった

533 ：デフォルトの名無しさん：2009/03/08(日) 21:41:55

>>528
1980年代から繰り返し言われてきた事だ。
エンドユーザープログラミング技術の死屍累々の歴史を知らないのか。
その結果現状Excelの数式程度しか残らなかった顛末の歴史を。

534 ：デフォルトの名無しさん：2009/03/08(日) 21:45:11

>>533
w3m -dump http://www.media-k.co.jp/jiten/wiki.cgi?%A1%E3%B4%E9%CA%B8%BB%FA%A1%A6%A3%C1%A3%C1%A1%E4#i28 | grep '´_'

535 ：デフォルトの名無しさん：2009/03/08(日) 21:47:28

SUNやMSは自社フレームワークに付随するいろんな作業量を増やして
「このフレームワーク使えるSeは希少価値がありますよ」
と思わせるのが昔からの伝統だからな。
しかくやセミナーで小金を稼ぐのも昔から。

536 ：デフォルトの名無しさん：2009/03/08(日) 21:49:17

>>535
× SUN
〇 CTC

537 ：デフォルトの名無しさん：2009/03/08(日) 22:00:26

足りたとして、それができれば楽になるのか？

538 ：デフォルトの名無しさん：2009/03/08(日) 22:03:04

#!/bin/bash
while :
do
echo '（　´_ゝ`）ﾌｰﾝ'
done

539 ：デフォルトの名無しさん：2009/03/08(日) 22:03:11

使える人間が増える
↓
需要がある(と錯覚する)
↓
価値がある(と錯覚する)

正気ではこんなことできない

540 ：デフォルトの名無しさん：2009/03/08(日) 22:08:59

まぁ、近い将来、昔ながらのソフトウェアの受注開発の形態は、
ビジネスモデルとして崩壊すると思うよ。

541 ：デフォルトの名無しさん：2009/03/08(日) 22:17:37

>>536
その昔, Sun3 全盛時代(Sun3-260とかか？？？)

某大学の研究室で

C「定期メンテに来ました」
D「〇〇、お茶いれてこい」
C 作業を開始しようとする
D「今、止められないプログラムが動いているから、ちょっと待って…」
C 「はぁ、そうですか………」
〇お茶持ってくる
C D 〇世間話をしていると数時間たつ
C 「まだ、終わらないんですか？」
D 「うぅむ、思った以上に時間がかかるな… 今日はもういいからまたにしろ」
C 帰る
D 「〇〇、こうやって奴等には指一本触れさせるんじゃないぞ！」
出演
D: 某大学研究室教授
C: CTC メンテナンスエンジニア

ってな話があったことを〇〇先輩から聞いたのを思い出した

542 ：デフォルトの名無しさん：2009/03/08(日) 23:11:11

>医者だって自分が作ったわけでもない薬を渡して医療行為とか言って金もらってるじゃん。

やべｗｗ
超ツボにはまったｗｗｗｗｗ

543 ：デフォルトの名無しさん：2009/03/08(日) 23:14:06

つまり薬剤師とか調剤師の待遇を改善しろって言ってるってことになるのか？
SIer=医者だとするとSE=薬剤師でPG=看護士なのか？
それとも製薬会社の研究者が一番エロいのか？

544 ：デフォルトの名無しさん：2009/03/08(日) 23:16:59

>>532
漏れ的には菅野美穂

545 ：デフォルトの名無しさん：2009/03/09(月) 00:30:36

>>543
看護士＝システム管理者じゃね？

546 ：デフォルトの名無しさん：2009/03/09(月) 02:21:30

OOから激しく、そして望んで脱線中なお前ら
分からないなら分からないと言え

547 ：デフォルトの名無しさん：2009/03/09(月) 02:43:57

>>524
薬渡すくらい簡単な作業だったらどんだけ楽か・・・
OOにしてそんな簡単に行くならいいんだけどね。

548 ：デフォルトの名無しさん：2009/03/09(月) 09:39:33

わかってるのは自分だけと思いたいやつがいるようだが
別に難しくも無い概念、みんなわかってるよ。
Cのポインタと同じで難しいイメージを浸透させたくて
みんなわかってないフリしてるだけだよな。

549 ：デフォルトの名無しさん：2009/03/09(月) 09:46:32

分かってない奴にありがちな発言。

> 別に難しくも無い概念、みんなわかってるよ。

550 ：a36 ◆K0BqlCB3.k ：2009/03/09(月) 10:16:05

私はオブジェクト指向設計技法がとりわけ大好きというわけでもありませんが、
最新の技術というわけでもないので昔ほど興味を持ってもいません。
ただ、現在ソフトウェア開発の現場にようやく浸透しつつあり、
構造化設計技法よりはマシなので消えてなくなったら困ります。

最近はlambda-calculusあるいはpi-calculusベースの設計技法の研究をする人が増えてきて、
関数型言語がずいぶん幅を利かせつつあります。
少しずつよりよいものにシフトして行けばよいでしょう。
でもまだオブジェクト指向が消えてなくなるべき段階ではないと思いますよ。

551 ：デフォルトの名無しさん：2009/03/09(月) 10:58:11

>>548
みんな分かってると思ってて実は理解していないという現実。
定数定義するためにinterface使ってるようなあほなコードを何度見てきたことか。。

552 ：デフォルトの名無しさん：2009/03/09(月) 18:50:30

変数一つごとにインタフェース用意してクラスにします(＾q＾)

553 ：デフォルトの名無しさん：2009/03/09(月) 19:58:53

まだ残ってた、このスレvwW

>>550
> 構造化設計技法よりはマシなので消えてなくなったら困ります。

何か勘違いしてないか？？？

最低でも、構造化設計技法使えない奴が
OOD 出来るとは思えないんだが…

現状では、
「OO 行けます！デザインでも…」
って言ってる連中って、設計以前のシステム
分析が甘すぎだろ wWW

OO 言語ができる前から、出来のいい C 言語
ライブラリは OO なデザインしてあった

554 ：デフォルトの名無しさん：2009/03/09(月) 22:02:22

>>> 構造化設計技法よりはマシなので

とかいうのは違和感あるね
なにか特定のモノ（例えばNSチャート）をイコール構造化設計技法と
思い込んでるんじゃないかね

555 ：デフォルトの名無しさん：2009/03/09(月) 22:27:32

特に違和感ないけど？
お前らのスキルが足りないだけじゃね？

556 ：デフォルトの名無しさん：2009/03/10(火) 01:57:46

>>550の文脈だとOOは構造化と相反するように見えるが、
もしその通りの意図で書いてるなら>>550の認識には誤りがある。
オブジェクト指向は構造化の一種なんだから。

少なくとも、ラムダ計算（lambda-calculus）などのLISPやHaskellはこのスレに全く関係ない。

557 ：デフォルトの名無しさん：2009/03/10(火) 02:17:15

>>550
>最近はlambda-calculusあるいはpi-calculusベースの設計技法の
>研究をする人が増えてきて、
>関数型言語がずいぶん幅を利かせつつあります。

例えば「pi-calculusベースの設計スゲ～」から関数型言語が流行って
いるのかな。
後者は前者によってドライブされているわけじゃないと思う。

OOADのオルタナティブとなる手法として「lambda-calculusあるいは
pi-calculusベースの設計技法」なるものが研究されているとしても
(良い論文等あればポインタ希望)、自分には未だマイナーだと思うし、
少なくとも昨今関数型言語がはやっている文脈からは随分明後日の
方向だと思う。

とりあえずは関係がイマイチ自明でない関係ないトピックをくっつけた
だけの文章としか読めなかった。

558 ：デフォルトの名無しさん：2009/03/10(火) 08:27:45

>>556
CLOSもスレ違いなのか？
Haskellのtype classは継承もあるけどスレ違い？

559 ：デフォルトの名無しさん：2009/03/10(火) 10:49:57

ウーパールーパーって食えるんだな
ttp://www.fnn-news.com/news/video/wmv/sn2009030908_hd_300.asx

560 ：デフォルトの名無しさん：2009/03/10(火) 15:44:17

ここはOOと関数型の関係について議論するスレじゃないのか。

561 ：デフォルトの名無しさん：2009/03/10(火) 15:48:20

2chで議論なんてできるわけがない

562 ：デフォルトの名無しさん：2009/03/10(火) 17:34:54

俺はけっこう勉強になってるけどな。雑音は全部スルーするけど。

563 ：デフォルトの名無しさん：2009/03/10(火) 19:23:56

ウーパールーパーのヌイグルミ持ってたｗ

564 ：デフォルトの名無しさん：2009/03/10(火) 21:57:08

プログラミング初心者レベルから抜けられない理由
プログラミングが苦手だという人がいる。
その人は、決して理解力が劣っているわけではない。
むしろ、ループや条件分岐、関数の作り方といった、
プログラミング言語の文法に関しては、
普通の人より速く理解できたりする。
入門書の章末に載っていような簡単な練習問題に対しては
ちゃんと正解を出すことができる。
しかし、ある程度の規模があって複雑な処理をするプログラムを書こうとすると、
どこから手を付けていいのか分からず、とたんに手が止まってしまう。
プログラミングの上手な友人に聞いてみると、
「問題を分割すればいいんだよ」と言われるが、
じゃあその「分割」とは一体何を指しているのかが分からない。
お気付きだと思うが、これはちょっと前までの自分の状態だった。
恥ずかしながら、情報系の学科に所属しているのにもかかわらず、
僕はつい最近までプログラミングというものに苦手意識を持っていた。
最近になって、ようやくその苦手意識が薄れてきて、
以前の自分がどんなところでつまづいていたのかが分かりかけてきたので、
まとめておくことにする。それは
「自分が何を分かっていないのかが分かっていない」
ということだ。
言い換えると、「問題そのもの」と「その問題を解く手段」を混同しているということ。

565 ：デフォルトの名無しさん：2009/03/10(火) 21:57:59

もう少し言うなら、
文法
ライブラリの使い方
アルゴリズム
問題そのもの
自分のやりたいこと
の5つのうち、1～3までが「問題を解く手段」で残り2つが「問題そのもの」だ。
特に初心者のうちはこれらがごちゃごちゃに入りくんでいて、混乱してしまいがち。
また、3番目くらいまでの情報はネットにも溢れているけど、
4、5番目あたりをどう整理するかはその場その場で考えるしかない。
問題そのものが分かっていないのか、あるいは問題を解く手法(ライブラリの使い方であったり、
アルゴリズムであったり)を知らないだけなのか、自分の経験を振りかえってみても、
また周りのプログラミングが苦手という人を見ても、これをきっちりと分けることができていないように思う。
プログラミングがどうも苦手だ、という人はこれを常に意識して問題を考えるようにすると、
上達速度が変わるだろう。
以上、初心者++くらいの人間の戯言でした。
ttp://d.hatena.ne.jp/tencube/20080418/1208535514

566 ：デフォルトの名無しさん：2009/03/10(火) 22:01:19

ライトついてますか？

567 ：デフォルトの名無しさん：2009/03/10(火) 22:15:30

問題発見の人間学
ワインバーグ

568 ：デフォルトの名無しさん：2009/03/10(火) 22:48:37

セコムしてますか？

569 ：デフォルトの名無しさん：2009/03/10(火) 23:54:26

本来UTF-8の文字列がCP932として処理されて文字化けしてしまっているのですが
これをオブジェクト指向で元のUTF-8に直すことは出来ますか？

570 ：デフォルトの名無しさん：2009/03/11(水) 00:08:55

>>569
8086 のバイナリを 6800 に食わせたら…
ってのと, 同列の不毛な争いはやめれ

571 ：デフォルトの名無しさん：2009/03/11(水) 00:21:10

ストリームに流し込めばいいんじゃね？

572 ：デフォルトの名無しさん：2009/03/11(水) 07:08:11

なるほど

573 ：デフォルトの名無しさん：2009/03/11(水) 09:07:24

いつになったら世界が１つの文字コードに統一されて、
文字化けがなんたらコード変換がどうのこうのってのに
悩まされないですむようになるのか・・・

574 ：デフォルトの名無しさん：2009/03/11(水) 12:44:40

バベルの塔が破壊される以前は統一されていた

575 ：デフォルトの名無しさん：2009/03/11(水) 13:01:37

自然言語でもエスペラント流行らんしなぁ

576 ：デフォルトの名無しさん：2009/03/11(水) 20:39:17

OO を否定する気はないが, カプセル化前提ってのが…
つか、何で必要なんだ、カプセル化？
結局、カプセル解かないとメンテ出来ねぇのに………

577 ：デフォルトの名無しさん：2009/03/11(水) 20:49:52

>>576
それはお前のとこのインターフェースが腐ってるからだろ
カプセル化が無かったら外部からデータに直接アクセスされてあたりがでかい

こんなことも分からん>>576みたいな奴がデスマ起こして迷惑かけやがる
自分の無知をやつあたりするとか理解できんわ

578 ：デフォルトの名無しさん：2009/03/11(水) 21:02:10

>>577
外部からデータに直接アクセスなんてのは、コーディングしてる現場
の運用だけの問題だろ？

インターフェース以前のモデルが腐ってる場合の方が多いんだが…

与えられた要求を表面的にモデル化してるだけだと、後付け条件が出て
きた時にモデル全体がアボンすることもある

腐ったモデルを、なんとかしようと思ったらカプセル化はじゃま！！！

よくあるんだわ、ユーザの本当にやりたいことを分析せずに、その場で
言われたことだけモデル化してて、「実は違ってました！」ってのがwW

579 ：デフォルトの名無しさん：2009/03/11(水) 21:37:13

>>578
それはメンテナーの設計が下手なだけじゃ？

580 ：デフォルトの名無しさん：2009/03/11(水) 21:48:40

Smalltalk でも Self でも ECMAScript でも、アクセス制限無く OO を表現・実装していますよ。
C++/Java よりは、テストファーストやリファクタリングが広がってる世界だけど。

581 ：デフォルトの名無しさん：2009/03/11(水) 22:35:33

そもそも, C++ とか Java の隠蔽機能なんてたいして訳に立たない

よく言われることだが、デッキとメディアをカプセル化したとして
ヘッドとメディアのインターフェースを公開する必要はないじゃん

C++ あたりだと、「そのためにネームスペースが…」とか言われ
そうだが、本質的にそんな問題じゃねぇだろ

582 ：デフォルトの名無しさん：2009/03/11(水) 22:46:10

「カプセル化を解かないとメンテ出来ない」って既存のクラスに
パッチを当てるのに継承とか使っちゃうって事なんだろうか。

583 ：デフォルトの名無しさん：2009/03/11(水) 22:49:34

オブジェクト指向って別に大して役に立ちませんよね、って言ったら先生に怒られました

584 ：デフォルトの名無しさん：2009/03/11(水) 22:53:33

>581
>よく言われることだが、デッキとメディアをカプセル化したとして
>ヘッドとメディアのインターフェースを公開する必要はないじゃん

聞いたことねえな
デッキ、メディア、ヘッドってなんのことだ？

585 ：デフォルトの名無しさん：2009/03/11(水) 22:57:44

社内の別部署から、業務管理のための小規模なシステムを作ってほしいとの依頼があった。
真面目にOOで設計しプログラミングしてたら、依頼元の奴がシェルスクリプトを使って自力で作りやがった。
「てめーで出来るなら最初から頼むな」と激怒したら
「OOなんか使ってるから遅いんだよ。動きゃいんだから、適当にゴリゴリ書けよ」
と反論されてマジでキレた。
おかげで俺は「素人にも負けるプログラマ」と馬鹿にされ、評価ガタ落ち。

586 ：デフォルトの名無しさん：2009/03/11(水) 23:01:25

>>585
>>425の自演乙

587 ：デフォルトの名無しさん：2009/03/11(水) 23:03:58

>>581
カセットテープの事か?
カセットテープの事を言ってるのか?

年寄りめ...(判る俺も年寄りか...orz)

588 ：デフォルトの名無しさん：2009/03/11(水) 23:05:36

>>585
それってOOPへのあてつけ？
OOPを責めるのは筋違いってもんだ

589 ：デフォルトの名無しさん：2009/03/11(水) 23:14:19

よく言われることだが（笑）

590 ：デフォルトの名無しさん：2009/03/11(水) 23:26:57

OOさえなければこんな仕事とっくに終わってるのに、
と思うことはあるな。

591 ：,,・´∀｀・,,）っ-○◎●：2009/03/11(水) 23:29:18

Railsは普通に生産性高いし

C++が泥臭すぎるんじゃね？
俺はどっちも好きだけど

592 ：デフォルトの名無しさん：2009/03/11(水) 23:35:09

自分ができないことをＯＯにやつあたり

593 ：デフォルトの名無しさん：2009/03/11(水) 23:52:19

そこでpythonですよ

594 ：デフォルトの名無しさん：2009/03/12(木) 00:53:00

OOに限らず、きれいな設計で作ろうとすると初動がのろくなってしまうのは仕方ない。
一度作ってしまえばあとは修正なども楽なんだが。

595 ：デフォルトの名無しさん：2009/03/12(木) 01:36:26

>>594
と、宣伝してはいますが、嘘です。

596 ：デフォルトの名無しさん：2009/03/12(木) 01:55:14

設計がどれくらい修正を想定してるか、ってのに依存する話なんだよね。
想定外の仕様変更が来ると全然ダメで、結局一から作り直しになったりする。

ほとんど変更前と同じコードを一通り書き直してると、OOPって再利用性低いな、とか感じる。

597 ：デフォルトの名無しさん：2009/03/12(木) 03:00:35

>>540
昔ながらのソフトウェアの受注開発形態って具体的にどういうヤツ？

598 ：デフォルトの名無しさん：2009/03/12(木) 03:18:44

再利用性で言うなら関数を値として扱える関数型言語のほうがはるかに再利用性の高い関数が作れるよね

599 ：デフォルトの名無しさん：2009/03/12(木) 03:58:12

何で？

600 ：デフォルトの名無しさん：2009/03/12(木) 08:01:06

>>596
それ、おまえがヘッポコなだけ。
OOに文句を言うのは、リファクタリングツールを自作するぐらいしてからにしろ。

601 ：デフォルトの名無しさん：2009/03/12(木) 13:54:52

class hoge{
int i;
public:
int getI(){ return i; }
setI(int n) { i = n; }
}

こういうのってiをpublicにしちゃダメなの？
隠す意味がわからない。

602 ：デフォルトの名無しさん：2009/03/12(木) 14:04:21

別にオブジェクト指向ならではというわけではないけれど、
関数に閉じ込めておけば、値の範囲を確認したり、
void setI(int n)
{
if (n < 0 || n > 1000)
throw std::out_of_range("hoge::setl");
i = n;
}
後の実装の変更の影響を最小限に留めたりできるというのが一般論。
class hoge {
foo f;
public:
int getI() { return f.getI(){; }
setI(int n) { f.setI(n); }
}

603 ：デフォルトの名無しさん：2009/03/12(木) 14:07:23

まぁ、殆どの場合杞憂に終わるし、リファクタリングツールも有るしで
なんだかなぁでは有るが、よそのライブラリがプロパティには対応してるけど
フィールドには対応してないとか最近ありがち。

604 ：デフォルトの名無しさん：2009/03/12(木) 15:39:29

実用的な効能としては、デバッグが楽になる。
セットしてる値をログに吐き出したり、デバッガでブレークポイント張ったりとかできるので。

605 ：デフォルトの名無しさん：2009/03/12(木) 15:59:57

>>596
アプリケーションロジック全部書き直しというような無茶な仕様変更が
きたとしても、ロジック部以外の周辺コードはたいてい使いまわしが
効くだろ。

606 ：デフォルトの名無しさん：2009/03/12(木) 16:06:38

特殊な理由かも知れないけど、一般的にフィールド値をpublicに
してしまうとそのクラスをスレッドセーフにするのが難しくなる。

607 ：デフォルトの名無しさん：2009/03/12(木) 17:04:59

あたりまえ。
javaならpublic finalとかすればいい

608 ：デフォルトの名無しさん：2009/03/12(木) 17:39:53

またOOが分からない連中による言語仕様論争がはじまった

609 ：デフォルトの名無しさん：2009/03/12(木) 19:43:36

またOOごときでプログラミングをマスターした気になっている奴が来た

610 ：デフォルトの名無しさん：2009/03/12(木) 19:47:07

どでもいいけど,
「Smalltalk とか CLOS とかの OO とC++ とか Java とかやってる
連中の OO ってのは, 言語じゃなくて、Object の捉え方が違う
ので, 同じ土俵で語っても仕方がない」
ってな事は理解できた

611 ：デフォルトの名無しさん：2009/03/12(木) 19:48:25

基本的にImmutableにすればいいよ

612 ：デフォルトの名無しさん：2009/03/12(木) 19:57:48

本物のオブジェクト指向でスゴイはずなのに、
まったく流行らないSmalltalk・・・なんで？

613 ：デフォルトの名無しさん：2009/03/12(木) 20:08:14

>>612
そこらのエンジニアとかプログラマが、
手続き型言語から抜け出せないから

614 ：デフォルトの名無しさん：2009/03/12(木) 20:19:56

OOが普及してからお手軽言語が少なくなった。
PerlやらRubyやらPythonやらがあるではないか、という声も聞こえてきそうだが
その程度で解決するほど生易しい問題ではない。

簡単に試して簡単に結果を得られる、そんな恩恵を広範なエンドユーザーが受けられる言語なんてほとんどない。
要求される学習量が大きくなることで、エンドユーザーはプログラミングを諦め、
PCはアプリを走らせるだけの道具としての意味しかなくなる。
いわばPCのWii化、プレステ化だ。

ニョキニョキとスクリプト言語・簡易言語が出ては消えて行くが、最近ではそれら全てがOO実装で、
それがエンドユーザー・コンピューティングの障害となっている。
やはり、言語もプロ用だけでなく、プロアマの別なく使えるものが必要なのだが、
道具としての言語を作る側がプロであるために、「今時の言語ならOOは当然」ということになってしまう。
エンドユーザー言語なら用途は広くなくていい。
言語と呼ぶのも恥ずかしいほど単純なもの、プログラマブルなツール程度でいいのだ。

OOが有用な道具であることは疑う余地もない。
だが、OOの本当の問題点はその押し付けがましさにあるのだ。
あらゆる言語、あらゆるプログラムをOOの色に染めようなどという陰謀は潰さなければならない。

615 ：デフォルトの名無しさん：2009/03/12(木) 20:21:05

>>613
smalltalkも手続き型言語じゃん

616 ：デフォルトの名無しさん：2009/03/12(木) 20:21:46

>>614
君、カラオケではマイク握って話さないタイプでしょ？w
自己陶酔型って奴だな

617 ：デフォルトの名無しさん：2009/03/12(木) 20:24:04

>>614
>ニョキニョキとスクリプト言語・簡易言語が出ては消えて行くが、最近ではそれら全てがOO実装で、
>それがエンドユーザー・コンピューティングの障害となっている。
たいていの言語はオブジェクト指向でプログラミングしなくても良いようになっているはずだよ。
(クラスを使うことがオブジェクト指向プログラミングではない)

618 ：デフォルトの名無しさん：2009/03/12(木) 20:29:45

>>617
UNIXのシェルや昔のROM BASICみたいに、「電源入れれば顔なじみ」で
「興味に任せてコマンド打てば何となく動く」環境ではないことも関係あるだろう。
だが、OOの影響は否定できない。
OO実装の言語の入門書のほとんどはOOについて触れている。
「読み飛ばせばいい」というのは簡単だが、エンドユーザーにその判断をするのは難しい。
また、OOらしくないプログラミングだけをしたとしても、端々にOOの影響がにじみ出る。
OOに適した言語で無理やり非OOをするのは、エンドユーザーには難しいのだ。

619 ：デフォルトの名無しさん：2009/03/12(木) 20:30:31

>>614
シェルスクリプトでいいやん。
Windows的にはバッチファイル？

それに、コンピュータをネットワークの向こうに追いやろうって言ってるのに
エンドユーザコンピューティングなんて今更はやらないし。

620 ：デフォルトの名無しさん：2009/03/12(木) 20:34:42

>>619
winのバッチ。
ありゃダメだろ。
貧相過ぎる。

俺はあれでアドベンチャーゲームやアクセスカウンター作って遊んだことがあるけどな。
単なる暇つぶしとして。

621 ：デフォルトの名無しさん：2009/03/12(木) 20:34:55

OOなんてそのへんのものに指示を与えればいいだけやん。
どこが難しいんかわからん。
昔プログラミングとかかじっとったおっちゃんが
「最近のプログラミングはややこしい」って言ってるだけにしか見えん。

622 ：デフォルトの名無しさん：2009/03/12(木) 20:38:58

>>621
今の人ならOOのほうが理解しやすいかどうか。
おそらくNOだろうな。

おっちゃん「最近のプログラミングはややこしい」
若者「クラスのオブジェクトにプロパティーとメッソッドが・・とか言ってんの、ウゼー」

こういうことになるだけ。

623 ：デフォルトの名無しさん：2009/03/12(木) 20:43:03

> 言語と呼ぶのも恥ずかしいほど単純なもの、プログラマブルなツール程度
仕事ならVBA、遊びならHSPでFA

異論は認める

624 ：デフォルトの名無しさん：2009/03/12(木) 20:49:08

>>615
イマイチ手続き型じゃないんだよな
関数型でもないんだけど…

625 ：デフォルトの名無しさん：2009/03/12(木) 20:49:52

>>622
原始人がマンモスを狩るのに、石ぶつけて殺せばいいじゃん、槍なんか作るのめんどくせぇ、
と言っているの似ているね。

626 ：デフォルトの名無しさん：2009/03/12(木) 20:50:37

エンドユーザ・プログラミングの普及率は
UNIX >= Linux > Windows
だろうね。

同じ「エンドユーザー」と呼ばれる人々でも、UNIXやLinuxのほうがWindowsよりも
平均してハイレベルだから。
勤勉な人はシェルスクリプト程度でも使わないより使った方が
比較にならないほど便利であることを知っている。
労力を惜しまなければTeXのほうがWordよりも美しく仕上げられることを理解している。

愚者ほど「便利」という言葉を「学習しなくても直感的に使えること」と定義したがる。

627 ：デフォルトの名無しさん：2009/03/12(木) 20:55:51

>>625
そりゃ極端だ。

パンクしたら自分で修理。
壁に棚を取り付ける。
ふすまの張替え。

そういったことすら自分でできなかったら不便だろ。
それと同じこと。

プレストレストコンクリートがどうだとか、そんなことは知らなくてもいいが
日常を便利にする技術は必要だ。
PCの世界ではそれすら廃れているから困る。

628 ：デフォルトの名無しさん：2009/03/12(木) 20:57:05

手続き型が好きな人は昔のBASICをGOSUB無しで使えばいいんじゃね？
OOに留まらず構造化チックな事は一切出来なくなるぞ。
FOR文ぐらいは使うのは許してあげる。

629 ：デフォルトの名無しさん：2009/03/12(木) 21:03:36

関数使おうが手続きは手続き

630 ：デフォルトの名無しさん：2009/03/12(木) 21:03:54

手続き型と構造化っていつから矛盾する概念になったの？

631 ：デフォルトの名無しさん：2009/03/12(木) 21:04:31

>>628
OO も普通に立派に手続き型なんだがwWW
Java/C++ 関数をデータとして使えないので屑
C++0x で lambda が全うに使えるようになったら
し腰だけ認めて上げよう >C++

632 ：デフォルトの名無しさん：2009/03/12(木) 21:05:00

手続き型言語って破壊的代入を許す言語のことじゃないの？

633 ：デフォルトの名無しさん：2009/03/12(木) 21:05:55

>>631
〇し腰だけ認めて上げよう >C++
× 少しだけ認めて上げよう >C++

634 ：デフォルトの名無しさん：2009/03/12(木) 21:08:00

>>632
一番でかいのは関数をデータとして扱えないところだと思う

635 ：デフォルトの名無しさん：2009/03/12(木) 21:11:20

>>634
ファーストクラスファンクションを認める言語でも破壊的代入(あるいは副作用)がある言語はいくらでもあるよ。

636 ：デフォルトの名無しさん：2009/03/12(木) 21:15:11

オブジェクト指向はオブジェクトとオブジェクトの通信によって成り立つものだよね。
それを包含する概念っていえばpi-calculusだね。

637 ：デフォルトの名無しさん：2009/03/12(木) 21:17:23

オブジェクト指向をもっと一般的に捉らえるべきじゃない？
それがオブジェクト指向の次の段階だと思う。
その一つの選択肢としてpi-calculusというのがあるわけで。

638 ：デフォルトの名無しさん：2009/03/12(木) 21:19:02

>>635
そだよ！つか、そこまでピュアな関数言語ってそんなにないし…

どこのクラスから使われるかも知れないけど、この引数をもった関数を
渡したい場合は山ほどあるし、その関数が引数見てディスパッチしてく
れたら、幸せになれる局面はたくさんあるんだが…

そんなことすら出来ない、C++[1]/Java は屑

[1] ここで boost の lamda 出さないように

639 ：デフォルトの名無しさん：2009/03/12(木) 21:20:08

boostのlambdaって偽lambdaじゃん。

640 ：デフォルトの名無しさん：2009/03/12(木) 21:23:24

先生、C++0xのラムダは挙げていいですか？

641 ：デフォルトの名無しさん：2009/03/12(木) 21:24:24

642 ：,,・´∀｀・,,）っ-○◎●：2009/03/12(木) 22:20:46

λλλλλ....

643 ：デフォルトの名無しさん：2009/03/12(木) 22:28:16

うつむいた人が、トボトボ歩いてく・・・
まるで壊れたプログラマの列のようだ・・・

644 ：,,・´∀｀・,,）っ-○◎●：2009/03/12(木) 22:32:06

death☆march～死の行進～

645 ：デフォルトの名無しさん：2009/03/13(金) 01:35:51

λで歩いてたら占い師に声掛けられた

646 ：デフォルトの名無しさん：2009/03/13(金) 10:19:35

>>633
「し腰」であってるなら訂正しなくても。

647 ：デフォルトの名無しさん：2009/03/13(金) 23:42:26

憧れのアーキテクトに会いに行こうぜ
待ってる。
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx

648 ：デフォルトの名無しさん：2009/03/14(土) 00:56:50

もうだめかもわからんね

649 ：デフォルトの名無しさん：2009/03/14(土) 09:31:26

経済危機を脱する処方箋はすでに解っている。量的緩和だ。
なのに日銀はかたくなにその実行を拒否している何故か？

不況を脱出する政策もすでに解っている。給付金だ。（ただし額が足りない。今の100倍は必要。
それを毎年やることだ）
なのに国民にはきわめて評判が悪い。何故か？

今の日本（いや世界は）は生産力余りまくり。足りないのは需要。未来はIT化とロボット導入が
ますます進み、失業者は増加する。
金は、配ればよい。その裏付けとなる生産力はあるのだから。

なのに、「働かざる者食うべからず」「モラルハザードだ」という旧来の道徳・価値観が
これらの人類の次のステージを邪魔している。

この道徳教育は糞。これを推進すれば、未来の日本人は人類の中でもっとも割をくうだろう。

そして、予言しておく。アメリカは消費大国として復活する。

「人間は、労働から解放されつつあるし、そうあるべきだ」この新時代の真理に
気づくべきだ。

650 ：デフォルトの名無しさん：2009/03/14(土) 22:35:46

素人が普通にＰＣ使うのに、ＣもＪａｖａもまるで必要ないんだよなぁ。
プログラムなんて所詮、自己満足のゲーム作るぐらいしか用途ない。

651 ：デフォルトの名無しさん：2009/03/14(土) 23:17:39

釣りにしてもあまりに無知すぎてかわいそうになる
目に見えないからって、電気なんて必要ないと言ってるようなもんだぞ

652 ：デフォルトの名無しさん：2009/03/15(日) 00:11:05

>>651
多分解釈が違うんじゃなかろうか
>>650は恐らく普通の人がパソコンを使う限りにおいて、直接コードを叩くことはないと言いたいんだと推測される

>>650
つ便所の壁

653 ：デフォルトの名無しさん：2009/03/15(日) 00:13:43

んで困ったときは何もできずに人に委託するんだよな
そうやってパソコンのトラブル解決屋っていう需要を生み出せるならいいんだけどね

654 ：デフォルトの名無しさん：2009/03/15(日) 03:10:14

サーバー管理者なんかはほとんどコード書かないんじゃね？
社内ネット環境の構築とかPCの設定ばっかりで。

655 ：デフォルトの名無しさん：2009/03/15(日) 05:33:21

( ﾟдﾟ)

656 ：デフォルトの名無しさん：2009/03/15(日) 08:13:09

>>654
釣りにしてもあまりに無知すぎてかわいそうになる

657 ：デフォルトの名無しさん：2009/03/15(日) 08:31:28

バックドアしかけたりとか色々あるだろ。

658 ：デフォルトの名無しさん：2009/03/15(日) 08:34:38

>>654
シェルとperl書けなきゃ鯖缶なんて勤まらんぞ。

659 ：デフォルトの名無しさん：2009/03/15(日) 09:19:58

パソコンなんてまだまだ発展途上なわけで、ウマウマとか赤ちゃん言葉で話しかけないと反応しないだけだ。

660 ：デフォルトの名無しさん：2009/03/15(日) 10:59:57

コンピュータは進化してるがパソコンは退化してる

661 ：デフォルトの名無しさん：2009/03/15(日) 11:13:29

ワシのようにサーバー管理者の管理者になると、シェルもperlも
書かなくなるな。Ｃ言語はわすれかけとるが、代わりに趣味のスペイン語は
だいぶ上達した。

662 ：デフォルトの名無しさん：2009/03/15(日) 11:16:46

Es maravilloso.

663 ：デフォルトの名無しさん：2009/03/15(日) 11:37:02

オブジェクト指向が消えたら、OSが全滅しちゃうじゃん

664 ：デフォルトの名無しさん：2009/03/15(日) 12:13:46

鯖管なのにcoreダンプ解析してた俺。
障害発生したのはうちのプログラムが原因だということを突きつけないと
開発部隊が動かなかったからな。

665 ：デフォルトの名無しさん：2009/03/15(日) 12:28:56

それはいわゆるコミュニケーションスキルという奴が君に足らないからでは?

666 ：デフォルトの名無しさん：2009/03/15(日) 12:48:31

開発部体は海の向こうで英語喋ってる連中だし、
ただの鯖缶の俺と開発の連中の間には四人くらいマネージャがいたし
まぁそういうこともあってコミュニケーションに問題があったことは確かだな。

667 ：デフォルトの名無しさん：2009/03/15(日) 14:24:54

この業界はアカデミックな人達のレベルが低いから、
彼らが次々に発表する「新しい」ものを疑うことから始めないと駄目だね。

668 ：デフォルトの名無しさん：2009/03/15(日) 14:38:22

ん～、例えば最近ではどういう「新しい」もの？
具体例を２・３個ﾖﾛ。

669 ：デフォルトの名無しさん：2009/03/15(日) 17:12:30

この業界にアカデミックな人なんてほとんどいないじゃん。

670 ：デフォルトの名無しさん：2009/03/15(日) 18:00:23

どの業界だよ

671 ：デフォルトの名無しさん：2009/03/15(日) 18:15:54

このスレは知ったかぶりさん達のレベルが低いから、
彼らが次々に書き込む「もっともらしい」ことを疑うことから始めないと駄目だね。

672 ：デフォルトの名無しさん：2009/03/15(日) 20:24:32

現場で人手が足りなかったら必要なスクリプトでも何でも書いてやらないと仕事にならないだろうけど
でもそれはオブジェクト指向でなくてもできることだから、あんま関係ないよね。
661さんみたいに現場から離れるとさらに関係なくなるし。

673 ：デフォルトの名無しさん：2009/03/15(日) 20:37:05

現場から離れてプログラミングへの興味を失ってスペイン語の勉強してるような奴がこんなスレに来るわけ無いだろ。

674 ：デフォルトの名無しさん：2009/03/15(日) 21:11:45

>>668
具体的なネタは2chには書かないよ
そういう書き込みで情報のタダ取りを狙うのはよく訓練されたネラーだけどね

675 ：デフォルトの名無しさん：2009/03/15(日) 22:15:53

Hasta la vista

676 ：デフォルトの名無しさん：2009/03/15(日) 23:08:43

>>674
KIP!

677 ：デフォルトの名無しさん：2009/03/15(日) 23:09:49

>>674
（ ´,_ゝ｀）ﾌﾟｯ

678 ：デフォルトの名無しさん：2009/03/16(月) 01:14:11

>>658 シェルスクリプトは書くが, シェルを書くほど暇じゃねぇぞ

679 ：デフォルトの名無しさん：2009/03/16(月) 10:48:51

>>674
知らないなら最初っから「見てきたようなウソ」書くなよ。

680 ：デフォルトの名無しさん：2009/03/16(月) 10:58:00

>>668
オブジェクト指向　ajax クラウドコンピューティング

681 ：デフォルトの名無しさん：2009/03/16(月) 11:23:10

クラウドというとどうしてもKuraudさんを連想してしまって駄目だ

682 ：デフォルトの名無しさん：2009/03/16(月) 12:01:38

オブジェクト指向なんて約40年も古い技術なのだが？

683 ：デフォルトの名無しさん：2009/03/16(月) 12:50:37

>>682
ajaxだってjavascriptがIEに乗った当初からコンセプトはありました。
だからいつ考えられたかじゃなくていつ流行ったかが重要です。

684 ：デフォルトの名無しさん：2009/03/16(月) 13:59:28

>>680
[タグ] これはひどい

685 ：デフォルトの名無しさん：2009/03/16(月) 14:04:58

>>680
PaaS

686 ：デフォルトの名無しさん：2009/03/16(月) 15:08:18

OOが最近の流行だと思ってる時点でダメだろ。

687 ：デフォルトの名無しさん：2009/03/16(月) 15:09:32

最近はなにが流行ってるの？

688 ：デフォルトの名無しさん：2009/03/16(月) 15:12:43

んなもんウォーターフローに決まってんだろ

689 ：デフォルトの名無しさん：2009/03/16(月) 15:18:37

うさんくせーのは
アジャイル関数型言語

690 ：デフォルトの名無しさん：2009/03/16(月) 15:19:57

>>689
うさんくさいどころか、確実にダメなのが、おまえw

691 ：デフォルトの名無しさん：2009/03/16(月) 15:32:33

>>689
アジャイルは単なるライフハック

関数型言語は別に何のことは無いものだが、たいていはセットで数学がついてまわる。
言語を使う分には関係ないけどね。

692 ：デフォルトの名無しさん：2009/03/16(月) 15:41:52

圏論とかか。
なんか料理を作るのに包丁鍛冶の修行始めましたぐらいの
遠回り感があるんだが、出来の良い包丁やレシピが揃うのを
待っていては結局町の定食屋にしかなれんのかね。

693 ：デフォルトの名無しさん：2009/03/16(月) 15:58:20

>>692
> なんか料理を作るのに包丁鍛冶の修行始めました
料理を作るのに栄養学の勉強を始めました
の方が近そう

694 ：デフォルトの名無しさん：2009/03/16(月) 20:04:41

言語勉強する前にCPUの勉強からはじめるようなもんか

695 ：デフォルトの名無しさん：2009/03/16(月) 20:08:57

せいぜいポインタを理解する為にComet2触る程度だろう
そんなに遠回りな気はしない

696 ：デフォルトの名無しさん：2009/03/16(月) 20:40:04

圏論の本って、特に日本語の本はたとえ話のネタとして群論とか
環の論理を持ち出すようなのばっかりだから。

数学未満の算数どまりの俺様には遠回りしようとしたら冬の雪山、
右も左も分からずそのまま遭難って感じ。
春山登山のシーズンになったら恐らく雪の中から見つかるので
その時はよろしく。

697 ：デフォルトの名無しさん：2009/03/16(月) 20:40:41

>>694
クンパイラ技術が発達していなかった当時の、
データフローマシンとかは「CPUの勉強」って言うより

「CPU アーキテクチャに合わせるにはどんな言語が必要？？？」

ってなことは、あった

698 ：デフォルトの名無しさん：2009/03/16(月) 22:52:46

オブジェクト指向を学ぶんならSmalltalkやるのが一番の近道

699 ：デフォルトの名無しさん：2009/03/16(月) 23:00:21

いいえσ計算です

700 ：デフォルトの名無しさん：2009/03/16(月) 23:01:34

>>697
言語に合わせてCPUアーキテクチャを作っちゃう、そんな時代も
ありました。

701 ：デフォルトの名無しさん：2009/03/16(月) 23:10:40

>>694
素晴らしく正しい勉強方法に見えるのは気のせいか?

702 ：デフォルトの名無しさん：2009/03/17(火) 00:01:32

That's right.

703 ：デフォルトの名無しさん：2009/03/17(火) 00:05:00

>>700
リスプマシンですね

704 ：デフォルトの名無しさん：2009/03/17(火) 05:42:33

>>661
スペイン語はやめとけ。イカデビルになるぞ。

705 ：デフォルトの名無しさん：2009/03/17(火) 06:09:40

>>701
学生なら正しいけど、社会人は時間がないから無理だろうね。

706 ：デフォルトの名無しさん：2009/03/17(火) 06:40:15

CPUってそんなに難しいか？
言語勉強する前に知っておいた方が良いCPUの勉強なんて
言語入門の最初の日の午前中だけで終わるだろ

707 ：デフォルトの名無しさん：2009/03/17(火) 07:28:31

言語とか目的とかによるでしょ。

基本的に物理ポインタ隠蔽されててガベージコレクタ持っている
昨今の高級言語であればそもそも言語を学び始めるのにCPUの
勉強が必要だとは思わない。
他方組み込みとかだと必要だし午前中じゃまず終わらん。

想像するに>>694は「Javaを使うのにまずJavaVMの仕様から」系
の回り道を想定しているのではないかと。

708 ：デフォルトの名無しさん：2009/03/17(火) 07:39:25

ポインタが隠蔽されてても、リファレンスとか言いつつ概念は表に出てくる

Javaなんかの整数値は値コピーで、オブジェクトはリファレンスで引き回す
ような仕様って、CPUのレジスタのイメージが無いとよくわからないじゃないかね
まる覚えで疑問覚えない人もいるだろうけど

709 ：デフォルトの名無しさん：2009/03/17(火) 07:47:37

>>708
だって仮想マシンですから。
JavaVMってようするにOOP用の仮想CPUエミュレータでしょ？

710 ：デフォルトの名無しさん：2009/03/17(火) 08:00:29

javaは文字列まわりの壮絶なクソさ加減をどうにかしてほしいよね
結局ポインタ理解してないと困るじゃんな
誤魔化しもいいとこだよね

711 ：デフォルトの名無しさん：2009/03/17(火) 08:15:04

>>710 kwsk

712 ：デフォルトの名無しさん：2009/03/17(火) 10:04:13

>>710
壮絶なクソとまで言う理由をｋｗｓｋ

713 ：デフォルトの名無しさん：2009/03/17(火) 10:16:30

>>705
社会人だろうが学生だろうが一緒ｗ
基礎が出来てない奴ほど学習能力が低くて役に立たない。

714 ：デフォルトの名無しさん：2009/03/17(火) 10:17:18

>>706
CPUを作ってから言え。
理解したなら作れるだろ。

715 ：デフォルトの名無しさん：2009/03/17(火) 10:27:32

>>706
そんなもんCPUの勉強に入らねーよ

716 ：デフォルトの名無しさん：2009/03/17(火) 10:32:33

>作ってから
東大行ってISに進めということですねわか(ry

717 ：デフォルトの名無しさん：2009/03/17(火) 10:36:35

ＣＰＵ実験は伝統だよなｗ

718 ：デフォルトの名無しさん：2009/03/17(火) 10:41:59

基情で出題されるレベルのCPUの説明程度じゃぜんぜん実感わかないと思うけどねぇ。
CPUをFPGAで作って、そのCPU用のMLコンパイラまで作って、初めてCPUを理解したと感じたんだよなぁ。
まぁ、あの時作ったCPUはふざけて変な命令まで仕込んだけど若気の至りって事でｗ

719 ：デフォルトの名無しさん：2009/03/17(火) 12:21:35

情報系の学部ならたいていやってるだろ > CPU作成

720 ：デフォルトの名無しさん：2009/03/17(火) 12:31:09

オレジェクト指向は未来永劫不滅ですか？

721 ：デフォルトの名無しさん：2009/03/17(火) 12:45:31

>>714-718
ttp://www.amazon.co.jp/products/dp/4839909865
自演乙

722 ：デフォルトの名無しさん：2009/03/17(火) 14:33:23

>>720
オレジェクトとデスマーチは不滅です。

723 ：デフォルトの名無しさん：2009/03/17(火) 17:41:09

>>721
ああ、それ買ったけど、あまり実用的な知識は載ってないよ。
コンピュータとも言えないような代物を74シリーズで作ってみようっていう話。
CPUの効率化・高速化の話には微塵も触れてない。

724 ：デフォルトの名無しさん：2009/03/17(火) 18:11:01

> CPUの効率化・高速化の話には微塵も触れてない。
その辺は、基礎的なものを自分で作れるようになってからだな。

725 ：デフォルトの名無しさん：2009/03/17(火) 18:51:35

そう言えば、
unisysになる以前のバロースなんてB5000とかB1700とか
滅茶苦茶おもしろそうなCPU作ってたのな

726 ：デフォルトの名無しさん：2009/03/17(火) 20:04:07

これでオブ脳に
http://pw.tech-arts.co.jp/

727 ：,,・´∀｀・,,）っ-○◎●：2009/03/17(火) 20:06:57

宣伝乙としか

728 ：デフォルトの名無しさん：2009/03/17(火) 22:04:42

>>713
低レベルのレイヤーが基礎とは限らない。

729 ：デフォルトの名無しさん：2009/03/17(火) 22:13:54

本当に素朴な疑問。

今まで生きててオブシコによってコードが再利用されたのを見た試しがないんだが
どこでどうやって「オブシコはコードの再利用性を向上させる」という都市伝説が生まれたのだろう…

730 ：デフォルトの名無しさん：2009/03/17(火) 22:20:10

>>728
間違いなく基礎。
仮にHaskellのように高度に抽象化された関数型言語であっても
CPUがどういう風に処理するのか分からなければ効率的なアルゴリズムは考えられない。

731 ：デフォルトの名無しさん：2009/03/17(火) 22:22:09

基礎って学問における「共通事項」のことなんだよね。
言語が違おうがパラダイムが違おうがCPUの構造は共通事項だ。

732 ：デフォルトの名無しさん：2009/03/17(火) 22:24:35

ということは圏論は基礎か

733 ：デフォルトの名無しさん：2009/03/17(火) 22:29:19

アセンブラ知ってる奴が、時間を無駄にしたって思いたくないだけだろ。

734 ：デフォルトの名無しさん：2009/03/17(火) 22:32:05

俺も流行に乗じて圏論を勉強したが、
圏論は共通事項なのか・・？
Haskellは単に圏論"っぽい"概念を持ち込んだだけで、圏論で抽象化しているわけじゃないし、
言語の重要な要素というわけでもない。

735 ：デフォルトの名無しさん：2009/03/17(火) 22:34:02

たとえばCの入門書を一通りやったやつが、次にどっちを読んだらいいですか?　って、
アセンブラの本と基礎的なアルゴリズムの本をみせたら、アルゴリズムのほうを薦める。
(別に両方やってもいいけど)
これからそいつがやりたいことにもよるけど、そんなに優先度高くはないわな。

736 ：デフォルトの名無しさん：2009/03/17(火) 22:44:52

>>729
別に自分の書いたコードを再利用する必要なんてどこにもない。
標準だったりそうでないけど有名なものを引っ張ってくるだけのこと。

737 ：デフォルトの名無しさん：2009/03/17(火) 22:45:19

やりたいことをやるのは結構だけど、
作ったものがどういう仕組みで動いているの？っていうのも自然に沸いてくる興味だと思うよ。
そういうことを追求していると基礎に帰着するんだよね。
自分で作ったものがどういう仕組みで動いているのかって意外と知らない人がいると思う。
動いてるんだから良いじゃないか、っていう人が定年３５歳の人だろうね。

738 ：デフォルトの名無しさん：2009/03/17(火) 22:45:58

>>734
ただ単に自分の知っている事なら何でも基礎だと言い回りたい
奴が張り付いているだけじゃね？CPU云々も一体どのレイヤー
のことを含んで基礎といいたいのかハッキリさせないし。

圏論も全然基礎だとは思わない。>>732も疑問系だし。
個人的には基礎だと言えるほど計算機屋さんが学べるインフラ
も特に日本語ではまだまだ整っていないと思う。

739 ：デフォルトの名無しさん：2009/03/17(火) 22:46:21

>>729
オーバーライドしてる時点で再利用してる。

740 ：デフォルトの名無しさん：2009/03/17(火) 22:49:19

「基礎」も階層構造になっているようです

741 ：デフォルトの名無しさん：2009/03/17(火) 22:50:02

>>737
物事を始めるに当たっての基礎と実現技術としての基盤は区別しようぜ。
でないとプログラムを学ぶ前に井戸型ポテンシャルとかバンドギャップから
勉強し始めることになる。

742 ：デフォルトの名無しさん：2009/03/17(火) 22:53:31

基礎なんてやりたい事やってるうちに覚えるくらいでいい

743 ：デフォルトの名無しさん：2009/03/17(火) 22:58:03

>>741
「共通事項」を見出す能力の問題。

極論を言う奴は単に逆らいたいだけの中二病なんだろうなぁ。
極論は説得力が無いし、もし分かってて書いているなら誤魔化しで書いてるだけなんだろうなぁ。
自分に自信がないんだろうなぁ。

744 ：デフォルトの名無しさん：2009/03/17(火) 23:00:01

>>742
まぁ、やりたいことだけやってれば良い人はそれで良いだろうけどね。

それってニート？ｗ

745 ：デフォルトの名無しさん：2009/03/17(火) 23:00:55

まともな意味で再利用されることなんてまずない
でも、再利用してコストを下げます、っていうと上の方には受けがいい
それだけ

746 ：デフォルトの名無しさん：2009/03/17(火) 23:05:00

再利用したいコードも再利用できないこんな世の中じゃ　オブジェクト

747 ：デフォルトの名無しさん：2009/03/17(火) 23:07:00

中途半端に勉強するのが一番育たない

748 ：デフォルトの名無しさん：2009/03/17(火) 23:45:01

>>729
ＧＵＩライブラリを使ったことないのかね。

749 ：,,・´∀｀・,,）っ-○◎●：2009/03/18(水) 00:09:35

>>733
マジレス
比較的若い世代のアセンブラ使いはRubyとかの高級なOOPL嫌いな人はあんまり居ない

750 ：デフォルトの名無しさん：2009/03/18(水) 00:13:06

>>729
オブジェクト指向の売りとして「継承による差分プログラミング」が喧伝された時代があった。
この継承による差分プログラミングを指して再利用と言っていた。
この主張は現代では絶賛否定中。

他のパラダイムと比べて、オブジェクト指向のコードは再利用しやすいと言う主張は古い、と思う。
変わりに、デザインの再利用ならデザインパターンの頃から強調されている。

最近はもっと新しい主張があるかも。

751 ：デフォルトの名無しさん：2009/03/18(水) 00:14:16

再利用するためのコードを書きやすい、位ならあるかもね。
フレームワークとか作るのは便利。

752 ：デフォルトの名無しさん：2009/03/18(水) 00:32:46

生産性の向上という言葉にみんな騙されてたわけやね
まあいつの時代もバカの一つ覚えみたいにそう謳ってるわけだが

753 ：デフォルトの名無しさん：2009/03/18(水) 00:45:26

とはいえ、構造化よりはオブジェクト指向のほうがモジュールの独立性があがるから
まともに作ればテスト、デバッグ、保守、仕様変更はしやすいんだけどね。
まともに作らなければ酷いことになるけど。

754 ：デフォルトの名無しさん：2009/03/18(水) 00:46:33

まともなオブシコ設計を考えられる奴は100人中1人いるかいないかだけどね。

755 ：デフォルトの名無しさん：2009/03/18(水) 00:55:23

オブジェクト指向は最先端の主張が結構変化するからね。
もうちょっとこなれてくるといいんだけど。

あと、まともな構造化を考えられる奴も実はあまりいないね。

756 ：デフォルトの名無しさん：2009/03/18(水) 01:38:18

>>750
継承を用いた場合の利点って、実装工数を下げるということよりも
ポリモーフィズムを用いて結合度の低いきれいな設計ができるってことだよね。
まぁ要するにインタフェースなんだけどね。

757 ：デフォルトの名無しさん：2009/03/18(水) 01:51:36

いまどきはwebのuriがAPIでオブジェクト指向を標榜しているところがありますね

758 ：デフォルトの名無しさん：2009/03/18(水) 09:14:19

>750
＞「継承による差分プログラミング」が喧伝された時代

その時代は、かなり長かった気がするなぁ。

759 ：デフォルトの名無しさん：2009/03/18(水) 09:58:36

今は
インスタンス生成による省略プログラミング
とか
インターフェースやファクトリによる差分プログラミング
が主流だな

760 ：デフォルトの名無しさん：2009/03/18(水) 10:01:08

>>750
ソースは？

761 ：デフォルトの名無しさん：2009/03/18(水) 10:40:42

アウトソースで

762 ：デフォルトの名無しさん：2009/03/18(水) 11:23:49

>>736
> 別に自分の書いたコードを再利用する必要なんてどこにもない。
> 標準だったりそうでないけど有名なものを引っ張ってくるだけのこと。

>>748
> ＧＵＩライブラリを使ったことないのかね。

それらはオブジェクト指向じゃなくても元々出来ていたことだから
オブジェクト指向でコードの再利用性が向上したとは言えない

763 ：デフォルトの名無しさん：2009/03/18(水) 11:31:12

OOによる再利用はよくライブラリの再利用で議論されるが、
逆にライブラリを使う側のコードの再利用のほうに効果があると思う。
ライブラリ側の変更のインパクトがクライアント側に及びにくい。

764 ：デフォルトの名無しさん：2009/03/18(水) 11:59:41

>>762
俺、オブジェクト指向じゃない言語なんてあんま知らないんだけど、
配列やテキストボックスを継承してちょっと拡張したりってのは
Cとかでも出来たってこと？

765 ：デフォルトの名無しさん：2009/03/18(水) 12:00:42

普通に出来るだろ。

766 ：デフォルトの名無しさん：2009/03/18(水) 12:23:34

おー知らなかった。Thx。
なんだ継承ってのはOOP特有でもなんでもないのか。

767 ：デフォルトの名無しさん：2009/03/18(水) 12:24:52

>>766
OOPってのはプログラム構造であって、
言語によって (サポートがない分) 煩雑にはなるが
できないわけではないし、やっている例もある。
(例えば、Motif のボタンはラベルから派生している)

768 ：デフォルトの名無しさん：2009/03/18(水) 12:28:25

…つか、「OOPL で書いたら OOP だ」と思ってるタイプか。

769 ：デフォルトの名無しさん：2009/03/18(水) 12:35:32

C＋＋出始めの頃は、C＋＋をCに変換するコンバータがあったし。

770 ：デフォルトの名無しさん：2009/03/18(水) 12:55:50

>>769
それを言うと、どんな言語も機械語だ。

771 ：デフォルトの名無しさん：2009/03/18(水) 13:23:43

>>769 C++ は, 最初は C のマクロパッケージだったんじゃないか?

772 ：デフォルトの名無しさん：2009/03/18(水) 13:34:36

>>770
スカッとしたよ、アンタのレスに。

773 ：デフォルトの名無しさん：2009/03/18(水) 14:09:50

>>771
マクロじゃなくて、プリプロセッサとして実装されていた。

774 ：デフォルトの名無しさん：2009/03/18(水) 17:58:36

>>764
出来ないとすると...
SDKでどうやってプログラムするんだ?

775 ：デフォルトの名無しさん：2009/03/18(水) 18:14:58

>>764
Cならたいていのことはできるけど、C全盛の頃は配列は配列としてそのまま使うのが普通だったな。
わざわざ配列を継承して差分だけ書くなんてことしたことない。
そういうことが考えられるようになったのはオブジェクトや継承の概念が浸透してからのことだと思う。
当時の頭でCを使って書くのと、今Cを使ってオブジェクト風に書くのを比べたらだいぶ違うソースになるだろう。

776 ：デフォルトの名無しさん：2009/03/18(水) 18:45:37

結局のところ

777 ：デフォルトの名無しさん：2009/03/18(水) 20:15:53

>>760
90年代前半のCマガジンとか見れば普通に出てくるはず。
後半でものってそう。DDJJとかもかな。
設計とかよりも、実装方法に主眼が置かれていたのが特徴。

今でも売ってる本なら「憂鬱なプログラマのためのオブジェクト指向開発」なんかが
そんな感じじゃなかったか。（記憶あいまい）
出た当初はいい本だと思ったが、後年よんだとき酷かった覚えがある。

778 ：デフォルトの名無しさん：2009/03/18(水) 20:16:49

そういえばオブジェクト指向アセンブラとかあったな。
どんなものか知らないが、興味あるなあ。

779 ：デフォルトの名無しさん：2009/03/18(水) 20:18:36

>>764
できるけどやらない。
そんなまねをする奴は道具の使い方を間違っている。

780 ：デフォルトの名無しさん：2009/03/18(水) 20:19:27

バイナリエディタさえあればどんなプログラムでも書ける！
みたいな主張は嘘じゃないけどさ。

781 ：デフォルトの名無しさん：2009/03/18(水) 20:32:13

>>778
マクロ使って構造化アセンブラ作って、ピープヒールオプティマイズ
するあたりまでは、普通の病人なんだが
> オブジェクト指向アセンブラ
って、どこで見かけた???

782 ：デフォルトの名無しさん：2009/03/18(水) 20:32:46

C++出始めのころは、オブジェクト指向といえば Smalltalk のことで
C++は抽象データ型言語、ぐらいの位置づけだったのにな

783 ：デフォルトの名無しさん：2009/03/18(水) 20:38:44

>>781
10年ちょっと前のTASMにそんなコピーがついてた。
Delphi付属だったかな？

784 ：デフォルトの名無しさん：2009/03/18(水) 20:46:48

>>777
いや、ごめん、現在絶賛否定中のほうのソースね。

785 ：デフォルトの名無しさん：2009/03/18(水) 20:53:23

>>784
その辺のオブジェクト指向の本を読めば、
実装の継承って普通に忌避されてないか？

具体例だと「オブジェクト指向のこころ」とか

786 ：デフォルトの名無しさん：2009/03/18(水) 21:05:55

>>785
いや、別にそんなの見かけないけど、具体的にどの本に書いてあったのを見たの？

787 ：デフォルトの名無しさん：2009/03/18(水) 21:07:49

>>785
酒入ってるんではずしてたらごめん
# 話の流れについていけてないかも知れない

X の toolkit あたりは普通に継承してるんだが…

788 ：デフォルトの名無しさん：2009/03/18(水) 21:12:03

ITProにはこんなことが書いてあった。
でもそれは実装の継承を忌避するというよりも、
「実装の継承もいいけどインターフェースももっと使おうね」
という意味だと思うけど。

> オブジェクト指向開発におけるクラス継承の位置付けも，
> 昔と今では開発者の間での認識が少し異なる。
> 昔は，継承と言えばまず実装（コード）の再利用を思い浮かべる人が多かったはずだ。
> 確かに，オブジェクト指向になじみがない人にとって，
> 実装の再利用が最も分かりやすいメリットなのは間違いない。
> しかし，現在では実装の継承よりも，多態性を利用するためのインタフェースの継承のほうが重要だ
> という認識が広まっている。「継承は多態性のための手段に過ぎない」とまで言われることもあるほどだ。

789 ：デフォルトの名無しさん：2009/03/18(水) 21:19:51

リンク貼るの忘れた
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20031002/1/

790 ：デフォルトの名無しさん：2009/03/18(水) 21:19:53

実装の継承が有効なコードって、GUIのように結構限られてるからな。
インタフェースの継承はもっと一般的に使える。

791 ：デフォルトの名無しさん：2009/03/18(水) 21:24:07

>>788
インターフェースって、はっきり言ってC++系の言語が錯誤に陥ってる最低の部分だ罠
C++もJavaもC#もSmalltakとかCLOSあたりの考え方採り入れるべきだと思う
つか、あのpublicやらprotectedやらprivateなんて隠蔽って全然意味がないし
流行りのデザインパターンだって、ほとんどSmalltalkからのぱくりじゃん

792 ：デフォルトの名無しさん：2009/03/18(水) 21:25:13

別に○○がいいよ、とか言われたって場合によって違うんだから、本になにが書いてあろうと関係ない。
昔のオカルト本みたいなもんだよ。
根拠のない神秘主義、ばかばかしい。

便利だと思った構造を使えば良い。
どうせ剣道や柔道の型みたいなものは無いんだから。
あるとしてもせいぜいGOFのデザインパターン？ってやつ？
胡散臭いけど。

793 ：デフォルトの名無しさん：2009/03/18(水) 21:28:11

>>792
禿同

いま必要なのはオカルトよりも科学。
プログラミングには体系的な形式化が必要だと確信している。

794 ：デフォルトの名無しさん：2009/03/18(水) 21:31:53

C++に関しては、Cと同等の自由度と速度を維持するのが使命だから仕方ない面はあると思ってる。

795 ：デフォルトの名無しさん：2009/03/18(水) 21:32:52

>>793
一口に科学っていっても、経済学みたいなのもあるよ

796 ：チラ裏：2009/03/18(水) 21:35:53

MSDNライブラリとかJava APIドキュメントとか見てつくづく思うんだが、
多くの人に再利用してもらえるようなコンポーネントやライブラリを作る・メンテナンスするのって
本当に難しいよね。時間が経てば経つほど過去バージョンとの互換性維持が難しくなっていくし、
新しい技術にも対応しなきゃいけないし……とかやってると、あっという間にコード規模が膨れあがるしで。

そういった問題を解決するために、「継承による差分プログラミングで実装工数を低減」だの
「ポリモーフィズムによる結合度の低いきれいな設計で拡張性と保守性を向上」だのとオブジェクト指向の特徴が
一時期もてはやされ、今は下火になって残念感が漂ってるけど、それ自体はすごく有用だし効果があると俺は思うよ。

ただ、オブジェクト指向だけでは解決できないほど問題が複雑すぎた……っていうか、問題の大きさの前に、
オブジェクト指向だけでは非力だったんだとも思う。結果、プログラマや設計者に多くの知識や経験を求めないと
現場で実践できない難解なパラダイムになってしまったんではないかと。

ってことで、俺的には「オブジェクト指向は基礎技術としては有用・必要だが、現場の人間が使うシロモノじゃない」
と思ってる。消えて無くなるのは非常に困るけど、銀の弾丸じゃないと割り切ったから期待もしてないって感じかな。

797 ：デフォルトの名無しさん：2009/03/18(水) 21:38:26

現場の人間でも普通に使える技術だが？

798 ：デフォルトの名無しさん：2009/03/18(水) 21:43:26

>>795
だよなあ・・・無理に、より学問らしくしようと数学使ったりもしてるし
もちろん、これはっていうアイディアも多々あるけど
結局のとこ人口が多い国が強かったり、資源あるとこが強かったり。
「金融工学」なんて胡散臭いことこの上ない。

799 ：デフォルトの名無しさん：2009/03/18(水) 21:44:25

>>796
問題なのは
「要求分析から設計からコーディングまですべてオブジェクトにすればいい」
って、風潮だろ？
俺的には、業務系でオブジェクト分析とか言ってる奴等が一番信用できない

本音：
「なんで、大昔からあんな巨大な工業プラントが OO の考えを必要とせず
動作してるんだよ？」

要らないじゃね？上流工程の OO

800 ：デフォルトの名無しさん：2009/03/18(水) 21:44:52

>>796
問題が複雑過ぎたっつーより、何でもかんでも.NETやJava標準APIでやろうとしすぎなんだよ。

801 ：デフォルトの名無しさん：2009/03/18(水) 21:48:50

>>786
すまないが>>785を3回ほど音読してみてくれ。
健闘を祈る。

802 ：デフォルトの名無しさん：2009/03/18(水) 21:49:43

>>787
ここで言ってるのは、「既存のクラスと似たクラスが欲しくなったときに、
そのクラスを継承して気に入らないところだけオーバーライドすることにより、
既存のコードに触れることなく、機能を変更できる（＝既存のクラスを再利用できる＝生産性が高い）」
という主張のこと。

今日では、こんな継承関係が無茶苦茶になる上にクラスが密に結合するアプローチが
だめなのは自明なので、「だめです。」と明言している本は、言われてみればあまりないかも。
>>785で挙げた本にしても、クラス間の結合度を疎にしましょう、とかそんな言い方になってるし。

toolkitはソースを見たわけじゃないけど、ちゃんと設計して実装の継承をするのは当然あり。
GoFのパターンにもテンプレートメソッドパターンとかあるしね。

>>792
デザインパターン以降くらいからは一般の趣味プログラマが読むような本でも、
まっとうに進歩してると思う。少なくとも腑に落ちる。

803 ：デフォルトの名無しさん：2009/03/18(水) 21:50:21

>>799
たまに業務系の作業手伝うと、もっと効率化したらいいのにと思えることはたくさんあるよ。
別にOOである必要は無いけど、OO入れれば今よりは効率化できるんじゃね？とおもう。

804 ：デフォルトの名無しさん：2009/03/18(水) 21:55:50

>>803
業務系の場合、習熟度の低い要員を大量に投入せざるを得ないから、
効率が悪くても、分かりやすいほうが好まれるとおもう。
きれいな設計にしても維持できる体制がない場合が多いし。

805 ：デフォルトの名無しさん：2009/03/18(水) 21:58:06

>>791
C++はCLOSの影響が凄く強い。
マルチディスパッチの汎関数。特殊化。
Lisp→CLOS ∽ C→C++と考えていいくらい。

806 ：デフォルトの名無しさん：2009/03/18(水) 21:58:49

現場というときはどんな現場にいるのか前提がわからんとなんともいえない。
ゲーム系、組み込みマイコン系、Winアプリ系、サーバ系、勘定系、数理系などぜんぶひっくるめて
同列で語れるわけがない。

807 ：デフォルトの名無しさん：2009/03/18(水) 22:00:17

>>791
クラスを作る人（＝比較的高レベル）と使う人（＝比較的高レベル）に分かれている
Javaとかの方が、使う人だけ大量に動員すればよい業務系には向いているとおもう。

808 ：デフォルトの名無しさん：2009/03/18(水) 22:01:27

>>803
そっちはそれ以前の問題だろ？
OO 設計できますとか言ってる連中って、まとも機能切り分けのしてある
ブロックチャート書けない奴の方が多いんだもん

システム設計って言うのはどこからどうゆう入力が入ってくるかを分析して
どこに何を出力しなきゃいけないかを決めることだろ?

当然、入力の中にはエラーとか外乱ってものも考慮されてなきゃいけない
はずなんだが、要求分析のクラス図書いてる時点でエラー分析とか外乱要因
切り捨ててるんだからまともに動くはずがないと思う

809 ：デフォルトの名無しさん：2009/03/18(水) 22:15:21

そもそも(エラーも含めた)入出力に関してはシーケンス図や状態遷移図を書くべきであって、
クラス図で表すものじゃないだろ。

810 ：デフォルトの名無しさん：2009/03/18(水) 22:19:15

>>808
> システム設計って言うのはどこからどうゆう入力が入ってくるかを分析して
> どこに何を出力しなきゃいけないかを決めることだろ?

ちょww
それは古すぎるような…

811 ：デフォルトの名無しさん：2009/03/18(水) 22:23:37

伊東へ行くならハトヤ鳩屋に決めた

812 ：デフォルトの名無しさん：2009/03/18(水) 22:24:07

>>809
> 入出力に関してはシーケンス図や状態遷移図
だから、
「こんな入力(たぶん、この辺でエラーがあるし外乱もあるはずなんだが…………)
をこんな出力にするためにはどんな機能が必要か？」
を、考えなくて
「わたくしは、``OO 分析/設計'' が出来ます！！！」
って、のたまわる奴が多すぎだって言ってる

813 ：デフォルトの名無しさん：2009/03/18(水) 22:28:11

>>810
なんで？
素粒子から生物や人工物に至るまで、すべて
「入力に対して何を出力するかの状態機械」
と見做すことが可能だぞ？

814 ：デフォルトの名無しさん：2009/03/18(水) 22:32:40

>>813
> 「入力に対して何を出力するかの状態機械」
> と見做すことが可能だぞ？

Blackboxかよw
こりゃ設計も糞もないな。

815 ：デフォルトの名無しさん：2009/03/18(水) 22:41:49

>>814
だから、どんな入力があるのかも分析しない奴が多すぎだって言ってる

まぁ、俺は、元がハード屋なんで
データ: メモリ or レジスタ
メソッド: ロジックパーツ
メッセージ: 伝送線路
として、信号処理系の一形態として分析してしまう悪い癖はあるが、
伝送線路に外乱が入るとかエラーが発生するとか考えないやつ多いぞ

816 ：デフォルトの名無しさん：2009/03/18(水) 22:45:54

クラス構成考えてるときに、いちいちエラーまで入れた状態遷移を考えてないのはその通り。
でも、エラーまで入れた状態遷移を考えてるときにそれをどう実現しようかまで考えて無いのも事実。

入出力の設計ができたとしても、中身を考える力がなければぐちゃぐちゃなコードができるだけ。
入力されたものを、出力に変換するためにぐちゃぐちゃなコードを弄ってるのは時間の無駄じゃね？
それよりOOとか使って綺麗に設計されたコードを弄ってる方がよくね？って話。

817 ：デフォルトの名無しさん：2009/03/18(水) 23:02:24

>>816
あぁ、なるほどね、C++/Java 系の OO になじめない理由が分かったような気がする
メッセージ(信号)が主役かクラス(パーツ)が主役かの差だわ

y = f(x) で、定義域 x と、値域 y が厳密に決定されれば中の手法は問う必要は
感じないが、関数 f が巨大だと分割するじゃん。
で、f -> g.h に分割された g と h の入出力をきちんときめられない奴が多い

ありゃ? これはもしかして, インターフェース設計できない奴多すぎって話だな
で、これって俺的には OO でも何でもないんだがw

818 ：デフォルトの名無しさん：2009/03/18(水) 23:07:04

きちんと設計されれば、gとhは疎結合だからね。
細々した入出力を決めないといけないという時点でダメダメ。

819 ：デフォルトの名無しさん：2009/03/18(水) 23:11:42

>>817
Javaは例外をインターフェイスとして宣言させるようになってるんだが、
きっとそう思ったやつがいるんだろうな。その後どうなったかはご存じの通りだ。
後発の言語も完全に無視してるしな

820 ：デフォルトの名無しさん：2009/03/19(木) 00:02:36

>>817
惜しい！
そこまで機能分割してインターフェイス設計までできたら、後は個々の機能を実行するオブジェクトを作って
メッセージ投げたらそれに反応して動くようにすればオブジェクト指向になる。

821 ：デフォルトの名無しさん：2009/03/19(木) 00:12:59

>>817
C++/JavaがOOってのは、OOブームに乗っただけだしね。
クラスが定義できればOO言語だと思い込んでる奴が多そう

822 ：デフォルトの名無しさん：2009/03/19(木) 00:14:18

>>821
静的型付は邪道という立場？

823 ：デフォルトの名無しさん：2009/03/19(木) 00:29:44

OOだと、メッセージもオブジェクトとしてとらえるのが普通だな。

824 ：デフォルトの名無しさん：2009/03/19(木) 00:50:48

>>821
静的かどうかより、オブジェクト指向かどうか、じゃない？

C++がOO言語だとする場合、「メンバ関数の呼び出し」＝「オブジェクトにメッセージを送る」
ってことだけど、実際C++プログラマがメッセージを送るアナロジーで考えてるとは思えない

825 ：デフォルトの名無しさん：2009/03/19(木) 00:51:45

>>817
それは関数型言語の設計に近いね。

だから彼らは凄く汎関数指向への愛着が高い。
隅々まで良く知られた関数を使えば、
手書きした関数を一つ一つ検証する必要がないから。
コンポーネント指向が非常に強い。
汎関数の組み合わせで書ければ、少々パズル的になることも厭わない。

SICPの序文にも、
> Lispプログラムにおいては、
> 関数の有用性が当初の目的である応用に収まらないため、
> ライブラリが膨張していくのである。
とある。

826 ：デフォルトの名無しさん：2009/03/19(木) 00:53:42

>>824
> オブジェクト指向かどうか、じゃない？

こういう切り口は言葉遊びになりがちなのでやめませんか?

827 ：デフォルトの名無しさん：2009/03/19(木) 00:55:16

>>824
最近のオブジェクト指向のデザインの本なんかを読むと、
オブジェクトにメッセージを送る、なんて表現しているものは見ないのだが、
なにかいい本あるかい？

828 ：デフォルトの名無しさん：2009/03/19(木) 01:07:32

>>791
CLOSの影響があったほうが扱いやすいわな。総称関数とクラスに分けたほうが、取り扱いが楽だしね。
C++/JAVAのようなOOって構造上カオティックなシステムを作ってしまいやすいし、簡潔に出来ないからね。

829 ：デフォルトの名無しさん：2009/03/19(木) 01:23:01

>>805にも書いたが、
C++はCLOSの影響が凄く強い。
CLOSの影響をもっとも強く受けた言語といっても過言じゃない。

830 ：デフォルトの名無しさん：2009/03/19(木) 05:22:07

>>829
C++はCLOSの表層機能を取り込んで、一番大切な魂を捨てた言語だな。

831 ：デフォルトの名無しさん：2009/03/19(木) 07:41:23

C++のダメダメなところ

他の言語のいいところをぱくろうとして、言語仕様を拡張すればするほど、
シンタックスが変態的になっていくところ

832 ：デフォルトの名無しさん：2009/03/19(木) 09:27:38

>>796
> ただ、オブジェクト指向だけでは解決できないほど問題が複雑すぎた……っていうか、
> 問題の大きさの前に、オブジェクト指向だけでは非力だったんだとも思う。

最近、けっこうこれに同意できるようになった。
るびまで紹介されていたプログラマさんが
「いままで読んだ中で最も美しいソースコードは？」との質問に、
「うん。大きなソースコードは必然的にあまりきれいにならないと信じてる。」
と答えてた。

これを読んだ当時は、そんなわけないだろう、
きれいになることもあるだろう、と漠然と思ってた。

今では、諦めてる。

それと、「銀の弾丸が無い」というより、
「モンスターが闇夜に行進してくるのが見えてない」という感じ。

833 ：デフォルトの名無しさん：2009/03/19(木) 10:52:05

Railsが吐くコード見て吐いた

834 ：デフォルトの名無しさん：2009/03/19(木) 11:01:07

自動生成されたコードなんて人間が見るものじゃないよな！

835 ：デフォルトの名無しさん：2009/03/19(木) 11:04:17

なんで？わりと綺麗なほうじゃん

Rubyはバグでも無い動作までマイナーチェンジの度に変更しないで欲しいんだが

836 ：デフォルトの名無しさん：2009/03/19(木) 11:52:07

だれも綺麗でないとは言っていない

837 ：デフォルトの名無しさん：2009/03/19(木) 12:14:54

>>829
おっしゃるようにジェネリック関数のところにCLOSの影響を感じるけど、気の毒なことにlispは型宣言は後づけになってるから
C++みたいなコンプリケイトな文法にはならなかった。
CLOS的なプログラミングも出来る反面、クラスに関数など全てをもたせるために、複雑怪奇になってるんだよな。オブジェクト
指向でもCLOSは別世界の印象は強いよな。だから、影響はあるかもしれないけど、c++/java系の感覚でしようとすると
理解できないところが多いって印象もある。もっと緩やかなんだよな。CLOSって。ただし、Lispは関数オブジェクトや関数ポイン
タみたいなことは普通にやってる<ファーストクラスの関数だし>から、オブジェクト指向が無くても困らないんだよな。
シミュレーションをするときには便利だけどね。

838 ：デフォルトの名無しさん：2009/03/19(木) 12:22:52

>>837
> クラスに関数など全てをもたせるために

C++全然知らないのね。

839 ：デフォルトの名無しさん：2009/03/19(木) 12:45:28

>>838
ああ？、better Cって印象でも使ってたけど。オブ脳の人ってすべてメンバ関数にするんじゃないの？オブ脳の連中の思考は知らんけどな。

840 ：デフォルトの名無しさん：2009/03/19(木) 12:46:36

俺自分のプログラムで構造体に関数ポインタとかよく使うんだけどな
Cなのに foo->func(a, b); みたいな記述がちらほらｗｗｗ

841 ：デフォルトの名無しさん：2009/03/19(木) 12:48:30

>>832
だから形式化が必要なんだよ

842 ：デフォルトの名無しさん：2009/03/19(木) 17:42:25

関数ポインタにあるクラスのインスタンスのメソッドのポインタを代入できますか

843 ：デフォルトの名無しさん：2009/03/19(木) 17:46:08

>>842
できませんｗ
それは誰もが通る道。

スタティックなメンバ関数のポインタは代入できる。
メンバ関数へのポインタと、
普通の関数へのポインタは扱いが違う。

あ、それと言っとくが俺はにわか！
くわしいことはプロに聞け！

844 ：デフォルトの名無しさん：2009/03/19(木) 17:57:56

>>842
・関数ポインタに
・あるクラスのインスタンスのメソッド(へ)のポインタ
を代入できますか

という構文解析でOK?

845 ：デフォルトの名無しさん：2009/03/19(木) 18:01:07

>>843
> できませんｗ
強引にやれば出来る。

846 ：デフォルトの名無しさん：2009/03/19(木) 19:16:20

なにがしかの値は代入出来るかも知れないが、それをどう
呼び出すかが問題だ。
例えばC++ってメソッドとレシーバのポインタを別々に渡して、
受け側で動的にがちゃこんと結びつけて呼び出すような
事って出来ましたっけ？

847 ：デフォルトの名無しさん：2009/03/19(木) 19:21:51

メソッドのある場所はレシーバのポインタからのオフセットで決まる？

848 ：デフォルトの名無しさん：2009/03/19(木) 19:23:14

そういうの気にしなくてよくするために
COMがあるんじゃないのか

849 ：デフォルトの名無しさん：2009/03/19(木) 19:33:41

>>842
C++と仮定すると、関数オブジェクト使えば似たようなことはできる。

>>847
コンパイラの実装にもよるだろうけど、
一般的にインスタンス内にメンバ関数のアドレスは持ってなかった気がする。
(一般的にvirtualがつく関数は vtableに入るんだったっけ？)

850 ：デフォルトの名無しさん：2009/03/19(木) 19:45:32

束縛と高階関数とカリー化があればいらなくね？？オブジェクト指向

851 ：デフォルトの名無しさん：2009/03/19(木) 19:52:44

いらなくなるかも知れないけど、どっちが良いかはまた別問題。
特に普及を考えた理解のしやすさという点では。

高階関数を使ったときは、OOPでありがちなanimal, dog, catの
例に対応するような説明例はどんなものになるのだろう。

852 ：デフォルトの名無しさん：2009/03/19(木) 19:59:36

>>851
function dog(){
// dogging...
}

function animal(f){
// animal nature
}

animal(dog);

結果：
アニマルとしての犬っぽい挙動

853 ：デフォルトの名無しさん：2009/03/19(木) 20:03:21

>>851
ラムダ計算の説明になる。

854 ：デフォルトの名無しさん：2009/03/19(木) 20:11:14

>>853
動物か食べ物でお願いします。

855 ：デフォルトの名無しさん：2009/03/19(木) 20:24:18

アリスとボブ

856 ：デフォルトの名無しさん：2009/03/19(木) 21:29:10

SUN死亡か

米ＩＢＭ、サン・マイクロシステムズ買収で交渉
http://jp.reuters.com/article/technologyNews/idJPJAPAN-37047020090318

857 ：デフォルトの名無しさん：2009/03/19(木) 21:30:11

またかって感じだけど

858 ：デフォルトの名無しさん：2009/03/19(木) 23:15:27

なんかよよくわからんが、OOなプログラムと
OOな分析とOOな設計を一緒にはなしてないか？

o OO な分析
昔からハードやがやってたこととどこが違うの?
場合によるが、普通、まともな設計にたどり行かない
ものが動くときの本質を見誤ってる
端的な例は「名詞を探そう！！！」
名詞探してもものが動く分けじゃない

o OO な設計
昔からハードやがやってたこととどこが違うの?

再利用なんて、オブジェクトサイズがでかくなると
役に立たない

だったら、コンポーネント化
だけど、まともなコンポーネント作るには、賢い
奴等が少なすぎ

o OOなプログラム:
場合によってはとても有用

859 ：デフォルトの名無しさん：2009/03/19(木) 23:22:44

(；´Д｀)oOO(OOAとかOODって結局あまり流行らなかったね)

860 ：デフォルトの名無しさん：2009/03/19(木) 23:29:26

OOoOOOoooOってお前ら幽霊語でも話してるのか?

861 ：,,・´∀｀・,,）っ-○◎●：2009/03/19(木) 23:31:12

OOな設計＝トランザムで通常の9倍性能うめぇｗｗｗ

862 ：デフォルトの名無しさん：2009/03/19(木) 23:32:09

oops

863 ：デフォルトの名無しさん：2009/03/19(木) 23:34:31

OOのアプローチでもまだ属人性が高すぎるんだよね
例えば凝集度を高めつつ、結合度を低くするっていう原則があっても
それらのパラメータを形式的に定義できないとかさ
結局良し悪しを判断するのは人間じゃ駄目だよなー

864 ：デフォルトの名無しさん：2009/03/19(木) 23:46:34

客観的な測定方法がない

865 ：デフォルトの名無しさん：2009/03/19(木) 23:53:02

OOって結局、人間の観点からコードを概念の固まりとして設計する道具で
あえてそれ以上定義しないことで設計パターン発明の流動性を高めてるんだから
突き詰めれば人間の感覚に依存する手法なのは仕方ない。

そこらへんが形式化される（客観的評価が出来る）時って、
プログラマが必要なくなる時にかなり近いと思うが。

866 ：デフォルトの名無しさん：2009/03/19(木) 23:57:09

形式化されまくってるRDBMS+画面+帳票の世界でもPGが大量に使われてるんだから大丈夫だろ。

867 ：デフォルトの名無しさん：2009/03/20(金) 00:15:19

オブジェクト指向できちんと設計できるやつって
全体の何割よ？
2割もいねえよな

868 ：デフォルトの名無しさん：2009/03/20(金) 00:22:42

中途半端に技術がある奴だと、設計なしでも力技でプログラム作れるからねぇ。
逆に技術的には大したことない奴が、教科書的な綺麗なOO設計してる例は何度か見た。

869 ：デフォルトの名無しさん：2009/03/20(金) 00:27:05

何その自分擁護

870 ：デフォルトの名無しさん：2009/03/20(金) 00:34:26

特急グリーン車をお望みならばこちらへ
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx

871 ：デフォルトの名無しさん：2009/03/20(金) 04:10:44

結局規模が問題になるだけなんだと思うんだが
一人で数十行書けば済むコードならOOもへったくれもないし
数十万行ともなればどんなパラダイムであれそれなりのルールは必要

872 ：デフォルトの名無しさん：2009/03/20(金) 04:36:31

そうなんだけど、OOが生まれてきた背景には、既存の構造化プログラミングで作った
数十万行ものプログラムをきちんと作って保守していくのが大変だからじゃなかったかな。
OOでうまく継承したクラスがあればコード量が少なくなり、メッセージパシングでやりとりすれば
結合度が緩くなって、個々のオブジェクトをいじってもメッセージとその振る舞いさえ変えなければ
他に影響が及ばないということで、グループ開発も容易になるということだったと思う。
そこで「じゃあやってみっか」という流れになったと思う。

873 ：デフォルトの名無しさん：2009/03/20(金) 08:49:00

で
だめだったと

874 ：デフォルトの名無しさん：2009/03/20(金) 09:21:20

「だめな子は何をやってもだめ」を証明した、という当然のことを証明したわけだ。

875 ：デフォルトの名無しさん：2009/03/20(金) 10:18:14

SI業界なんて石器時代かそれ以前

876 ：デフォルトの名無しさん：2009/03/20(金) 10:23:17

コンピュータ言語の世界で偉大だった発明は関数だけか

877 ：デフォルトの名無しさん：2009/03/20(金) 10:40:34

関数よりスタックが偉大だった

878 ：デフォルトの名無しさん：2009/03/20(金) 12:16:49

このスレ読んでみたけど、何が正しい意見なのか、全くわかんね。
ある意見が出るとまず前提の否定の応酬が続いて、
それ以上遡れなくなると、結局とかつまりとかのネタレスという流れの連続。
マ一年生のおいらには難しすぎる流れだわ。
カレー食ってくる。

879 ：デフォルトの名無しさん：2009/03/20(金) 12:21:10

こんな所見るより
Object-oriented programming - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Object_oriented
とか、そこに載ってる各種参考文献に目を通した方がいい
基本的に質問スレ以外はネタスレだし

880 ：デフォルトの名無しさん：2009/03/20(金) 13:17:13

プログラムの部品化なんてシグマプロジェクトでも崩壊したしな

881 ：デフォルトの名無しさん：2009/03/20(金) 13:51:02

シグマプロジェクトの発想そのものはよかったし、プロジェクトの目指したところは
今現在のインターネットとLinuxをはじめとするOSSによって実現されてると思っていい。

ただ、国レベルでやってしまったので草の根レベルの開発者を巻き込めなかったのと、
予算獲得に群がるベンダーを制御できなかったのが敗因。

882 ：デフォルトの名無しさん：2009/03/20(金) 14:17:57

>>881
関係者乙

883 ：デフォルトの名無しさん：2009/03/20(金) 14:18:40

>予算獲得に群がるベンダー
国がやると大抵そうなってしまうのはなんでだろうね
なんのための補助金なんだか

884 ：デフォルトの名無しさん：2009/03/20(金) 14:21:30

>>881
> 予算獲得に群がるベンダーを制御できなかったのが敗因。

これが霞が関方面の目的ですからw
あのくらいの予算のプロジェクトなら今も無数に行われていて、
あれはUNIXがらみだったから世間にも名前が知られただけ。

885 ：デフォルトの名無しさん：2009/03/20(金) 14:35:44

>>884
つーか、揉めたことをつつみ隠さずバラしちゃうオッサンがいたから、というのが真相。

886 ：884：2009/03/20(金) 14:43:59

そうねw
向こうの人からみれば「お前は何を言っているのだ」だろうけど

887 ：デフォルトの名無しさん：2009/03/20(金) 14:44:40

>>883
日本は天下り社会主義共産国だから

888 ：デフォルトの名無しさん：2009/03/21(土) 09:27:33

>>872
OO語るんならSmalltalkくらい触っとけよ

889 ：デフォルトの名無しさん：2009/03/21(土) 11:40:15

とりあえず年功序列はやめろ。
５０のジジイより俺のほうが仕事が出来る。

890 ：デフォルトの名無しさん：2009/03/21(土) 12:12:26

で、50をすぎると既得権益を守るジジイになると。

891 ：デフォルトの名無しさん：2009/03/21(土) 12:46:10

50過ぎて新規開拓とか冒険出来る人を尊敬します

892 ：デフォルトの名無しさん：2009/03/21(土) 13:03:42

ジジイは新しいことが出来ないから必然的に若者よりも無能になるくせに、
サボる技ばかり磨いてほんとに使えない。
特に団塊世代は無能ぞろい。

893 ：デフォルトの名無しさん：2009/03/21(土) 13:14:51

ま、そのじじぃ達がいたから今きみらの仕事があるんだがな

894 ：デフォルトの名無しさん：2009/03/21(土) 13:18:12

ジジイが作ったものの保守とかじゃないよ。
新規開発。

895 ：デフォルトの名無しさん：2009/03/21(土) 13:20:57

確かに初等教育はジジィから受けたが、既にもらった知識より自分で学んだ知識のほうがはるかに多いし、
教育された分の借りは既に返してる。
何も偉そうにされるいわれは無い。

896 ：デフォルトの名無しさん：2009/03/21(土) 13:21:02

若者が活躍できる会社です、なんて書いているのはちょっと年取ったら使い捨てってことでも
あるしな。そういうのを強調している会社はどこか怪しい、やはり無理してる。
889みたいに素朴な世代間対立みたいなのを信じちゃうのがいるからだろうけど、自分も結局
は歳を取るわけで。
ある程度の年功序列がちゃんと機能する会社や仕事じゃないと、永続しないでしょ、なんて考
え出した俺も歳を取ったということか。

897 ：デフォルトの名無しさん：2009/03/21(土) 13:23:16

>>896
ジジイはジジイで自分たちにしか出来ないことを見つけて会社作ればいいし、
若者も年取ったらそういう会社に転職すればいい。
終身雇用とか年功序列とかクソだろ。
転職すりゃいいじゃん。

898 ：デフォルトの名無しさん：2009/03/21(土) 13:25:53

だいたい、歳をとったら新しいことに興味が無くなる、っていうのは迷信。
同じ仕事ばっかりしてたら何かに興味を持つ気持ちなんて沸いてくるわけがない。
時々転職とかしてリフレッシュしないとダメなんだよ。
年寄りだってまだまだ十分働けるところ見せてください。

899 ：デフォルトの名無しさん：2009/03/21(土) 13:28:18

でも転職が多い人間には厳しいのも現実

900 ：デフォルトの名無しさん：2009/03/21(土) 13:29:36

そういう会社に転職すればいい、という理屈は自分にも跳ね返ってくるよな。
若いならなおさら、「そういう会社に転職すればいい」のでは？
年寄りに出てってよ、なんて２ちゃんに書いている段階でダメでしょ。
ご自分の高い実力があれば、そういう会社からも引く手あまたなのでは？

901 ：デフォルトの名無しさん：2009/03/21(土) 13:40:54

>>893
がんばったのは団塊よりちょっと前の世代のひとたちだよ
団塊はバブルでおかしくなったひとたち
彼らがいなくなる5年～10年先までこの不景気は続く

902 ：デフォルトの名無しさん：2009/03/21(土) 13:41:46

糞談義はマ板でやれ

903 ：デフォルトの名無しさん：2009/03/21(土) 13:45:51

マ板向けネタが出てくるとは、もうネタ切れってことなんでしょうなあ

904 ：デフォルトの名無しさん：2009/03/21(土) 14:57:27

この程度の奴らが、「C++は駄目だ」、「OOは役に立たない」とか言ってても何の説得力も無い

905 ：デフォルトの名無しさん：2009/03/21(土) 15:07:43

実際金にならないなら役に立たないだろ。

906 ：デフォルトの名無しさん：2009/03/21(土) 15:13:23

>>904
「C++は（使えないから俺は）駄目だ」
「OO（も理解できない俺）は役に立たない」

907 ：デフォルトの名無しさん：2009/03/21(土) 15:17:06

じじぃがつかえねぇからおれが活躍できねぇってやつは、
じじぃがいなくても活躍できない。

908 ：デフォルトの名無しさん：2009/03/21(土) 15:30:07

まぁ、じじぃにもなってまだプログラム言語がどうのこうの
と言ってソースコードをシコシコ書いてるヤツは、
技術者と言うよりも人間として無能だろ？

日本の会社じゃぁ、30歳くらいになってエラくなってきたら、
普通、もうプログラムなんて書かない。

909 ：デフォルトの名無しさん：2009/03/21(土) 15:37:44

>>908
陶芸をしない陶芸家に価値はあるの?

910 ：デフォルトの名無しさん：2009/03/21(土) 15:45:08

>>906
ねえ？これまでこのスレで何を見てきたの？
なんでOOが要らないと思う奴の意見を尊重できないの？ｗ

911 ：デフォルトの名無しさん：2009/03/21(土) 15:47:17

尊重するに値しなければ尊重できない。

912 ：デフォルトの名無しさん：2009/03/21(土) 15:58:55

>>910
尊重してたら仕事にならない。
サンデープログラマなら一人で好きにやってくれてよし。

913 ：デフォルトの名無しさん：2009/03/21(土) 16:20:05

でもC++のメリットって説明できる奴いないよね
具体的な数字で語れる奴っていないのな
特に頭の悪い奴ほどC言語とC++とで同じことやるソースを比較したことがねぇもん
だからテキトーなこというから怖い

現実としてC++にしたからといって組まなくていい仕様ができるわけではない
仕様書に書いてあることはC言語でもC++でもどちらの場合も
実装しなくてはならない
つまり、この時点で大した違いはほとんどないと言っていいんだけど
仕事にならないまで言っちゃうってのはなんかこれ以上に大事な要素があるということだろうか？

914 ：デフォルトの名無しさん：2009/03/21(土) 16:26:22

STL使えないと面倒だねぇ。boostの一部も。

915 ：デフォルトの名無しさん：2009/03/21(土) 16:34:20

>>914
それって自分で関数作れば似たような仕組みできね？
仕組みだけならvoid*だっていいわけだし
いずれにしても工数に影響でるほどじゃないよね？

仮にそれが使える仕事だったとして
Ｃ言語の人が見積もった工数に対してどのくらい減らした工数で見積もることが可能なの？

916 ：デフォルトの名無しさん：2009/03/21(土) 16:36:02

WebKit見るだけで、C++がどれほど有益な言語かよく分かる。
ただしIT土方向きの言語でないのは議論の余地がない。

917 ：デフォルトの名無しさん：2009/03/21(土) 16:36:09

自分で作った関数なんて、怖くて使えない

918 ：デフォルトの名無しさん：2009/03/21(土) 16:38:24

コードよりもコードを導き出す過程により大きな差があるんじゃないかな
言語やそれにより使用可能なライブラリによって考え方が決まるとかそういうやつ
コードの比較もいいけど、そこに「何故このようなコードになるか」という説明もあるといいと思う

919 ：デフォルトの名無しさん：2009/03/21(土) 16:38:31

で？どのくらいの工数で見積もることができるの？
数字だせないでしょ？

仕事にならないとかいっちゃうぐらいだから１．５～２倍速ぐらいでできるの？

920 ：デフォルトの名無しさん：2009/03/21(土) 16:38:54

>>915
C++がどうのこうのいう以前に、頭が悪すぎて話にならない。自作てw
優れた良く使われているライブラリを使う効用が分からない時点で馬鹿丸出し。

921 ：デフォルトの名無しさん：2009/03/21(土) 16:40:52

>>920
でもそれは今求められてないよね？
今、求められてるのは工数の短縮の話
C++だと保証できるものってのは会社が求めてもいない安全性（？）でも追求してるのかな？
ちょっと的外れなんだよね

922 ：デフォルトの名無しさん：2009/03/21(土) 16:44:00

見積もり金額は変わらないと思うが、粗利は上がるwww

923 ：デフォルトの名無しさん：2009/03/21(土) 16:44:30

>>922
粗利が上がらない＝仕事にならない？

924 ：デフォルトの名無しさん：2009/03/21(土) 16:44:36

うちの会社のCOBLerと同じこというんだな。
「ソースは半自動で生成できるし、口数の見積もりも簡単。
まぁ時代の流れだからオープン系にならざるを得ないんだろうけど、
俺に言わせればCコンパイラの吐く機械語はキモい」

925 ：デフォルトの名無しさん：2009/03/21(土) 16:44:42

>>921
え？バグ含んでる可能性のあるコード作るより、
安全なライブラリ使った方が実工数少なくなるのは当たり前だろ？
「バグ作るかもしれないリスク」なんて項目は見積もりには入れないけどさ。

926 ：デフォルトの名無しさん：2009/03/21(土) 16:45:52

>>923
粗利が上がらない＝給料が出ない
wwww

927 ：デフォルトの名無しさん：2009/03/21(土) 16:46:06

>>925
そんなのテストで見つけていくらでも修正すればいいんだから
お前が心配することじゃないんだよ

928 ：デフォルトの名無しさん：2009/03/21(土) 16:46:30

不変条件を使って一部のテストの過程を吹き飛ばしたりできます
場合によっちゃ10倍どころの話ではなくなる

929 ：デフォルトの名無しさん：2009/03/21(土) 16:47:02

工数の世界の人はC++使わない方がいいぞ。
実際工数の世界からまともなC++アプリ、ライブラリが出てきた試しがない。

930 ：デフォルトの名無しさん：2009/03/21(土) 16:48:05

１０倍ねｗ
じゃＣ言語の人が見積もった工程の１０分の１でできますとお前そういえるの？

そりゃすげーやｗ
やってみろやｗ

931 ：デフォルトの名無しさん：2009/03/21(土) 16:48:18

>>927
末端PG的にははバグ改修が増えた方が残業代増えてウハウハだけどね。

932 ：デフォルトの名無しさん：2009/03/21(土) 16:48:51

なにおまいら盛り上がっちゃってるのｗ

933 ：デフォルトの名無しさん：2009/03/21(土) 16:49:48

だいたいさ
できるっていうほどに給料下がっていくじゃん
主張しないほうがいいんじゃない？ｗ

934 ：デフォルトの名無しさん：2009/03/21(土) 16:52:55

去年から社内システムの開発プロジェクトを Common Lisp ベースで
やってるんだけど、C++/Java より、はるかに開発効率いい。

C++ と C の開発効率はそんなに違わないって印象があったので、
最初は Java で試してたんだけど、こっちも今一だった。

CLOS の機能もそれなりに使ってはいるが、実質的には、クロージャ
とか高階関数の方が役に立ってる。

どうシステム化するかあたりから、手探り状態で始めたんだが、
・プロトタイプが成長して使い物になるシステムが出来上がる
・大きな要求仕様の変更があっても、バグが出てもシステム止めなくていい
ってのが、何よりありがたいw

935 ：デフォルトの名無しさん：2009/03/21(土) 16:52:58

工数を少なく見積もる意味が無いwww
工数は多く見積もり、少なく仕上げる物www

936 ：デフォルトの名無しさん：2009/03/21(土) 16:54:48

>>935
会社のメリットなんもねーじゃんｗ

937 ：デフォルトの名無しさん：2009/03/21(土) 16:55:36

>>936
お前はどの立場で見て発言してるんだ？

938 ：デフォルトの名無しさん：2009/03/21(土) 16:56:33

>>936
お前、赤字出すの得意だろwwww

939 ：デフォルトの名無しさん：2009/03/21(土) 16:56:36

>>934
昔からプロトタイプに向いている言語って言われていたからね。

それから高階関数ベースに再利用を進めるから、

> 実質的には、クロージャとか高階関数の方が役に立ってる。

ということになる。SICPの序文でも、
「Lispプログラミングでは有用で汎用性の高い関数がどんどんたまっていく」
と書いてある。

940 ：デフォルトの名無しさん：2009/03/21(土) 16:57:01

>>937
Ｃ＋＋なら１０倍速でできますと不穏な発言をする隣のチームを疑い深い目で眺めるとあるチームのリーダー

941 ：デフォルトの名無しさん：2009/03/21(土) 16:58:23

>>940
工数少なく見積もって出すようなら、今すぐリーダーを辞めろ。
会社のためにならねぇ。

942 ：デフォルトの名無しさん：2009/03/21(土) 16:59:53

>>940
よっ!!!デスマーチビルダー!!!
憎まれてるよ!!!

wwwww

943 ：デフォルトの名無しさん：2009/03/21(土) 17:04:05

C++でWebKitを使ってブラウザ作る
CでWebKit相当のものを作りながらブラウザ作る

10倍程度で済むの? 1万倍くらい?
後者なんて完成しないだろ。

944 ：デフォルトの名無しさん：2009/03/21(土) 17:07:42

>>943
ブラウザ? そんなもんどっかから買ってきて組み込むだろ？

945 ：デフォルトの名無しさん：2009/03/21(土) 17:08:42

>>944
その為のオブジェクト指向だろ?

946 ：デフォルトの名無しさん：2009/03/21(土) 17:13:15

別にＣ言語だってライブラリぐらいは呼ぶぐらいはいいだろ
呼ぶ箇所がちょっとＣ＋＋だからＣ＋＋使ってる！とか言い張るほど馬鹿なら話にはならないけど

947 ：デフォルトの名無しさん：2009/03/21(土) 17:16:48

>>946
健忘症?
>>915で自分で作ればいいって自分で言ってるんじゃないの?

948 ：デフォルトの名無しさん：2009/03/21(土) 17:18:22

>>915なんか絶対STL相当のコードなんて書けないよ。
文章から頭の悪さがにじみ出ているもの。

949 ：デフォルトの名無しさん：2009/03/21(土) 17:18:26

>>900
何か勘違いしているようだが、俺一人が得をすれば良いわけではない。
全国民にとって社会システムが平等に幸せを享受できるものでなければならないという考えに基づいて
社会システムにどういうルールを取り込めばそうなるのか、ということを考えているんだよ。
ゲーム理論っていうの？

950 ：デフォルトの名無しさん：2009/03/21(土) 17:18:57

>>947
は？そういう無意味な議論したいならdll組んでそれ呼ぶわ
ハイ、終了

951 ：デフォルトの名無しさん：2009/03/21(土) 17:21:13

Cでもできる、Cで充分と強弁しちゃう輩は、
OOPLとOOPを軽視しているのではなくて、
それ以前に、何についても何一つ分かってはいない。

952 ：デフォルトの名無しさん：2009/03/21(土) 17:21:49

dll作るの？めんどくせ。

953 ：デフォルトの名無しさん：2009/03/21(土) 17:21:55

>>951
で？工数はどのくらい変わるの？
Ｃ言語での見積もりの１０分の１？ｗ

954 ：デフォルトの名無しさん：2009/03/21(土) 17:25:22

>>953
よっ、デスマーチ職人!!!
怨まれてるよ!!!

955 ：デフォルトの名無しさん：2009/03/21(土) 17:26:47

>>942
ていうか発言内容がさっぱりわからない
なんで>>940のレスでそれなの？
会話が成立しねぇじゃん
頭悪いの？

956 ：デフォルトの名無しさん：2009/03/21(土) 17:27:59

>>955
オマエガナwwww

957 ：デフォルトの名無しさん：2009/03/21(土) 17:29:28

>>956
会話も出来ないクズはレスつけんなよ

958 ：デフォルトの名無しさん：2009/03/21(土) 17:32:59

大域変数を使わないっていう方法論に対して
「なんで？大域変数使った場合と、使わなかった場合でそんなに違いがあるの？」
って言ってるのと変わらんなぁ。

959 ：デフォルトの名無しさん：2009/03/21(土) 17:33:52

>>957
>>935を見て、会社の利益が無いといい
>>937にどの立場と問われ、>>940と答える
>>940は、多く見積もって、少なく作ると言ってるのを疑ってる立場ってことだろ?
つまり、少なく見積もって、多く作る人ってことだ

960 ：デフォルトの名無しさん：2009/03/21(土) 17:40:28

>>959
頭悪いじゃん

961 ：デフォルトの名無しさん：2009/03/21(土) 17:42:20

オブジェクト指向ってC++に限定されないパラダイムだからな。
今では C++以外でもJavaや Python, C#, JavaScriptなど主要な言語で
(サポートの幅の差はあるにしても)使われている考え方なわけで。
それをスマートに表現できないCは使いにくい。
Cで書かれてるプログラムを Lispで書くくらいに、違和感がある。

962 ：デフォルトの名無しさん：2009/03/21(土) 17:52:13

工数とかウンコ語使うなよ

963 ：デフォルトの名無しさん：2009/03/21(土) 17:56:23

大体、ソフトウェア開発に工数なんて言葉は使うな。

964 ：デフォルトの名無しさん：2009/03/21(土) 17:56:25

なんでここIDでないんだろ

965 ：デフォルトの名無しさん：2009/03/21(土) 18:04:31

>>961
Unix 系の OS のカーネルは C で書いてあるけど、Solaris とか *BSD の
ソース読むと、そこらの OO プログラマが屑に見えるくらい、きれいに
OO 的な設計をしてあって、コードもそれなりにスマートに表現されている。

OO 言語を使う/使わない以前にどんな風に抽象化するかが問題だと思う………

966 ：デフォルトの名無しさん：2009/03/21(土) 18:08:08

>>963
行数とかよりは適切な指標だと思うけど？
コストとかにすればおk？

967 ：デフォルトの名無しさん：2009/03/21(土) 18:20:26

ソフトウェアは工業品でなく芸術です
時間とかコストとかは無意味！

968 ：デフォルトの名無しさん：2009/03/21(土) 18:21:21

押して駄目なら引いてみろってか

969 ：デフォルトの名無しさん：2009/03/21(土) 18:29:44

　　　　　　∧＿∧ 　♪PG同士で争うなよ
　　　　　（　´∀｀）　 ♪仲間じゃないか～♪
　　　　　⊂(⌒)　つ　♪
　　　　　　　∪　ﾉ　　ランランラ～ン♪
　　Ｙ⌒Y⌒　∪

970 ：デフォルトの名無しさん：2009/03/21(土) 18:34:26

socket関連のソースはいつ見ても汚くみえる

971 ：デフォルトの名無しさん：2009/03/21(土) 18:35:13

そうだね

972 ：デフォルトの名無しさん：2009/03/21(土) 18:48:18

そんなことよりCLispベースでの開発で効率upってのが気になって仕方ない。
そういう話はよく目にするんだが、具体的な例を見ないんだよな。
そういうフレームワークや関数群のサンプル的なものを
公開しているところはないかな？

973 ：デフォルトの名無しさん：2009/03/21(土) 19:12:39

ttp://www.youtube.com/watch?v=aH3HaA_2lfU

974 ：デフォルトの名無しさん：2009/03/21(土) 19:17:01

>>965
それとこれとは直行した問題なのでは。
何を使っても優劣の差はあるというのは当たり前の話。
アセンブラでさえ美しいプログラムは美しい。

975 ：デフォルトの名無しさん：2009/03/21(土) 19:43:34

アセンブラのマクロで

976 ：934：2009/03/21(土) 19:54:18

>>972
> そういうフレームワークや関数群のサンプル的なものを

そんなもんは作ればいいし、扱う問題によってはよそで作った物が
使えるとも限らない。

関数ベースで書くから副作用を心配することはほとんどないんで、
動かしながらでも関数の再定義やったりとか、遅いと言われれば
実システムでプロファイルとってチューニングとかやってる。

取りあえず最小構成を作って公開して、実際に使う側の意見を聞き
ながら作り込みをやってる状態。

実運用やりながらだから、予期せぬエラーとかも早くつぶれる。

何度かクラス構成の変更とかする羽目になったが、その時でもシス
テムは停止させなかった。
update-instance-for-redefined-class って、長い名前の関数のおかげだw

若干、余分な手間は発生するけど、大きな手戻りは発生しない。

ただし、このやり方だと、どうしても少数精鋭になってしまう
システム規模はそこそこでかいけど C++ とかだと 20 人がかり程度
の規模を 3 人でやってる。

あんま、人と金かけられないって事情もあるけど………

977 ：.：2009/03/21(土) 21:02:54

ume

978 ：デフォルトの名無しさん：2009/03/21(土) 21:03:30

梅の季節

979 ：デフォルトの名無しさん：2009/03/21(土) 21:46:52

桜

980 ：デフォルトの名無しさん：2009/03/21(土) 21:55:07

きも

981 ：デフォルトの名無しさん：2009/03/21(土) 22:21:32

Rubyおわったな

982 ：デフォルトの名無しさん：2009/03/21(土) 22:25:58

Common LISPってOOなのか？

983 ：デフォルトの名無しさん：2009/03/21(土) 22:41:04

>>982
CLOSでググれ

984 ：デフォルトの名無しさん：2009/03/21(土) 23:46:04

iseg = ARGF.read
iseg = iseg.
gsub(']', 'end;').
gsub('[', 'while dseg[dx] != 0;').
gsub('+', 'dseg[dx] += 1;').
gsub('-', 'dseg[dx] -= 1;').
gsub('.', 'print dseg[dx].chr;').
gsub(',', 'dseg[dx] = $stdin.getc;').
gsub('>', 'dx += 1;').
gsub('<', 'dx -= 1;')

eval(<<INIT + iseg)
dseg = Array.new(32768, 0)
pc = 0
dx = 0
INIT

puts ''

985 ：デフォルトの名無しさん：2009/03/22(日) 00:32:21

この舌ったらずめが

986 ：デフォルトの名無しさん：2009/03/22(日) 00:47:45

>システム規模はそこそこでかいけど C++ とかだと 20 人がかり程度
>の規模を 3 人でやってる。
嘘くせえな。
というか、自己申告だから実際にみてみたらショボイプロジェクトってオチじゃないかな？

987 ：デフォルトの名無しさん：2009/03/22(日) 00:58:33

２０人だろうが３人だろうが一緒
一人で十分

988 ：デフォルトの名無しさん：2009/03/22(日) 01:40:49

SchemeでJavaのソースも生成したとかいう話とか見ると、
正直、うさんくせーとか思うけど、どうも嘘じゃないらしい。
といって、この手の話には必ずモノが存在していない。
ネットで聞いてみても「そういう風に書けばいかようにでも」的な回答しかない。
くやしい！でも…Gauche入れてみちゃう。

989 ：デフォルトの名無しさん：2009/03/22(日) 01:46:39

つmosh
gaucheでc++のコード生成してます

990 ：デフォルトの名無しさん：2009/03/22(日) 02:11:32

結論:closureでOK