なぜオブジェクト指向は嫌われているのか？

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/09 17:59 / Filesize : 164 KB / Number-of Response : 786
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：仕様書無しさん [2007/07/01(日) 10:57:27 ]: 前スレ
なぜオブジェクト指向は賛否両論なのか
pc11.2ch.net/test/read.cgi/prog/1181318210/
2 名前：仕様書無しさん [2007/07/01(日) 11:04:35 ]: 考えれば考えるほど嫌いになっていく。
それがオブジェクト指向なんだよね。
3 名前：仕様書無しさん mailto:sage [2007/07/01(日) 11:08:58 ]: モジュールの結合度の問題について何も理解してないから
前スレの>>853なんて、その典型
4 名前：仕様書無しさん mailto:sage [2007/07/01(日) 11:22:43 ]: オブジェクト指向以前に、抽象データ型の利点が理解できない奴がいるとは驚いた
引数ずらずら並べるのが正解って、アホじゃね？

ココ電のこと笑えねぇよなｗ
5 名前：仕様書無しさん mailto:sage [2007/07/01(日) 11:50:57 ]: おじゃぱが

841 名前：仕様書無しさん[sage] 投稿日：2007/06/30(土) 09:11:25
>825
>おじゃばが「OO勉強している奴偉い」と思える環境ができあがっている。
おじゃばって「OO勉強している俺偉い」としか言ってねえよーな。
しかもとんでもなくうわっつらのとこで。

以来来なくなった。これが真実か。
新人研修が忙しい状況に、なったのかな？
6 名前：仕様書無しさん mailto:sage [2007/07/01(日) 11:55:39 ]: おじゃばは基本的に休日はレスしない
7 名前：仕様書無しさん [2007/07/01(日) 11:58:12 ]: 電卓のクラスを作ってみよう。

class CALCULATOR{
　　　　staing formula[int_MAX];
　　public:
　　　　CALCULATOR();
　　　　FOI_ERROR FORM_Input(string/*入力する式*/);
　　　　int FORM_Solution(int/*計算モード*/ staing*);
};
8 名前：仕様書無しさん mailto:sage [2007/07/01(日) 12:02:27 ]: 前すれのくだんねー議論に横レス
xyzのうち yz zx xy に対するんなたらかんたらは、要するに平面三次元空間から平面を取り出して、それに対する操作という事なのだろう
それならそのうち任意法線に垂直な平面に対する処理というのも当然でてくるだろうから、平面の指定方法で抽象化して統一化すればいいんじゃね？
9 名前：仕様書無しさん mailto:sage [2007/07/01(日) 12:16:50 ]: 溶岩流アンチパターンの一因について盛り上がっていたね。
10 名前：仕様書無しさん mailto:sage [2007/07/01(日) 12:42:04 ]: >>7
もしかして: staining
11 名前：仕様書無しさん [2007/07/01(日) 12:48:48 ]: >>10
なんだそれ。
12 名前：仕様書無しさん mailto:sage [2007/07/01(日) 12:54:47 ]: 前スレのリゾットメソッド君には驚いたな
13 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:07:08 ]: オブジェクト指向が嫌われる理由
それは、
オブジェクト指向の有効性を分からない上役が
分からないまま導入するため。
14 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:25:07 ]: 上役が分からなくても、自分たちが価値を見出して活用できればいいのでないの？
バカな上役の勧める物は何でも嫌いじゃ、駄々っ子のガキだ。
15 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:40:50 ]: 自分たち、ってのは誰を指してんだ？
偽装請負会社から来てるわからんちんも含めてのことだよな？
16 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:46:44 ]: >>15
自分たち＝オブジェクト指向をコードで実践するプログラマたち
って思ってくれ。
わからんちんは教育するしかないな。
わからんちんが見込みなければ、オブジェクト指向はあきらめて、
構造化でも何でも理解できる方法論使ってやってくれ。
17 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:49:10 ]: 用語を統一してくれと何度か思ったけど、もうどうでもいいや
18 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:50:05 ]: >>16
なぜオブジェクト指向は嫌われているか・・・わかったよ！
19 名前：仕様書無しさん mailto:sage [2007/07/01(日) 13:58:55 ]: >>16
なぜオブジェクト指向は嫌われているか・・・わかったよ！
20 名前：仕様書無しさん [2007/07/01(日) 14:29:59 ]: 学校でC言語学んでいるとですが
C言語でオブジェクト指向するにはどうすればよかとですか？
21 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:33:06 ]: まずC言語を学んでください
22 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:33:21 ]: www.sage-p.com/process/cool.htm
23 名前：仕様書無しさん [2007/07/01(日) 14:33:45 ]: >>20
インクリメントすればいい
24 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:33:53 ]: Cは（当然言語だが）OOPを言語レベルでサポートしていない
25 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:36:05 ]: >>20
Cの標準関数でも引数にオブジェクトへの参照を必要とする関数群（fprintfとかね）は
広い意味でOOP
26 名前：仕様書無しさん [2007/07/01(日) 14:46:11 ]: int i = new int()
ってやったら、どうなるの？
今、手元に開発環境が無いので試せない。
27 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:46:36 ]: fprintfつかFILE構造体だな
28 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:47:36 ]: ゲームなんかはOOが分かりやすいな
キャラクターそれぞれの動きと性格をインターフェースで定義して、
それぞれを実装して、って感じで
これが制御プログラムとかの業務になるとわかりにくいって言う奴がいるってことでしょ
29 名前：格之進 ◆xiPQGz7lVI [2007/07/01(日) 14:49:27 ]: 「オブジェクト指向」それ自体には何の問題もないと思うよ。
押し付けがましい人がいるのが問題。
30 名前：仕様書無しさん [2007/07/01(日) 14:52:53 ]: Cでもオブジェクト指向的なコードは書けるよ。
でもね。C++で言うとこのthisポインターを持ち回りで自己管理しなくちゃならないとか、クラス内のメソッド呼び出しにアクロバチックな仕掛けを設けなきゃいけないとか、グズグズのコードになるから、実装レベルではしんどい。
31 名前：仕様書無しさん mailto:sage [2007/07/01(日) 14:52:57 ]: 新コテハンかと思ったらココ電かよ・・・
32 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:03:21 ]: 統計とったわけでも無いのに属人的な問題にしてしまうのは思考停止
33 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:07:28 ]: 日本語でおｋ
34 名前：格之進 ◆xiPQGz7lVI [2007/07/01(日) 15:17:04 ]: オブジェクト指向といっても、要するに一つの道具なんだから、
使いたくなきゃ使わなきゃいいんだし。
使う必要があるなら使えばいい。

自分のやることについては道具を自分の判断で選べるものならば、
他人がその人のやることにどのような道具を使おうと、
そんなに拘る必要はないんじゃないの？
35 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:25:46 ]: >>30
クラスベースのOOなプログラミングはCでは無理。
36 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:28:42 ]: >>35
第一引数に構造体を突っ込むのと何が違うの？
つまり、fopenとかそんなのみたいなもん
37 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:29:19 ]: 面倒なだけで不可能ではない。
初期のC++実装はCに足したものだったからね。
C++ソースをCへプレコンパイルしてたのさ。
38 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:30:13 ]: >>36
それを強制・支援するクラスって概念が無いから、約束事を決めてコーディングしないと
いけないからだお。
39 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:33:18 ]: CではOOっぽく作れるだけで、
クラスも継承もインターフェースも無い時点でOOではない
40 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:34:57 ]: >>30
C++でも最後には機械語になる。
OOPの動きを真似て良い所だけをつまんで使うのが由。
アセンブラレベルでの働きは、昔からよく使われている手法だし。

継承の真似事、仮想関数の真似事（直前まで呼び出し先が未定）を
する感じの物はCやアセンブラでよく作った。
41 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:35:54 ]: >>38
それはなにで組んでも大してかわんねーよ
42 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:36:50 ]: >>39
継承やインターフェースなんて大して重要でもねーよ
しかも両方後付けじゃねぇか
43 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:39:32 ]: >>42
重要でもねーよ？
CでOOっぽく作ることは確かにできるが
そんなことするぐらいならC++の方がいいだろ
オーバーロードなんかはどうすんだ？
44 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:40:38 ]: >>43
構造体と関数へのポインタでゴリゴリやんだよ。
45 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:41:03 ]: >>43
そりゃＯＯを表現するのになきゃいけないもんか？
俺は使ってねぇけど
混乱の元だから
46 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:41:56 ]: すでにC/C++それぞれの役割分担はだいたい決まっている話なので、どうでもいい。
C++はOOとしてはかなり中途半端な存在だな。
47 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:42:52 ]: >>44 >>45
分かってねーだけじゃん
48 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:44:12 ]: Cでもマクロを駆使して継承やインターフェースを実現させてるシステムはあるよ。
すんごく制限あるけどね。
もう、初期のC++をCに変換した後のコード見ているような感じさ
49 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:45:17 ]: >>47
お前、オブジェクト単位で表現することよりもＣ＋＋のテンプレートとか
妙な小細工機能使ってＯＯを理解してると思い込む性質だろ？
50 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:46:45 ]: 言語に頼るのはＯＯとは言わない。
51 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:47:16 ]: >>49
そういうことじゃなくて、
>>48みたいなことをあんたはわざわざやるのか、ってこと。
ラクして作りゃあいいのに
OO以前の話じゃん
52 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/01(日) 15:47:22 ]: まあ、結局、CからC++ や Java 移っても、
新しいことができるようになった、というよりも、
楽になった、としか思わないよね。
53 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:49:14 ]: それでいいじゃん
54 名前：仕様書無しさん mailto:sage [2007/07/01(日) 15:49:31 ]: >>51
だったらわかってないとは言わないじゃん
意味不明
55 名前：仕様書無しさん mailto:sage [2007/07/01(日) 16:31:31 ]: そういえば、かつてのg++って、なんかオプションでC++のコードをC言語のコードに変換できたよな？
56 名前：仕様書無しさん mailto:sage [2007/07/01(日) 16:44:19 ]: 継承もオーバーロードもインターフェースも OO の本質ではない

OO はプログラムを考える時に値と機能（変数と関数）を、
機能主体の分割（関数化・APIライブラリ化）ではなく、
動作部品単位で分割するようにした方が分かりやすいぜ、
って、設計のための概念だからだ

もちろん、そういう設計をする以上、継承やらが使えた方が便利だし、
今となっては OO 対応の言語を使わない意味は無い

ただ、継承やらの末端の機能にこだわるマが、
クラス設計としては見通しが最悪なプログラムを書いて、
プロジェクト全体で OO 禁止になったりする事があるから
木を見て森を見ずには注意しような
57 名前：仕様書無しさん mailto:sage [2007/07/01(日) 16:54:26 ]: おまいら>>22は無視ですかそうですか。。
58 名前：仕様書無しさん mailto:sage [2007/07/01(日) 16:56:41 ]: >>57
C言語の話を書いてあるだけでスレタイと無関係
59 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:01:42 ]: >>58
わかりましたすみません
60 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:06:41 ]: >>58
Cで継承もオーバロードもできるって書いてあるじゃん
61 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:08:34 ]: >>60
もう一回書くぞ
"C言語の話"を書いてあるだけで"スレタイ"とは無関係
62 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:11:37 ]: >>61
アホはレスせんでいいぞｗ
63 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:20:16 ]: >>60
しつっこいから見に行ってみたけど、これ、「C言語でオブジェクト指向やってると思いこむためのコードの書き方」でないの。
メソッドもどきは、関数の先頭を Staff_ で統一してるだけだし。

強固な意志と思想を持ったプログラマであれば、こういうコードでもOOのカプセル化などを達成できるだろうけど、
そうでない大半のプログラマは、面倒くさくなってグローバル変数入れたりして、破綻させちゃうよ。
64 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:24:38 ]: >>60
昔のC++コンパイラはバイナリじゃなくてC言語のソースを生成してた
つまりC++のソースをコンパイルするとCのソースが生成されて、
それをコンパイルするとバイナリになった。

CでOOを別に書けん事も無いが、それは「C言語であってC++言語ではない」
65 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:29:30 ]: >>61
>>62のようなかわいそうな奴はスルーしとけ
66 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:30:30 ]: そこでObjective-Cですよ
67 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:33:40 ]: スレタイ厨は半年ROMってろ
68 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:34:47 ]: OOPはOOPLでなくてもできる
ここはOOPLのスレでは無いからスレ違いという程でもなかろう
非OOPLでOOPやることはあまり実用的じゃないけどな
69 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:36:26 ]: >>67がスレタイとは関係の無い実のある話をしてくれるそうです
70 名前：仕様書無しさん mailto:sage [2007/07/01(日) 17:59:49 ]: オブジェクト指向が嫌われる原因は、
設計と実装が一体化するからだろう

プログラムはできん、と言ってSEを自称する連中が多く、
UMLなどを学習する素地がないため、
PGがオブジェクト指向を学習しても設計ができてないため、
OOの本質である設計から実装へのスムーズな移行ができてない

簡単に言えば、設計でOOを活用できる人材が少ないということだ
71 名前：仕様書無しさん mailto:sage [2007/07/01(日) 18:31:09 ]: class 電卓キー {
　　計算();
};

これが理解できるものは上級者。
72 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/01(日) 18:41:22 ]: 「電卓キー」を表現するなら、こうじゃないの。

interface 電卓キー {
「=」キー();
}

「計算」は実装クラス側にあって、

class 電卓 implements 電卓キー {
　「=」キー() {
　　計算;
　}
}
73 名前：仕様書無しさん [2007/07/01(日) 18:41:47 ]: >>71
どうやってアクセスするんだか。
そもそも、どう使うのか。
というより、初心者でも解りそうだが。
74 名前：仕様書無しさん mailto:sage [2007/07/01(日) 18:42:13 ]: >>72
ココ電球はやめたのか？
75 名前：仕様書無しさん mailto:sage [2007/07/01(日) 18:43:49 ]: >>73
実装の話はしてないんじゃ・・・
76 名前：仕様書無しさん [2007/07/01(日) 18:46:32 ]: >>75
設計とも言えないくらい穴のある設計ですね。
77 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/01(日) 18:46:57 ]: >>74
「ココ電球」って何ですか？
78 名前：仕様書無しさん mailto:sage [2007/07/01(日) 18:53:09 ]: 自演発覚の瞬間を見た
79 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:00:33 ]: (・∀・)
80 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:09:32 ]: class 電卓キー {
　　計算();
};

やはり思った通りだな。
一見稚拙な設計に見えるこのクラスの奥が見えるものと、見えない香具師に分かれたな。
81 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/01(日) 19:12:20 ]: いや、そうやって、オブジェクト指向を、
なんかの奥義みたいに言うもんだから、
嫌われるんじゃないの？
82 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:12:45 ]: またお前らＵＩ無視ですか．．．
83 名前：仕様書無しさん [2007/07/01(日) 19:14:24 ]: >>80
お前そんな設計でもないもの見せられても、ちゃんと設計しろ。としか言えない訳よ。

まずデータ構造からだ。
どんなデータを扱うか？それが分からないとクラスの奥も何もないぞ。
84 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:14:33 ]: >>80
おまい、計算ボタンひとつひとつを継承クラスにしてしまおうって魂胆だろ？
85 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:18:06 ]: >>84
浅いな。
86 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:19:07 ]: ところで何この糞コテ
87 名前：仕様書無しさん [2007/07/01(日) 19:19:50 ]: オブジェクト指向は奥義なのです。
88 名前：仕様書無しさん [2007/07/01(日) 19:35:19 ]: >>80
………で、答えは？
89 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:38:48 ]: もう既出で答えられず顔真っ赤なんだろ？
90 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:42:20 ]: ていうか、万人にわからん時点で糞設計ということは確定してるがな
なんのためのオブジェクト指向なのか・・・
もう色々履き違えてるよねｗ
91 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:45:56 ]: VB.netの初心者本を本屋で見てみたら
「まるでVBの代替として使うような」章分けになっていた
困るねコレじゃ　たぶんそれでも使えるからOKってことなんだろうけどさ
92 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:46:51 ]: こんなわからんもん出して悦にいってる自分を恥じれよｗ
客から
windowsの関数電卓くらいの仕様は想定して言ってるんだろうね？
とか言われて作り直しになる未来が予想できる
93 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:48:07 ]: ＶＢ．Ｎｅｔは糞
あれだったらＶＣやったほうがいい
ＭＳが自由に改変できるような言語を使ってちゃ駄目
94 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:54:21 ]: オブジェクト指向は達人用の道具なので、万人向けではないのでは？
95 名前：仕様書無しさん mailto:sage [2007/07/01(日) 19:59:22 ]: >>94
そんなオブジェクト指向なら、無い方がいい。
オブジェクト指向とは、そんな難解な暗号制作技術じゃない。
96 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:02:35 ]: >>94
設計技術でわかりにくいとかすでに目的が不明ｗ
97 名前：仕様書無しさん [2007/07/01(日) 20:03:58 ]: >>95-96
しかし、分かりにくいのは確か。
98 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:06:37 ]: >>97
じゃあ、つかえねぇんだよｗ
99 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:07:16 ]: >>97
まさか、その分かりにくいと言うのが、
英語やドイツ語圏の人に日本語見せる程度の分かりにくさだろう？
覚えずに分かりにくいも何もネエよ。
100 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:12:21 ]: 本格的にオブジェクト指向されてなくても、
クラスなどの構造で、ある程度汚いながらも分割されていたほうが遥かにマシ。
101 名前：仕様書無しさん [2007/07/01(日) 20:19:13 ]: >>98
そのとうり。
全く以て使えない。

>>99
覚えた所で使いこなせるか？
と、言われると。
どうだろう？と、首を傾げてしてしまうほどの世界。
102 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:22:54 ]: 指向とはそういうものだよ。
103 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:22:56 ]: だから、OOは
使う機会が無ければ、使わなくても済む技術。

不要だと思う人は、使わなければいいだけ。

ただし、大手のプロジェクトに参加するなら、必ずOOと対面する。
そのときにアセっても、後悔するだけ。
104 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:26:06 ]: 楽譜が書けるからといって、名曲が作れるわけではない。
これに等しい。
105 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:28:26 ]: >>104
そうだね
でも、他人に自分の作曲した作品を伝える為には便利だよ。
尤も、相手が楽譜を読めればの話だけどさ。
今なら演奏そのものを録音してしまえばいいとかそんな話してるのと同じ。
106 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:28:46 ]: おれなんか最初から自然にオブジェクト指向だったよ。
向いてるのかな？
107 名前：仕様書無しさん [2007/07/01(日) 20:31:47 ]: >>106
向いてるんじゃね？
ただし、オブジェクト指向嫌いになる確立あり。
108 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:33:17 ]: 確率を確立と書くのは、何故なんだぜ？
109 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:33:37 ]: 名曲を作るヒントの一つにオブジェクト指向があるわけなので、
名曲が作れないからといって、オブジェクト指向を否定するのはどうかな。
110 名前：仕様書無しさん [2007/07/01(日) 20:36:31 ]: >>108
単なる変換ミスでーす。
111 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:38:40 ]: どこぞのアホが、義務教育で確率を確立と書くように改めたんだって偽情報が反乱してた時期があってな。
それからと言うもの、確率を確立と書く奴らは信用してないんだよ。

チラシの裏でスマンコ
112 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:44:52 ]: そうだよね。
文字が書けても、文学が作れるわけではない。
楽譜が書けても、名曲が作れるわけではない。
おいらは向いてないのかな？
113 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:46:05 ]: そうか！オブジェクト指向は芸術だったんだ！
114 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:47:41 ]: >>113
それをいうならプログラムはだろ？
頭悪いのなｗ
115 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:50:40 ]: まあ、誰もプログラムに芸術なんて求めていないけどな。
確実に動くものを早く高品質に仕上げてほしいだけだ。
116 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:54:01 ]: 匠の技か。ワクワクするぜ。
117 名前：仕様書無しさん mailto:sage [2007/07/01(日) 20:55:12 ]: >>115
それならオブジェクト指向をお勧めするよ。
118 名前：仕様書無しさん mailto:sage [2007/07/01(日) 21:00:07 ]: 学問に王道なし。設計も同じ。
119 名前：仕様書無しさん [2007/07/01(日) 21:03:52 ]: オブジェクト指向はいいけど
アスペクト指向だけは納得いかない
120 名前：仕様書無しさん mailto:sage [2007/07/01(日) 21:26:36 ]: アスペクト便利じゃん
121 名前：仕様書無しさん [2007/07/01(日) 21:31:41 ]: ディポジット指向プログラミングの時代が来る。
122 名前：仕様書無しさん mailto:sage [2007/07/01(日) 21:54:43 ]: ディスポーザブル指向？
123 名前：仕様書無しさん [2007/07/01(日) 22:10:48 ]: ディポジット指向←６件しか引っ掛からない
ディスポーザブル指向←医療関係がトップだった。
124 名前：仕様書無しさん [2007/07/01(日) 22:19:10 ]: 994 ココ電球（∩Ｔ∀T)　 ◆tIS/.aX84. New! 2006/08/12(土) 02:23:31 ID:XVMqMvcK
俺の場合は原因は下痢だな
ちょっともれちゃって・・・・
125 名前：仕様書無しさん mailto:sage [2007/07/01(日) 22:50:27 ]: OOで設計できる奴が少ないだけだろ
JavaやC++がわからん奴が設計すれば
機能分割したものを作ってしまいがち
126 名前：仕様書無しさん mailto:sage [2007/07/01(日) 22:54:39 ]: せっかくのオブジェクト指向なのに、クラス分けと機能分けを混同して、同じ概念を複数別々に実装してるプロジェクトを結構見かける。
同じ概念なんだから、そこは同じインターフェースで実装しないと。とか、別会社同士で歩調が取れる訳も無くw
案の定、座礁しかかってるww
127 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:11:14 ]: XX業務クラスってか？ありがち
128 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:11:29 ]: >>126
インターフェースわざわざ一致させる意味がわからない
別部署が担当することになったらさらに意味がない
ちゃんと説明できた上で煽ってんの？ん？
それとも本読んだらそう書いてあっただけ？
なんかただ煽ればいいみたいな奴多くて嫌なんだよね
129 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:12:53 ]: おまいらが全員死んでオレのクローンが開発すれば
あっという間に開発は終わる。

・・・世界も終わる。
130 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:18:52 ]: >>129
クローン分のお前のおとんとおかんと妹が必要じゃね？
ひきこもりだろうから友だちは必要なさそうだけど
131 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:22:47 ]: UML覚えるのがねえ
132 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:26:22 ]: >>131
大半がUMAの知識で代用できる
新しく覚えることはほとんどない
133 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:26:31 ]: 覚えるまでもなく、見りゃわかんだろ
134 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:29:10 ]: >>128
一回きりの使い捨てプロジェクトなら、いいけどね。
これから新規で使うプラットフォームのためのクラスなんだよ。
もうね、その割にクラス構成とか、グッチャグチャ。
135 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:31:39 ]: >>134
グチャグチャの根本的原因がお前のいうことのような気が全くしねぇの
単純にグローバル変数とか普通に使ってあるからキモイことになってるだけなんじゃねぇの？
136 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:32:31 ]: JavaやC++の経験があっても無理な奴は無理。
作業分担がしやすいとか、テストを作りやすいとか、
あとでツブシがきく、というような設計は、
それなりの設計＋コーディングの経験をつまないと。

こういうのは頭でっかちの若い奴にやらせないで、
徒弟制にして、ちゃんと技術力のある人から継承してかないと
ダメだと、マジで思う。
137 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:33:16 ]: UMLは出発点に過ぎないよね
ツールの扱いとか作図に時間かかる、ってことで敬遠されることもあるし、
見てもわからんって言う人は存在するし
138 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:33:57 ]: >>136
技術のあるなしってどうやって判断するつもりだよ
139 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:35:58 ]: >>137
継承関係を表した図なのか
状態遷移図なのか
関連図なのか
インスタンスの有り方を表した図なのか
わからんのでもうそういうクラス関連の図はいらんｗ

作ってる奴ですら間違いに気付いてない
文句付けると大抵逆上する
もう一枚たりとも書くなといいたい
140 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:37:19 ]: >>136
前半は同意
後半は、具体的にどうすればいいか不明？
141 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:37:35 ]: >>135
ああ、無駄なクラスが山のように作られてるよ。
この時だけは使うクラスはこっち。あの時だけはこっちを使うってな。
もうね、ポリモフィズムもなにもあったもんじゃねえ。
しかも使い分ける用にその間を取り持つクラスを作ってる有り様。
142 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:37:55 ]: 「汎化ってなんですか？」
協力会社の先輩後輩がこういう会話をしてた。

OOには一般的でない言葉が多すぎる。
143 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:39:00 ]: >>141
お前のいってることが意味不明
俺、そんなことで困ったことねぇし
普通にグローバル変数が使ってあってキタネェだけなんだろ？
144 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:39:31 ]: 構造化は一般的な言葉か？
145 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:40:26 ]: C/C++で分散開発なんて聞いたことねえからJavaなんじゃね？
Javaならグローバル変数ねえぞ
146 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:42:13 ]: >>142
まさしくOOが嫌われる原因だな
自分が学習してたとしてもわからんちんに説明するときに
どうしても用語の壁にぶちあたる
147 名前：仕様書無しさん [2007/07/01(日) 23:43:46 ]: >>146
なら医学や法学も嫌われてるのか？
148 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:44:12 ]: >>146
あたんねーだろ普通
実は自分もよくわかってねぇもん説明してっから変な言葉使って誤魔化そうとしてんだろ
理解してないのバレバレ・・・みたいなｗ
149 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:44:32 ]: >>144
構造化って言葉は知らなくても開発できるからね
でもOOは設計から実装するときに翻訳が発生する
150 名前：仕様書無しさん [2007/07/01(日) 23:45:43 ]: >>141
そこで何故継承を使わない。
151 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:46:05 ]: 汎化だってニュアンスでわかんだろ普通
ああ、一般化？みたいな感じで
152 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:46:34 ]: >>143
グローバル変数なんて使わずとも、
クラス設計が糞なシステムは、無駄に肥大化するし、保守にも莫大なコストがかかる。
それぞれが思い付くまま勝手に少しづつ仕様の違う似たようなクラスを量産している。
しかもベースクラスからの派生とか言う方法でもなく、勝手にインターフェースを独自仕様で作っている。
仕様変更なんてかかった日にゃあ、何人死人が出るかわからない状況。
153 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:47:04 ]: >>145
先生！こうやればいいと思います。

public class GLOVALBALUE {
public static int GLOBALVALUE001;
public static int GLOBALVALUE002;
public static int GLOBALVALUE003;
public static int GLOBALVALUE004;
public static int GLOBALVALUE005;
public static int GLOBALVALUE006;
}
154 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:47:43 ]: >>148
そうか？
146じゃねーけどクラス図わかんねー奴なんかごろごろいるぞ
多数の協力会社からかき集められた連中なんかはほとんどわかってねーし
155 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:48:23 ]: >>150
ベースクラスが無いから。
つうか、雨後のタケノコのように一斉に足りない機能を追加し始めたからw
156 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:49:03 ]: >>151
ニュアンスで仕事しないでくれよ・・
157 名前：仕様書無しさん [2007/07/01(日) 23:49:24 ]: >>154
それはあなたの会社がｒｙ
158 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:49:57 ]: >>156
>>149はいいのか？わけわかんね
159 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:51:23 ]: そうか、設計段階で破綻してたんだ。納得。
160 名前：仕様書無しさん [2007/07/01(日) 23:51:47 ]: >>153
頭いいな、おまえ。
161 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:52:49 ]: >>160
悪魔を誉めるなw
162 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:52:54 ]: いや・・・構造化という言葉を知らないのはさすがに。
言語研修を終えたばかりの新人でもあるまいし。
新人でも「構造化構文」ぐらいは教わるのでは？

言葉を知らなくても確かに開発は出来るだろうが。
163 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:53:14 ]: >>157
お、あんたんところは人材に恵まれてんだな
うらやましい限りだ
～～言語できますか？のみで集められた連中は悲惨だぞ
こういう集め方を改めないSIerが悪いんだけどな
164 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:53:42 ]: ろくすっぽ言葉しらねえで開発してたくせに、
OOは用語が一般的じゃないからダメだ？いいわけくせえよ
165 名前：仕様書無しさん [2007/07/01(日) 23:57:35 ]: OOの悪い所。
抽象化を人任せ。
166 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:58:00 ]: つか、人は自分で集めるもんだろw
どんだけ受身なんだよ
167 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:58:25 ]: 新しいパラダイムには新しい言葉が付き物なのだが
168 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:58:38 ]: >>164
汎化、特化、継承、集約、委譲、あとは略。
これらを見てOOを知らない人が敬遠せずに素直に学習すると思ってる？
辟易する奴がいてもおかしくないだろ。
169 名前：仕様書無しさん mailto:sage [2007/07/01(日) 23:59:20 ]: >>166
宗教やってんじゃないんだから
170 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:00:46 ]: >>28
pc11.2ch.net/test/read.cgi/prog/1179153355/
●下記の話題は何度繰り返されても結論が出ず、無駄に荒れるだけなので避けましょう
・オブジェクト指向
171 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:00:52 ]: >>168
辟易する奴がいてもおかしくないし、全く否定はしないが
そいつらは置き去りでいいだろ。
なんであわせる必要がある？
172 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:02:31 ]: >>171
考えて書いてくれよ・・・
工程はそいつら込みで引いてあんだから置き去りにはできんだろ
173 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:03:10 ]: >>169
宗教？いみわからん
適当に人足あつめて「こいつら使えません＞＜」
で、結論が「OOは習得するのは難しいからダメだわ」

おかしいだろ
174 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:04:16 ]: >>172
だから人を選別できない理由はなんだよ
おまえが集められる側だからだろうが
175 名前：仕様書無しさん [2007/07/02(月) 00:04:36 ]: >>163
OOの説教たれたり駄目出しする会社だ
OOがもっと流行って欲しい気もするが安っぽくなるは嫌と難しいところだな
176 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:05:29 ]: 開発者が人材確保しなければならないスレはここですか？
177 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:05:43 ]: つうか、人足にOOの知識なんていらんのだよ。
設計する奴らの問題。
178 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:06:47 ]: >>176
ここらしいです
179 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:09:04 ]: つか別にいいんだよ。人集めできようができまいが

だが、OOの是非を論じるときに「開発者の質」って問題は
切り分けたほうがいいんじゃね？

構造化なら雑魚集めてもうまくいくか？いかないだろ
180 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:12:14 ]: >>177
いやそれはいるだろ。普通に
181 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:12:50 ]: >>168
なんだその、ならべると７つの大罪みたいでカッコイイなｗ
182 名前：仕様書無しさん [2007/07/02(月) 00:13:34 ]: 思い出した事。

オブジェクト指向には、
普通のオブジェクト指向とＣ＋＋型オブジェクト指向がある。
183 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:14:05 ]: >>180
コーディングスタイル教えて、設計書与えれば、与作でもコードは書けるぜ。
ダメなのは、コーダーに設計レベルを要求する姿勢。

分業しようぜ。
184 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:15:44 ]: >>183
なにいってんの
設計・実装を分離しないためのOOだぜ？
185 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:16:04 ]: >>181
ないす！
186 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:17:16 ]: >>184
責任逃れのＯＯって事か？
187 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:19:36 ]: >>186
責任逃れというより、「設計専任」「実装専任」って存在がそもそも不要
188 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:21:44 ]: >>187
不要なのは、00分かってる奴らを集めて初めて言えよ。
分からねえ人足集めて来て、設計までやらすからくだらねえクラス量産するんだろw
189 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:26:20 ]: >>188
だからさっきから言ってんだろ
人足集めるスタイルを変えないでOOして使えねーって
結論だすこと自体おかしいだろって
190 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:29:12 ]: >>189
だから、現状に合わせて、設計はしっかり集める側でやって、
人足にはコーディングとテストだけしてもらえって。
191 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:30:22 ]: >>1-190
だから・・・
192 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:31:07 ]: >>190
だからOO使う限りそのやり方じゃうまくいくはずねーって
193 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:32:36 ]: >>192
ならOO使わなきゃいいじゃんw
194 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:35:44 ]: >>193
OO使わないほうがいいのはおまえだろ
俺は人足を使わないw
195 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:39:14 ]: でも正直オブジェクト指向ってもんが見えてきたよな
元のオブジェクト単位でどうこうってのも確かな理論があっていいって言ってるわけじゃねぇしな
その上にあれこれ無駄なもん積み上げても結局本質はあやふやなまま

まさに砂上の楼閣
これが現状ですよ
196 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:39:22 ]: なあOOだと設計も実装も兼任なんて、誰が言ったんだ？
それじゃあ、設計の人数多すぎるし、実装の人数少なすぎねえか？
197 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:39:47 ]: 人足ってなんて読むの？にんそく？じんそく？ひとあし？
198 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:40:54 ]: >>196
メイヤーとかストラウストラップ
その他多数
199 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:41:40 ]: なんか上の方で用語がどうのこうの言ってたけど、
用語使わないと他人に説明できない技術は「身についた技術」とは言えないと思うぞ。
ただまぁ、用語が通じる相手の方がコミュニケーションが楽なのは当たり前だが。
200 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:42:02 ]: >>196
兼任なんて誰も言ってねーだろ
設計と実装を「分離しない」ためのOO。
なので設計者と実装者は別でも構わん
201 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:42:52 ]: >>199
用語ってそういうもんだろ
202 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:43:17 ]: >>196
おめー、原理主義者の俺だってそんぐれーは知ってるぞｗ
おめーの宗派が何かは知らないけど勉強不足じゃね？
とりあえずオブジェクト指向は設計～実装までシームレスだかなんだかってのが売り文句だったんだぜ
そのためにクラスなんだぜ
203 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:44:53 ]: >>199
激しく同意
用語知らんから伝わらんってのはいいわけ
技術者が説明できなくてなんのための技術者か？

説明嫌ならさっさと辞めろといいたい
204 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:44:58 ]: >>199
な。>>196みたいな奴がいるんだよ。
205 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:45:08 ]: 言語を覚えましたって奴が設計出来るとは限らない。

OOの話はその辺を複雑化した後抽象的な表現にする流れが多いと思う。
実装方法と言語のOO要素をごちゃ混ぜにしてクラス分けで全て解決ですよ
みたいな流れになる。

単純化と具象化をモットーとする構造化をなぜ先にやらず、
いきなりOOなのかが疑問だ。

論理的思考が出来ていてこその抽象化なのになぜそれを否定するのか？

今も昔も実装技術と設計技術と言語習得は似ている様で違う。
OOPなら全部まとめて面倒見れるんだ？
206 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:45:29 ]: ああ、おまいらの勘違いか。
別に設計と実装が別人でもいいんだろ。
やっぱし、人足に設計までさせるなや。
207 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:46:31 ]: 上のは用語自体の説明のことじゃね？
「汎化ってなんですか？」
ってらしいから。
そういうことを教えるのが鬱って話でしょ。
208 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:46:42 ]: >>206
たぶんお前わかってねえぞ
209 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:48:19 ]: >>205
構造化知らずにいきなりOOって、お前がいいだした珍説だろ
210 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:49:10 ]: ところで、おまいら、どれが誰の言った書き込みか分かるのか？
211 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:49:40 ]: C++に詳しい人が多そうなんで質問。

class A:B<A>;
こんなクラスをたまに見るけど、
こういうのはどういう時に使うのか教えてください。
212 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:50:16 ]: >>209
証明してよ。

今時構造化知ってるやつ居るのか？
213 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:50:19 ]: >>210
わかるよ。>>205だろ
214 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:51:30 ]: >>212
証明？やぶから棒になにを言い出すんだ
215 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:53:52 ]: >>213
いきなりハズレだし。
誰が誰だかわからねえのに、オマイが先に言い出したとか、言うなよw
216 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:54:16 ]: >>141
それは技術を使わない
土方方式

クラス定義したからOOPだよと言ってるだけだ。
言語使用がOOP出来るだけの物。
217 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:54:30 ]: >>212
構造化とOOは対立してない
OOがいい、構造化はダメ
構造化がいい、OOはダメ
ってのは分かってない証拠だ
218 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:56:26 ]: >>217
それは同意。
構造化を押し進めると、OO的な構成になる。
219 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:56:30 ]: 悪かったwだが
>>215
オマイが先にって何の話だよw
俺は>>205にしかつっこんでねえよ
220 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:57:14 ]: >>211
スーパークラスが導出先クラスの型によって生成されるクラスだよ。
他にもポリシーのような使い方もある、とりあえずModern C++ Design見ながら使い倒してみるといい。
おれはBのクラスの上に共通の抽象スーパークラスを入れるのが得意技。
boost系のソースコードにもその種の面白いのが沢山あるよ。
221 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:57:33 ]: なぜ素人にオブジェクト指向（言語）なんて使わせるんだ？

なぜ素人がプログラム作ってるんだ？

昔からある疑問だ。

いきなり屑みたいな文章が増えて嫌になった。

>>141見たいなのがオブジェクト指向の実際なんだろ？
222 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:57:35 ]: >>217は正しいとおもうが、>>218はどうかな。。
223 名前：仕様書無しさん mailto:sage [2007/07/02(月) 00:59:20 ]: まああれだ。
OOってのは過去の開発で失敗したことを失敗しないようにと考えられたわけだ。
ところが資格などの統一見解が無いので
OOが実装されてる言語を扱う技術者はそれなりに理解するが
OOの設計を行う技術者（実装をしない連中）は学習しないわけだ。
となると、当然設計から実装へのシームレスなんてもんは期待できんわけ。

ってことでOK？
224 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:01:05 ]: >>222
あ？
だってよ、構造化じゃマルチタスクに対応できねえもんw
構造化した先に、各機能を同時に使えるようにとか言い出したら、オブジェクト指向に行かざるおえなかったよなぁ？
225 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:01:10 ]: >>223
だから構造化に資格があるのかと小一時間
226 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:01:57 ]: いかざるお？日本語おかしいおw
227 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:01:57 ]: 220のつづき
そうそう、この種の話題はオブジェクト指向ではなくてテンプレートジェネリックスまたはテンプレートメタプログラミングの領域になるので、それらしいスレにいってみるといいと思う。
唯一オブジェクト指向を超られそうで、かつ実用的手プログラム技術ネタだと思うんで熱いよ、行き着くところまでいくと最終的にはHaskellマンセーになるかも知れないがw
C++は増築が行き過ぎて少し複雑になりすぎたからな
228 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:03:15 ]: >>224
構造化でマルチタスクできるけど、釣り？

キムチ臭いよﾌﾟｹﾞﾗ
229 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:03:58 ]: >>227
OOを越えるも何も、OOで抽象化がカバーしきれなかった「アルゴリズム」
の抽象だろ。そもそも被ってない。
230 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:04:48 ]: 関数単位に分割する方法が構造化手法で，責務単位に分割する方法がオブジェクト指向
こう考えれば分かりやすいのだけど、
オブジェクト指向はやたらと用語が多いし、
へんな例が多くて一層混乱してるってのは事実。
231 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:05:37 ]: >>228
構造化がマルチタスクで使えるかどうか
それは実装の問題じゃ？
232 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:05:44 ]: >>229
半可通な知識で語ったら恥ずかしい目にあうよ、それとは全然関係ないから。
233 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:07:11 ]: >>232
あれ？そうなんだ
まあひとまずスマンね
234 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:07:21 ]: >>230
関数自体が責務単位だからＯＯ＝構造化だよな？
235 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:08:46 ]: >>234
Cなんかの関数が表してるのは、いわゆる「機能」だろ？
236 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:09:49 ]: >>231
プログラムの設計手法とマルチタスク動作を混合して
抽象化した結果、

OOPじゃなければマルチタスクに対応できない。
というオブジェクト指向的解が導きだされたんだろう。
237 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:12:10 ]: >>235
機能と責務ってそんなに違わんだろw
238 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:14:07 ]: オブジェクト指向って、Windowsで窓やダイアログ単位で実装してくうちに考えついたんじゃねえの？　とか思う今日このごろ。
239 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:15:45 ]: >>237
「何を」と「誰が」っていう点で違う
240 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:17:19 ]: 技術者の学習不足も原因の一つだろうが、
OOの話題が何かと混乱してるは事実。

OOがわかりにくい、って話があるのはあんたらも知ってるだろ。
そんな状況のものに手を出す奴がどれだけいるかだな。
少なくとも今の偽装請負があたりまえのままではダメだな。
241 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:18:47 ]: >>239
じゃあ、「誰が」で機能分けしちゃえば、構造化プログラムもOOだな。
242 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/02(月) 01:19:15 ]: >>238
今の若いものは知らんじゃろうが、
昔、Alto ちゅうワークステーションがあってのう・・・。
243 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:20:01 ]: >>238
原理主義者の俺が説明すると
はじめは気体分子のシミュレーションが目的だった
分子１つの動作と衝突したときの動作のプログラムを組んで
一斉に動かすとどんなもんじゃいボケが
って感じだった
244 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:20:44 ]: >>242
だからココ電に戻せって
あぼ～ん指定してるんだから出てくんなよ
245 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:21:05 ]: >>241
うん。。いわゆるOOだなそれ、普通に。
246 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:23:19 ]: >>243
じゃあ、ゲーム屋さんがアセンブラで組んでた頃からOOやってたって話も、まんざら嘘じゃないんだね？
247 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:25:06 ]: >>246
飛躍しすぎだろ
248 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:25:32 ]: >>220
ありがとう。Modernはtypelistでtree作ってくあたりでお腹いっぱいに…。
オブジェクト指向的に見ると、集合Aの中に集合Bがあって、
さらに集合Bの中に集合Aがあるわけでおかしくなりますね。

そういうわけで、単に実装の都合で、こういうクラスがでてくるのだと思います。
このクラスが必要になる簡単な例なんてないでしょうか？
249 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:28:54 ]: >>248
うっせー。空気嫁
250 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/02(月) 01:29:26 ]: >>244
多分、信じてもらえないでしょうけど、人違いですよ。
あなたは少し、2chのやりすぎで、疲れているのだと思います。
251 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:33:36 ]: >>248
それは数学の集合の事かと、ついでにいうと数学的な集合でも、それを「指す物」であれば入れちゃっても問題ないですよ。
集合にはならくても領域(クラス)にはなるから。
例ですか、うーん、その前にもう少し理解が進まないと難しいかも。
boostのtype_traitsとか見て助走を付けてごらん、そのあとその使い方を想像してみるべし夢広がリングです。
252 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:37:18 ]: >>251
お前もクレクレにレスつけてんじゃねーよボケが
スレタイ千回嫁
253 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:44:12 ]: 今の職場にいる限りはOOなんかまったく関係ないな
と思う今日この頃
254 名前：仕様書無しさん mailto:sage [2007/07/02(月) 01:47:30 ]: そらそうだOOPLを使っていなければ
255 名前：仕様書無しさん [2007/07/02(月) 03:00:28 ]: 毎日毎日代わり映えしない自作自演ご苦労
256 名前：仕様書無しさん [2007/07/02(月) 07:22:39 ]: オブジェクト指向、って
「クラスライブラリ屋」だけがやってれば十分だと思う。
それを使うだけでいい側は手続き型っぽく書ければ十分じゃないか？
単発開発の案件なのに、抽象クラス作って継承してるの２つだけとか
全く足かせでしかない。
ライブラリそのものを売り物にでもしてなけりゃ
現実的には再利用性なんてYAGNIだよ。
257 名前：仕様書無しさん mailto:sage [2007/07/02(月) 11:09:48 ]: 計算機
258 名前：仕様書無しさん mailto:sage [2007/07/02(月) 11:26:12 ]: >>256
なかなかの見識かと。
結果として再利用性のあるものを生産するためには、事実上、余計な工数がかかる。
OOの最大の売りは再利用性なのだが、
そんな「将来必要となるかも知れない」という再利用性なぞに工数はかけていられない。

正しい。正しいけど。再利用の夢を捨てきれない者にそれを理解させるのは(ry
259 名前：仕様書無しさん [2007/07/02(月) 13:01:32 ]: >>258
まあ、再利用性は見込めないかも知れんが。
プログラムの依存性を少なくして、デスマ予防が出来るメリットはある。
260 名前：仕様書無しさん mailto:sage [2007/07/02(月) 14:12:07 ]: 疎結合はOOだけが実現できる特性ではない
261 名前：仕様書無しさん mailto:sage [2007/07/02(月) 19:59:23 ]: 再利用がなければ最初の手間は無駄にしかならないのは確か。
それは数が多ければ多いほどに無視のできない差になる。
それでも私はオブジェクトを推したくなる。
理由がないのに推すのはただの信者でしかないがなww
262 名前：仕様書無しさん mailto:sage [2007/07/02(月) 20:09:43 ]: 不思議なのは、使わない奴らの不満の声。
不要だと思うのなら黙っておればよかろう。
263 名前：仕様書無しさん mailto:sage [2007/07/02(月) 20:12:11 ]: >>261
それは貴方の仕事が同一のシステムをある程度以上の長期間、
保守／バージョンアップをする仕事であるから
ではないのか？
264 名前：仕様書無しさん [2007/07/02(月) 21:09:22 ]: なんかのクラスを継承した時点で再利用じゃね?
265 名前：仕様書無しさん mailto:sage [2007/07/02(月) 21:44:44 ]: >>264
正解
266 名前：仕様書無しさん [2007/07/02(月) 21:51:43 ]: OOの再利用性を生かすべき場面は、
COBOLプログラマが言うところの「共通ライブラリ」じゃないかな
267 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/02(月) 21:56:18 ]: ゲームでは「ギャラクシアン」（１９８２ごろ）に移動物体を Objectと言っていた。
回路図にもそう描いてあったし、プログラマーも「オブジェ」って呼んでた。
268 名前：仕様書無しさん mailto:sage [2007/07/02(月) 21:57:16 ]: >>256
YAGNIであってもOCPがまるっきり無視されていいわけじゃないぞ
変更が入ったときあっちこっち直してまわるのはだめ
269 名前：仕様書無しさん mailto:sage [2007/07/02(月) 22:21:40 ]: >>267
そんなの珍しくもないし、他の会社でも似たような造りだったし。
まったくプログラムを擬人化してる辺りは、既にＯＯだったし。
270 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/02(月) 22:23:36 ]: 最初にオブジェを使ったのがギャラクシアンなのだ。
271 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/02(月) 22:24:38 ]: 回路を考えたのはアタリで、そのルーツは軍用ディスプレイだったと聞く。
272 名前：仕様書無しさん [2007/07/02(月) 22:27:44 ]: 最初から完全に設計しきって始めるか、
途中で必要に応じて粘土のようにクラスを変形させながら進めるか。
そのどちらかならうまくいく。
中途半端に設計して中途半端に手戻りを許さないスケジュールだったりするのが最悪。
273 名前：仕様書無しさん mailto:sage [2007/07/02(月) 22:31:19 ]: 同意。FとかHとかNとかそんなんばっか。
274 名前：仕様書無しさん mailto:sage [2007/07/02(月) 22:45:35 ]: オブジェクト指向に関するお勧めの書籍を教えれ。
275 名前：仕様書無しさん mailto:sage [2007/07/02(月) 22:52:59 ]: >>274
いい加減秋田
276 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:00:24 ]: 再利用性を信じている香具師は勉強不足なのが丸出し。
277 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:04:13 ]: 感覚指向とか雰囲気指向の奴らにオブジェクト指向は無理がある。
278 名前：仕様書無しさん [2007/07/02(月) 23:09:51 ]: >>272
後者はデスマになるから止めとけ。
279 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:24:51 ]: 指向　ってのは誰がつけたんだ？
なんとか指向って言ってれば売れるご時勢なのか？
280 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:27:40 ]: 至高ってつけたのは海原雄山
281 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:44:26 ]: 違うよ
帝都新聞だよ
282 名前：おじゃばさま ◆GxjxF3yEw6 [2007/07/02(月) 23:44:48 ]: >>5
前スレ825の意見は的外れだ。
ライブラリを使う側も、それらのライブラリを使ってアプリを作る事を考えれば、労力は似たような物だ。
また俺はOO万能だとは言っていない。OOは修正が少なく、速度を要求される物には向かないと言っている。
第一、OOの場合はライブラリと、クラスやアプリケーションの区切りは、作成者の任意になる。
ライブラリとアプリを区切っている段階で、825は構造化の人だと思われる。

OOを勉強するのが偉いとは言っていないが、OOをマスターしている人と、マスターしていない人がいたら、
他の条件が同じなら、マスターしている人の方が偉いだろう。

新人研修は俺の部下がやっているが、話を聞くと優秀な新人は数カ月でWEB-DBアプリを作る所まで来るらしい。
CよりJavaの方が習得も早いそうだ。やっぱり教え方と素直さが大切なんじゃね？
283 名前：仕様書無しさん mailto:sage [2007/07/02(月) 23:45:04 ]: >>272
インクリメンタル手法を思い違いしてるんじゃないか？
284 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/03(火) 00:21:15 ]: おじゃばのジョークは判りにくいんだよ
285 名前：仕様書無しさん mailto:sage [2007/07/03(火) 00:27:27 ]: Simula～、うしろ、うしろ
286 名前：仕様書無しさん mailto:sage [2007/07/03(火) 00:30:29 ]: つまらんよ
287 名前：仕様書無しさん mailto:sage [2007/07/03(火) 01:01:29 ]: どういう機能が再利用し易いか？

という定理みたいなもんがあるのかねぇ。
288 名前：仕様書無しさん mailto:sage [2007/07/03(火) 01:20:14 ]: 転職を頻繁に繰り返すなら簡単な名簿を毎回作り、
同じ会社に骨を埋めるのなら、最初に本格的なものを作り、
後から付け足していくのと同じ感覚で、、、
ってのはなんか誤解してるかなww

俺の頭の中では後者のような流れにオブジェクトと思ってるけど。
289 名前：仕様書無しさん mailto:sage [2007/07/03(火) 01:21:57 ]: [オブジェクト指向]
　戦場では必要の無いもの。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
　尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
　ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
　ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。
290 名前：仕様書無しさん mailto:sage [2007/07/03(火) 01:39:53 ]: >>289
ｗｗｗコピペ？

親亀を構成するクラスのそのまた下の下の下はどうなっているかを
考えるのはオブジェクト思考じゃないんだろうね。
291 名前：仕様書無しさん mailto:sage [2007/07/03(火) 08:55:33 ]: 全体をコーディネートする人がいないと、老舗旅館みたいになるよ。
どちらも逃げ出すのが大変ｗ
292 名前：仕様書無しさん [2007/07/03(火) 09:40:09 ]: 老舗旅館は宣伝さえうまくいけば
客は来るよ
293 名前：仕様書無しさん mailto:sage [2007/07/03(火) 20:40:15 ]: なお、C++とPythonでは二人の亀に乗る亀もおり（以下略）
294 名前：仕様書無しさん mailto:sage [2007/07/03(火) 21:24:27 ]: >>287
抽象度が高いものほど再利用性も高い
295 名前：仕様書無しさん mailto:sage [2007/07/03(火) 21:32:06 ]: 設計やりきってから実装すればOKとかいってる奴
図とか自然言語で設計するのが
エディタ上でコード書きながら設計するのより速いわけないだろ
296 名前：仕様書無しさん mailto:sage [2007/07/03(火) 21:49:49 ]: >>295
その「設計」は保守のための文書を残すための作業。
だから理論的にはその設計はリリース後でも良いのだが。
頭が古い人を納得させるのが大変　とか
文書を今作成しても間に合う　とかの理由で(ry
そして言いにくいのだがｽﾚﾁｶﾞｲ
297 名前：仕様書無しさん mailto:sage [2007/07/03(火) 21:59:26 ]: >>296
ｽﾚﾁｶﾞｲついでに聞くけど、設計に「その」とか「どの」とかあんの？
298 名前：仕様書無しさん mailto:sage [2007/07/03(火) 22:33:40 ]: 良く出来たフレームワークに乗っかるだけなら、実装ポイントのサンプルだけ見て、
「ああ、そういうものなんだ。」って思うだけで別に中身の機構について深く考える必要ないんじゃないか。

要するに、ドキュメントは実装ポイントのHOWTOだけ書いてあればよろし。
内部的な詳細はコメントで語れ。ドキュメントジェネレータが解する形式で。
299 名前：仕様書無しさん mailto:sage [2007/07/03(火) 22:38:06 ]: 家の設計図は柱の組み方も見ただけで分かるくらいに詳細に描くよ。
なのにプログラムの設計図はどうしてあんなにいいかげんなの？
300 名前：仕様書無しさん mailto:sage [2007/07/03(火) 22:39:42 ]: プログラムの設計図はソースコードだよ
バイナリが成果物
301 名前：仕様書無しさん mailto:sage [2007/07/03(火) 22:58:32 ]: >>300
支持なのだが。その正しい認識を獲得していない人がね。大杉
302 名前：仕様書無しさん mailto:sage [2007/07/03(火) 22:58:50 ]: ウェブサイトを家や本や雑誌に例えて批判するのがナンセンスなように、
プログラムを建築に例えて批判するのはナンセンスだ。

だいたいお金も納期も設計者も法整備も労働者に対する配慮も無いじゃないか。
303 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:05:21 ]: 設計っていうと、なんか唯一無二の正解がありそうな作業に感じる
デザインっていうことばをそのまま訳さずに使う方がいいとおもう
304 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:12:49 ]: >>300
スクリプト言語の場合はどうなるの?
305 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/03(火) 23:17:16 ]: まあ、建築といっても、かまくらから高層ビルまで、
いろんなレベルのものがあるわけで、
必要とされる精度によって、設計図の精度も変わってくるのは当然でしょう。
かまくら作るときに、三面図作ったりしないように、
スクリプト言語で使い捨てのコードを書くのに、設計図はいらない。
306 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:18:52 ]: >>300
鋳造の型を持って来て、「これが設計図だ！」と言ってるようなもんだな。
それを作るのに設計が必要って話をしてるんじゃねえの？
307 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:19:58 ]: >>305
スクリプト言語で作り上げたweb上のお城も使い捨て？
308 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:25:37 ]: >>306
まあそんなのは設計の定義次第だから、各自好きなように考えればいいやな。
だけど、
>それを作るのに設計が必要って話をしてるんじゃねえの？
どこでそんな話してる？
309 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:26:53 ]: 最近はフレームワークから自動で吐かれたスクリプトもあるからなあ。
そうなるとバイナリっつーか成果物の方に入ってしまうんじゃ？
310 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:28:28 ]: そんなこといいだしたらC++のテンプレートとかどうなる？
311 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:28:29 ]: >>308
オブジェクト指向って、設計理論じゃないの？
312 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:29:31 ]: 少なくとも「理論」ではないだろ
313 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:38:40 ]: >>311
それとコーディング＝設計と、どう関係ある？
314 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/03(火) 23:41:18 ]: >>307
いや、
>スクリプト言語で使い捨てのコードを書くのに
というのは「ありがちな例」として引き合いに出しただけで、
スクリプト言語で書かれたから使い捨てという意味ではないよ。
315 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:51:04 ]: 現状、ソースコード以上に厳密に簡潔に設計を表現できるものは存在しない。
LL言語なんか抽象度高いから特に自然言語の冗長性が顕著にあらわれて、
設計書書いててもいらいらする。直接コード書かせてくれと。
316 名前：仕様書無しさん mailto:sage [2007/07/03(火) 23:59:50 ]: 複数人で作業の必要があるのならインターフェース合わせと振る舞いの概要さえ決めておけば済む話では無かろうか？
保守で必要なのは外部仕様とコメントだけな。
317 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:10:14 ]: >>316
トップから降りてくるところはインタフェース合わせだけでいいけど、
モデルってボトムアップで設計しなきゃうまくつくれないし。
ボトムアップで積み上げる部分が小さけりゃOOのメリットも少い。
318 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:11:01 ]: 神は細部に宿る。
319 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:14:01 ]: そして悪魔も細部に宿る。
320 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:21:13 ]: ソースコードが設計書、というのは間違いではないが、
ソースだけで業務を把握することは不可能。
ソースに書いてあるのは実行結果が中心であり、
なんのためにその結果を求めるかは分からない。

という当たり前のことはおまぃら分かって喋ってんだよな？
321 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:23:20 ]: >>320
煽りたいだけの馬鹿を相手にしないのw
322 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:28:23 ]: んだからドキュメントは概要と最低限の決め事だけでいいよって話。
コーダーにまわすなら細部までキッチリ書く必要あるんだろうけど。
323 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:30:07 ]: ２年生レベルだとそうなんだろうな
324 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/04(水) 00:31:17 ]: >>292
老舗旅館が増築に増築を繰り返して迷路のようになった巨大木造建築で火災が発生すると大量死するという例えだよ
（適）マークが作られたのはそういう事件があったから。
325 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:31:21 ]: UML書くのが好きな人っている？
いい加減めんどくさいんだよね
時間かかるし
326 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:36:23 ]: >>325
全般的に不要だが
なかでも一番いらんのがシーケンス図だな
327 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:37:28 ]: モデリングセッションでホワイトボードに書き出した奴をデジカメでパチリとやればいいよ。
後はソースからリバースで吐き出してくれるツール使うとか。
328 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:37:31 ]: >>325
ツール使いな。
h ttp://jude.change-vision.com/jude-web/index.html
こんなんとか
329 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:39:51 ]: >>320
何をなすか、は「仕様」だろ
設計とは違う
330 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:41:49 ]: >>329が基本仕様と業務設計の違いを教えてくれるそうです
331 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:43:09 ]: 設計って、例えば飛行機の設計には、重心や揚力などの基本的な計算も含まれるんだけどね。
それを含めて、設計じゃね？
332 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:46:07 ]: わかってないなあ
設計ってのは、やることを書くんじゃなくて、
やらないことをはっきりさせるのが重要なんだよ
333 名前：仕様書無しさん mailto:sage [2007/07/04(水) 00:47:26 ]: それを含めて、つかそれ普通に設計じゃね？
よくわからん
334 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:02:10 ]: スペックとデザイン、って英語で書いた方が通りが良くなるから不思議だ。
もっとも日本ではデザインと書くと意匠を意味する事が多いが。
335 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:04:10 ]: なんのために＝要求
なにをやるか＝仕様
どうやってやるか＝設計
336 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:07:09 ]: 要するに俺らのやってる事はオブジェクト指向どうのこうのより前に工業ですら無いわけさ。
かといって著作業でもない。ふふふ。
337 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:12:48 ]: >>325
クラス図最高
338 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:14:23 ]: >>337
最高にいらん
339 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:15:31 ]: アセンブラで組んでた頃は、サブルーチンの総マシンサイクルや使用スタックサイズなんてぇのも要求されたもんだよ。
340 名前：仕様書無しさん [2007/07/04(水) 01:17:11 ]: >>336
そもそも工業じゃねえし。

システム開発は職人芸。
341 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:18:43 ]: >>338
詳細なインタフェース仕様書とかフロー書かされるよりマシだろｗ
342 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:19:20 ]: >>336
>>339
レス内容以前に、会話が成立してない。
ココ電クラスのコミュニケーション力のなさ。
つか本人だろ。
343 名前：339 mailto:sage [2007/07/04(水) 01:21:36 ]: >>342
ソフトウエア作りは工業だって話だろ。
おまえはこのスレの何を見てるんだ？
344 名前：仕様書無しさん mailto:sage [2007/07/04(水) 01:35:45 ]: >>335
「要求仕様設計書」なんてタイトルのドキュメントがあるとなんかドキドキするな。
345 名前：仕様書無しさん [2007/07/04(水) 02:24:32 ]: オブジェクト指向が嫌い、使いこなせない人は以下のどれかに５つ以上に当てはまる人である。

・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている人
346 名前：仕様書無しさん mailto:sage [2007/07/04(水) 02:26:43 ]: >>345
そのままオブジェクト指向を推奨してる人の傾向じゃね？
347 名前：仕様書無しさん [2007/07/04(水) 02:41:58 ]: ・保守管理のコストより、実行時間などの動作コストの方がより重要だと感じている人
・後先を考えず、新しい物にすぐ飛びつく人
・旧来の物との整合性を検証しない人
・コーディングは○投げすれば良いと思っている人
・言語仕様をマスターしなくても開発できると思っている人
・その場しのぎのパッチワークに全く嫌悪感を感じない人
・世界は自分のために存在していると思っている人
・機能を全て使いたがる人
・機能を全て自分で作りたがる人
・自己に固い信念を持っていて絶対に変えられない人
・学校で覚えたことが死ぬまで使えると思っている人
・ポーランド記法を多用する人
・アルゴリズム、ロジックで全てを表現できると思っている人
348 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/04(水) 03:11:54 ]: オブジェクト指向を進める人、使いこなせていると自称する人は以下のどれかに５つ以上に当てはまる人である。

・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている
349 名前：仕様書無しさん mailto:sage [2007/07/04(水) 07:51:13 ]: なんかこの業界に多そうなのばかりだな。
350 名前：おじゃばさま ◆GxjxF3yEw6 [2007/07/04(水) 09:31:10 ]: オブジェクト指向が苦手な人のほとんどは、以下の項目の3つ以上に当てはまる。

・構造化プログラミングに染まっている。
・思い込みが激しい。
・新しい事を覚えるのが苦手。
351 名前：仕様書無しさん [2007/07/04(水) 09:40:48 ]: オブジェクト指向プログラミングと構造化プログラミングは排他的じゃないよ
352 名前：仕様書無しさん [2007/07/04(水) 09:51:45 ]: ハッキリ言って電球が嫌い
353 名前：仕様書無しさん mailto:sage [2007/07/04(水) 09:53:25 ]: 電球は追い詰められると逃げるからなｗ
354 名前：仕様書無しさん mailto:sage [2007/07/04(水) 10:19:13 ]: ライブラリ使うだけでもOOPの恩恵は受けられるだろ。
Cのライブラリで
corp_libname_namespace_verb_args(this, ...)
なんて関数がずらずら並んでるの見るとゲンナリする。
355 名前：仕様書無しさん mailto:sage [2007/07/04(水) 11:06:37 ]: >>354
わかるわかる
クラスのメソッドでも長い名前の見ると
大概オブジェクトの粒度が間違ってる
356 名前：仕様書無しさん [2007/07/04(水) 12:49:42 ]: >>346
＞そのままオブジェクト指向を推奨してる人の傾向じゃね？

まぁ、そもそも向いてない人が推奨してるからカオス化してるんじゃないかと。

普通、プログラミングをすればC言語でもオブジェクト指向のコードになっていく。
さすがに言語仕様がOOじゃないから完全なOOじゃないが。
良いプログラミングになればなるほど、OOに近づいていく。
移植性、保守性、論理性、可読性、再利用性、そういった物を考慮するとね。
357 名前：仕様書無しさん [2007/07/04(水) 16:56:17 ]: プログラミングの安全性を高めようとすると、柔軟性が無くなる。
逆に柔軟性を高めようとすると、安全性が無くなる。
で、その中間をとろうとすると、今度は人間がプログラムを読めなくなる。

何時解決する事やら…
358 名前：仕様書無しさん mailto:sage [2007/07/04(水) 17:00:01 ]: >>357
プロダクトごとに落としどころを決めろ、
としか言えんな・・・。
359 名前：仕様書無しさん mailto:sage [2007/07/04(水) 17:30:19 ]: あるある…orz
360 名前：仕様書無しさん [2007/07/04(水) 19:05:20 ]: >>357
安全性を高めた「粒」を集めて柔軟性に結びつけるのがOOPですよ。

まぁ粒が細かくなって多種多様になるとやっぱり読めなくなるけどね。
361 名前：仕様書無しさん mailto:sage [2007/07/04(水) 19:07:30 ]: 粒
ではなくて
層
であると愚考するが
362 名前：仕様書無しさん [2007/07/04(水) 20:06:10 ]: >>357
それは言語仕様に拘束される。
日本にまともなプログラミング言語開発者が居ないので問題が起こる。
本来は言語を拡張して対応すべき問題。
仕様やコーディング規則でやるのは限界がある。
363 名前：仕様書無しさん mailto:sage [2007/07/04(水) 20:06:33 ]: 継承、ポリモフィズム、再利用性、構造化、保守性……全てオブジェクト指向の恩恵ﾆﾀﾞ
364 名前：仕様書無しさん mailto:sage [2007/07/04(水) 20:37:04 ]: OOマンセーなやつら、エディタ何使ってる？
365 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/04(水) 21:15:44 ]: まあ、OOなんて手段だから、マンセーなんてありえないんだが。
いまんとこ、UMLとJavaでやってるけど、必要とあらば、
Cやアセンブラで非OOなプログラムも組むよ。

オブジェクト指向言語を使うなら、エディタは、
やはり継承関係を追えるようになっていないと、不便だね。
結局、単体のエディタよりも、Eclipse のような IDE を使うことになると思うよ。
366 名前：仕様書無しさん mailto:sage [2007/07/04(水) 21:29:19 ]: OOなんて所詮どーでもいいんです。
癒し系(死語)の優しいおねぇたんと一緒に仕事できればシヤワセなんです。
所詮俺なんて・・・
367 名前：仕様書無しさん mailto:sage [2007/07/04(水) 21:31:49 ]: と、いう意味で

SmalltalkのGoldbergおねたん
CLU/X WindowのLiskovおねたん
COBOLのAmazing Graceおねたん

この業界おねたんに事欠かないね♥
むさ苦しいおぢさんがひたすらジケーンする物性業界とは天と地ほど差がある・・・
368 名前：仕様書無しさん mailto:sage [2007/07/04(水) 21:34:07 ]: 麻酔たん＠Appleの富豪的プログラミングの次は
やっぱ癒し系プログラミングだろ
369 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:26:14 ]: いま、組んでるプログラムは全部void*なんだけどすげー見易いし、わかりやすい
370 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:27:47 ]: つLL言語
371 名前：おじゃばさま ◆GxjxF3yEw6 [2007/07/04(水) 22:42:13 ]: >>356
C言語でもオブジェクト指向になる？
ならないだろう。C言語でクラスを自作するのは大変だぞ。
構造化の良いソースとOOの良いソースは、モジュールの分割単位が全く違う。縦切りと横切りぐらい違う。
例えば電卓をクラス化するとしよう。
構造化の人はこう組む。
class Computer{
public:
　　int compute(string stmt);
};

OOの人はこう組む。
class Computer{
public:
　　void push0();
　　void push1();
　　void push2();
　　　　:
　　int getAnswer();
};

どっちを進化させても、もう片方に近づくことはない。
最初の設計思想が違う。
372 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:45:37 ]: >>371
>OOの人はこう組む。
断じて否ｗ
373 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:46:47 ]: push0なんてメソッド書きやがる人は(´･д･`) ﾔﾀﾞ
374 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:47:27 ]: おじゃばはネタなのか、釣りなのか、天然の愚図なのか。
375 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:49:49 ]: だいたいGUI部分と電卓の計算機の部分がいっしょになってるのが納得いかねぇ
手持ちの電卓分解してみろといいたい
っていうかちゃんと仕組みまで再現しろよ

そこで電卓を電卓たるように具現化するに一番いい簡略化をしろよ
センスが感じられないｗ
376 名前：仕様書無しさん mailto:sage [2007/07/04(水) 22:51:14 ]: かなしいけれど、おじゃばの底力を見た気がしたｗ
377 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:00:48 ]: ・・・つ、釣られないぞ
378 名前：sage [2007/07/04(水) 23:02:51 ]: 「例えば電卓」だ？電卓なめんなよ。
俺がこの間買った電卓、[2][0][0][+][2][0][%]って感じで押すと
200に20%増しで「240」って表示されるぞ。
あと[1][0][×][2][=] で「20」と表示された後[5][=]と押すと「50」って出る。
どうやら「10×」までの部分が記憶されてるらしい。
そんな機能あること20になるまで知らなかったぞ。
379 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:08:40 ]: 電卓を設計するとなりゃ
とりあえず内部の計算機の部分と外のケース（電卓）の部分にわけるだろ？

電卓クラス（液晶パネル、ボタン、計算機の関連を制御）
　液晶パネルクラス（数字を表示する。計算機の表示レジスタを画面に反映。）
　ボタンクラス（自分の記号がなんであるか知っている、ユーザの押下を検出。）

計算機クラス（表示レジスタと計算クラスの関連を制御）
　表示レジスタクラス（ここにぶち込まれたものが表示される）
　計算クラス（入力された文字列を解析→計算し、結果、経過を返す。
　　　　　　　　　文字列は電卓クラスから計算機クラスを通して渡される。
　　　　　　　　　押されたボタンの記号が文字列をして流れてくる。例：「１＋１＝」←これが文字列）

即興だがこんな感じでどうだろうか？
380 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:10:50 ]: 物理的な構造を真似ても意味が無いだろw
いったいどこまでここはネタスレなんだかw
381 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:12:41 ]: テラカオスｗ
382 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:13:47 ]: >>380
>物理的な構造を真似ても意味が無いだろ
俺はあると思うぜ
眼に見えるものだから相手との認識が一致しやすい
絵に書いて見せるから相手を理解させやすい
そういうもんだと思うぜ

多分、王道は無いと思うんだ。俺は。
383 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:17:21 ]: じゃあ、本体の裏蓋止めるネジや、電池、・・・ああ、ソーラー電卓なら太陽電池も必要だよ。
384 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:18:51 ]: おまいら本当に電卓のＯＯもできないのん？
おなはなしにならない。
385 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:19:10 ]: >>383
だから、大事なものだけ
相手を理解させるために必要なものだけ選定する作業が必要になる
自分が必要だと思うものを強引にこじつける能力だと思うんだよね
俺は

例えば電卓だって座標が必要になれば俺は外枠のケースをクラスにして座標をもたせるとかするよｗ
386 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:20:02 ]: ＯＯは本質を抽象化するのだよ。
387 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:20:56 ]: 俺もよく帰りの電車とかで
色んなものをオブジェクト指向で設計してみたりするけどな

カツラを髪の毛の派生にするか、帽子の派生にするかでかなり悩んだが
388 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:21:01 ]: 細かいこと言い出したらボタンにだって座標・縦横サイズが必要だしね
意外と外れて無いぜ
ネジははめ込み式のケースなのでないｗ
389 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:21:20 ]: 電卓なんて、
入力　→　計算　→　出力

この３っつのクラスで十分。
390 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:21:53 ]: そうさ、おまいらが持つセンスの本質をブースとするのがＯＯさ。
391 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:23:08 ]: 電卓の本質はインタープリタだよ。
392 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:23:50 ]: >>389
それは>>379の計算機部分でしかない
たまには他の人の設計も見ておくといいと思う
誰がどこまでを想定しててどのレベルで話してるのか一致させる能力がないと
作っても作り直しになっちゃうぞ
393 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:26:02 ]: >>391
そういうのあったなぁｗ
394 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:26:56 ]: 新入社員向け課題としての「電卓」をマジで分類すると：

HP関数電卓： Forthインタプリタを核にスタックマシンを構成
CASIO電卓：　Forthインタプリタに中置演算子プリプロセッサを追加
数式電卓：　　プログラミング言語の数式パーサにアクション記述。
　　　　　　　　　暇があったらスクリプト言語で数式処理機能(微積分、数式簡約化等)を追加。
　　　　　　　　　多項式イデアルの表現方法に迷い、課題提出期限に間に合わず入社３ヶ月で退社。

って感じかな。
10年位前に調べた所では、多項式イデアルの最適な表現方法やら、
広範囲に適用可能な数式の簡約化方法ってなんか難しいテーマらすぃ。
そしてそのレベルで悩める達人ならば、OOなんてお茶の子なんじゃないかな。
395 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:27:12 ]: 電卓はインタープリタなので構文解析も必要なのさ。
おまいらにはちと難かったか。すまん。
396 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:27:26 ]: >>392
あのな、実物の電卓だって、ボタンと石（集積回路）と液晶だけしかないっつうの。
397 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:28:46 ]: >>391で正しいと思う
インタープリタって言葉の意味を、よーく考えてみないといけない
398 名前：394 mailto:sage [2007/07/04(水) 23:28:51 ]: ってなテーマは、ここ２ちゃんでも狸系カテ趣味板に行けばやってる。

・・・OO議論するなら、それくらい押さえとけよな。
399 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:29:06 ]: 結論から言うと、電卓で表層の部品しか見えない香具師にはＯＯは無理って言うこと。
じゃ、おやすみ。
400 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:31:24 ]: 同じように、オセロで石が見える香具師もＯＯは無理。
ポットで水が見える香具師も上に同じ。
401 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:31:34 ]: 昔、５万円ぐらいした電卓（ポケコン？）って何ができてあんなに高かったの？
402 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:32:33 ]: ＯＯは万人には無理な概念なのさ。
403 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:32:45 ]: ああ、でもな
入力、処理　出力
この３っつは、全ての基本クラスだ。
404 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:34:36 ]: いやむしろ俺は「インタプリタ」って概念を知ってるからこそ
電卓がインタプリタである、と考えることができるんだと思う

つまり、実物を「既に知っている概念」に押し込めることで扱いやすくする。
オブジェクト指向とはそういう技術。
405 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:34:58 ]: オブジェクト指向、ってくくりで話してるけど
クラス指向とプロトタイプ指向で大きく違うと思うんだけど。
406 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:35:20 ]: >>403
あたりまえだけど、この概念は強力すぎて香具師には活用できないよ。
407 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:37:00 ]: >>403
ライトセーバーと同様に強力すぎてマスタ以外には使いこなせない。
408 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:37:11 ]: 原則、このスレのオブジェクト指向＝クラス指向のことでいいだろ。
409 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:37:37 ]: >>404
なんだ、OOで電卓するにはインタプリタ知識が必要、でおしまいか。
俺は数式処理からベンキョして、関数型言語逝って、
「現場向け実用パラダイム」としてOOやったから、
努力足りない奴に「OOの研究者にしか判らない理屈を言うな」とか言われると
すんげぇムカつく。
410 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:38:56 ]: >>409
日本語でｒｙ
411 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:39:11 ]: ・入出力
・データ
・処理
ってクラス構成もあると
412 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:39:20 ]: おまいら本当にＯＯの勉強してるのかぁ？
レベル低すぎないか。
413 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:40:14 ]: だいたい「OOの研究者」なんて今時いねぇだろ。
10年前なら分散オブジェクトの未来形としての「エージェント指向」、
10～5年前ならポストOO的テーマの一つとして「アスペクト指向」
とかあったわけだが、今だと
・OOを教育目的として使ったり
・OOを含む、ソフトウェア/システム開発上の諸問題を
　CMU SEI的観点から研究
みたいなんじゃねぇの。
414 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:41:11 ]: 超お勧めのＯＯ本があるけど教えてやろうか？
415 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:41:16 ]: エージェント指向はどっかいった
アスペクト指向はJavaドカタの必需品
416 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:41:32 ]: >>410
何が判らなかったの？
キミが理解できなかった点をちゃんと説明してくれたら、
俺ももうちょっと噛み砕いて説明してあげるよ。

きちんと整理してわからない点を説明してくれたまえ
417 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:44:45 ]: 頭のおかしい人がきちゃった
418 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:45:04 ]: きちたぁ
419 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:45:58 ]: やヴぁいみんなにげｒ
420 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:46:32 ]: 今日からは、オブジェクティブエージェンタブルアスペクト指向で行こう
421 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:46:58 ]: 計算機をインタプリタとして扱うのは>379のオマケみたいなもんで
本質はそこじゃないだろｗ
422 名前：仕様書無しさん [2007/07/04(水) 23:47:31 ]: やばくなると相手を中傷って、こいつおじゃば？
423 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:47:45 ]: >>421
またまた俺様解釈か？
424 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:49:10 ]: ここのスレにトグロしてる人って、
「日本最初のOO専業コンサル会社」の創始者？

ちょっと信じがたい雑言ばっかだな。
425 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:50:13 ]: じゃあインタプリタのクラス設計やるよ！
・入力
・トークン抽出
・辞書
・コマンド
・レジスタ
・出力
・電池
・太陽電池
・ネジ
・ふた
・バックライト
あとは？
426 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:50:15 ]: アミダのトグロでデッドローック攻撃！
427 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:50:16 ]: 電卓の本質はインタプリタである。
428 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:51:32 ]: >>421
本質が見いだせないＯＯ不適格者。
429 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:52:42 ]: 電卓の本質は数式処理である。
数式とは、OOとは異なる、より精緻なモデリング技法である。
従って、OOによる電卓モデリングなどというものは、
「ダイヤブロックでDNA模型を作りますた」程度の児戯に過ぎない。
430 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:54:30 ]: >>429
それは本質ではなく実質。
431 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:55:27 ]: むしろOOのメリットは「萌えプログラミング」にある。

ぬるぽたんハァハァ
ORまっぴんぐたん萌え萌え
432 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:56:53 ]: >>425
それは機能抽出？
433 名前：429 mailto:sage [2007/07/04(水) 23:56:56 ]: >>430
あのさ、あんたやっぱ議論に値しないわ。
実質言い出したら数値処理だろ。
そして数値処理の実現機構はMPU的ロジックだろ。

あんた一生言葉遊びで人生潰しちゃえばどう？
434 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:58:03 ]: >>433
素直になって勉強し直そう。素直が一番。がんばれ。
435 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:58:36 ]: このスレの本質：　かみ合わない議論を延々続ける社会不適応者のオナーニ
436 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:59:08 ]: ＯＯは実質ではなく、本質を抽象化してインターフェースする技術なのだ。
437 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:59:31 ]: そろそろ殺伐としてきました
438 名前：仕様書無しさん mailto:sage [2007/07/04(水) 23:59:47 ]: 頭がおかしい人をからかうのって、意外とつまんねえな。

何を言っても反応がワンパターン。
439 名前：仕様書無しさん [2007/07/04(水) 23:59:54 ]: GUIクラス
　ボタン配置等
　　　数字
　　　　一桁シフトして数字レジスタに値を格納
　　　ファンクション
　　　　計算クラスに値を渡す

数字レジスタ
　数字を記憶

計算クラス
　計算の関数を格納
　　数字レジスタの値を計算

こんな設計でどう？
440 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:00:25 ]: じゃあなにかい？
Windows付属の電卓ソフトはOOじゃ表現できないってえのかい？
441 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:00:42 ]: 　　　　　　　　　　　　　多項式イデアル萌え
442 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:01:35 ]: 数式処理をOOで実装しようというなら、
まずは多項式イデアルのデータ構造の議論から始めないとダメでしょ。
443 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:02:04 ]: ＯＯはこのようにセンスをブーストするので
レベルの差がハッキリしすぎて、教えてやっても逆切れされてしまう悲しい技術なのです。
444 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:02:43 ]: >>439
どうだろうね？
レジスタって、実際には変数１個と対応でしょ？
クラスにするほどのものかなぁ・・・
445 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:03:29 ]: 多項式イデアルのデータ構造を検討するには、まず
非多項式時間で処理可能な数式簡約化アルゴリズムを検討せねば・・・
446 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:04:22 ]: >>445
10年位前だと、ホロノミック基底がよさそうってな話になってたね
447 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:06:16 ]: 計算クラスで四則計算からなにからを派生クラスとして作成して、
ボタン操作から意味抽出されたパラメータを取り出すクラスから呼び出すって感じ？
448 名前：仕様書無しさん [2007/07/05(木) 00:06:29 ]: >>444
記憶クラスにしようかなと最初思ったけど、
電卓だから単なるグローバル変数でも良いかなと思った。
でも一応、レジスタという名前で小ささをアピールしてクラス化したｗ

あ。もし、億とか兆とか無量大数まで
計算させる場合はこの方が都合が良いかｗ
449 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:08:11 ]: 生意気な若い人の論文によれば(
Domain Logic Programming Theory and Application in Scientific
Knowledge Representation by K J Dryllerakis 1996)Dryllerakisいわく、
本質的に現在の数式処理システムは大変すすんだパワフルな(だけの)数式
数値電卓にすぎない。つまり標題のDomain Logic Programming が知識をうま
く表現してくれればいいんだけどね、僕は信じないが一つの行き方ではあるね。
こんな処でいってどうなるというものでもないが現在の数式処理をささえる
いろんな分野でいくつかの重大なピース(部品)が欠けていると思う。もっとも
それがなにかはっきりしていないがとにかく欠けている。
怪人Doron Zeilberger のWZアルゴリズムも本質的に有限和だから、(
A WZ PROOF OF RAMANUJAN'S FORMULA FOR π)にあるように工夫して無限和に
対応できるとしてもスタンダードアルゴリズムとして採用するには
適用限界がきつすぎるというひともある。(この論文は1Pしかなくて彼のホー
ムページから手に入る) むろん彼の一歩はこのへんでは比類無い程重要だ。
"A=B"ではclosed form が重要だとしか書いてないがアイデアの源泉は
HOLONOMIC SYSTEM にあって多くの特殊関数がholonomic systemsの解として
得られることにあるようだ。(HOLONOMIC SYSTEMS APROACH TO SPECIAL
FUNCTIONS IDENTITIES をみよ) つまり言語やアルゴリズムの問題の他に数学
自体の問題でもあるのだ。僕等の夢はこのへんの分野ではコンピュータ化し
たRAMANUJYANを作ることであるはずだがまだまだ道は遠い。
450 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:09:07 ]: >>448
そか、もしかすると２６個のレジスタになるかもしれないし、
リンゴとみかんを分けて処理しないといけないかもしれないからねw
451 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:10:46 ]: なんだか、設計というのが物事を単純化させる作業ということ真逆な方向に行ってるねぇ
452 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:12:42 ]: 電卓など所詮初心者プログラミング課題。
現時点において、一流のプログラマ兼マセマティシャンが
本当に解くべき最前線というのは、
例えば数式処理システムを本質的に進化させる数学的アルゴリズムの探索である。
453 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 00:13:46 ]: なんだ数式処理って？
コンピューターを計算に使ってるやつなんかほとんどいないぞ
454 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:14:59 ]: 新着レス 2007/07/05(木) 00:14
453 名前：あぼ～ん [あぼ～ん] 投稿日：あぼ～ん
あぼ～ん
455 名前：仕様書無しさん [2007/07/05(木) 00:15:14 ]: 時々思うんだけど、業務システムとかは単純な加減乗除と
データのコピーしかやってないんだよね。

それに特化したアーキテクチャのCPU・OS・システムを
組んだ方が効率がいいんじゃないかと時々思う。
456 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:17:10 ]: ヒント：　それに特化したアーキテクチャのCPU・OS・システムは、
　　　　　ホラリス統計機～汎用機～オフコン　として知られている
457 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:17:38 ]: >>455
君の目の前のパソコンだって、そんなに高度な計算をやる事に特化してる訳じゃないよ。
所詮は四則計算の繰り返しが９９％じゃね？
３Dのゲームでもしない限りはw
458 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:18:07 ]: Wヒント：　有能な人間は、業務システムなどという単純作業には我慢できない。
459 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:20:34 ]: 「複雑な計算」の例が３Dゲームとは
とんだ底辺プログラマだな
460 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:22:48 ]: >>459
高度な複雑な計算だって、所詮は四則計算の繰り返しでしかないんだし、
３Dゲームって煽ったのは、ベクトル計算を鬼のように最適化しなくちゃユーザーが黙ってないからさw
461 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:24:13 ]: すげーｗおじゃば大量だぜｗ
462 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:27:52 ]: 業務システムとか３Dゲームなんてのは、
有能な人間が取り組む重要なテーマ (遺伝子解析、地球環境シミュレーション、etc.)
の補助となる計算チップ/計算システムを構築するためのスポンサー的存在に過ぎんだろｗ

つまり、PCやゲーム機のCPUの処理能力が、何故不必要に高いか、って話なわけだが、
あれは要するに並列計算機をコストダウンするためなんだよね
463 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:29:24 ]: 数式処理の話しても、いつものパターンで流そうとする
低脳っぷりに爆笑した

やっぱバカはバカだなぁ～
464 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:30:28 ]: >>462
９９％無駄にアイドル状態のパソコンに何故高性能を求められるかって？
ユーザーが馬鹿だからさ。
465 名前：仕様書無しさん [2007/07/05(木) 00:36:05 ]: >>462
まあ並列計算機を実際に使うのは
有能な人間をサポートする計算職人に過ぎないけどね
466 名前：仕様書無しさん [2007/07/05(木) 00:36:39 ]: >>462
というか、ゲームが大好きな奴らが集まって何にでも使える
一般家電的なコンピューターを作ってたら、誰も予想しなかったくらい
滅茶苦茶に高性能化したので、こっちに全部ブッ込んじまえば良いや的な
流れで今があるんだよ。

結局、進化の過程のいびつさが言語仕様に反映されてて、
エレガントで直感的じゃないってのも嫌われる理由の一つにあるのか？
467 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:37:52 ]: >>462
でも、そういうことがなぜ大事かというと、
業務計算やったり、ゲームやったりしてる日常を守るためなんでないかな？
一概にどっちが上とかはいえないような。
468 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:39:15 ]: それをいっちゃ、所詮コンピュータの面倒を見るだけの使用人ですからねぇ　それだけの事ですよ。
469 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:39:42 ]: 簡単な話題になるとレスをたくさん付ける人がいるねｗ
470 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:42:27 ]: で、数式処理って、只の記号処理なんだよね？
コンパイラがオプティマイズかけるようなもんさ。
471 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:44:21 ]: こんなにも「無理」「無理」と言われるOOを学習する意味あるのか？
ただでさえ人材が少ないのに、
OO「無理」なやつらばかりじゃ仕事にならんだろ
472 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:45:57 ]: OOが無理なんじゃなくって、分散開発でOOとか無理な事やってるのが悪い。
473 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:46:17 ]: >>462
まあ並列計算機を実際に使うのは
有能な人間をサポートする計算職人に過ぎないけどね
474 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:48:00 ]: フィルタ。
475 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:49:47 ]: OOくらい齧らないで、「人材」たりえんのじゃないか？
476 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:51:25 ]: >>466
また知ったかか。無理すんなよ。

cellチップの共同開発は、次世代マルチコアCPUの開発費捻出に困ったIBMの苦肉の策だし、
GPUの当初目的は、スパコンの計算速度とデータ量に見合った、データ可視化装置
(サイエンティフィック・ビジュアリゼーションWS)の実現にある。

要するに、有能な人が使う道具を限られた予算で実現し発展させていくために、
一般大衆向けの大量生産品とのコラボレーションが行われたって事。
そしてもっと素晴らしいのは、その「有能な人のための道具」が充分安価に提供された事で
第三世界の研究者や学生であっても、有能ならばそれを本来の目的で使いこなせる時代になったって事。

業務システムでひぃひぃ言うレベルの人には無関係だけどねｗ
477 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:52:52 ]: >>471
適性のない人材も確かに存在するが、
彼らは学習してもダメなのか、学習していないだけかが不明だし。
「OO」って単語をオブジェクト指向と読みかえることができる奴が
どれほどいるのか怪しいし。
不勉強というよりも分野が多すぎてノータッチってのが多そう。
478 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:52:57 ]: >>471
つか、全然無理じゃないから。
最初のハードルだけちょっと高くて、多少のメリットを得るところくらいまでは誰でも到達可。
Cのポインタ使いこなすくらいの難易度
479 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:53:56 ]: >>470
只の記号処理じゃないことって、この世に存在するの？
480 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:54:17 ]: バカスレ
481 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:54:48 ]: このスレの住人て、なんでこんなにレベル低いの？

高校生？
482 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:55:59 ]: >>479
なら、正解だろ？　それで？
483 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:56:28 ]: 中学生もいますよー
484 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:57:23 ]: 結局自作自演がメインだから、自作自演者のレベルがスレに如実に現れるニョロ
485 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:57:24 ]: >>481
煽りがヘタですねえ
ま、厨房ならその程度でしょうねえ
486 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:57:32 ]: オマイが先に言ったんだからな！
487 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:58:15 ]: >>484
それくらいにしとけ

またこいつ発狂するぞ
488 名前：仕様書無しさん mailto:sage [2007/07/05(木) 00:59:38 ]: OOよりもガーデニング検定がんばった方がよさげ
489 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:00:54 ]: このスレの住人の割合

このスレが100人の村とすると・・・

C言語を理解：　　　　　　　　約３名
じゃわ言語を理解：　　　　　約２名
構造化プログラミング命：　約１.5名
OO命：　約1.5名
その他：　
　　こんなスレなどどーでもいいと思っている：　97名
490 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:02:22 ]: ５人侵入者がいるな
491 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:02:42 ]: >>489
１００人もいないろ
492 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:02:51 ]: まぁ実際書き込んでるのは３人がいいとこだな
493 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:03:44 ]: じゃ、番号！
１！
494 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:04:13 ]: 俺はこのスレほとんど来ないんだけど。
このスレ毎日50～100レス単位で伸びてるな。
もしかしてたった２人で会話してんの？
一人で自作自演の可能性もあるな
495 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:04:50 ]: >>494
正解。いつも書いてるのは一人。
だから内容が無いよう
496 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:04:55 ]: こんなかんじ？
学生×1
ドカタ×1～2
ヒキ×1
497 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:05:05 ]: >>494
おまえと俺とで、２人は確実だ。
498 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:06:23 ]: >>497
自作自演の芸が細かいな。なんちゃって。
ほとんどお前一人でやってるだろこのスレ。
499 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:07:01 ]: かみ合ってない会話ばっかで、自演はなさげ
500 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:07:11 ]: 結論：ヒキ学生ときどきドカタが一名で回しているスレ
501 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:07:45 ]: >>499
ほー。わざとかみ合わない会話を自作自演してるだけじゃんお前
502 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:08:41 ]: 退屈な人の退屈なスレ
寝る
503 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:08:49 ]: なんのためのわざとだよｗ
504 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:09:37 ]: で、おまいら、オブジェクト指向の方は、理解出来たのか？
505 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:10:21 ]: まだやってたんかｗｗｗｗ
506 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:11:11 ]: 中身ゼロだな、ここ
507 名前：仕様書無しさん [2007/07/05(木) 01:13:28 ]: ああ。俺分かっちゃった。

（3D以外のゲームプログラミングに）OOは要らない。
（もの凄くハードウェア寄りの組み込み開発に）OOは要らない。
いや、（業務システム開発には）OOが必須。

と延々やってるんだと。
508 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:14:42 ]: insert01
select02
select03
・
・
・
こんなクラス設計やっちゃうみかかが年金システムか
509 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:15:45 ]: >>507
うんにゃ。
ちみは理解してない。
特に３行目。
（空白行含む）
510 名前：このスレの結論 mailto:sage [2007/07/05(木) 01:16:57 ]: 1. 業務システムは奴隷に任せとけばおｋ
　　その中身がOOかOOじゃないか、などという仔細な問題に拘る必要なない

2. 奴隷じゃない人は、もっと有意義なテーマを志しましょう

3. このスレ終了
511 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:16:58 ]: 業務と言う観点から見たら

結局、出来上がればいいんだろ？
と言う人から、
美しいコード、美しいロジック（自称）を追求する奴の差なんて
ほとんど無い。

と書く事さえ意味が無い。

何が言いたいかというと、設計技法、プログラミング技法を
どうやって習得するかの話題が先ではないのかと思う。
512 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:17:40 ]: >>507
そんな明確な意思は感じ取れないな
このスレは「ポインタ死ね」スレとおなじ趣
513 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:18:22 ]: >>482
>>470
の記述には、「数式処理はこの世に存在する」という以上の意味は無いということ。
514 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:20:06 ]: というか、業務やってる連中はOO理解してないヤツばっかだから
一人でOO設計しててもかなり空しい
「何いかにもC++知ってますみたいなコード書いてんの？ｗ」みたいな
515 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:20:14 ]: 以前、バリバリなフレームワークをJava, Perl, C++の三つで書いたら、

「うん、彼のコードはなかなか綺麗だよ」って軽く流されてめげた。
ちなみにその発言者は、自作オプソのメンテをRuby作者に任せたっつーその筋の人だったりする・・・
516 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:23:58 ]: >>513
最初からそういうことだってw
やっと気付いたの？
517 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:24:21 ]: そいえばRuby作者っていえば、ObjectStoreのためのGCシステム開発もしてんだよね。
・・・俺はObjectStoreはパスしたな～。ORマッピングの方が気になってたし。

意外とMatzと同じような経歴をたどってたにも関わらず、現在では(ピー)な俺・・・・
518 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:25:07 ]: >>516
きみのあたまの中身はお花畑だという事を理解した
519 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:26:50 ]: オブジェクト指向って名前をどーにかしないとな。
めんどいから　Java言語標準設計論　とかにすりゃあいい
略して　ジャバロン！！！！だせーー！！！
520 名前：仕様書無しさん [2007/07/05(木) 01:27:55 ]: >>476
それってかなり大昔の話でしょ。
五インチフロッピーが全盛くらいの。

それと今の状況は全く違うと思うよ。
パラダイムシフトは95年辺りだよ。
それまではワークステーションはUNIXだったが、
Windowsが使えるレベルになったのでx86が台頭してきた。
521 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:28:07 ]: 今更OOにこだわりを持つよりも
今扱うべきテーマはRonR with Agileだたーりして
522 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:28:40 ]: >>520
おじゃば発見
523 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:28:52 ]: OOｲﾗﾈつって、じゃあ関数型やるか？っていったら
よけい誰もやらねえだろうしなあ。
524 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:29:12 ]: >>520
お花畑2号発見

なんで知りもしない話に知ったか始めるの？

だからキミは相手にされないんだよ
525 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:29:17 ]: 構造化を突き詰めると当たり前のようにOOになるんだから、別に名前なんて無くてもいいよ。
526 名前：仕様書無しさん [2007/07/05(木) 01:29:22 ]: >>519
Java Standard Poricy Programming

で、JSPPで良いんじゃね？
527 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:29:53 ]: >>523
あ、それ大丈夫。
情報科学～コンピュータサイエンス出身の学生さんがやってくれるから
528 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:31:19 ]: >>526
JSPとかぶるし、ジャバロンの方が耳に残るｗ
529 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:31:43 ]: 宿題スレに宿題丸投げしてるような学生が行き着くところかｗ
530 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:31:47 ]: 学生がやってもしゃあねえべ
531 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:32:15 ]: >>527
むしろ今までの方が変だよね。
学生時代に論理型言語や関数型言語で研究テーマこなしてた
プログラミング好きな学生(修士含む)が、
プログラミングが好きだから現場指向の会社に行くと
途端にCだJavaだCOBOLだって低レベルな言語やらされる無駄
532 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:32:37 ]: 現場でやってもしゃーねーべ T T
533 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:32:43 ]: >>530
無料で出来るぜ。
学校ごと教授ごと巻き込めw
534 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:34:25 ]: 学生がやってもしゃあねえだろ
つかそういう意味ではOOやる学生だっているだろ
535 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:34:44 ]: 言語なんて出来て当たり前でしょ
OOは必要性が問われないから、出来ない奴が多いだけで、
必要性が問われれば学習する奴も増えるでしょ
536 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:36:11 ]: >>520
お花畑ちゃんにマジレス

1995がパラダイムシフト？はぁ？

1995頃、まともに使い物になるOpenGLマシンつうと、
DEC Alpha載せたWS/Windowsマシンしか見当たらなかったよ。
そりゃ、CADとかライトな目的ではIntelマシンも使われてたけどね（HAHAHA

cellに至っては、21世紀に入ってからだろ（PUPUPU
537 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:36:59 ]: カプンコがPS3のゲームエンジン開発者募集してるよ。

大阪だけど。
538 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:37:44 ]: Cellのミドルウェア開発やってみてーな
539 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:37:44 ]: >>535
OOに限らず、開発を効率化する「何か」の必要性は問われてるでしょ
つか、必要ありきで学習するなんて妄想杉
はじめに技術ありきで、必要は生み出されるもの
540 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:38:47 ]: >>537
無理だ無理。
PS３のエンジン開発は、その道の専門が何年もかけてつくらんと。
541 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:39:03 ]: 先週、求職で某研究所逝ったら、
下請けが「さんそうけん」というソフトウェア会社だと言われた。
俺の役目は、顧客とそのソフトウェア会社の中継ぎ。
聞いた事ねぇソフトハウスだなぁ～って言ったら、・・・

ってなレベルの俺様が降臨しましたよ～
542 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:40:41 ]: >>541
>さんそうけん
ぐぐったら、
もしかして「産総研」？　とか聞かれたよw
543 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:42:03 ]: 爽健美茶が出てきて吹いたｗ
544 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:42:55 ]: うん、よく似た名前のハードウェア系ベンチャーがあってね、
俺はうっかりそこの事だと思ったわけよ。
そしたら「産総研」だって。「下請け」つったのは性質の悪いジョーク。
顧客は国内トップレベルの基礎研究所だって・・・・あそこはな、俺が学生時代にあこがれてた基礎研なんだけど・・・ぶつぶつ
545 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:46:09 ]: sin cos
cos -sin

の１軸回転の行列を３軸やって（ここまでは１フレームに一回だけしか計算しない）
ポリゴンの頂点座標を世界座標から上の行列をかけて視点座標に変換して、表示しない物体は切り捨てて
後はz/Lの投影変換してクリップしてポリゴンは終わり。

衝突はいいとして地面とか壁とか面倒だな。
煙や火は関数持ってくるんだろうな。
546 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:46:15 ]: >>544
で、その身の程知らずが、この廃墟に何の御用？
547 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:46:23 ]: ってな自慢話をするから、嫌われるのだとおもた（切腹
548 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:48:24 ]: >>545
その３Dオブジェに関節があると、３軸回転を何度も繰り返すんだよぉ～♪
549 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:49:18 ]: そかツリーでもって変換変換ね
鎖なんかの物理シミュレーションは難しいな。
550 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:50:01 ]: お前の頭じゃ一生理解できんだろ
551 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:51:15 ]: マジレスすると、このおっさんシェーディングの説明できねぇんだろうな、とか思った
552 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:51:15 ]: 相互作用型はちょっと俺には無理
553 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:51:22 ]: OOが分かってなくても、
動くものは作れるし設計もできる現実
554 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:51:50 ]: ギザギザ取りだろ
つくたことあるよ
555 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:52:42 ]: セガサターンの時代には、３Dオブジェのデータ構造が、まったくそのマンマ計算プログラムだったなぁ。
556 名前：しょこたん mailto:sage [2007/07/05(木) 01:53:12 ]: ギザギザ鳥？はぁ？

面の法線と光線の内積とって面の光度きめにゃあかんだろギザ
557 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:54:15 ]: 軽いね
その程度でいいの？
558 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:54:32 ]: シェーディングは、色のグラデーションで表示物の表面をなめらかな曲面に見せかける手法だよ。
559 名前：仕様書無しさん [2007/07/05(木) 01:55:13 ]: >>536
cellの原型は９０年代初頭からあったよ。
560 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:55:36 ]: シェーディング. シェディングとは、光源、物体、視点の位置情報などから面に陰影づけを行う方法のことで、還元するとJ.Kajiyaによって示されたレンダリング方程式の解を求める事に帰着します。レンダリング方程式. Iout(Θout)=E(Θout)+∫l=1 nρl(Θout ...
561 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:56:12 ]: >>545
なぁココ、その行列間違っているぞ
転置したとしても間違ってるからw
562 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:56:17 ]: >>559
はいはいPower CPUのマルチコア版乙乙
563 名前：仕様書無しさん mailto:sage [2007/07/05(木) 01:56:51 ]: >>560
自分の言葉で書けw
564 名前：仕様書無しさん [2007/07/05(木) 01:57:29 ]: >>536
あと、お前アホだな。
アメリカの開発経緯は日本みたいにお上主導の計画経済じゃねぇよ。
よく言えば自由で開かれた開発、悪く言えばベンチャーを切り張り取って付けた行き当たりばったりだ。

お前の言うように綺麗な開発経緯なんて存在しねーよ。
後付の泊付けだ。
565 名前：仕様書無しさん [2007/07/05(木) 01:57:39 ]: >>563
　>>556
566 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 01:57:58 ]: ちょととまて
頭の中で作図チェックしてみる
567 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:01:02 ]: >>564
お前の反論はすぐ論点がずれるからダメだ
挙句に、デタラメを並べ出すがらゴミ

どうせ論点ずらすなら
「日本は軍需産業が小さいため、民生品に高度先端技術がつぎこまれる傾向がある。
　この結果、国外の軍需/先端科学産業は、日本の民生品技術とコラボレーションする傾向が強まっている」
とかなんとかそっちの方向に行けばいいのに。
お前の文を読んでガックリきたぞ。マジ
568 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:01:14 ]: 回転行列は、左上から右下に向かって対角線がcosです
なお書き方として、転置して横ベクトルを使う形式と(DirectX)、そのまま縦ベクトルを使う形式があります(一般的な教科書)。
どちらであってもcosは対角線になるのだ
569 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:01:56 ]: cos -sin
sin cos
かな？
570 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:02:19 ]: おまぃら二人
スレチガイですよ
571 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:02:50 ]: いいやんなもん
暗記しなくても
572 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:03:13 ]: ほっといてやれ
573 名前：仕様書無しさん [2007/07/05(木) 02:03:37 ]: ああ。なんだ。ゲーム機の話しか。

ゲームの世界とPCの世界がごっちゃになってるから困る。
574 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:03:56 ]: すれ違いが4人いるとみた
575 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:06:20 ]: やっぱネーミングが悪い。「オブジェクト」指向
このネーミングだから、元ゲームプログラマ廃人がのこのこと現れるんだ。
576 名前：仕様書無しさん [2007/07/05(木) 02:06:40 ]: やっぱ、ゲームプログラマが荒らしてんだよ。
ゲームプログラミングはロジック主体だから。
オブジェクト指向とか、再利用性とか意味無いし。
577 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:07:45 ]: まぁ技術的には

ゲームプログラマ　＞＞＞＞＞　業務プログラマ

だな。凡人レベルの給料比較すると、正反対だけど
578 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:08:15 ]: 逆だね
ゲームはオブジェクト指向が向いている部分が多い。
579 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:08:33 ]: エンジン部分は高度なOOじゃないか？
580 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:09:12 ]: 炎とか波とかははオブジェクト指向では無理だな
581 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:09:23 ]: 技術レベル的には、もっと下が居るよ

ゲームプログラマ　＞＞＞＞＞　業務プログラマ＞＞＞＞＞　有象無象の業務アプリ設計者
582 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:09:28 ]: >>576
おまい、ゲームプログラムなんてOOを２０年前からやってんだぞ。
敵キャラの性格作るのに、ベースの敵クラスから派生クラス作って性格に肉付けするんだぞ。
583 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:10:31 ]: OOをやってるからすばらしい、という前提は正しいのか？
584 名前：仕様書無しさん [2007/07/05(木) 02:10:33 ]: >>567
日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
まぐれ当たりが何本か出る程度だよ。
それにそれを育てようともしない風土だし、結局枯れる。
それを延々繰り返してるんだな。
金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
585 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:10:44 ]: なんかさ、ココが３Dレンダリングの話でいきいきしてるの見て、
ちょっとだけ嬉しくなった。こいつ変な話ばっかりする奴だと思ってたけど、
彼は彼なりに好きな分野があるのね。で、今は何やってる人なの？
586 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:11:28 ]: >>584

・・・・おまえは大前健一クラスの批評家かっつーの。
根拠示せ根拠
587 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:13:02 ]: 航空産業などにいますが
588 名前：仕様書無しさん [2007/07/05(木) 02:13:15 ]: >>582
シューティングとかアクション系でOOとか要らないじゃん。
下手すると、関数呼び出しすらオーバーヘッドが問題になって使わず、
とんでもないプログラムを延々書く。
逆に、RPGとかシミュレーション系は多用するだろうけど。

前者にしか関わらない人間はOO要らないと言うでしょ。
589 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:13:33 ]: かっちょえええ
590 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:13:36 ]: > 日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。

開発技術？どの分野の話してんの？
開発技術って一体何？

> 金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。

体言止めすな。ちゃんとしまいまで説明せい。
いい加減な言葉をいい加減な態度で示す奴には虫唾が走る
591 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:14:55 ]: >>582
Strategy使ったほうよくね？
592 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:14:58 ]: >>588
実際にやってたからw　おまいの話は真実味が無いwww
593 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:15:05 ]: ココってNASDA関係やってたっけ？
それともダイヤモンドマーク関係？

そういえば、宇宙ステーション計画どうなったんだろう・・・
594 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:17:13 ]: MIPS R3000の開発やった事ある人居る？
595 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:17:17 ]: >>591
だからStrategyだってw
596 名前：仕様書無しさん [2007/07/05(木) 02:17:21 ]: >>586
・大学の研究レベルが低い
・学生の質が一部を除いて低い
・中学高校教育のレベルが低い。システム的な問題がある。時代遅れ。
　能力のある人間を伸ばしていない。
・院卒をデタラメに扱う社会
・開発投資をしない会社風土
・日本独特の先輩後輩文化による文化硬直化。
　それによる革新の欠如、革新の破壊、芽を摘む
・高度に管理しすぎる官僚制
　社会が減点主義の鎖に繋がれる

などなど上げればキリがない。
597 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:17:26 ]: OOを学習しても発揮する場が無い
こんな人が多そう
598 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:17:56 ]: 返事がないのはガセの印
599 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:18:46 ]: >>596
へー。じゃもう海外移住済だよね？そんなに文句あるんだから
600 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:18:58 ]: >>594
それって、PS？
601 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:19:59 ]: R3000　・・・ソニーのWSだっけ？
602 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:20:28 ]: ひたすらスレ違いな奴が多すぎ
603 名前：仕様書無しさん [2007/07/05(木) 02:20:59 ]: >>599
・問題点を見つめること
・問題点を見ないようにすること
・問題点から逃げること
この３つは全て違う。
604 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:21:11 ]: >>597
OOの利点をしっかりプレゼン出来ればいいと思う
605 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:21:39 ]: >>603　とか
こっちでやれ
pc11.2ch.net/test/read.cgi/prog/1178266663/
606 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:21:44 ]: つか、もう寝る('A`)ﾉｼ
607 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:26:42 ]: ・国内大学の研究レベルは低いというよりは、産業向けの実用的研究と方向が乖離しているのが問題。
・逆に産業分野の研究は、製品開発に焦点が絞られすぎていて、本当の意味の基礎開発が不充分。

・例の青色LED発明以降、ポス毒の就職状況は改善されてるらすぃ。
・社会の硬直化：これはしょーがねぇな。横の人と同じ事してればいいと考えるのが農耕民族だからなｗ
608 名前：607 mailto:sage [2007/07/05(木) 02:28:58 ]: > 基礎開発

基礎研究のまてぃがい

あと、国内の教育環境はなぁ・・・難しいよなぁ・・・俺の時代は飛び級すらなく、ひたすら灰色の日々・・・
これの改善は、草の根レベルでやるっきゃないっしょ。そして金持ちだけが優れた教育を受けられる格差社会へ・・・
609 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:30:01 ]: >>606
あら。やっぱり居たのね。
奥さんお元気？
610 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:30:29 ]: >>607
スレ違いなのは分かっているが

まで読んだ
611 名前：仕様書無しさん [2007/07/05(木) 02:33:53 ]: 何も、アメリカ型にする必要はない。
大資本家も居ない。規制も緩くない。期待もない。
日本で一番金を持っているのは国。
高度に組まれた規制を緩めれば、問題点ばかりが出る。
海外の投資家が積極的に日本に投資しようと考えることはまず無い。
ハゲタカが技術だけを買い叩いていくだけ。

日本の場合は、大学は浮世離れしすぎで、産業は目先のことを考えすぎる。
だから、政府や大企業が研究所をどんどん作って、
院卒をねじ込んで研究をどんどんさせるべき。
国内での雇用を拡大し、人材を確保する。同時に人材育成にもなる。
あらゆる理系分野でやるべき。
そうすることで、相互作用で市場が拡大する。
612 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:36:43 ]: はいはい、必死必死
613 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:39:02 ]: ちょっと前ならここでシグマの話題になったのに・・・
614 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:40:53 ]: NEXT Step だっけ？　OOやったの？
615 名前：仕様書無しさん [2007/07/05(木) 02:44:31 ]: 日本にはベル研、ローレンス・リバモア研究所のような、
大卒、院卒を受け入れる研究所がない。
だから育たない。
616 名前：仕様書無しさん [2007/07/05(木) 02:46:05 ]: それ、目的設定が重要だな

第五世代レベルじゃ寸足らず
地球環境問題じゃ根拠や切迫感に欠ける

敗戦後、吉田爺や白州次郎が立てた｢輸出立国｣に相当する、おっきなスローガン
617 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:47:31 ]: >>611=615
OOとの関連性が無い内容で、
日本語の学習がより一層必要です
618 名前：仕様書無しさん mailto:sage [2007/07/05(木) 02:48:22 ]: とにかくこのスレを埋めたいらしい。
619 名前：仕様書無しさん [2007/07/05(木) 02:50:13 ]: >>615
まあメーカー系研究所はフツー入れるんじゃねえ？
OB系の実績があればの話だけど。
620 名前：仕様書無しさん [2007/07/05(木) 02:53:09 ]: >>616
スローガンとか一過性のカンフル剤じゃダメだと思う。
開発投資が成果を生む、人材確保に繋がる、
そういった社会サイクルを形成しないとダメなんだと思う。

そういう政治家や企業家や思想家を、
今時の日本で見たことがないからダメなんだろう。
621 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 02:57:28 ]: いっぽうアメリカはアポロ計画を立ち上げた
622 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 03:01:22 ]: やっぱ人工知能だよなあ
623 名前：仕様書無しさん [2007/07/05(木) 03:06:40 ]: 話題がぐっと卑近になるけどw
ここ数年IPA未踏はずいぶんと好循環になっているんじゃねえ？

ずーっと前のIPAは、メーカー系やソフトハウス系の訳わかんない研究ばっかで、
(あんなん時間とキャリアの無駄)
とか感じたけど、
今じゃWeb2.0系企業の研究開発に入る一種のライセンスになってる感もある。CybouzLabやらGoogleやら。まあ結局はその人の実力次第だけど。

最近転職活動していて、ああ、あの時応募しとけば・・・とかどうでもいい妄想に悩まされて
624 名前：仕様書無しさん [2007/07/05(木) 03:08:03 ]: 思想的な面から言えば、日本の現代の科学思想不足は異常。
理系離れなどはそれの現れである。

何よりもまず、科学・数学・テクノロジーを肯定する思想を作らなければならない。
そして、それを社会に根付かせなければならない。
そうすることで、優秀な子供が科学を志すようになる。
思想は自動的な仕組みとして社会に組み込まれる。

思想という受け皿があって初めて、人が育成できる。
そして、優秀な人材に投資ができる。
これがダメだと、資金の湯をざるに注ぐような物。
何時までも開花しない。
625 名前：仕様書無しさん [2007/07/05(木) 03:21:34 ]: とりあえずIT分野に限定すると、業務系や組込系で3Kっぽい開発してる所、あれが随分と業界イメージを悪くしている。
あれを兎に角改善しないとダメだと思う。

10年前の俺の壮大な妄想では、Java と OOを踏み絵にして駄目っぽい開発を改善/峻別/排除して理想郷を実現する予定で、
実際業界は一時期その方向に傾きかけてたんだけど(爆笑)
結局10年後、Javaかつ駄目っぽい開発が残ってしまっている、と。
626 名前：仕様書無しさん mailto:sage [2007/07/05(木) 17:02:25 ]: 10年もやってて「IT」なんてバズワード使う人もいるんだね。
627 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 19:32:46 ]: 技術的な話をすると客が逃げる
628 名前：仕様書無しさん mailto:sage [2007/07/05(木) 19:37:26 ]: 業務系と組込系以外に未経験でもぐりこめるとこありませんか？
629 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 19:51:13 ]: >>628
カプコン
630 名前：仕様書無しさん mailto:sage [2007/07/05(木) 21:01:39 ]: >>577
それはゲームのシステム屋でしょ？
エンジン作ったりする奴の話。

アプリ層しか出来ないゲームプログラマのレベルは酷いぞ。
仕様書なんて書けないし出てこない。
基本口頭で、今時言った言わないで争ってるんだぞ。
631 名前：仕様書無しさん mailto:sage [2007/07/05(木) 21:24:51 ]: >>628
ココ電の会社
632 名前：仕様書無しさん [2007/07/05(木) 21:46:55 ]: ITつう単語は最初ガートナーあたりが流行らせた単語だろ。
俺は、この業界ちょっと小馬鹿にしたニュアンスで揶揄する時にITって使うな。
あと素人相手に3Kバカ業界って説明するのが面倒な時とか
633 名前：仕様書無しさん mailto:sage [2007/07/05(木) 21:53:11 ]: 単語の起源も知らないような雛っ子に限って、
よく判らない業界バズワードにいちいち敏感に反応するのなｗ
ﾁｮｰ笑える
634 名前：仕様書無しさん mailto:sage [2007/07/05(木) 22:18:38 ]: >>630
それでも技術レベルはゲーム屋の方が残念ながら上だわな。
OS屋、コンパイラ屋、ゲーム屋はスクリプト屋とかSQL屋なんかよりぜんぜん上だよ。
635 名前：仕様書無しさん mailto:sage [2007/07/05(木) 22:34:40 ]: でも、仕様を書かせたら、まるっきりダメなのがゲーム屋
636 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 22:37:07 ]: 何しろプログラマ適正がない落ちこぼれがプログラマを統括する役につく仕組みになってるからな。
637 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/05(木) 22:39:05 ]: 入社→プログラマやらせる→使えない→企画屋さん（PM）
という鉄の掟があるのだ。
まるっきり才能のない判ってないやつが束ねる事になっている。
638 名前：仕様書無しさん [2007/07/05(木) 22:48:47 ]: なんでそんな変なサイクルになるんだろうね？
639 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:08:03 ]: ＯＯを理解してるのは１００人に１人くらいだな。
640 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:14:45 ]: サイクル？
違う、廃品利用だ。
641 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:30:01 ]: 構造化を理解しているのは１０人に１人くらいだね。
642 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:31:37 ]: >>641
基本情報処理試験の本買ったら載ってたぞ
643 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:33:08 ]: >>642
あら、そうなの。でも、これはおいらの経験値だす。
644 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:35:39 ]: 美しいコーディングをする人は本当に少ないね。
645 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:36:45 ]: んなこといったらOOだってソフ開の対策本に載ってるよ
646 名前：仕様書無しさん mailto:sage [2007/07/05(木) 23:46:00 ]: しかしプログラミングは奥が深いよな
2年前でも結構OO理解してたつもりだけど
今ソース見ると恥ずかしいｗ
647 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:19:51 ]: >>645
俺、いままで資格の勉強なんてしたことなかったんだけど
最近心変わりして、基本情報処理試験の本買ってみたら結構役に立つ情報が多くて感動した
648 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:29:27 ]: 昔の一種、二種よりは大分マシになったな
649 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:35:52 ]: 美しさなんて時代や背景によって随分感じ方も変わるもんだ
650 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:37:25 ]: >>634
酷いね。

でもﾎﾘｴもんはスクリプト屋上がりだったか。
儲けるのが上手いのは案外そういう方面の奴なんだろうね。
651 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:38:09 ]: >>646
HSPを美しく書く奴こそ本物。
652 名前：仕様書無しさん mailto:sage [2007/07/06(金) 00:54:20 ]: おまいらオブジェクト指向がわからないから
延々とスレ違いを続けてるんだな
653 名前：仕様書無しさん mailto:sage [2007/07/06(金) 01:09:02 ]: ここはそういうスレだろ
654 名前：仕様書無しさん mailto:sage [2007/07/06(金) 01:14:43 ]: クラスと継承とポリモがわかってればOK
655 名前：仕様書無しさん mailto:sage [2007/07/06(金) 01:57:17 ]: あとはクラスが性格と動作を担ってることがわかればいい
動物→猫→三毛猫
Win32API→MFC
これで分からんって奴が不思議
656 名前：仕様書無しさん [2007/07/06(金) 02:16:27 ]: >>655
クラスの組み方が分からないと実戦で使うのは無理だろう。
657 名前：仕様書無しさん mailto:sage [2007/07/06(金) 02:32:19 ]: >>634
昔は確かにゲーム屋といえば、実質オブジェクト指向らしい概念が無かった時代から、それらしい機能を実装していたり
プロトタイプ開発といった概念なども持っていてこここそが最先端といえたと思う。
でも今はどうかな、もうすでに一種の分野になっているので、多方面をこなせる万能屋ではないよ、個別分野になれば知識レベルで完全に負ける。
昔と違って知識範囲が広がったので万能系は、全てに関わる必要のあるOS屋、言語屋だけだろうと思われる。
658 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/06(金) 03:13:42 ]: >>638
プログラマーを憎みながらこき使うことができる人間の屑にしかできない仕事だから適任なのだ。
659 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/06(金) 03:17:02 ]: いざとなったらそいつに恨みを集中させて切ればいいし、会社としては楽
だけど時代遅れのやり方で、役員は楽だけど競争に弱い。
だからバタバタと吸収されて減っていった。
660 名前：仕様書無しさん mailto:sage [2007/07/06(金) 08:21:28 ]: >>657
つ　スレタイ
661 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/07/06(金) 08:49:51 ]: 【文化】新作「機動戦士ガンダム００」放映を機に「ガンダム」関連売上高、今期最高めざす…バンダイナムコ
news22.2ch.net/test/read.cgi/newsplus/1183674740/
662 名前：仕様書無しさん mailto:sage [2007/07/06(金) 09:09:22 ]: >>657
僕は３D関係の数学知ってますって奴が実装技術に優れた物を持っていない場合、
その技術を持ってる奴と組んで仕事するとかでいいと思う。
全員が全員大学院卒並の数学出来なくても問題ない。

リアルタイムマルチタスクな組み込み系では、結局オブジェクト的な考えが
一番効率よかったから、ここでいうOOとはちがうかもしれないけど、むかしから使われてきている。
663 名前：おじゃばさま ◆GxjxF3yEw6 [2007/07/06(金) 22:08:48 ]: かなり話が流れてしまったが、OOの話をする事にする。
俺が構造化とOOの違いを電卓で示して見たが、何やら話が変な方向に行ってしまったようだ。
別に電卓を作ろうと言う意図ではない。

OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
OO電卓の場合、計算結果を内部に持つ必要があり、push0()が動作になっている。
構造化電卓の場合は、状態を持っていない。
664 名前：おじゃばさま ◆GxjxF3yEw6 [2007/07/06(金) 22:11:27 ]: ではこれらがどう影響するか考えてみよう。
最初に足し算と引き算のみに対応した物を作るとしよう。
多分、構造化電卓の方が分かりやすく少ないコードで作成する事が出来るだろう。
OO電卓の方はまどろっこしく感じるかもしれない。

次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
回避方法もあるが、基本的に呼び出している場所も全部修正になる。
まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。

次にOO電卓の場合はどうだろう。
ボタンの追加はメソッドの追加になる。適切に分割されていれば、他のボタンへの影響は少ない。
ボタン追加の10個や20個は問題ないだろう。
また変更前のクラスを親クラスにしextendsすれば、親クラスへの影響はない。
変更前を使うのも、変更後を使うのも自由だ。呼び出していた所を修正する必要もない。

つまりこれが構造化とOOの違いになる。
変更が少ないシステムなら構造化、修正が多いシステムはOOが適している訳が分かっただろうか？
665 名前：仕様書無しさん mailto:sage [2007/07/06(金) 22:24:58 ]: まんどくせい
ボタンクラスと計算クラス作って、ボタンごとに呼び出す計算クラスの派生クラスの機能実装しる！
666 名前：仕様書無しさん mailto:sage [2007/07/06(金) 22:26:06 ]: >>664
構造化なら掛け算と割り算を追加するだけで動くはず。

全部小さな部品として作ってあればそれで行ける。

それが細分化の真骨頂。

ちまちました最小機能毎に関数を作っておいて
ある程度の塊に組み上げる。
この塊は作り直しか、再設計だがちまちました部品は手付かずが普通。

OOだから、構造化だからじゃない、設計が糞という前提ありきだろ？

構造化を馬鹿にすんな。

関数の中にバージョンフラグ？　そんな糞設計が構造化だなんて、
勘違いしないでよね。
667 名前：仕様書無しさん mailto:sage [2007/07/06(金) 22:28:01 ]: ＞かなり話が流れてしまったが

流してんのお前だろ
668 名前：仕様書無しさん mailto:sage [2007/07/06(金) 22:39:56 ]: よく居る、全体を見通せず目先の処理だけを動かしたいが為
変なフラグを幾つも作り、ロクに管理も出来ないような奴が、
作るとすれば、継承出来ない構造化の方が優れている面もあるんじゃないか？

結局クラス内部の動作の把握が必要になるのなら、関数単位で機能を固められる
構造化にもメリットがあるんじゃないかと思う。

継承すべきじゃないところを継承したお陰で関係箇所全滅という事もありうる。

技術じゃなくて教育とか人こそが問題なんだよ。
669 名前：仕様書無しさん mailto:sage [2007/07/06(金) 22:59:07 ]: ＞次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
＞作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
＞引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
＞回避方法もあるが、基本的に呼び出している場所も全部修正になる。
＞まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。

それって、構造化の技法使ってないやん。

キー入力割り込み
↓
キーの値ゲット
↓
関数へのポインタ配列を使いキーの値をインデックスにして
該当処理をcall （この方式は各メソッド毎の処理を呼び出すときにOOのコンパイラも愛用してる）
↓
キー入力待ち

Cやアセンブラでこんな処理作った事あるよ。
構造化ヽ(´ー｀)ノﾏﾝｾｰ
670 名前：仕様書無しさん [2007/07/06(金) 23:25:48 ]: >>663

＞OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。

そこじゃない… そこじゃないんだ…

＞構造化電卓の場合は、状態を持っていない。

いろいろ突っ込みたい事はあるが一つにしておく。
⇒説得力無いわ。
671 名前：仕様書無しさん [2007/07/06(金) 23:40:18 ]: >>664 >>668
↑こんな構造化とOOの違いについてを、低レベルな話しで討論しているやつの技量はたかがしれている。
672 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:14:19 ]: 電卓をOOでと聞いて
MVCの話かなと思った

けど全然ちがかった
673 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:21:48 ]: モデル、ビュー、コントロールという考え方は、OOでも有効だよ。
674 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:31:31 ]: はぁ?
675 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:40:07 ]: スレ違いのバカレスはほっとけ

要はOOが嫌いと言ってる連中がなぜ嫌いなのかってことだろ
それってOOが浸透してないってだけじゃん
676 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:44:03 ]: つーか、それぞれの部品の動作とかを定義すりゃあいい話で、
延々とどーでもいいレスを書いてる奴は分かってないだけ
677 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:45:37 ]: >>673
見込になし
678 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:51:42 ]: ゲームがどうのこうのとかレス打ってる奴。
お前ら仕事できるようになったら来いや。
初心者はまず本を読んで学習してこい。
679 名前：仕様書無しさん mailto:sage [2007/07/07(土) 00:53:47 ]: >>671
OK

実のある書き込みを期待する。
680 名前：671 mailto:sage [2007/07/07(土) 00:58:22 ]: OOが問題になるのはPGじゃなくてSE。
SEが分かってないから業務レベルの設計を書きまくり、
クラス設計なんかは知らん、
というスタンスのためPGが翻訳する必要が出てくる。

また、この場合でもPGが優秀な奴じゃないと対応が不可能であり、
結局はOOが分かってないSEが昔どおりの設計をやってるだけため、
Javaが機能分類されてるだとかの話になるだけ。
681 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:00:22 ]: >>680
激しく禿同。と言いたいところだが酔っ払って眠いんだな。
682 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:02:19 ]: 根本的にOOのレスを打てない奴は分かってないだけで、
雑談スレに行けばいいのに粘着してるだけだろ
683 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:08:43 ]: Javaとかで"何とかUtil"ってクラス作る奴馬鹿だろ
684 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:09:50 ]: >ボタン追加の10個や20個は問題ないだろう。
おおスゲーｗー・・・言い切ってやがる！
やがてclass爆発を引き起こすんだろうなぁ

>また変更前のクラスを親クラスにしextendsすれば、親クラスへの影響はない。
うわｗ・・ｱｲﾀﾀﾀ・・第一に親クラスへの影響がないかどうかはOOの範疇ではない。
access controlが無いOO言語だってあるだろう？それと継承そのものがOOみたいに
言っちゃってｗ恥ずかしくなってくるぞ・・・基本は「継承よりaggregationを使え」だ・・

>変更前を使うのも、変更後を使うのも自由だ。呼び出していた所を修正する必要もない。
断じて違うね、自由なのは呼び出す側じゃない、幾重にも継承され、まったく似たような動作が
あるクラスの一つを選んで、そしてそれを正しく初期化して、適切な引数を与える必要があるなら
それは自由というより呪縛だろ？

まあ、これはOOと構造化の比較というより設計の問題だ、ﾁﾐはどちらを選んでも結果は同じ事。

>class Computer{
>public:
>　　void push0();
>　　void push1();
>　　void push2();
>　　　　:
>　　int getAnswer();
>};
>
うへぇ・・・反吐が出そう・・・alogrithmとcontainerの違いすら認識できんのか・・・・・orz

ココで問う、あなたはscratchから継承されうるpublic classを作成する選択するのは何故か
それを選ぶのは流行であったり、安易な選択ではないのか？
685 名前：仕様書無しさん [2007/07/07(土) 01:13:24 ]: なぜ>>1は嫌われているのか？
686 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:14:33 ]: >>683
なんで？
687 名前：仕様書無しさん [2007/07/07(土) 01:16:07 ]: >>679
何を期待しているかは知らないが、答えは一つなのだから自分で考えてはどうだろうか。

>>884
そこじゃな(ry
688 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:17:12 ]: >>884
わっふるわっふるｗ
689 名前：仕様書無しさん [2007/07/07(土) 01:17:31 ]: >>685
何故俺は>>1に嫌われたのか。
690 名前：仕様書無しさん [2007/07/07(土) 01:18:19 ]: >>685
何故俺は>>685に嫌われたのか。
691 名前：仕様書無しさん [2007/07/07(土) 01:19:23 ]: >>689←誤爆でーす(^-^)
692 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:24:18 ]: >>686
たいてい単なる関数ライブラリだから
693 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:29:28 ]: >>692
それの何がいけないのか。
C#にはstatic classだってあるぞ？
694 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:30:05 ]: １．OO理解せずに嫌っているヤツがいる
２．漏れはOO理解してるけど嫌いだ

がループしてね？

個人的にOO理解した上で嫌いってのは変だと思う
それってOOが設計の一手法って事を理解してないってことだろ？

手法の一つだから使うべきところで使えばいいし、
使う必要の無いところでは使わなければいい
使い捨てのテキスト整形用のプログラムとか、
高度なgrepがやりたくて書いたperlシェルとか
まさかOOではやらねだろ？

OOが嫌われる他の可能性だけど、
万能っぽく振りかざすから他の連中に嫌われる、
ってーのはあるかもな
695 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:34:52 ]: 電卓の本質はインタプリタだ、って話があったけど
OOの本質は「物事を本質と本質でないものに分解すること」
じゃないんだよな。

もちろんそれも大事な要素なんだけど。

OOの本質は「物事と物事のつなぎ方」の方にある。
696 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:36:03 ]: >>693
だって自作のクラスをインスタンス化して引数に渡してるんだぜ
697 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:37:33 ]: >>695
私もおおむね同意だし、
そもそも、使いやすく見渡しのいい適当なレベルの
モデルが手に入れば何指向だろうがどうでもいいと思っている。

ただし、そのような本質論を語りだすといつのまにか荒れる。
あなたがあなたの主観を押し付けているように見えるからだ。
698 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:41:21 ]: >>696
頻度によるね。

あきらかにクラスに移動してしまったほうがいいぐらい呼び出し頻度が多くて、
移動しても不自然じゃなければクラスに持たせたほうがいい。
それか、クラス自体にstaticメソッドを持たせるべき。

素朴なコレクションいじりとか、横断的に発生するのとかは
Utilクラスに持たせちゃっていいと思う。
699 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:42:19 ]: >>697
まあそうだろね
どうしたもんか
700 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:46:18 ]: 呼び出し頻度なんか関係ないだろw

OOの設計というのは、いかにブロックを組み、バラバラにできるかということ。
あっちのブロックの組と、こっちのブロックの組と、いかにバラバラにして組み直せるかって事。
701 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:49:31 ]: >>700
ブロックばらすのにもセンスとか考える時間とか色々必要があるから、
頻度とかモデル以外の視点で決定してしまうのもひとつの手だよ。
いくらオブジェクト同士がかかわってても
702 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:51:57 ]: >>700
理想。これが行き着く姿。だから再利用って話になる。

それを誰も分かろうとしない。
703 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:53:41 ]: 俺は頻度とか考えずCRCカードの考え方でクラス作るなぁ。
たいていメソッドを持たせるクラスの候補は複数あるので、
Utilクラスとかは作らずにクラス数を減らす方向で行く。

理論的にはよく分からないが経験的には、
そっちの方が使う側も単純に書ける気がする。
704 名前：仕様書無しさん [2007/07/07(土) 01:54:13 ]: >>694
OO中途半端だから嫌い。
705 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:54:23 ]: まあ、ブロックのばらしかたは各自のセンスでいんじゃね？
ここOO相談室じゃないし

OOわからないってのは「何でばらすか？」がわかってないってことかねえ
706 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:55:54 ]: まったく異なるシステムの為に作ったあるクラスを、また全く違うシステムに組み入れる事を容易にさせるためにやるんだよ。クラス設計って言うのは。
707 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:56:47 ]: ま、それも再利用のひとつだわな
708 名前：仕様書無しさん mailto:sage [2007/07/07(土) 01:57:07 ]: >>705
最初あたりはJavaだったら、
「関数ポインタないのでインタフェースか抽象クラスにしてバラします」
ぐらいの意識でいいんじゃないかと思う。

# 一応VB6でもインタフェースあるので、この程度だと出来る。
709 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:00:52 ]: >>706
それは大概フレームワークと呼ぶものじゃない？
ま、クラス設計とか以上に縛りがあるけど。

あるいはまったく違うシステムに組み入れられるのは
クラスというよりは、クラスの抽出手順、つまりデザインパターン。

どこかでやった作業を最終的に別の成果物に転用できるのは
気分がいいけど、発表する場所がふつうはないんだよな。
710 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:04:48 ]: まったく違うシステムに持ってくのももちろん再利用だけど、
まずは同じシステムの中で再利用されるケースがおおいわな。
711 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:06:26 ]: つか、歴代使ってる老舗のタレみたいな処理は、ラッパーで包んでしまうから、
それでいいんじゃね？　クラスなんて考えなくてもさ。
712 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:14:52 ]: その手の物って探すと既にあったりしないか?
713 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:18:26 ]: 処理は好き勝手に変えたいわけさ。
処理を変えたいし、さりとて変更コストは安くあげたい。
さて、どうする？ってところがスタート地点かねえ
714 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:18:26 ]: >>712
自社製品の使い古されたシーケンス処理の実装とか、探しても出て来ねえよw
715 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:20:30 ]: >>714
その手のかw
716 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:24:10 ]: >>713
以下も追加して：
＋ある程度のパフォーマンスは見限る。

テストを行い問題がありそうならプロファイラを用いて、
問題の箇所にだけあまり一般的とは言えない処理を記述して高速化を図る。
717 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:36:44 ]: OOって結局、ｵﾚｵﾚ指向の次元の間は
これ以上は普及しないだろうな。

というか、話せば話すほど
全員が違う事を言い出すっていう時点で
そういう類のものっていう認識は持たないとまずいんじゃないかな。
悪い意味じゃなくね。
718 名前：仕様書無しさん mailto:sage [2007/07/07(土) 02:59:23 ]: 道は一本しかないけど、道すがらいろんな景色が見えてるってだけの気もするけど
オプソのコードなんか見てても、「あ、これはめずらしいOOだ！」なんてのは無い品
719 名前：仕様書無しさん mailto:sage [2007/07/07(土) 03:06:05 ]: そうそうJIS規格のボルトとナットみたいな訳にはいかないよ。
720 名前：仕様書無しさん mailto:sage [2007/07/07(土) 04:46:35 ]: >>687
答えは一つだね。
理解したよ。

何の意味も無く、実も無いという事。
なるほど、達人は違うな。
721 名前：仕様書無しさん mailto:sage [2007/07/07(土) 04:55:09 ]: >>671の力量は未知数だ。

ただ、２ｃｈで偉そうな事いう奴は凄いんだろうね。
たかが知れるほど凄いのに論破の一つもしない。

さあ、高レベルな話はまだですか？
低レベルに理解できるように説明してこその高レベルだよ。

電卓のコードでも書いて見せてよ。
高レベルなら5分ぐらいで出来るだろ？
722 名前：仕様書無しさん mailto:sage [2007/07/07(土) 04:57:37 ]: 粘着されるからかね。
723 名前：仕様書無しさん mailto:sage [2007/07/07(土) 07:45:39 ]: 電卓の設計には、CommandパターンとInterpreterパターンが適用できる。
UndoするならMementoパターンで行こう。
724 名前：仕様書無しさん [2007/07/07(土) 07:59:10 ]: >>723
何語？
昔、そういうパターンまとめたのあった気がするけどそれが何か全く覚えてないやｗ
悪いけど内容まで詳しく書いてみてくれない？
725 名前：仕様書無しさん mailto:sage [2007/07/07(土) 08:00:49 ]: 仕様書に～パターンて書きたいなら
仕様書ごとにデザパタ一冊買って添付しなきゃ駄目だよなｗ
726 名前：仕様書無しさん mailto:sage [2007/07/07(土) 08:00:54 ]: >>724
頑張って勉強しよう。素直が一番。
727 名前：仕様書無しさん [2007/07/07(土) 09:04:23 ]: >>694
２．漏れはOO理解してるけど嫌いだ

は間違い。

２．漏れはOO理解してるけど、おじゃぱって奴は嫌いだ

が正解
728 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:30:28 ]: 嫌われようがなんであろうが、
Windowsの開発が.Netに移行してんだから
OO必須になってくのはしょーがない
729 名前：電卓しなりお mailto:sage [2007/07/07(土) 09:38:28 ]: 1.ユーザは、電源キーを押し電源を入れる
　電卓は初期化を行い、初期値として0が表示される
2.ユーザは、電卓の数値キーを押し数値を入力する (もしくは3に移行)
　有効桁数は12桁、浮動小数点数を含み、
　有効な数値範囲は10^12-1～10^-11とする
　有効桁数を超えたキー入力は無視する
　電卓は入力された数値を順次表示する
　数値クリアキー[CE]を押すと、数値入力をやりなおす事ができる
3.ユーザは、演算子キー(＋－×÷)を押す
　電卓は次の数値入力を待つ (2に移行)
3'.ユーザは、[＝]キーを押し、計算結果を得る
　電卓は以前の計算結果もしくは以前の数値入力(Reg1)と、
　新しい数値入力(Reg2)に、3で入力された演算子を適用し
　新しい計算結果を得る
　演算中に演算エラー(0割り)や桁溢れ/桁落ちが発生した場合は、
　エラー表示(0E)をする
4.ユーザはクリアキー[C]を押し、次の計算に移る (2に移行)
　電卓は初期値として0を表示する
5.ユーザは、電源キーを押し電源をoffする

はい次誰か仕様書けｗｗｗ
730 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:42:28 ]: ユーザーは別に電卓のボタンを押したいわけじゃないだろ
式を計算してくれればそれでいいわけなんだがなんでみんなキーとかこだわるんだ？
731 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:47:49 ]: そのとおりだな。
というか、ソフト開発やってんだからソフトだけを言ってりゃいいだろ。
電卓のボタンだとか、液晶だとか、
どう考えても専門外。

こんなこと言い出したらボタンの反発ゴム？の設計とかまでに話が及ぶだろ。

ボタンを押されたあとの計算ロジックだけ考えてりゃいいんだよ。
732 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:50:10 ]: バッカみてぇな質問だな。
答は簡単。ふつー電卓って言った場合は
通常の数式処理(演算子順位文法)ではなく
HP電卓流スタック演算に中置演算子を適用したような形態を指すからさ。

つまり、
普通の数式処理： 1+2*3=7
HP電卓流処理： 1+2*3=9
733 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:52:38 ]: キー入力ってのを物理的なキーの話だと思っているあたりで、
こいつはド素人だからしょうがないんだなぁって思った
734 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:52:56 ]: >>732
何を言いたいのかさっぱりわからん
735 名前：電卓仕様 mailto:sage [2007/07/07(土) 09:56:42 ]: 入力/演算方式：　演算子順位無視の順次入力/演算
　　　　　　　　　　・二つの数値と、一つの演算子を入力し、計算結果を順次表示する
　　　　　　　　　　・入力の順番は、[数値1][演算子1][数値2]とし、
　　　　　　　　　　・次の演算子または[=]キーを入力した時、計算結果を表示する
　　　　　　　　　　・[数値1]は、明示的な数値入力、もしくは直前の計算結果を使う
　　　　　　　　　　・数値入力中に[CE]キーを押すと、数値入力を最初からやり直せる
サポートする演算：　四則演算(＋－×÷)
有効桁数：　　　12桁、浮動小数点数含む
有効数値範囲：10^12-1～10^-11
　　　　　　　　　　有効桁数範囲外のキー入力は無視する
　　　　　　　　　　有効桁数範囲外の演算結果はエラー表示[0E]する
　　　　　　　　　　その他計算エラー(0割り)が発生した場合もエラー表示[0E]
入力キー：　　　[0][1][2][3][4][5][6][7][8][9][.][CE][+][-][×][÷][=][C]
736 名前：仕様書無しさん mailto:sage [2007/07/07(土) 09:57:39 ]: >>734
キミがバカだからさ。
まずは、手計算で 1+2×3 を計算し、
次に電卓で同じ計算をして、
計算結果が同じか違うか確認してみろｗｗｗｗ
737 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:00:55 ]: ド素人向け解説

手計算の場合：

　１＋２×３＝１＋（２×３）＝１＋６＝７
　　　　　　　　　　　※乗除演算は、加減演算よりも優先する

HP流電卓計算の場合：

　１＋２×３＝（１＋２）×３＝３×３＝９
　　　　　　　　※演算子の優先順位は考慮せず、ひたすら左側から順番に計算する
738 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:02:08 ]: >>736
あのな、そんなの誰でもわかるだろ。
どういう流れで喋ってんだ？と聞いてんだけど。
739 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:02:57 ]: キチガイ発狂！！！！
740 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:03:36 ]: HPの電卓っていったら普通逆ポーランド記法じゃねーの？
741 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:04:16 ]: 涙目ｗｗｗｗｗｗｗ
742 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:04:17 ]: スレ違いがすさまじいな
743 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:05:36 ]: キチガイが頑張ってるな

電卓テーマでキー入力するのが気に入らないって
どれだけキチガイなんだコイツｗｗｗ

お前は何を話題にしたいんだよこのキチガイめ
744 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:07:21 ]: >>743
どうしたぼっちゃん？
何か悲しいことでもあったのか？
745 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:07:24 ]: >>740
正確には上に書いたように、
HP電卓流処理を中置演算子に代えたもの＝通常の電卓の処理
を説明している

ちゃんと最初から読めよ
746 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:08:07 ]: 本来オブジェクト指向って奴は学ぶのではなくて、
手続き型言語とかで開発している人たちが
こうなれば効率いいなぁ・・・って感じで産まれたもんじゃんか。
なんで、デザパタとかやる若い人ってちょっと可哀想なきがする
747 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:08:58 ]: 仕様も出たことだし、誰か設計しろよｗ

あ、ちなみに仕様にはちゃんと穴があるから、
それも発見するようにｗ
748 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:09:35 ]: >>745
めんどうで読んでなかった。すまん。
749 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:09:35 ]: 相変わらずバカが目先の課題から逃げ回っているなｗｗｗ

電卓の設計もできねぇなんて、どれだけバカなんだコイツ
750 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:10:16 ]: 電卓なんて、プログラミング実習の最初の週でやるようなテーマだろ

それすらこなせないとは、小学生レベルだな
751 名前：仕様書無しさん [2007/07/07(土) 10:11:09 ]: 電卓で重宝したのはカシオのCM-100だったな。
予備着含めて３つは買ったものだが、結局全部壊れちまった。
再販してくれないかなぁ・・・
752 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:11:16 ]: OOのスレで電卓に必死なのな
753 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:11:27 ]: ↓じゃキミ、電卓の設計ヤレ
754 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:11:57 ]: 電卓終了。
755 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:13:48 ]: >746
デザインパターンをいきなりやる若い人って、そんなにいるのかな？
身近にはおらんっす。
756 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/07(土) 10:16:41 ]: かわいそうなのは、「やらされている」人ですね。
自分の興味で’勉強する分には、
（人によっては）面白いんじゃないでしょうか。
757 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:17:33 ]: 逃げた逃げた～～～～～～～～～～～～～～～～～～～～～～～～

小学生なみに幼稚な奴が
OOでも構造化でも電卓の設計できず
逃げたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ほんとレベル低いなお前
758 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:19:04 ]: 　 ∧＿∧
　（　´∀｀）
　（　　　　）
　｜｜　|
　（_＿）＿）
759 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:19:08 ]: >>756
デザパタってやっぱ勉強しといた方がいいだろうか？
まだ全然見たことなくてね。興味はあるんだけどね。
760 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:19:33 ]: 小学生のぼっちゃん向けヒント

[キー入力]＼
　　　　　　　　＼
　　　　　　　　　　[コントローラ]→[計算機]
　　　　　　　　／　　　　　　　　 ←
[結果表示]／
761 名前：格之進 ◆xiPQGz7lVI mailto:sage [2007/07/07(土) 10:27:57 ]: >>759
無理に勉強する必要は無いと思います。

ある程度実務経験のあるひとなら、
「そんなことはもうやってる」というような内容が多いでしょう。
デザインパターンは分かりきったことを整理して名前をつけただけだ、
という言い方をする人もいますから。

ただ、例えば Java の標準クラスライブラリにしても、
Factory とか、 Composite とか言う言葉がよくでてくるので、
そういうライブラリやフレームワークなどを理解する際には、
知っておいたほうが、理解が早いでしょうね。
762 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:30:55 ]: バカコテが何を言おうと、こいつ電卓の設計もできないクズですから
763 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:31:55 ]: ↓はい、キミは電卓の設計くらいできるよね？
　さっさと設計文書書けよ
764 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:33:53 ]: >>761
なるほど。
本屋行ったときにでもちょっと見てみるかな。
765 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:34:44 ]: 電卓設計で「コントローラ」ってのは、何か違和感あるな。
コントローラの責務は何よ？
766 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:35:30 ]: 結論
電卓でクラスこねくり回す設計するやつはｱﾌｫ
767 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:36:25 ]: 電卓なんていうトイプログラムすらこなせない
痴呆老人が粘着するスレ
768 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:37:33 ]: >>757
お前が一番レベル低いだろ
精神的にな。。
769 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:40:24 ]: >>768
それはどうかな。
キミがいつもこのスレで議論にならない議論を繰り返しているから、
ちょっとからかってみただけだよ。

キミはいつも繰言を繰り返すだけで、
まともな設計図など出した事がないだろう。
キミは一体何のためにこのスレに粘着しているの？
770 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:41:22 ]: >>765
電卓程度にMVC適用ってのは、ちょっと大げさかもしれん。
普通のコントローラの設計でいくと、
入力、出力、モデルを有機的に結びつける「つなぎ」の役目なんだけど。
771 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:42:08 ]: OOが苦手な分野ってあんの？
772 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:42:17 ]: >>769
ヒント：引き篭もり自称トレーダ
773 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:46:25 ]: >>769
>キミはいつも繰言を繰り返すだけで、

ヘンな日本語だな
774 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:47:00 ]: 　　　　　　　　結論：このスレに粘着している人物は、プログラミング/設計の素養などない引き篭もり
775 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:47:51 ]: 774の必死さに合掌
776 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:50:23 ]: 電卓のコア部分は数字か演算子を受け取ればいい。

class Caluculater :
　　+ putNumber(int number)
　　+ putOperator(Operator op)

実計算は Operator を派生した各クラスに数字を渡してお任せ。
各派生オペレータは名前空間や代替手段で纏めておく。
777 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:53:31 ]: 最近の電卓の太陽電池の部分のプログラミングが問題だな
778 名前：仕様書無しさん mailto:sage [2007/07/07(土) 10:57:38 ]: >>776
最終行意味不明
ってかなんでこんな簡単な話で荒れる事ができるのか、
このスレのレベルの低さに脱帽した

>>777
またキチガイの話題ずらしか
半導体のプログラミング？
寝言は寝て言えキチガイ
779 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:02:56 ]: >>778
お前が荒らしてんだろ
780 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:04:32 ]: 太陽電池のプログラミング(ｗ
781 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:05:09 ]: 荒してるんじゃねぇよ
てめぇのバカさ加減をからかってるだけだよ
782 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:08:35 ]: 黒太陽の毒電波を受信する太陽電池プログラミングｗ
783 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:13:11 ]: 月食どうする?
784 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:13:48 ]: 毒電波トレーダ
785 名前：仕様書無しさん mailto:sage [2007/07/07(土) 11:40:17 ]: >>778
大量のクラスが全部公開されてると名前喰い杉
一つに纏めておけば、使いたい時は using すりゃいいし
使いたくないとしても喰う名前は一つだけだ

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef