07/12/28 15:13:40
closure で十分じゃんよ
2:デフォルトの名無しさん
07/12/28 15:17:54
>>1
クローじゃーってなあに？
3:デフォルトの名無しさん
07/12/28 17:43:05
オブジェクト指向⊃クロージャ
4:デフォルトの名無しさん
07/12/28 18:42:39
TMで十分、コンビネータで十分と言ってるのと変わらん。
なんでもできるのはいいことじゃない。
人はときには縛ってあげないと間違った道を選んでしまうんじゃよ。
5:デフォルトの名無しさん
07/12/28 18:50:39
てｓｔ
6:デフォルトの名無しさん
07/12/30 04:03:01
そんな貴方にアスペルガー指向プログラミング。
7:デフォルトの名無しさん
07/12/30 15:50:00
クロージャでクラスを模す事は出来るけど、一々それをコーディング
するのは面倒だし、出来たコードはコンパイラの支援も受けられず
非効率的。事前にクラスシステムをクロージャで用意しておくので
あれば、それはオブジェクト指向言語と変わらん。
8:デフォルトの名無しさん
08/01/04 02:08:24
OOスレ7 なぜオブジェクト指向は普及しないのか
ｽﾚﾘﾝｸ(prog板)
9:デフォルトの名無しさん
08/01/04 20:02:42
>>1はオブジェクト指向がコーディングスタイルの一種だと
勘違いしている。
10:デフォルトの名無しさん
08/01/04 20:50:42
>>1 ではないが >>9
> オブジェクト指向がコーディングスタイルの一種
ではない理由を説明してくれ。
11:デフォルトの名無しさん
08/01/04 23:17:25
>>9ではないが、
コーディングスタイルは言語仕様が確定された上で、どのように表現するかの問題で、
オブジェクト指向は言語仕様の中にあるものだから、明確にコーディングスタイルとは異なる。
12:デフォルトの名無しさん
08/01/05 00:27:51
単なるコーディングスタイルならOOPLなんて言葉存在しとらんだろしな
場面を絞れば制約のための工夫／広義のコーディングスタイルでも十分な設計できる事もあるからな
OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める馬鹿もいるし。いるっていうか、お
13:デフォルトの名無しさん
08/01/05 01:18:17
>>9 じゃないけど
Lisp系の言語にとってはOOなんて只のコーディングスタイル
の問題なんだが…
14:デフォルトの名無しさん
08/01/05 01:19:29
アンカー間違えた >>10
15:デフォルトの名無しさん
08/01/05 04:59:22
まあ C++ もコーディングスタイルの問題に済ませることもできるな。
でも、オブジェクト指向を仮定するといろいろな手法が導けるので、
コーディングというレベルでなくて、システム設計とかのレベルで考えるとメリット、デメリットがあるよな。
要するにチーム全員がオブジェクト指向を理解できるという仮定でシステム設計をするメリット。
ただ逆に、オブジェクト指向を理解できないプログラマというのが存在することを
考慮できるか否かが問題だとおもう。
構造型プログラミングの理解できないプログラマは排除できるのだが、オブジェクト指向を理解できない
プログラマを排除できないのが今の世の中。
16:デフォルトの名無しさん
08/01/05 11:12:00
>>13
それこそまさに>>12が
> OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める
の典型例と思われ。
17:デフォルトの名無しさん
08/01/19 14:02:19
そう言えばさ、オブジェクト指向って現場で役に立ってる？
オレオレオブジェクトまかり通ってて実質的には足枷になってる
ケースの方多い気がするんだけど…
つか、思ったことない？
「アフォはクラス設計するんじゃねぇ！！！」
18:デフォルトの名無しさん
08/01/19 14:05:48
>>17
> 「アフォはクラス設計するんじゃねぇ！！！」
このセリフには、本来オブジェクト指向は現場で役に立つという前提があるように思えるのだが。
19:デフォルトの名無しさん
08/01/19 14:07:03
JavaだろうがC#だろうが全然オブジェクト指向じゃないコードは書けるよ
ていうか書く人がいる
20:デフォルトの名無しさん
08/01/19 14:20:19
>>18
「そのように考えていたときが俺にもありました」って、過去形な
21:デフォルトの名無しさん
08/01/19 14:24:18
>>20
ならば、「アフォはクラス設計するんじゃねえ！！！」のかわりに
「クラス設計するんじゃねえ！！！」と言うべきじゃないかな。
22:デフォルトの名無しさん
08/01/19 18:20:46
効率の良いクラス設計の方法論って無いの？
23:デフォルトの名無しさん
08/01/19 18:24:36
>>19
いるねー。ほとんどのメソッドがstaticな人とか。
24:デフォルトの名無しさん
08/01/19 18:31:12
万能クラスを作ってしまうってのが一番多いな
25:デフォルトの名無しさん
08/01/19 18:32:47
>>24
本当に万能なクラスなら、ぜひソース公開してほすいｗ
26:デフォルトの名無しさん
08/01/19 18:48:03
かなり万能ですよ
ただし必要に応じて中にコードを追加するので成長し続けます
27:デフォルトの名無しさん
08/01/19 19:31:34
ときどき癌化するんだよな
28:デフォルトの名無しさん
08/01/21 01:20:57
Ｃプログラマ必須テキストです！
URLﾘﾝｸ(mori.eco.to)
29:デフォルトの名無しさん
08/01/21 02:44:58
>>25
神様クラスのことだろ
クラスは全部これを継承しろっていう
30:デフォルトの名無しさん
08/01/22 23:54:26
しかし、その神々しさに畏怖して誰も使わない罠。
31:デフォルトの名無しさん
08/01/23 02:46:53
万能クラスと万能ネギはどっちがより万能ですか？
32:デフォルトの名無しさん
08/01/24 18:06:17
概念的には万能クラスの方が万能だが、
それで飯をジェネレートできねーなら俺は万能ネギとりますねぇ。
あ、でも万能クラス一個あれば仕事全部やってくれんのかな。
揺らぐなぁ。
33:デフォルトの名無しさん
08/01/28 14:17:49
××があればほとんど全ての問題は解決する。
というキャッチフレーズに乗せられた人の如何に多いことか。
さあ、君も××に当てはめる言葉を考えて遊んでみよう！
34:デフォルトの名無しさん
08/01/28 14:35:06
お金があればほとんど全ての問題は解決する。
35:デフォルトの名無しさん
08/01/30 00:27:48
時間があればほとんど全ての問題は解決する。
36:デフォルトの名無しさん
08/01/30 00:31:18
真実の愛があればほとんど全ての問題は解決する。
37:デフォルトの名無しさん
08/02/03 06:28:58
愛＞金
飯＞愛
金＞飯
38:デフォルトの名無しさん
08/02/03 13:26:31
推移律が定義できないので順序構造が成り立たない件
39:デフォルトの名無しさん
08/02/04 01:23:23
・飯は食べないと何もできなくなるし病気とか治らない
ただし大金を掛ける必要はない。
・お金があればほとんど全ての問題は解決する。
・時間があればほとんど全ての問題は解決する。
だが効率が悪ければ十分な金は得られない。
効率良く真実の愛を得る方法もない。
・真実の愛があればほとんど全ての問題は解決する。
・お金があれば、ほとんどの真実の愛についての問題は解決する。
ただし、金で買えない愛もある。
また、効率を重視し過ぎると真実の愛と立ち向かえない。
以上の過程から重み付けを線形に評価すると、
金≦真実の愛（妥協含む）＞時間＞飯（ただし必須であることには変わりがない）
試みとしてはこんな程度だろうか。当然まだtransitibityを網羅できてる訳じゃなく、要素考察の礎に過ぎないが。
40:デフォルトの名無しさん
08/02/04 18:54:55
>>39
グラフ構造にしたほうがよくないか？
41:デフォルトの名無しさん
08/03/07 21:23:50
>>34, 35
無限大の金と時間があれば, 物理法則に抵触しない限り
何だって解決出来ると思うんだよもん
# 心の問題は別かもしれんが...
42:デフォルトの名無しさん
08/03/07 21:50:54
無限の性能を持った仮想のマシンを使って
無限の時間をかけて計算するってことなら
昔の数学者がやってたが
どうせなら無限の金より無限の才能が欲しい気がしなくも無い
43:デフォルトの名無しさん
08/03/07 21:54:46
「消えてなくなれ」というフレーズがジャンプの漫画みたいで恥ずかしい
44:デフォルトの名無しさん
08/03/08 00:27:21
ﾊ,,ﾊ
（ ﾟωﾟ ) 男割します
／ ＼
((⊂ ） ﾉ＼つ))
（＿⌒ヽ
ヽ ﾍ }
ε≡Ξ ﾉノ ｀J
45:デフォルトの名無しさん
08/03/10 23:12:45
ごめん聞いていい？
javascriptってオブジェクト指向？
46:デフォルトの名無しさん
08/03/10 23:33:56
>>45
クラスは無いけどオブジェクト指向だよ。
47:番組の途中ですが名無しです
08/03/11 02:11:52
なんでこんな糞スレがいつまでも残ってんだよ。
オブジェクト指向そのものについては、ここ読んどけ。
URLﾘﾝｸ(d.hatena.ne.jp)
48:デフォルトの名無しさん
08/03/11 08:04:06
var HogeClass={
fuga:function(){
},
hage:function(){
}
};
constructor/destructorが使えるのかどうかは不明
ああこれはstaticmethodだけか
49:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/04/19 23:08:10
OO = クラスが無限増殖するだけの糞手法
51:デフォルトの名無しさん
08/04/22 16:16:29
フロー制御やコーディング手法というのは、構造化プログラミングの話だろ
オブジェクト指向は、ライブラリ構築手法だと思うんだが
それはともかく>>4が、マゾであることは、火を見るより明らかなんだ
なんせ、縛って欲しい人なんだぜ
52:デフォルトの名無しさん
08/04/28 07:24:57
>>48はクラスとグローバルオブジェクトの違いがわかっていないアフォ
53:デフォルトの名無しさん
08/06/24 02:04:15
オブジェクト指向的に美しいプログラムとか、
オブジェクト指向的に正しい記法とか、
それで生産効率が下がったら目も当てられないよなぁ
54:デフォルトの名無しさん
08/06/24 05:47:52
>>53
下がった例なんてあるの？
55:デフォルトの名無しさん
08/06/24 18:52:13
OCPとかLSPとかを忠実に守ると、
爆発的にクラスは増えるし、ウザいことこの上ないな
適度にグローバル変数とか使ったほうが、生産効率上がることが多い
56:デフォルトの名無しさん
08/06/26 11:03:14
釣るなよ
57:デフォルトの名無しさん
08/07/11 10:43:53
オブジェクト指向って、プログラマの半分は理解してないでしょ？
58:デフォルトの名無しさん
08/07/12 14:12:44
理解していない奴？
95～98%くらいだと思うけど。
59:デフォルトの名無しさん
08/07/12 18:12:04
なんだその程度か
60:デフォルトの名無しさん
08/07/19 01:03:57
理解できてる人間なんて世界中に100人も居るだろうか?
って最近思うよ。
俺はもちろん理解できていないが、他人が理解できているかどうかは分かるつもり。
OOという言葉と概念を知って20年近く経つけど、
「この人はＯＯが理解できている」なんて思わせる人間には一度もあったことないよ。
61:デフォルトの名無しさん
08/07/19 08:47:47
>>60
まずは、近所のコンビニまで出かけることに挑戦しよう。
そしたら次は駅前まで買い物だ。
こうやって順に慣らしていくことで君もヒキコモリを卒業できる。
62:デフォルトの名無しさん
08/07/19 09:52:21
>>60
少し違う。ＯＯ自体には宗派(笑)が少なくとも三つある。教祖が三人以上いるつうことだ．
そしてそれぞれの宗派の理解度は層を成して存在する。
当然ながら、それぞれの最上位の理解者は教祖様（笑）だよ。
宗派は何ですか？
63:デフォルトの名無しさん
08/07/19 23:24:01
＞宗派は何ですか？
えーと、スンニ派（多数派）はどれなんでしょうか？
64:デフォルトの名無しさん
08/07/20 23:23:52
いったいどの宗派を信じればメシアが救ってくれるのだろう。
エッ、自力本願だから自分で努力するしかないの？そんなあ・・・(w
65:デフォルトの名無しさん
08/07/21 13:56:57
禅宗系だと、OO知れば知るほど何も判らなくなっていくんだろうな
色即是空
空即是色
一生悩み続ける運命
66:デフォルトの名無しさん
08/07/22 08:09:49
>>65
で、頓悟するわけですよ。「OOとは結局、糞コンサルと糞教祖の金脈でしかないのだ」とね。
67:デフォルトの名無しさん
08/07/22 11:22:32
>>62
三系統の“オブジェクト指向”を「北斗の拳」に例えてみる
URLﾘﾝｸ(d.hatena.ne.jp)
68:デフォルトの名無しさん
08/07/23 00:02:31
迷えるプログラマ達よ。あなたはOOを信じますか？
69:デフォルトの名無しさん
08/07/23 04:21:53
OOは宗教か技術かと問われれば、俺は宗教だと答えるね。
70:デフォルトの名無しさん
08/07/23 04:42:51
OOは企業の陰謀だよ
企業の陰謀にちょうどよかったから利用されたのさ
71:デフォルトの名無しさん
08/07/24 10:34:43
オブジェクト指向は必要ないと？ んなー
72:デフォルトの名無しさん
08/07/24 12:39:49
必要なところだけ使えばいい。
73:デフォルトの名無しさん
08/07/24 18:47:21
OOはどの経典を読んでもわかるようでわからない。
いくら説明されても空の意味がわからないのと同じようなものかもしれない。
しかし、空の意味がわからないと悟れないのでわかるしかない。
同じようにOOがわからないとプログラマは救われないのである。
修行するぞ、修行するぞ・・・・・・・・
74:デフォルトの名無しさん
08/07/24 22:47:01
経典やら宗派によって概念が違うみたいだからね。
75:デフォルトの名無しさん
08/07/27 14:37:41
言葉では説明できない。だから本読んだだけでは駄目。
OOは教えることはなく、各人がOOを学び得ることを目的とする。
・・・やはり宗教だね。
76:デフォルトの名無しさん
08/07/27 18:04:02
>>75
まさに自分で修行して悟らなければいけない小乗仏教の世界だなあ？
すると創始者のアラン・ケイは釈迦か？(w
じゃあ、また写経（サンプルプログラムを打ち込む）でも始めるか？
心が落ち着くなあ・・・・落ちつかねえよ(w
77:デフォルトの名無しさん
08/07/28 08:49:06
なんかまたSmallTalkの本が出てたけど、変わりばえしないね。
あいかわらず宗教臭いし著者が出してるライブラリの宣伝っぽい。
立ち読みだけでパスした。
78:デフォルトの名無しさん
08/07/28 14:36:02
ぶっちゃけ、そんなに難しくはない
79:デフォルトの名無しさん
08/07/28 14:58:49
良かったね。で、それを周りの人間全員に教えることは出来るのかい？。
80:デフォルトの名無しさん
08/07/30 09:30:14
たこ焼きの鉄板を使って、
材料を入れて
たこ焼きを作る
こんな感じ
つまり、鉄板をクラスで作り引数材料を加工してたこ焼きインスタンスの出来上がりだよね。
こんな感じの説明する人いるけど、混乱するでしょ。 はあ？ って。
81:デフォルトの名無しさん
08/07/30 11:28:20
>>80
その説明でよくわかるぞ。
たこ焼きの作り方が・・・(w
82:デフォルトの名無しさん
08/07/31 02:05:41
タイ焼きで説明した例は目にしたことあるよ
重要なのはオブジェクト指向の設計であって
オブジェクト指向のコーディングじゃないよ
オブジェクト指向のコーディングをオブジェクト指向の設計だと
勘違いしてる人をたまに見かけるけど最悪だよね
83:デフォルトの名無しさん
08/07/31 05:54:02
形にばかりこだわって本質に目を向けないものは真の悟りを得られないと φ(・＿・”）ﾒﾓﾒﾓ
えーと・・・・・どこの宗派かな？
84:デフォルトの名無しさん
08/07/31 09:16:15
オブジェクト指向をキッチリ理解していないと、
オブジェクト指向のコーディングなんてできん。
ってことですよ
85:デフォルトの名無しさん
08/07/31 14:30:57
オブジェクト指向って、オブジェクト指向の設計を肉付けしながら、
コーディングしてるから、コーディングも設計も同時進行なのであった。
86:デフォルトの名無しさん
08/07/31 18:18:15
オブジェクト指向言語の文法をしっかり記憶してオブジェクト指向を理解した気になる。
長いこと記憶重視の受験勉強していればそういうことになるよな。
だれか「試験にでるオブジェクト指向」とか「ここだけ押さえれば大丈夫。オブジェクト指向の傾向と対策」とかいう
本をだしてやってくれ（笑）
87:デフォルトの名無しさん
08/07/31 19:55:54
>>85
それは・・・オブジェクト指向の目標の一つであったかと思うが。
本当にそれが実現しているのかい？
「自分だけ」という状況でも立派なもんだが。
88:デフォルトの名無しさん
08/08/01 01:13:26
利用する側から作るので、クラスやプロパティやメソッドが先に列挙され、インプリメントが後から埋まるよ
前者を設計、後者をコーディングと呼んでるよ
名前も重要だよね
IOPtrって何を担当するクラス？ 想像しやすいネーミングにしようよ
89:デフォルトの名無しさん
08/08/01 20:40:31
>>77
黒くて厚い本？スモールトークの真髄というわりにはライブラリを使った話ばかり。
文章もなんだか無理に分量を稼いでるかんじだし。同じぐらいの厚さのスクイークの
白い本のほうがいいと思った。
90:デフォルトの名無しさん
08/08/09 17:10:58
消えて無くなれ？
魔法か何かで本当にオブジェクト指向消すことができたらどうなるのかなあ？
オブジェクト指向が無くなればオブジェクト指向で開発したプログラムは存在しなくなるから
世の大半のプログラムは無くなるなあ？
そりゃあえらいこっちゃ・・・・・・・
91:デフォルトの名無しさん
08/08/09 18:08:20
>>90
> 世の大半のプログラムは無くなるなあ？
組み込み舐めんなVC++厨。
92:デフォルトの名無しさん
08/08/13 00:22:36
組み込みって、スイッチのオンオフに毛が生えた程度でしょ？
93:デフォルトの名無しさん
08/08/14 20:51:59
毛がボーボーで元のスイッチが見えません
94:デフォルトの名無しさん
08/08/15 02:43:09
エーンベデッド
エンベーデッド
エンーベデッドおおー
95:デフォルトの名無しさん
08/08/28 02:19:08
スイッチのオンオフに毛が生えていないノイマン型コンピューターは全滅した！
「ぐふふ、これで勝ったと思うなよ。ぐふっ」
いんてる の しにがお は やすらか だった……。
96:デフォルトの名無しさん
08/08/29 09:12:55
>>95
組み込みってノイマン型なん？
97:デフォルトの名無しさん
08/08/29 09:16:32
あ、ノイマン型ではないってことか。 もめん。
98:デフォルトの名無しさん
08/08/29 22:53:22
消えてなくなれよ>オブジェクト指向わからない奴
99:デフォルトの名無しさん
08/11/09 18:24:28
>>98
激しく同意！ （←セリフ古いなｗ）
オブジェクト指向のメリットとして重要なものに、SE/PGテロの撲滅がある。
意図的に難読化、スパゲッティ化したプログラムで利権維持と工数水増しを図ろうとする
部落団体に支援されている派遣請負SE/PGの追放。
これは、クライアント企業の担当者や経営幹部、更には派遣元会社にも設計ドキュメントや
ソースコードが理解困難になる仕組みを悪用して寄生し、正規社員も苦虫を噛むテロ行為。
オブジェクト指向による高度な抽象化を行えば、上流から下流へは粒度だけの違いになり、
役員や幹部にも判りやすい記述になるので、従来のSE/PGのテロ行為が無力になるという
とても大きなメリットがある。
100:デフォルトの名無しさん
08/11/09 19:55:27
>>99
おまいマじゃないな。
101:デフォルトの名無しさん
08/11/09 20:56:24
まあ俺みたいな天才じゃないとオブジェクト指向を使うのは難しい
102:デフォルトの名無しさん
08/11/09 21:05:10
>>99
お前マじゃないし、しかもかなりできの悪い人間と見た。
底辺より悪いんじゃないか？
103:デフォルトの名無しさん
08/11/09 21:06:34
先生、ネタにそういう反応は無粋です
104:デフォルトの名無しさん
08/11/09 21:08:55
>>99
作為的にソースを理解困難にする事とオブジェクト指向とは何の関係もないよ
ソースにコメントを記述するだけで実際動作しているコードが読みにくくなるだろ
105:デフォルトの名無しさん
08/11/09 21:22:48
>>104
はははｗ、確かに偽コメントは「マ」にとって最高のオナニーだし威力あるだろうなｗ
ソースを保存し終えた途端に不敵な笑みを浮かべ、「グフフ・・・」と笑ってる「マ」の
姿は不気味で異様ｗ 他人事として見るなら面白い。
106:デフォルトの名無しさん
08/11/09 21:36:47
OOで実装するのはいいと思うが、
OOで設計するのはどうかと思う。
レベルが低い奴にやらせると、抽象化が不十分なモデルを組んできて、
しかも仕事の流れ上、それに逆らえなくなってしまう…。
107:デフォルトの名無しさん
08/11/09 22:41:22
なんか手順が違うな
要件が不足してるから不十分なモノができるんだろ？
108:デフォルトの名無しさん
08/11/10 07:43:14
>>106
そうそう。「実現不可能な実装のやりかけ」を設計と称して押しつけてくるw
109:デフォルトの名無しさん
08/11/10 09:08:03
オブジェクト指向は悪の枢軸
110:デフォルトの名無しさん
08/11/10 09:14:06
マルチパラダイム言語で使用可能な道具の一つ
って程度でいいよ
無くなれとまでは言わんけどOOが全てっていうのはちょっと
111:デフォルトの名無しさん
08/11/10 22:11:29
わざわざクラスにしなくていいものまで
クラスにしなければいけないキモさが嫌だ
かといってオブジェクト指向コードとそうでないコードが
混在してるのも読みづらくて仕方ない
つまりオブジェクト指向そのものが生理的に受け付けない
112:デフォルトの名無しさん
08/11/10 22:54:15
>>111
おまえオブジェクト指向理解してないだろ
113:デフォルトの名無しさん
08/11/11 16:44:38
C++で構造体の配列をつかわず、
クラスのvectorつかうって普通？
114:デフォルトの名無しさん
08/11/11 17:07:03
C++では配列は要素数固定なので
それで困る場合は vector 使うのが当然だろう。
115:デフォルトの名無しさん
08/11/11 21:50:06
Javaみたいな"融通の効かない"OOPLだと
デリゲートがなくてちょっとした亜種でも派生する必要がある
無駄なクラス増殖はいずれDRY原則の破綻を招く
プログラミングの入り口がJavaの人って、どんな言語でも無駄にクラス作りまくる傾向があってウザい
JavaのOO思想をOOのあるべき姿として布教されてるうちは「OOは生産的」論には賛同しねえ
よく見るJavaOO脳のミス
・安易に継承しまくってクラス増殖→仕様変更に弱くなる(熟練でもよくある)
・特殊な状況でも無理矢理デザパタを馬鹿正直にあてはめる(慣れてきた人によくある)
116:デフォルトの名無しさん
08/11/11 23:47:05
>>115
過剰継承もオープンプロテクトの一技法なんですね、わかります。
117:デフォルトの名無しさん
08/11/12 04:56:25
オブジェクト指向って元々は、基本的に同じ性質を持つ複数の実体を個別に扱う
ことを容易にするという発想から発展してきたんだけどなー。多数の個人情報とか
多数の契約書とか、多数の図形とか。。。
クラス定義はそのオブジェクト指向を表記するための便宜上の概念なんだけど、
オブジェクト指向の情報源は真っ先にクラス、継承などから説明して混乱を与えて
いるよな。
118:デフォルトの名無しさん
08/11/12 08:46:01
>>116
お前の世界だけの造語使われても意味がわからん…
119:デフォルトの名無しさん
08/11/12 11:51:43
>>115
>JavaのOO思想をOOのあるべき姿として布教
そんなこと言ってる脳足りんがいるんですか？
120:デフォルトの名無しさん
08/11/12 12:40:31
>>119
いくらでもいるだろ…
新人教育やってる奴に目を向けてみろ
121:デフォルトの名無しさん
08/11/12 12:42:50
C++やOcaml的な使える所だけOOというのがあるべき姿…と
122:デフォルトの名無しさん
08/11/12 20:54:26
>>121
どこにそんなことが書いてあるのか小一時間(ry
123:デフォルトの名無しさん
08/11/12 21:01:34
小一時間お茶しますか?
124:デフォルトの名無しさん
08/11/12 21:10:37
OOって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな
125:デフォルトの名無しさん
08/11/12 21:30:08
マクロって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな
126:デフォルトの名無しさん
08/11/12 22:24:31
マクロの挙動は定義を見れば分かるが、
テンプレートだの多重継承だの多用した結果
コンパイラ様が出すコードを想像するなど変態の技だ
だいたい、STLをまともにコンパイルできるコンパイラ
なんてないんじゃね？（笑）
127:デフォルトの名無しさん
08/11/12 22:34:58
>>123
可愛い女の子なら
128:デフォルトの名無しさん
08/11/13 01:32:13
STLやるぐらいなら
自分で言語作るわ
129:デフォルトの名無しさん
08/11/13 07:18:59
STLとオブジェクト指向の関係って？
130:デフォルトの名無しさん
08/11/13 11:09:13
OOPLとしても使用可能なC++の標準ライブラリの、さらに一部。
…関係ないと言えよう。
131:デフォルトの名無しさん
08/12/28 21:04:22
もうC++はOOPもできるテンプレート志向言語とか公言して良いんじゃないか
132:デフォルトの名無しさん
09/02/17 15:37:47
リレー回路はオブジェクト指向だよね
133:デフォルトの名無しさん
09/02/17 17:17:47
全然。
134:デフォルトの名無しさん
09/02/23 18:01:14
>>133
メッセージを伝えたら、バルブの開け閉めやら、過電流保護やら、照明やらしてくれるんだぞ
135:デフォルトの名無しさん
09/02/25 11:32:29
ハードウェアすべてが該当する件について
136:デフォルトの名無しさん
09/02/25 15:13:27
要はfacadeとかinterfaceというものなんだろうけど
それってOOPなの？
137:デフォルトの名無しさん
09/02/25 19:20:27
>>135
テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
分解して取り出せば別の用途に使えるが、取り外されたスイッチは既にテレビの電源スイッチじゃない
リレー回路のスイッチは、ポンプだろうがバルブだろうが関係ないONとOFFを制御するだけ
138:デフォルトの名無しさん
09/02/25 19:25:04
なんというgenericity…
139:デフォルトの名無しさん
09/02/26 10:45:19
>>137
>テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
ラジオの電源スイッチにも使えますね。
140:デフォルトの名無しさん
09/02/26 12:02:04
>>139
それは、ラジオの電源スイッチで、テレビの電源スイッチじゃない
仮に、テレビとラジオの機能を持った機械のスイッチだとすれば、それは、テレビの電源スイッチとは言えない
ラジオ機能付きテレビ(もしくは、テレビ機能付きラジオ)の電源スイッチだ
141:デフォルトの名無しさん
09/02/26 20:46:40
リモコンそのものはインスタンス。
Sharpのテレビを買ってきたら、付属するリモコンはその機種にしか使えない。
Sonyのコンポを買ってきたら、それに付属のリモコンはそれにしか使えない。
リモコンという抽象があって、リモコン付きの機械という抽象がある。
こういう考え方はどうでしょう？
142:デフォルトの名無しさん
09/02/26 21:53:16
>>141
抽象度が甘い気がする
むしろ、アンプやスピーカーなどバラバラに買ってくるコンポとか
AVシステムの方がオブジェクト指向だよね
143:デフォルトの名無しさん
09/02/26 21:58:55
現実の物引っ張ってきてオブジェクト指向だって言い張るのと、
それをオブジェクトモデルとして捉える(捉えられる)ことは違うんじゃないかな
144:デフォルトの名無しさん
09/02/26 22:09:08
リモコンはユーザインターフェースだけにインタフェースだね(そのまんま
ところで甘いっていうのはどういう程度を指すの
論理学の言葉を使えば弱いとか強いとかあるよね
ベン図で考えると狭い、広いとも言える
さて抽象度が甘いというのは
1.適用できる範囲が広すぎる
2.さらに汎化できる余地がある
どちらを指すのでしょうか？
145:デフォルトの名無しさん
09/02/26 22:49:56
>>144
2.だよ
146:デフォルトの名無しさん
09/02/26 23:08:19
リレー回路は、インターフェイスを継承して新しいインターフェイスも作れるし
動作内容も変更できるよ
そもそも、ハードワイヤードなプログラムだから
147:デフォルトの名無しさん
09/02/27 00:03:40
>>142
それはコンポーネント指向っていうんだお
148:デフォルトの名無しさん
09/02/27 00:17:35
>>137
あのな, on/off を伝えるメッセージ発信源としてかんがえるんだ
つか、オブジェクト指向ってハード屋がやってきたことの
＊＊＊＊＊劣化コピー＊＊＊＊＊
以外の何者でもない！！！
149:デフォルトの名無しさん
09/02/27 00:33:33
オブジェクト指向の利点は仕様をそのままクラスに反映できるってただそんだけだと思うな
ひねった抽象化したりしたらその時点で詭弁を使いだすイカレタ同僚と変わらないわけで
抽象化すればするほど利点が消えていくと思う
情報の共有化っていうの？
自分は他の誰かと仕事してるって感覚を身につけないと
一生わからんままテンプレート弄ってるＣ＋＋厨房と同じ道たどると思う
150:デフォルトの名無しさん
09/02/27 00:39:51
すっぽすっぽ先生の論文読んでから出直してください
151:デフォルトの名無しさん
09/02/27 12:06:45
あれだ、100％理解しないといけないと思ってるやつが駄目だ。
152:デフォルトの名無しさん
09/02/27 18:44:55
なんかへん
153:デフォルトの名無しさん
09/02/27 18:58:47
OO原理主義というか、シミュレーション主義なやつらがクソ。
現実世界をコード化、みたいなことに固執するやつら。
すなおにOOPしてればいいのに。
154:デフォルトの名無しさん
09/02/27 20:11:49
>>148
つ Software IC
155:デフォルトの名無しさん
09/02/28 02:26:55
現実世界はどうでもいいから
仕様書とクラスが１対１になっていればいいよ
サブのクラスはサブでコメント書いておきゃいいけど
とりあえず仕様書とプログラムがまったく一致してないような設計はダメだ
仕様書に書いてある物体ぐらいはオブジェクトにしてないと
オブジェクト指向の意味がまったくない
156:デフォルトの名無しさん
09/02/28 02:59:49
ようは入力の受付窓口と出力の出口の形を明確にする方法だろ？
と入門2ヶ月の俺が知ったかぶってみる
157:デフォルトの名無しさん
09/02/28 05:42:15
>>1
csosureたててんじゃねーぞ
158:デフォルトの名無しさん
09/02/28 05:44:11
オブジェクト指向を徹底すると可読性が著しく下がる件
159:デフォルトの名無しさん
09/02/28 06:03:08
>>158
それは君がヘッポコだから
160:デフォルトの名無しさん
09/02/28 10:47:55
オブジェクト指向の最大の功績は・・・
素人をプログラミングから遠ざけたこと。
OOPLだと、思いつくまま適当に書けばそれなりに動くプログラムが書きにくい。
だから、昔だったら自分でプログラムしたであろうような事でも
プロに依頼して、金を恵んでくれる。
そう考えると、シェルスクリプトで何でもかんでもできてしまう
UNIX/Linuxは職業プログラマの敵なのだ。
161:デフォルトの名無しさん
09/02/28 11:34:06
自称オブジェクト指向マスターって
引数中心で考えることを避ける人が多いような感じがする
しかもそういう人は「そこで発生させるべきでない副作用」をあちこちに散りばめる
162:デフォルトの名無しさん
09/02/28 11:45:41
副作用はCの文化だろｗ
163:デフォルトの名無しさん
09/02/28 12:13:47
ミスリード工作乙
164:デフォルトの名無しさん
09/02/28 14:50:40
>>161
それ、ただ単にOOが体得できてない「自称」OOマスターでしょ。
165:デフォルトの名無しさん
09/02/28 15:34:45
オブジェクト指向をもう少し機能や適用を限定させればいいんじゃないかな。
なんでもかんでもクラスにしないでこれはクラスにしなければダメだというものだけクラスにする。
166:デフォルトの名無しさん
09/02/28 16:11:49
おもしろいよね。
一人でプログラム組んでるときはC++の何でもできるってすごくうれしいのに
チームでプログラム組むことになるとマルチパラダイムの弊害が猛烈な勢いで襲い掛かってくる。
167:デフォルトの名無しさん
09/02/28 22:41:43
>>166
あのさ、class ってのが良くない
他人が作った class はドキュメントさえしっかりしてれば一応使えるけど,
現実には, ドキュメントはないわ, 抽象はでたらめだわ… で, どうしろとorz
Unix 系の C ライブラリの方が遥かにかわええわ!!!
168:デフォルトの名無しさん
09/02/28 23:14:39
「ええわ」でなく、「かわええわ」なのがふいんき(なry)でてる
70点
169:デフォルトの名無しさん
09/02/28 23:50:56
>>164
検討違いなツッコミどうも。
その自称オブジェクト指向マスターを沢山産んだのはオブジェクト指向自身なんだよ
カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ
本来意図されていた意味と違うとはいえ、カプセル化という言葉を広めてしまったオブジェクト指向の罪は重い
TDDがBDDに生まれ変わったように、オブジェクト指向も新しい何かに生まれ変わるべきだろう
170:デフォルトの名無しさん
09/03/01 00:07:07
>>169
> カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ
んだんだ！！！
オブジェクト内変数は呈の良いグローバル変数以外の何者でもない
get* とか set* の * にオブジェクト内変数名が使われているような
メソッドを大量に書く奴は、クラスを抽象化する時点で敗北してる
オブジェクトを現実世界のメタファーとして抽象する奴等は
*死* *ね* *ば* *い* *い* と思うよ
171:デフォルトの名無しさん
09/03/01 05:23:51
なるほど、そのへっぽこって君のことだったわけか。そりゃ見当が外れてた。
余計な副作用を残すのって、OO初心者がよくやる間違いだよね。
それを称してOOの罪というところがマヌケっつーか、、、、アホ？
172:デフォルトの名無しさん
09/03/01 05:24:42
>>170
で、そのオブジェクトはグローバルに参照できるの？www
173:デフォルトの名無しさん
09/03/01 10:53:10
>>170の適切な突っ込みにホッとした。
174:173
09/03/01 10:53:50
×>>170の適切な突っ込みにホッとした。
○>>172の適切な突っ込みにホッとした。
175:デフォルトの名無しさん
09/03/01 13:27:21
>>172
>>170ではないけど
>で、そのオブジェクトはグローバルに参照できるの？www
それはできないけど
メンバを大量に作るとグローバル変数と変わらない動作をするってのは俺はわかる
１クラスが異常にでかいソースにあたったときに苦労した
void setEdit()
{
transXXUnkoUnko(m_Bom);
}
void setEdit(int bom)
{
transXXUnkoUnko(bom);
}
単純に書くとこんな違いになるんだけど前者は追えるけど
後者はまったく追うことができない
176:デフォルトの名無しさん
09/03/01 14:07:15
>>175
しかし参照による相互作用はオブジェクト内におさまるよね？
プログラム全体がグローバル変数でガチガチに結合されるのと、
一応はオブジェクト単位に分離できるのとで、どっちがマシだと思う？
177:デフォルトの名無しさん
09/03/01 14:09:32
>>175
> void setEdit()
セッターがこのシグネチャってのは全く理解できないんですが。
> void setEdit(int bom）
1つのセッターで1つのメンバ変数にアクセスすることのどこが「大量」なのかサパーリ。
178:デフォルトの名無しさん
09/03/01 14:25:08
>>172
グローバルに参照したいから get* とか set* なんてアクセッサ作ってるんだろ
じっさいに名前空間切り替えることもせずに無節操にアクセスしてるしwW
179:デフォルトの名無しさん
09/03/01 15:52:53
おっとまた>>178が頓珍漢な返答を！
180:デフォルトの名無しさん
09/03/01 17:09:12
>>176
そりゃたしかにグローバルにしてしまうよりはいい
でも、そういうダメなものとどっちが・・・って議論をしたいんじゃなくて
そもそもこれってどーなのよ？
って言いたい
181:デフォルトの名無しさん
09/03/01 17:35:03
>>180
これ、とは？
182:デフォルトの名無しさん
09/03/01 17:45:53
昔、4つか5つの処理があれば何でもできると聞いたが、
オブジェクトはなんでこんなにややこしいの？
183:デフォルトの名無しさん
09/03/01 17:57:46
>>182
オブジェクトがややこしいんじゃなくて、
君の脳細胞が未分化なだけ。
184:デフォルトの名無しさん
09/03/01 17:58:33
>>180
それがわかれば、あとはオブジェクトの粒度を適切に設定すればいいんだ、ということに気付くはずだが？
185:デフォルトの名無しさん
09/03/01 18:11:03
つぶどってなんなんだぜ
186:デフォルトの名無しさん
09/03/01 18:13:37
>>184
粒度の問題なのか？と問いたい
だったらグローバル変数・関数だって小さいうちはアクセスしやすいし便利なだけだろ？
ただ、そのプロジェクトでの増加量を誰も予測できないから
やっぱりおかしくなってしまうわけで
俺がどう考えてるかというと
基本的にはメンバ変数ってのはダメなんだと思う
187:デフォルトの名無しさん
09/03/01 18:17:48
！？
188:デフォルトの名無しさん
09/03/01 18:18:55
クラスとインスタンスの違いが分かってない子の気配。
189:デフォルトの名無しさん
09/03/01 18:41:36
>>171
一人でコード書いてりゃいいニートと一緒にしないでくれよ
仕事でプログラム組む時は複数人でやるのが当たり前
お前の理想は現実とはかけはなれてる。そこわかってる？
190:デフォルトの名無しさん
09/03/01 18:49:31
>>184
他人が書いたコードも君は全て責任持って修正できる？
191:デフォルトの名無しさん
09/03/01 19:14:34
>>184
そこに明確な基準は無いよね
重要な部分を個々の考えに任せる時点でダメ
192:デフォルトの名無しさん
09/03/01 21:39:13
メンバ変数が追えないというヤツは関数内やファイルスコープ内の静的変数にもハマるだろう。
193:デフォルトの名無しさん
09/03/01 22:52:03
>>186
メンバ変数とグローバル変数とは全然違うぞ...
クラス内では、まるでグローバル変数のように見えるけどな
194:デフォルトの名無しさん
09/03/01 23:13:36
オブジェクトがたった一つなら、名前空間内のグローバル変数だけど、複数あったら事情が違うが。
195:デフォルトの名無しさん
09/03/02 00:04:59
>>191
個々の考えと言ってるうちは、何も理解してない
ということになってしまう。
196:デフォルトの名無しさん
09/03/02 00:07:54
だけど実際はクラスは大きくなってしまうわけで
そうなるとグローバル変数と変わらない動きをする
グローバル変数も管理できていれば問題はおきないってのは一緒なんだよね
でかいだけじゃなくて、１つのクラスを３つぐらいの使い方ができたり、
呼ぶ場所によって挙動を変えてるようなのもかなり複雑でまずい
197:デフォルトの名無しさん
09/03/02 00:16:27
>>196
int a, b;
としたとき、aとbの数値は連動するの?
a = 1;
としたら、bも1になってるの?
巨大化するクラスは、何かがおかしいと思うの...
俺みたいなニートなプログラマが気まぐれで作っているならともかく、プロが仕事で作っているのに1つのクラスが巨大化したら駄目でしょう
198:デフォルトの名無しさん
09/03/02 00:34:12
>>195
明文化された明確な基準のソースを示した人でなきゃそのセリフは吐けないはずだけど…
そうでないのに何コレ
199:デフォルトの名無しさん
09/03/02 00:38:36
グローバル変数と変わらないって言ってる意味が全く分からん
アクセサ経由でメンバ変数にどこからでも参照できるから、みたいなアホな意見？
200:デフォルトの名無しさん
09/03/02 00:42:03
staticか非staticかに関わらず複数メソッドから直接見える変数が存在することがダメって話…かと思いきや
違うのか
ちがわなければ同意
201:デフォルトの名無しさん
09/03/02 00:42:50
>>199
違うんだよ
１つのクラス内の関数同士の話
202:デフォルトの名無しさん
09/03/02 00:43:41
>>199
メイン関数まで内包してるような
超巨大クラスを想像しろ
メソッド同士が呼び出しあって動作する
203:デフォルトの名無しさん
09/03/02 01:03:54
>>201-202
怖い、怖いです...
冬なんですから怪談話は止めてください
204:デフォルトの名無しさん
09/03/02 01:08:53
ローカル変数もスコープ内のどこでも使えるから一緒ですか分かりません
205:デフォルトの名無しさん
09/03/02 01:11:38
オブジェクト指向を知らないまま、オブジェクト指向した末の惨劇ですね
206:デフォルトの名無しさん
09/03/02 01:48:54
信者共はあえてアホレスのみを捕まえて袋叩きにしたあと、
痛いとこついてるレスまでついでにまとめて
理解できない奴が悪いで済ませようとしてるけど
それでオブジェクト指向の暗黒面が消え去るわけじゃないだろ…
207:デフォルトの名無しさん
09/03/02 01:58:39
>>204
同じようになるよ
超長い関数で一番上でまとめて宣言されると
どこで使ってるかマジで不明
使う場所で適切に用意→破棄してくれと言いたい
でもＣ言語だとダメなんだっけ？
っていうかその前に長い関数作るなよと言いたい
208:デフォルトの名無しさん
09/03/02 03:36:46
ラッパークラスなんか超長い関数と同じ
生成期間も無駄に長い
209:デフォルトの名無しさん
09/03/02 05:41:58
ループカウンタとかどこで定義しようが何も問題無いだろ
210:デフォルトの名無しさん
09/03/02 05:49:46
忘れっぽいからさ。
使うところの近所で定義してもらわないと型とかあっさり忘れるんだわ。
老化が始まると全部関数の頭で定義なんてマジしんどい。
211:デフォルトの名無しさん
09/03/02 07:38:46
結局、メンバ変数を叩いてる人は、自分がプログラミング初心者ですと告白している、ということでFA？
212:デフォルトの名無しさん
09/03/02 09:07:23
>>211
とりあえずFPやってみろ
213:デフォルトの名無しさん
09/03/02 09:12:52
>>212
俺はMiranda, Gofer, SML, HaskellとFPやってきたが、>>211に同意だ。
OOを叩いている側の人間に明らかな技量不足が見える。
214:デフォルトの名無しさん
09/03/02 09:15:29
毎回アンチをひとまとめにして叩いてるあなたが言っても
自演にしか見えにゃーど
215:デフォルトの名無しさん
09/03/02 09:19:39
>>213
自由変数&mutableベッタベタだったのか…
216:デフォルトの名無しさん
09/03/02 09:23:18
>>214
技量不足以前に妄想性人格障害か。お大事に。
217:デフォルトの名無しさん
09/03/02 09:26:28
気軽にOOPを持ち込もうとして混乱する者どもの存在は分かった。
218:デフォルトの名無しさん
09/03/02 09:27:28
>>215
へー、Mirandaでどうやってmutableを実現するのか、説明してよwww
219:デフォルトの名無しさん
09/03/02 09:28:44
このスレには
他人のクラスの粒度どころかライセンス的に修正不可なソースまで修正できる自称スーパープログラマ(笑)
が沢山いるみたいだな
BREWとかどうすんのマジで
220:デフォルトの名無しさん
09/03/02 09:33:25
>>218
できないから移行(挫折)したんだろ？w
221:デフォルトの名無しさん
09/03/02 09:34:43
メンバ変数ってまでに広げたら、それこそ状態量を持つオブジェクトすべて指すようになってしまうな
流石にそれは極論だと思うので、もう少し範囲を狭めて考えてみる。
「グローバル変数と同じ」という性質を「何処で誰が触っているかわからない」ということだと仮定すれば
恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。
222:デフォルトの名無しさん
09/03/02 09:38:08
>>221
だとしても、そのオブジェクト自体がグローバルに参照されていなければ
メンバ自体がpublicでも「何処で誰が触っているかわからない」状態にはならないよね。
223:デフォルトの名無しさん
09/03/02 09:39:49
>>221
> 恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。
じゃなくて、もっとひどい。
>>201
> １つのクラス内の関数同士の話
↑このように、クラス、という静的な単位で困っている様子。
食べることが悪いんじゃない。
食べ過ぎることが悪いんだ。
メンバ変数が悪いんじゃない。
メンバ変数が多すぎたり、
クラス内の関数が多すぎたりでかすぎたりするのが悪いんだ。
224:デフォルトの名無しさん
09/03/02 09:55:22
そうか、全然読めてなかったよ
折角クラス内だけにスコープを止めても、そのクラス内がカオスだったら
人間が把握できない程度に複雑になる可能性があるという点ではグローバル変数と同じ
と解釈した
「とりあえずクラスにすりゃなんとかなるじゃんｗ」っていうような安直なOOPに対する批判なのかな？
225:デフォルトの名無しさん
09/03/02 10:02:21
逆にアンチOOPに訊きたいのは、
プログラム全体が1つのクラスになってしまうような巨大クラスは問題だ、という主張なんだよな？
まあ、それはそれでいいけど、
(1) そもそもクラスにしないで関数や手続きとして実装しても同じ問題になるし、
関数や手続きとして実装してうまくいくのなら、それをそのままクラスにしても、
それなりにうまくいくのでは？
(2) その巨大クラスのインスタンスは何個できるの？
もしインスタンスが多数できるのなら、参照関係の複雑さも多少は整理されているのでは？
ぜひ答えてほしい。
226:デフォルトの名無しさん
09/03/02 10:17:48
多少複雑さが軽減されるからといって、
把握できないぐらいのものが把握できないぐらいのものに変わっても意味ないよね。
OOPを使って複雑なものを人間が把握できる程度まで落し込めるような使い方じゃないと、
同じどころかOOAのコストの分だけ損になると思うよ。
こんな考え方でもアンチOOPになるんですか？
227:デフォルトの名無しさん
09/03/02 10:18:09
アンチはしらんが、どっちで実装しても同じならわざわざ手間のかかる
手段をとらなくていいのでは？
228:デフォルトの名無しさん
09/03/02 10:47:09
>>227
手間かけていないから巨大クラスになるんじゃねーの？
229:デフォルトの名無しさん
09/03/02 17:57:38
巨大クラスを作るってのは、オブジェクト指向が必要だとか不要だとか言う前に
構造化プログラムとは何かから始めないと駄目だと思うの
230:デフォルトの名無しさん
09/03/02 22:37:31
>>229
> 構造化プログラム
以前の問題で、
「自分が何をしなければならないか？」
の、分析ができてないんとちゃうん？
「作らんとあかん物の分析をやってない」
としか思えんのよ
231:デフォルトの名無しさん
09/03/02 22:55:58
つまりほとんどのプログラマはOO以前に構造化すら満足に出来てないと。
232:デフォルトの名無しさん
09/03/02 23:03:21
やはり構造化よりオブジェクト指向の方が頼りにされていたクライアんトとの戦いで
おれは納期に遅れてしまったんだがちょうどマネージャがわきはじめたみたいでなんとか耐えているみたいだった
おれは家にいたので急いだところがアワレにもCプログラマがくずれそうになっているっぽいのが携帯で叫んでいた
どうやらプログラマがたよりないらしく「はやくきて～はやくきて～」と泣き叫んでいるチームメンバーのために俺はオブジェクト指向を使って普通ならまだ出来ない時間できょうきょプログラミングすると
「もう出来たのか！」「はやい！」「きた！オブジェクトきた！」「メインプログラマきた！」「これで勝つる！」と大歓迎状態だった
233:デフォルトの名無しさん
09/03/02 23:03:41
クラス勉強し始めた初心者ですが、正直何でFunctionだけじゃダメなのか分かりません。
・Functionだけでも資産は後に再利用できる
・1ページの表示で同じクラスオブジェクトを複数作成する必要がない
・いちいちオブジェクトを生成するのが面倒
それでもオブジェクトの方が便利と言う方・・お話聞かせて頂けませんか？
234:デフォルトの名無しさん
09/03/02 23:20:41
>>232
日本語でどうぞ
235:デフォルトの名無しさん
09/03/02 23:22:06
>>233
そのコメントみてるとたぶんwebやってるんだろうけど
それくらいならオブジェクト導入してもしなくても良かろう
236:デフォルトの名無しさん
09/03/02 23:26:25
クラスが巨大になりすぎるからとかいってるやつって、
関数が巨大になりすぎたり、グローバル変数をポコポコ作ったりするやつでそ
237:デフォルトの名無しさん
09/03/02 23:27:02
>>233
ﾒﾝﾄﾞｲ。
とりあえず憂鬱なプログラマのためのオブジェクト指向開発講座を読んで、
なじまないと感じたなら以後はオブジェクト指向言語を避けろ
オブジェクト指向言語で無理に関数だけでプログラム組んでも馴染まないしな
言語の思想にあった手法を取るのが一番
避けようのない状況ならご愁傷様
238:デフォルトの名無しさん
09/03/02 23:31:26
>>236
> 関数が巨大になりすぎたり、グローバル変数をポコポコ作ったりするやつ
が、OO したつもりになると
「クラスが巨大になりすぎるので OOって意味ねぇ！！！」
言ってるじゃね？
239:デフォルトの名無しさん
09/03/02 23:34:04
コボラーのように罵られる存在になりたくないから皆必死にOOを守ろう
240:デフォルトの名無しさん
09/03/02 23:50:04
とりあえず比較的年配の方々で、やたら「オブジェクト指向」連発する人間は
信用できない。
241:デフォルトの名無しさん
09/03/03 00:57:51
>>235, >>237
アドバイスありがとうございました。
ActionScriptもいつの間にかClassが使用され
周りの言語は、全部オブジェクト指向を取り入れて行っているような気がしてなんだか焦りますね。
そのうち、オブジェクト指向出来ない人は、ハイさようならになりそう。
「憂鬱なプログラマのためのオブジェクト指向開発講座」もちょっと読んでみることにします。
その他、効率の良いクラスの設計の仕方など、参考になる本はありますでしょうか？
242:デフォルトの名無しさん
09/03/03 01:08:43
>ActionScriptもいつの間にかClassが使用され
昔というか最初からClassだったよ
直接見えなかっただけで
243:デフォルトの名無しさん
09/03/03 04:12:48
今も昔もプロトタイプベースだよね＞AS
クラスベースちっくに書いたりパフォーマンスを得るために
文法とか内部実装とか工夫しているだけであって。
244:デフォルトの名無しさん
09/03/03 06:28:52
>そのうち、オブジェクト指向出来ない人は、ハイさようならになりそう。
っつーか良く出来たフレームワークは
オブジェクト指向を特に意識しなくても
だれでも使える構成になってたりするが
245:デフォルトの名無しさん
09/03/03 06:31:19
あー使う側の立場だけ考えるとそうだけど作る側ならあれだね
246:デフォルトの名無しさん
09/03/03 11:17:55
>>242, >>243
ああ・・・そういえば、インスタンスを作成するって昔からありましたね。＞AS
クラスを意識させない方向だっただけなんですね。
247:デフォルトの名無しさん
09/03/03 12:39:39
>>241
「オブジェクト指向でなぜ作るのか」が比較的わかりやすくていい。
あとは、これとか。
URLﾘﾝｸ(kmaebashi.com)
これかな。俺も勉強始めたばかりなんでなんだが…。
URLﾘﾝｸ(www.stratagenom.com)
248:デフォルトの名無しさん
09/03/03 12:54:26
>>246
インスタンスを生成するのはクラスベースの専売特許ではない。
プロトタイプベースでもインスタンスは生成できる。
249:デフォルトの名無しさん
09/03/03 13:33:11
>>247
一個目のリンク先、わりと意欲的な文章だと思う。
OOPが分からない人々に対して、まず最初に、
インスタンスについて強調するのは大事だと思う。
250:デフォルトの名無しさん
09/03/03 16:04:15
>>246, 248
というかそもそもAS1、AS2にクラスなんてあったのか。
AS2のclass宣言はprototype云々を書く手間を省くだけの
省略記法程度のものだと思っていたんだが。
251:デフォルトの名無しさん
09/03/03 17:32:59
>>248
インスタンスの無いプログラミング言語なんて無いだろう...
252:デフォルトの名無しさん
09/03/03 17:46:58
>>251
primitive typeの値は普通インスタンスとは呼ばない。
253:デフォルトの名無しさん
09/03/03 17:52:15
え゛？
254:デフォルトの名無しさん
09/03/03 17:55:49
>>252
おいおい...
255:デフォルトの名無しさん
09/03/03 17:57:36
>>251
Cには、オブジェクトはあるがインスタンスはない。
256:デフォルトの名無しさん
09/03/03 18:05:58
>>255
インスタンスは意識してプログラムしないと碌な事がないよ
特にC言語の場合...
257:デフォルトの名無しさん
09/03/03 18:20:25
schemaとinstance、classとobject、typeとvalue、他にもあるかな。
定義無しでインスタンスという単語を使いたいのであれば、ざっくり
いって上記の組の右の単語を「インスタンス」の一言で括った程度
のものではないかと。
単語の使い方としての慣用は確かにあるけれども、きちんとした
定義無しに言語内での有無を論じられるようなものではないよ。
258:デフォルトの名無しさん
09/03/03 20:02:39
メモリ上の具体的な「オブジェクト」と、OOの「オブジェクト」は意味が違うだろ
後者は前者を内包することはあるが、一緒にして語ってる時点でおかしい
259:デフォルトの名無しさん
09/03/03 20:04:22
インスタンスとエンティティの違いについて教えてくだされ
260:デフォルトの名無しさん
09/03/03 20:11:31
classとentity
261:デフォルトの名無しさん
09/03/03 20:19:11
>>257
>きちんとした
>定義無し
だからこそ
>言語内での有無
は「言語仕様にあるか、ないか」しか言えない。
あれだ、「Javaにもポインタがある」つってる奴と一緒。
262:デフォルトの名無しさん
09/03/03 20:40:33
インスタンスって、オブジェクト指向云々に関わらず
メモリ上で実行されているプログラムそのものの事を言うもんだと思っていたが
263:デフォルトの名無しさん
09/03/03 21:23:45
エンティティってなに？
264:デフォルトの名無しさん
09/03/03 21:52:39
オブジェクト指向をコーディングだけにあてはめようとする奴と、
分析・設計からを理解してる奴が話すと
当然ながら噛み合わないな
265:デフォルトの名無しさん
09/03/03 21:58:05
分析・設計から理解してると
普及するのは自然な事だと納得できるし、受け入れやすいんだがなあ
266:デフォルトの名無しさん
09/03/03 22:06:19
北大路欣也
267:デフォルトの名無しさん
09/03/03 23:04:27
１つの機能に関するファンクションを
パッケージにできるだけでもありがたいのにな。
忌み嫌うわけが逆にわからん。
268:デフォルトの名無しさん
09/03/03 23:57:30
>>267
それはただのモジュール化との違いを説明できんのか
269:デフォルトの名無しさん
09/03/04 00:09:36
機能と状態をセットでパッケージ化できるわけで。
270:デフォルトの名無しさん
09/03/04 00:30:16
オブジェクト指向は、ウェブページだと利点を生かし切れない場合も多い気がする
271:デフォルトの名無しさん
09/03/04 00:33:19
構造化プログラミングの体質のままオブジェクト指向を導入すると、
必要とは思えないのは当たり前だ。
ジジババがネットの必要性を感じないのと同じ。
272:デフォルトの名無しさん
09/03/04 00:34:38
Webページのオブジェクト指向ってなんだ？Webプログラミングのことか？
273:デフォルトの名無しさん
09/03/04 01:03:56
>>268
検索機能なんかを考えればわかるのでは?
単純にモジュール化しても、ただの関数の集まりとしてしか扱えない上に、肝心な検索結果を保持する場所は人任せになる
クラス等を利用すれば、検索結果を中心に関数をモジュール化でき、検索結果の保存場所をどうするのか利用者が気にする必要が無くなる
274:デフォルトの名無しさん
09/03/04 01:20:04
>>273
それはただの抽象データ型でしょ
あとクラス使わないと出来ないなんてことはない。
例えば C言語のストリーム入出力だってファイルアクセスの関数を
モジュール化でき、ファイル管理データ(FILE型構造体)の保存場所を
どうするのかを利用者が気にする必要がなくなってる。
275:デフォルトの名無しさん
09/03/04 01:45:41
>>272
ホームページ作成でPHP等でオブジェクト指向を取り入れること
276:デフォルトの名無しさん
09/03/04 02:13:09
>>274
さらに付け加えれば、非標準ながら
fdopenやfmemopenによって多態性も実現できていると言える。
277:デフォルトの名無しさん
09/03/04 03:42:01
オブジェクト指向の必要性なんて、「IntelliSenceしやすくなる」で十分すぎるだろ。
278:デフォルトの名無しさん
09/03/04 03:59:45
あまりオブジェクト指向関係ないと思うよ。
型付けが静的か動的かの違いの方がでかいでしょ。
279:デフォルトの名無しさん
09/03/04 06:49:18
>>274
だよな
>>269 >>273 は
>>247 を読んでないよ
280:デフォルトの名無しさん
09/03/04 06:51:25
>>270
一番の原因は毎回接続しなおしてること
実際はCookieでごまかしてるが
httpのプロトコルが糞で
オブジェクト指向の普及を妨げてる
281:デフォルトの名無しさん
09/03/04 07:03:36
>>263
ぐぐれかす
282:デフォルトの名無しさん
09/03/04 07:27:57
PL上の概念としての「インスタンス」の話をしているときに分析設計での「インスタンス」を持ち出されてもw
283:デフォルトの名無しさん
09/03/04 07:35:42
いや～、HTTPをクソ呼ばわりするのは結構蛮勇が必要だと思うな。
何に対して憤っているかよく判らないけど。ステートレスなところ？
284:デフォルトの名無しさん
09/03/04 07:40:16
>>280
ひょっとしてHTTPリクエストを出す度にsynパケットが飛んでると思ってる？
285:デフォルトの名無しさん
09/03/04 11:17:39
Cでもできる系の話は聞き飽きた。
そりゃ、できるだろうよ。
C++の最初の実装はC Frontなんだし。
大事なのは、俺様ルールでバラバラな実装をするのか、
言語仕様による統一的ルールでやるのかということだ。
286:デフォルトの名無しさん
09/03/04 12:04:27
>>274
ファイルを扱うためには、少なくともFILE型が必要である
FILE型を扱うためには、専用の関数が必要である
それらの関数をFILE型に閉じ込めておければ便利だと思わないか?
file++とか、file--とか、file + nとかで、ファイルポインタを制御し
*fileでファイルポインタの位置にアクセス出来きたりした方が便利な気がしないか?
まあ、*をオーバーロードしちゃ美味くないけどな
287:デフォルトの名無しさん
09/03/04 12:38:59
>>273 >>286は根本的にオブジェクト指向が分かっていない
コンポーネントにどういう責務を持たせるかが重要なのであって、
「ユーティリティクラスみたいなのがあれば便利だよね」、
とか言いだすのはインターフェースの切り出しができない奴の典型
288:デフォルトの名無しさん
09/03/04 12:51:26
>>287
何を言っているのか判らない...
検索オブジェクトが検索結果を持たないのが責務って事?
ファイルオブジェクトは、ファイルを扱わないのが責務って事?
289:デフォルトの名無しさん
09/03/04 13:19:31
出た！ それでは、
根本的にオブジェクト指向が分かっている>>287さんに色々語ってもらいましょう。
290:デフォルトの名無しさん
09/03/04 13:39:26
phpって、元々classを使うことを前提に作られてない点がJavaなんかとは違うよね？
こういうスクリプト言語が大普及しているから、オブジェクト指向使わない・・や
必要性を感じない人が多いんだと思う。
291:デフォルトの名無しさん
09/03/04 14:29:51
emacs lispなんてもうね…
292:デフォルトの名無しさん
09/03/04 16:29:57
ひどいオブジェクト指向の例なら、Perl 5に勝てるものはいないだろ。
293:デフォルトの名無しさん
09/03/04 16:41:36
>>290
単にカジュアルプログラマへの動機付けの問題であればそれも
答えとしては十分なんだけど。
設計論に対する意見の違いもあるし、プログラマの世代差とか
属人的な要素も絡んで実際はそこそこ根深い話だと思う。
1980年代だったか月刊ASCIIでオブジェクト指向を取り上げた
記事を読んだときには今でいうちょっと前のWeb2.0とかクラウド
みたいな胡散臭さをプンプン感じた記憶がある。
「次の波はこれ！ソフトウェア危機もこれで一発解決」みたいな。
294:デフォルトの名無しさん
09/03/04 16:49:32
オブジェクト指向って別に効率的じゃないじゃん。
295:デフォルトの名無しさん
09/03/04 16:53:01
かつて、「オブジェクト指向」という単語は「再利用」という単語と強く結びついていた。
特に出版界で。
296:デフォルトの名無しさん
09/03/04 17:24:46
>>294
効率的だし再利用によってプログラミングの生産性は劇的に向上する、
と「期待されていた」んだよ。
「21世紀には社会で必要とされるプログラマ数が世界人口を超える」
そんな危機意識が語られていた時代もありました。
297:デフォルトの名無しさん
09/03/04 18:46:49
オブジェクト指向の話題では、大別すると２つの内容になる
ひとつはここにも多数存在する、言語うんぬんの話
もうひとつはオブジェクト指向根幹の分析・設計の話
オブジェクト指向の最大の利点は、
分析から設計、コーディングまでの設計外観を統一できるということ
分析や設計にオブジェクト指向を利用してこそ、
オブジェクト指向対応の言語を使うメリットがある
そういうことを理解してない奴が、言語うんぬん言いだす
一番の問題は、分析者・設計者がオブジェクト指向を利用していないくせに、
要件定義の時点でなぜかオブジェクト指向言語を採用してること
298:デフォルトの名無しさん
09/03/04 19:03:15
オブジェクト指向って一つの作業を一つ又はいくつかのオブジェクトだけを使って行えるようにする為のもんだろ。
だからある程度の汎用性を持たせられるインターフェース、実装を考えれば使いまわしができる。
そうすると長期的な生産性が上がるってことだったと思うんだが。
だから適当に作ったり下手くそな設計だと逆に使いにくくて当然。
299:デフォルトの名無しさん
09/03/04 19:03:53
>>297
> 分析から設計、コーディングまでの設計外観を統一できるということ
できねぇよ
少なくとも, 時系列のデータを扱う場合、単純に、
「お前らが言うオブジェクト設計」
を、やったら負けだと思う
関わった中では、とろくて使いもんにならんものが………
ハード屋よろしく
「ブロック図書いて、各ブロックの機能要素求めて、タイミングチャート
書いて、デッドロック要素見つける」
程度の事前検証ゐしないと、納期までにまともな動作は期待できない
ものによったら、伝達関数とかまで出てくる現場ではあるんだが
300:デフォルトの名無しさん
09/03/04 19:07:18
>>298
インターフェースの設計が分かってないだろ
ある程度の汎用性を持つインターフェース、ってなんだそりゃ？
コンポーネント間でどうしても必要な場合に、
やり取りとしてインターフェースが存在するんだぞ
301:デフォルトの名無しさん
09/03/04 19:15:23
指向とは言うけど何が指向性を持っているかが不明
302:デフォルトの名無しさん
09/03/04 20:22:50
>>300
やり取りする為以外にインターフェース存在するのかよ。
今やりたいことを達成すればいい設計にするのか、
それとも今は必要無いかもしれんけど、この先使いまわす時に必要になる事も考慮するのかって事だよ。
303:デフォルトの名無しさん
09/03/04 20:57:02
300 のインターフェースは URLﾘﾝｸ(e-words.jp)
298 のインターフェースは URLﾘﾝｸ(msugai.fc2web.com)
304:デフォルトの名無しさん
09/03/04 21:08:44
OOAとOODとOOPをごっちゃにして放言しているから収拾がつかない。
305:デフォルトの名無しさん
09/03/04 22:19:41
根本の考え方は、プログラムの生産性をより高めていこうってことで
言語の発展の流れとしてはごく当たり前で受け入れやすいと思うのに
まず「オブジェクト指向」って翻訳が悪い気がする
かといって良い言い方も思いつかないが
306:デフォルトの名無しさん
09/03/04 22:28:39
>>286
274は「Cでできるからオブジェクト指向言語なんて不要」と言っているようには見えないのだが。
307:デフォルトの名無しさん
09/03/04 23:21:31
>>302
拡張性の話とインターフェースの話を一緒にするから突っ込まれてることに気がつけよ
なんか、「JavaやってるんでOO理解してます」ってな奴が多すぎ
308:デフォルトの名無しさん
09/03/04 23:46:08
オブジェクト指向の真の意味を理解しているのは俺様だけだな、
っつーやつばかりだな。
309:デフォルトの名無しさん
09/03/05 00:55:29
てか、レベルの低いやつほど
『オブジェクト指向を馬鹿にしているやつは「Cでできるからオブジェクト指向言語なんて不要」なんて言っているから馬鹿なんだ』
なんて言うんだよな・・・
関数型言語とかもっと違う方向には目が向かないのかね、こういう輩は。
大体ソフトウェアの世界なんてまだまだ混沌としていて何が正しくて何が正しくないのか誰もわからないんだから、
あまり人が言っていることを馬鹿にしないほうがいいよ。
どうせまだ誰も正しいことなんてわかりっこないんだから。
少なくとも歴史が長い物理学よりはずっとやってることが原始的。
310:デフォルトの名無しさん
09/03/05 01:05:55
そこでわざわざ物理学を出すのはどうかと思う。
物理学に失礼すぎる。
311:デフォルトの名無しさん
09/03/05 01:37:46
>>310
そこの部分は、>>309の話の中で、彼の発言の趣旨から外れた一番どうでもいい部分。
何故そこを拾って取り上げようとするのかな？ もっと全体像をとらえようよ
312:デフォルトの名無しさん
09/03/05 03:12:58
>>311
自分だってどうでもいいと思ったから取り上げた。
そんなこと蛇足にすぎない、書かないほうがよかったぞという思いを込めて。
313:デフォルトの名無しさん
09/03/05 03:23:56
>>309
>てか、レベルの低いやつほど
>『オブジェクト指向を馬鹿にしているやつは「Cでできるからオブジェクト
>指向言語なんて不要」なんて言っているから馬鹿なんだ』
>なんて言うんだよな・・・
ここと、
>関数型言語とかもっと違う方向には目が向かないのかね、こういう輩は。
ここの話の繋がりを分かりやすく教えて下さい偉い人。
俺にはさっぱりだ。
314:デフォルトの名無しさん
09/03/05 07:39:10
>>309は岡村を知らないモグリ
315:デフォルトの名無しさん
09/03/05 15:44:08
>>314
岡村って知らないんだけど、何やってる人？
316:デフォルトの名無しさん
09/03/05 16:06:06
芸人長いことやってる
317:デフォルトの名無しさん
09/03/05 19:06:56
>>241
> 「憂鬱なプログラマのためのオブジェクト指向開発講座」もちょっと読んでみることにします。
>>247
> >>241
> 「オブジェクト指向でなぜ作るのか」が比較的わかりやすくていい。
「憂鬱本」と「オブジェクト指向でなぜ作るのか」は、今となってはあんまり良くない。
URLﾘﾝｸ(d.hatena.ne.jp)
> あとは、これとか。
> URLﾘﾝｸ(kmaebashi.com)
これはオススメ。
318:デフォルトの名無しさん
09/03/05 19:36:57
カモノハシ本たけーよ。
319:デフォルトの名無しさん
09/03/05 19:40:57
オブジェクト化すると責任の所在がハッキリするよね
320:デフォルトの名無しさん
09/03/05 20:34:49
オブジェクト指向も設計実装の道具のはずなんだけど
理解が難しいのが問題では？
使いづらい道具は人は使わないですし本来道具は使いやすさが
重要だとおもうのですが
321:デフォルトの名無しさん
09/03/05 20:37:07
定義が曖昧なのも問題
322:デフォルトの名無しさん
09/03/05 20:59:59
オブジェクト指向ですら難しいという人はプログラマ向いてない。
323:デフォルトの名無しさん
09/03/05 23:34:06
オブジェクト指向の考え方は何となくわかるが、小さいプログラムだと今までのやりかたの方が簡単に組める。
どうしても必要にならないと本気で使おうと思わないんだよね。
高速に動かしたいところはやっぱりCになっちゃうし。
ま、確かに俺はプログラマ向いてないと思う。
324:デフォルトの名無しさん
09/03/06 00:13:47
オブジェクト指向は、必要なければ使わなくても良いんじゃないかな？
そういう人のために、オブジェクト指向使わなくても利用できる言語やスクリプトあるわけだし…
ま・・俺もむいてないけど、適度に出来る程度で十分な案件だけやってるw・・・全部一人でwww
325:デフォルトの名無しさん
09/03/06 00:47:20
オブジェクト指向は、必要なければ使わなくても良い
326:デフォルトの名無しさん
09/03/06 00:52:14
オブジェクト指向は、仕事に困らないのであれば使わなくても良い
327:デフォルトの名無しさん
09/03/06 01:30:28
ぶっちゃけC++やC#使えればよくて
オブジェクト指向を使う必要はない
328:デフォルトの名無しさん
09/03/06 01:33:15
まあ、stlやboost使える程度に知識があれば
厳密の意味でのオブジェクト指向なんて別にいらんよな。
329:デフォルトの名無しさん
09/03/06 01:35:16
オブジェクト指向ははったりで使う
仕事でそれ以上の意味はない
330:デフォルトの名無しさん
09/03/06 01:37:44
会議で黙らせる時に使う
331:デフォルトの名無しさん
09/03/06 02:42:27
最初にオブジェクト指向から入った人には
オブジェクト指向が普通で、そうじゃない物を使う人が変に見えるだろうな
意外とこういう人多いんじゃ無かろうか
それと、分業させるのがOOだと楽ってのもあるんだろうな
332:デフォルトの名無しさん
09/03/06 05:29:29
そうでもないみたいだよ
333:デフォルトの名無しさん
09/03/06 07:18:34
ここで言ってるOOって、結局は手続き型ベースのOOPLばっかりで、
関数型ベースや論理型ベースについては皆さん無知ってことで。
334:デフォルトの名無しさん
09/03/06 07:51:30
道楽じゃないんでね。
335:デフォルトの名無しさん
09/03/06 12:14:41
ほんとに、昨今のオブジェクト指向だけが正義みたいな風潮やめてほしいなぁ。
336:デフォルトの名無しさん
09/03/06 12:18:08
抽象化の手法はOOP派生のアプローチだけじゃないのは確かだけど、
現在主流となってる言語でできるのは大概それぐらいしか無いから仕方ないね
337:デフォルトの名無しさん
09/03/06 12:30:31
>>336
Haskellとかは全く違うスタイルなんだけど。
338:デフォルトの名無しさん
09/03/06 12:31:34
てか、F#とか最近流行ってるやん。
あれは関数型言語だからオブジェクト指向スタイルじゃないよね。
339:デフォルトの名無しさん
09/03/06 12:47:00
HaskellとかF#の案件がperlとかCとかJavaの案件以上にないと主流とは言えません
340:デフォルトの名無しさん
09/03/06 13:00:40
Haskellにもclassあるけどな。
341:デフォルトの名無しさん
09/03/06 13:03:02
340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。
342:デフォルトの名無しさん
09/03/06 13:03:53
340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。
343:デフォルトの名無しさん
09/03/06 13:04:55
340 ：デフォルトの名無しさん [↓] ：2009/03/06(金) 13:00:40
Haskellにもclassあるけどな。
344:デフォルトの名無しさん
09/03/06 13:07:07
>>340
なんという釣りｗ
345:デフォルトの名無しさん
09/03/06 13:26:19
ん？haskellにもtype classがあるだろ。class typeじゃないけどw
346:デフォルトの名無しさん
09/03/06 13:49:29
世の中の案件が全て消えてなくなればデジドカも消滅するしOOPも要らなくなる
347:デフォルトの名無しさん
09/03/06 13:59:38
プログラミング系の学校では、OOはどのくらいの行程で勉強し始めるのかな
学校ではやはりOOは重要みたいな教え方なんだろうか
348:デフォルトの名無しさん
09/03/06 14:01:41
わんわんにゃーにゃー共通化
名詞抽出
デザパタを覚えてそれを雛形にして当てはめましょう
349:デフォルトの名無しさん
09/03/06 14:02:13
>>347
それどころじゃない。
教科書（それも低レベル過ぎるやつ）
を入力させて教えた気になってる。
●馬の高●にある●ューティーの隣。
350:デフォルトの名無しさん
09/03/06 14:10:23
また言語論争か
OOは言語とは関係ないとあれほど
351:デフォルトの名無しさん
09/03/06 14:33:33
>>350
関係ないわけがない。
オブジェクト指向でプログラミングするために作られた言語はオブジェクト指向でプログラミングしたほうが自然にかける。
○○するために作られた言語は○○につかうのが一番自然なんだよ。
当たり前のこと。
352:デフォルトの名無しさん
09/03/06 14:37:11
人の作った「当たり前」は疑うべし
353:デフォルトの名無しさん
09/03/06 14:38:56
当たり前のことが出来ない言語は出来損ないの言語
354:デフォルトの名無しさん
09/03/06 15:14:31
プログラマとかってガンダムOOみても
「あ、オブジェクト指向」とか反射的に思っちゃうわけ？
355:デフォルトの名無しさん
09/03/06 15:16:34
javaやrubyなんて明かに意識して作られてるし
C++は斜め上だけど
356:デフォルトの名無しさん
09/03/06 15:17:20
C++だって20年くらい前はCにクラスがついただけのような素朴な言語だったぞ。
357:デフォルトの名無しさん
09/03/06 15:40:48
おれもはじめは 「オブジェクト指向」 ってヤツになかなか慣れなかった。
Ｃ言語にまだ 「プロトタイプ」 やら 「void」 が無かったころの人間なんで・・・
「オブジェクト指向」 の何が嫌いかって、それはだな、
他人の書いたソースコードを追いかけるのに、上を見たり下を見たり
あっちこっち飛ばなきゃならんってこと。
プリンター用紙に印刷して赤ペンで印を付けながら卓上デバッグすんだぜ。
すんげ～～～大変だよ。
今はすぐれた統合開発環境ＩＤＥがあるから、キーボードのファンクションキーを押すだけで
ソースコードのあっちこっちへ飛ぶことができて楽に追っかけられるようになったが。
そうでも無けりゃやってられないよ、オブジェクト指向なんて。
言語単体だけじゃダメだ。オブジェクト指向言語は統合開発環境とセットで評価すべき。
そう思た。
358:デフォルトの名無しさん
09/03/06 16:12:03
なんで赤の他人が作った仕様書も残ってないクラスを解析するとか言う
トンデモな世界を当たり前のように語っているんだ？
359:デフォルトの名無しさん
09/03/06 16:14:47
コードが仕様書です（キリッ！！
360:デフォルトの名無しさん
09/03/06 16:41:37
>>357
つ Smalltalk
361:デフォルトの名無しさん
09/03/06 16:45:37
>>357
それ、手続型でも同じですから。
362:デフォルトの名無しさん
09/03/06 16:47:59
>>358
オブジェクト指向と言いつつ、なんやかんやで
結局、そのクラスがどう言う実装してるかまで追いかけないと、
発生した障害が解決しないんだよね・・・
363:デフォルトの名無しさん
09/03/06 16:52:41
中身を意識させないためのカプセル化(笑なのに見る必要性がでてくるという本末転倒な
せめて明確な事前条件、事後条件、不変条件ぐらいは確立させてドキュメント化しておくべきなんだけど
そういう事に言及している解説書の少ないこと
364:デフォルトの名無しさん
09/03/06 17:22:09
>>362
幸せになりたいなら、他人のコードを追いかけないこと。
多少処理が重複して無駄が出来ても気にするな。
365:デフォルトの名無しさん
09/03/06 18:26:29
いいな、殿様ショウバイは。うらやましいよ。
366:デフォルトの名無しさん
09/03/06 19:20:08
>>357
規模が大きいと自分で書いたものまで分からなくなりますからｗ
367:デフォルトの名無しさん
09/03/06 20:09:28
結局、何で書こうと人間の頭で把握できなくなったらそこで終わりだしね。
368:デフォルトの名無しさん
09/03/06 20:18:59
ここにいる奴に存在するのか聞きたいんだけど、
UML書けない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。
369:デフォルトの名無しさん
09/03/06 20:21:37
ただのお絵かきにご大層な名前つけなくてもいいのに。
370:デフォルトの名無しさん
09/03/06 20:36:50
>>361
というのがまるっきり理解できない莫迦ほど
>>357 みたいなトンチキな批判を繰り返すんでしょ。
371:デフォルトの名無しさん
09/03/06 20:45:16
普通に考えてUMLのかけない奴なんていくらでもいるだろ
描く必要の無い人間の数と同じくらいいる
372:デフォルトの名無しさん
09/03/06 20:48:06
いや、Cは一ヵ所見ればいい。
単純な関数()+1とかでも底が見えないのがC++なのは事実。
373:デフォルトの名無しさん
09/03/06 20:50:10
UMLって別に大げさに考えるほどのものでもないけど、
必要なら描き方を覚えるぐらい誰でも出来るんじゃないの？
374:デフォルトの名無しさん
09/03/06 21:05:17
ここにいる奴に存在するのか聞きたいんだけど、
フローチャート書けない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。
375:デフォルトの名無しさん
09/03/06 21:37:44
>>374
何も見ないでは正確に書けないけど。
四角と矢印ぐらいならかける。
376:デフォルトの名無しさん
09/03/06 21:54:31
ここにいる奴に存在するのか聞きたいんだけど、
風呂に一週間以上入ってない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。
377:デフォルトの名無しさん
09/03/06 21:57:58
オブジェクト指向だけだと、Object-Oriented って形容詞句だから意味が定まらないよね
OOP か OOD か OOA か(まだある?)
378:デフォルトの名無しさん
09/03/06 21:58:56
ここにいる奴に存在するのか聞きたいんだけど、
86系のマシン語すら理解してない奴ってどれくらい居るの？
必要・不必要論は抜きとして。
379:デフォルトの名無しさん
09/03/06 22:00:25
>>1
closureって何なの？
380:デフォルトの名無しさん
09/03/06 22:45:00
>>368
ここにUML書ける奴どころか読める奴すらいないようだな
どいつもこいつも言語の話に終始
UMLでアクティビティやコンポーネントを見た上で、
インターフェースを設計してるなら言語の話なんかする必要ないからな
設計のままクラスとインターフェース作ればいいんだから
381:デフォルトの名無しさん
09/03/06 22:50:37
UMLどころかデザパタすらシラネ
382:デフォルトの名無しさん
09/03/06 22:55:02
ここにいる奴に存在するのか聞きたいんだけど、
Z読み書きできる奴どれくらい居るの？
必要・不必要論は抜きとして。
383:デフォルトの名無しさん
09/03/06 22:57:57
ＵＭＬ書ける出来る、と言ってるヤツの設計のまま作ると、
なぜか>>362とかみたいになるのだよ。
本当にオブジェクト指向で作ると安全で保守しやすいモノが出来るのか？
384:デフォルトの名無しさん
09/03/06 23:22:21
>>380
いや、そんな読めるとか読めないとか低レベルなことを気にしてるのはお前ぐらいのものだろｗ
385:デフォルトの名無しさん
09/03/06 23:25:41
UMLもデザパタも知らないけど>>362みたいにならないから設計の違いだと思われ
386:デフォルトの名無しさん
09/03/06 23:27:28
>>383
それは設計者の能力不足の問題であって、オブジェクト指向の問題ではないよな
オブジェクト指向はプログラマーよりも、むしろ分析者・設計者が学ぶべきことなんだよ
387:デフォルトの名無しさん
09/03/06 23:28:41
>>384
そんな低レベルなことを言われないようにお前はもっと学習しろ
388:デフォルトの名無しさん
09/03/06 23:48:01
カプセル化を今日Wikipediaみて再理解した
で、どうも府に落ちないことがあって、カプセル化と抽象化の違いをうまく説明できない
だれか恐ろしくわかりやすく文章化できるやついる？
389:デフォルトの名無しさん
09/03/06 23:50:57
抽象化＝インターフェース抽出
カプセル化＝利用する側から見えないこと
390:デフォルトの名無しさん
09/03/07 00:12:55
>>378
別に理解はしてないな。
マニュアル見れば使えはするが。
391:デフォルトの名無しさん
09/03/07 00:13:25
ここにいる奴に存在するのか聞きたいんだけど、
地図が読めない奴ってどれぐらいいるの？
たとえば、この記号。ちゃんとわかる？
＼ ／
＼＿ | ＿／
彡彡彡
ミミミミ
ﾐﾐﾐﾐ
ﾉ σ ヽ
／ / ﾟヽ ヽ
／ ／／＼＼ ＼
（ ( ) .)
＼ ＼＼／／ ／
` ＼／ '
＼ ＊←─この記号
＼＿＿＿＿_／＼＿＿＿＿_／
392:デフォルトの名無しさん
09/03/07 00:16:19
結局は機械語で書くのが一番
393:オブジェクト指向神
09/03/07 00:18:52
次代のポストコボラの諸君
せいぜい頑張って我を信奉するがいい
394:デフォルトの名無しさん
09/03/07 00:22:33
気象予報士って13歳でも受かるんだな
395:デフォルトの名無しさん
09/03/07 00:38:49
JavaでOOPしようとするのは、Windowsのメモ帳つかってプログラミングするくらい頭悪いわけだよ
なんでプリミティブ型があるんだよバカだろ
オートボクシングは便利だけど、本来それ自体が必要ないものなんだ
どんだけJavaが糞なのかみんなもっと理解すべき
その面倒な分だけスキルが上がった奴もいるのだろうけど、それ以上に糞コードが蔓延して、たくさんの人間が不幸になったわけだ
さっさと純粋OOPLが政治的、ビジネス的に普及してくれれば全部解決だろjk
396:デフォルトの名無しさん
09/03/07 00:42:15
業務系やオープン系のような「仕事」のプログラミングだと
結局保守性の良いコードってのは
value class と strategy に分ける形式になっていく気がするんだが、
それならオブジェクト指向でなくていいんじゃねーの？っていう。
397:デフォルトの名無しさん
09/03/07 00:47:32
オブジェクト指向とかあんまり関係なくてさ、
要は情報隠蔽してインタフェース駆動のプログラミングをしましょう
ってだけじゃね？
private な field と public な accessor を分けることで value class の情報隠蔽を実現して、
interface と implement を分けることで strategy の情報隠蔽を実現する
だけでいいんじゃないのかと。
データと振る舞いを一緒にカプセル化するっていうのは、
発想として面白いけど正直プログラミングモデルとしては複雑性を増してるだけな気がする
398:デフォルトの名無しさん
09/03/07 00:48:21
ここにいる奴に存在するのか聞きたいんだけど、
いちいち他人様を馬鹿にしないと気がすまない奴ってどれぐらいいるの？
必要・不必要論は抜きとして。
399:デフォルトの名無しさん
09/03/07 00:51:00
オブジェクト志向をいっさいつかわないということは1クラスに10万行くらい書いて納品するということ？
分担作業やりづれーよ
ていうかムリ
400:デフォルトの名無しさん
09/03/07 00:53:09
例えばJavaなら全部ユーティリティクラスにしてpublic staticなメソッド
だけで書けば分担作業出来るじゃん。
401:デフォルトの名無しさん
09/03/07 00:57:35
>>397
振る舞いを含めないのなら、カプセル化する意味ないんしゃない？
つまりゲッターとセッターの存在理由がないじゃん
コード量を5倍に増やしてるだけ
Step数的に必要？w
402:デフォルトの名無しさん
09/03/07 01:32:33
strategyパターンって何？それなんて高階関数？
403:デフォルトの名無しさん
09/03/07 06:58:47
>>395
Integer.toString(5);
とか馬鹿すぎ糞すぎアホ過ぎ
404:デフォルトの名無しさん
09/03/07 10:45:21
>>388
カプセル化 ＝ 抽象化
405:デフォルトの名無しさん
09/03/07 11:10:10
>>404
氏ね
406:デフォルトの名無しさん
09/03/07 11:38:40
>>404
カプセル化 ＝ 英語表音を取り入れたハイカラな呼び方
抽象化 ＝ 漢語表記にした東アジア的呼び方
407:デフォルトの名無しさん
09/03/07 13:26:57
カプセル化 ＝ データ抽象 ＝ 抽象データ型 ＝ ユーザーによるデータ型定義
408:デフォルトの名無しさん
09/03/07 14:23:42
>>404
抽象はAbstractionの訳として用いられるから、
カプセル化と抽象化をイコールで結ぶのは違和感がある。
409:デフォルトの名無しさん
09/03/07 14:25:57
カプセル化と抽象化は直交する概念だろ
410:デフォルトの名無しさん
09/03/07 14:55:55
カプセルか・・・
カプセルか・・・
カプセル怪獣！
411:デフォルトの名無しさん
09/03/07 15:02:16
カプセル化＝インタフェースとその実装との関係での話。
抽象化＝インタフェース設計での話。
412:デフォルトの名無しさん
09/03/07 15:10:06
抽象化 ＝ いくつかの事物に共通なものを抜き出して、それを一般化して考えること
カプセル化 ＝ 要約化, 簡約化すること
413:デフォルトの名無しさん
09/03/07 16:02:31
なんでもかんでもクラスにしようとする香具師は死ねばいいのに
414:デフォルトの名無しさん
09/03/07 16:30:23
カプセル化の目的は抽象化だけではないし、
抽象化はカプセル化以外にもたくさんある。
415:デフォルトの名無しさん
09/03/07 16:31:42
[1] 授業単元：オブジェクト指向講座
[2] 問題文(含コード&リンク)：
1から9までの数字を縦横方向に同じものが並ばないように下記の例のように並べる
並べ方が全部で何通りあるかとその並びをすべて列挙する
[3] 環境：オブジェクト指向で解決すること
[4] 期限： 明日まで
[5] その他の制限：
例
534681297
685293714
948367125
153472869
426538971
261759483
817945632
379126548
792814356
416:デフォルトの名無しさん
09/03/07 16:40:23
はいはい未解決未解決
417:デフォルトの名無しさん
09/03/07 17:10:01
私は素人なんですが、一言。
プロの人でもよく分かってないことが多いのなら、
ホビイストとか日曜プログラマと呼ばれる層にとっては
OOは邪魔なだけになりやすいですよね？
昨今はオブジェクト指向じゃないと自然に書けない・・・というか
オブジェクト指向を半ば強要するような仕様の言語が多いですけど、
ダイクストラ流の構造化だけしか要求しない言語だったら、
「HSPも中途半端にしかできない」、「シェルスクリプトしか組めない」、
「わしは昔BASICで色んなもんを作ったんじゃよ」なんていう
素人でもそれなりの物を作れるはずです。
ところが、今日では計算機技術全般がプロ用になってしまっているため
ワードやエクセルで適当にやってみて、それでダメだとすぐ自力解決を諦めてしまう。
その結果、そのまま泣き寝入りするか、プロに無駄金払う人が増えています。
やろうと思えば自分でできるはずのことだったとしても。
418:デフォルトの名無しさん
09/03/07 17:15:41
オブジェクト思考は天才
オブジェクト思考は天才
419:デフォルトの名無しさん
09/03/07 17:16:57
>>417
> プロの人でもよく分かってないことが多いのなら、
> ホビイストとか日曜プログラマと呼ばれる層にとっては
> OOは邪魔なだけになりやすいですよね？
あなたはプロで、現場のことを良く知っている、という前提ですか？
それともソースは2chだけという にわかさん ですか？
後者なら、2chでオブジェクト指向がよく分からないと発言している人が素人だと私は言いますよ。
420:417
09/03/07 17:18:09
さらに言いますと、
プロの方にとってもOOが弊害になる場合が多々あるのではありませんか？
私の社内にいる情報系の人がC++で作ったプログラムを見て、
「何でこの程度のことをC++で書くんだろうか？」と疑問に思ってしまいました。
黙っている方が賢明だったかもしれませんが、見るに見かねて無駄を指摘し、
目の前でそのプログラムと同じことを、Bashの一行野郎でやってみせたら不機嫌そうでした。
何でもOOでやるのが当たり前、と考えるのは簡単なことを複雑にし、
普通の人の自己解決を妨げると同時に、プロにまで無駄を強いるのではありませんか？
421:デフォルトの名無しさん
09/03/07 17:19:56
>>419
いえ、OOが悪いと言ってるんじゃないですよ。
ただ、時と場合によるはずなのに、
「OOこそ専ら正義」であり、「それができない者もしくは好まない者は
プログラミングから排除されて当然」という風潮が変だと申し上げているだけです。
422:デフォルトの名無しさん
09/03/07 17:26:48
> 「それができない者もしくは好まない者は
> プログラミングから排除されて当然」という風潮
プログラミングから排除ってｗ そんな風潮あるの？
申し上げましょうか。
OOPのメリットを知るには非OOPの苦痛を知らなければなりません。
そのためには、非OOPの業務経験が必要だと考えられます。
OOPがいつでも役立つなどと言うものは、
おそらくOOPを理解していません。
同時に、OOPを理解するものは、
OOPを理解しないものを排除したりはしないでしょうが、
代わりに、経験不足を見て取ります。
423:デフォルトの名無しさん
09/03/07 17:31:29
>>413だけど、
> OOPがいつでも役立つなどと言うものは、
> おそらくOOPを理解していません。
激しく同意
ほんと死ねばいいのにね
424:デフォルトの名無しさん
09/03/07 17:50:34
>>421
とりあえずOOPとOODやOOAは区別して話すべきだと思うけど。
OOPに関しては、開発インフラと言うのも無視できないと思う。
例えば案件がJavaでのWebアプリ開発だったとして、Javaという
言語はもちろん周辺のライブラリやフレームワークも一応OOPに
乗っ取ったデザインになっている。
結果として開発するにしてもOOPの流儀に則るのが一番楽だし、
そこを無理に外すとかえって大変だったりあとから保守する人が
面倒を被ったりする。
イチからスクラッチで開発するのならともかく、実際はそうした既存
のライブラリやフレームワークといったインフラの上で開発する場合
も多いのだから、こうしたインフラが現在ますますOOPに基づいて
整備されている以上OOPを理解しないと仕事では辛くなるのでは？
と思う事はあります。
425:デフォルトの名無しさん
09/03/07 17:52:10
>>422
たまたま私の周りにいる人たちが変なだけかも知れませんね。
私の会社は医療サービス業なので、直接的にはプログラミングと関係ありません。
しかし、今時いかなる業種であろうともコンピュータと無縁ということは許されませんので、
いわゆるプログラマやシステムエンジニアと呼ばれる人々ともある程度関わらざるを得ないわけです。
現場サイドだけで使うCSV形式のデータベースを処理するごく簡単なシステムを
社内の情報系職員に依頼したら、「できません」と断られました。
開発に手間がかかりすぎるので外部に依頼すべきというのです。
ようするに面倒くさいから逃げただけなのでしょう。
で、とある業者に見積りを出させたら、開発に十数万円、保守が月数千円ということでした。
バカらしくなってしまったので、WindowsのインストールされたPCに
GNU BashとGawkを入れて、自分で作りました。
本当はUNIXやLinuxでやるほうがスマートなのですが、社内になかったので・・・
私はプログラミングなんてできませんが、たまたまシェルスクリプトをかじったことがあるので
こんな方法で解決できましたが、そうでなければプロにボッタくられるところでした。
大規模なプログラムを設計するには便利な技術であろうとも、それをあらゆる場面で強要するのは
我々普通の人にとって迷惑でしかありません。
いや、迷惑をかけられていることすら気づかずに、本当は自己解決できる程度のことに
大金を払い、感謝すらするのです。
426:デフォルトの名無しさん
09/03/07 17:57:39
でっかい釣り針が何本もみえるスレだなw
>>425 なんてオブジェクト指向となんの関係もない話じゃん。あほくさ。
427:デフォルトの名無しさん
09/03/07 18:05:49
>>425
自分で出来る事をプロに頼むのが間違い
証明写真をプロに撮って貰うのか、3分間写真で撮るのかってのと同じ問題だ
428:デフォルトの名無しさん
09/03/07 18:06:10
ぼくはぷろぐらむがかけるんだぞ
そとにいたくしたらなんじゅうまんえんもするしごとができるんだぞ
すごいでしょ
ほめてよ
あっそ
429:デフォルトの名無しさん
09/03/07 18:06:13
「クラスのオブジェクトのプロパティがメソッドでインスタンスだからぁ～
ポリモーフィズムのインヘリタンスがカプセル化でぇ～」
とか語ってる暇があったら、非OO言語でゴリゴリ書いたほうがマシなことは沢山あるけどな。
素人さんたちが、それすらやらなくなったのは確かに退化だと思う。
その原因の一つが「プログラミングは普通の人には難しすぎる」という刷り込みで、
さらにその原因の一つがオブジェクト指向なのは間違えてないだろう。
だからと言ってオブジェクト指向を目の敵にするのは変だけどな。
430:デフォルトの名無しさん
09/03/07 18:25:51
>>425
というかCSV形式のデータをゴリゴリやるのに今更awkというチョイスが
よく判らない。趣味？
perlでもpythonでもrubyでも、CSVをComma-Separated Valuesとして
扱ってくれるライブラリを持っている言語を使って書いた方が書く人も
使う人もあとで読まされる人も楽だと思うけど。
別にライブラリだけ使ってその後は手続き的に書いても良いわけだし。
431:デフォルトの名無しさん
09/03/07 18:30:34
BASICだろうがCだろうがコードを書いてる間に関数レベルで抽象化はするし
どうせ、抽象化するならオブジェクト指向に対応した言語を使ったほうが楽じゃん
432:デフォルトの名無しさん
09/03/07 18:32:49
なんかちょっとする時はRubyの一択だな。
>>425もcygwin入れてもっとラクしたらいい。
433:デフォルトの名無しさん
09/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
09/03/07 18:36:47
>>430
それはプロ的な発想でしょう。
私はプログラミングの素養などありません。
単純にコマンド並べて動くものしか理解できません。
だから、他の言語で書いたほうが楽だとおっしゃられても
私には楽ではありません。
後でソースを読む人なんているのでしょうか？
プロとおぼしき人といえば、
別の部署にあてにならないシステム管理者がいるだけです。
私の部署にはプログラムを組める人なんて皆無ですし。
そんな状況でお金をかけずに解決するには、bashとawkくらいしか思いつかなかったんですよ。
awkは古いとお思いでしょうが、perlより覚えることは少なく、単純なプログラムなら
可読性も高いでしょう。
素人にはうってつけではないでしょうか？
435:デフォルトの名無しさん
09/03/07 18:38:29
フレームワークつかっててさ。
えれー使いにくいAPIと、えれー使いやすいAPIってあるじゃん。
そては何でか？ってのを、自分なりに考えてみれば
見えてくるものもあるんじゃないかと。