なぜオブジェクト指向は嫌われているのか？
1 ：仕様書無しさん：
|
|
|
2 ：仕様書無しさん：2007/07/01(日) 11:04:35
考えれば考えるほど嫌いになっていく。
それがオブジェクト指向なんだよね。
それがオブジェクト指向なんだよね。
モジュールの結合度の問題について何も理解してないから
前スレの>>853なんて、その典型
前スレの>>853なんて、その典型
オブジェクト指向以前に、抽象データ型の利点が理解できない奴がいるとは驚いた
引数ずらずら並べるのが正解って、アホじゃね？
ココ電のこと笑えねぇよなｗ
引数ずらずら並べるのが正解って、アホじゃね？
ココ電のこと笑えねぇよなｗ
おじゃぱが
841 名前：仕様書無しさん[sage] 投稿日：2007/06/30(土) 09:11:25
>825
>おじゃばが「OO勉強している奴偉い」と思える環境ができあがっている。
おじゃばって「OO勉強している俺偉い」としか言ってねえよーな。
しかもとんでもなくうわっつらのとこで。
以来来なくなった。これが真実か。
新人研修が忙しい状況に、なったのかな？
841 名前：仕様書無しさん[sage] 投稿日：2007/06/30(土) 09:11:25
>825
>おじゃばが「OO勉強している奴偉い」と思える環境ができあがっている。
おじゃばって「OO勉強している俺偉い」としか言ってねえよーな。
しかもとんでもなくうわっつらのとこで。
以来来なくなった。これが真実か。
新人研修が忙しい状況に、なったのかな？
おじゃばは基本的に休日はレスしない
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*);
};
class CALCULATOR{
staing formula[int_MAX];
public:
CALCULATOR();
FOI_ERROR FORM_Input(string/*入力する式*/);
int FORM_Solution(int/*計算モード*/ staing*);
};
前すれのくだんねー議論に横レス
xyzのうち yz zx xy に対するんなたらかんたらは、要するに平面三次元空間から平面を取り出して、それに対する操作という事なのだろう
それならそのうち任意法線に垂直な平面に対する処理というのも当然でてくるだろうから、平面の指定方法で抽象化して統一化すればいいんじゃね？
xyzのうち yz zx xy に対するんなたらかんたらは、要するに平面三次元空間から平面を取り出して、それに対する操作という事なのだろう
それならそのうち任意法線に垂直な平面に対する処理というのも当然でてくるだろうから、平面の指定方法で抽象化して統一化すればいいんじゃね？
溶岩流アンチパターンの一因について盛り上がっていたね。
>>7
もしかして: staining
もしかして: staining
11 ：仕様書無しさん：2007/07/01(日) 12:48:48
>>10
なんだそれ。
なんだそれ。
前スレのリゾットメソッド君には驚いたな
オブジェクト指向が嫌われる理由
それは、
オブジェクト指向の有効性を分からない上役が
分からないまま導入するため。
それは、
オブジェクト指向の有効性を分からない上役が
分からないまま導入するため。
上役が分からなくても、自分たちが価値を見出して活用できればいいのでないの？
バカな上役の勧める物は何でも嫌いじゃ、駄々っ子のガキだ。
バカな上役の勧める物は何でも嫌いじゃ、駄々っ子のガキだ。
自分たち、ってのは誰を指してんだ？
偽装請負会社から来てるわからんちんも含めてのことだよな？
偽装請負会社から来てるわからんちんも含めてのことだよな？
>>15
自分たち＝オブジェクト指向をコードで実践するプログラマたち
って思ってくれ。
わからんちんは教育するしかないな。
わからんちんが見込みなければ、オブジェクト指向はあきらめて、
構造化でも何でも理解できる方法論使ってやってくれ。
自分たち＝オブジェクト指向をコードで実践するプログラマたち
って思ってくれ。
わからんちんは教育するしかないな。
わからんちんが見込みなければ、オブジェクト指向はあきらめて、
構造化でも何でも理解できる方法論使ってやってくれ。
用語を統一してくれと何度か思ったけど、もうどうでもいいや
>>16
なぜオブジェクト指向は嫌われているか・・・わかったよ！
なぜオブジェクト指向は嫌われているか・・・わかったよ！
>>16
なぜオブジェクト指向は嫌われているか・・・わかったよ！
なぜオブジェクト指向は嫌われているか・・・わかったよ！
20 ：仕様書無しさん：2007/07/01(日) 14:29:59
学校でC言語学んでいるとですが
C言語でオブジェクト指向するにはどうすればよかとですか？
C言語でオブジェクト指向するにはどうすればよかとですか？
まずC言語を学んでください
23 ：仕様書無しさん：2007/07/01(日) 14:33:45
>>20
インクリメントすればいい
インクリメントすればいい
Cは（当然言語だが）OOPを言語レベルでサポートしていない
26 ：仕様書無しさん：2007/07/01(日) 14:46:11
int i = new int()
ってやったら、どうなるの？
今、手元に開発環境が無いので試せない。
ってやったら、どうなるの？
今、手元に開発環境が無いので試せない。
fprintfつかFILE構造体だな
ゲームなんかはOOが分かりやすいな
キャラクターそれぞれの動きと性格をインターフェースで定義して、
それぞれを実装して、って感じで
これが制御プログラムとかの業務になるとわかりにくいって言う奴がいるってことでしょ
キャラクターそれぞれの動きと性格をインターフェースで定義して、
それぞれを実装して、って感じで
これが制御プログラムとかの業務になるとわかりにくいって言う奴がいるってことでしょ
29 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 14:49:27
「オブジェクト指向」それ自体には何の問題もないと思うよ。
押し付けがましい人がいるのが問題。
押し付けがましい人がいるのが問題。
30 ：仕様書無しさん：2007/07/01(日) 14:52:53
Cでもオブジェクト指向的なコードは書けるよ。
でもね。C++で言うとこのthisポインターを持ち回りで自己管理しなくちゃならないとか、クラス内のメソッド呼び出しにアクロバチックな仕掛けを設けなきゃいけないとか、グズグズのコードになるから、実装レベルではしんどい。
でもね。C++で言うとこのthisポインターを持ち回りで自己管理しなくちゃならないとか、クラス内のメソッド呼び出しにアクロバチックな仕掛けを設けなきゃいけないとか、グズグズのコードになるから、実装レベルではしんどい。
新コテハンかと思ったらココ電かよ・・・
統計とったわけでも無いのに属人的な問題にしてしまうのは思考停止
日本語でおｋ
34 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 15:17:04
オブジェクト指向といっても、要するに一つの道具なんだから、
使いたくなきゃ使わなきゃいいんだし。
使う必要があるなら使えばいい。
自分のやることについては道具を自分の判断で選べるものならば、
他人がその人のやることにどのような道具を使おうと、
そんなに拘る必要はないんじゃないの？
使いたくなきゃ使わなきゃいいんだし。
使う必要があるなら使えばいい。
自分のやることについては道具を自分の判断で選べるものならば、
他人がその人のやることにどのような道具を使おうと、
そんなに拘る必要はないんじゃないの？
>>30
クラスベースのOOなプログラミングはCでは無理。
クラスベースのOOなプログラミングはCでは無理。
面倒なだけで不可能ではない。
初期のC++実装はCに足したものだったからね。
C++ソースをCへプレコンパイルしてたのさ。
初期のC++実装はCに足したものだったからね。
C++ソースをCへプレコンパイルしてたのさ。
CではOOっぽく作れるだけで、
クラスも継承もインターフェースも無い時点でOOではない
クラスも継承もインターフェースも無い時点でOOではない
>>30
C++でも最後には機械語になる。
OOPの動きを真似て良い所だけをつまんで使うのが由。
アセンブラレベルでの働きは、昔からよく使われている手法だし。
継承の真似事、仮想関数の真似事（直前まで呼び出し先が未定）を
する感じの物はCやアセンブラでよく作った。
C++でも最後には機械語になる。
OOPの動きを真似て良い所だけをつまんで使うのが由。
アセンブラレベルでの働きは、昔からよく使われている手法だし。
継承の真似事、仮想関数の真似事（直前まで呼び出し先が未定）を
する感じの物はCやアセンブラでよく作った。
>>38
それはなにで組んでも大してかわんねーよ
それはなにで組んでも大してかわんねーよ
>>43
構造体と関数へのポインタでゴリゴリやんだよ。
構造体と関数へのポインタでゴリゴリやんだよ。
すでにC/C++それぞれの役割分担はだいたい決まっている話なので、どうでもいい。
C++はOOとしてはかなり中途半端な存在だな。
C++はOOとしてはかなり中途半端な存在だな。
Cでもマクロを駆使して継承やインターフェースを実現させてるシステムはあるよ。
すんごく制限あるけどね。
もう、初期のC++をCに変換した後のコード見ているような感じさ
すんごく制限あるけどね。
もう、初期のC++をCに変換した後のコード見ているような感じさ
言語に頼るのはＯＯとは言わない。
52 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 15:47:22
まあ、結局、CからC++ や Java 移っても、
新しいことができるようになった、というよりも、
楽になった、としか思わないよね。
新しいことができるようになった、というよりも、
楽になった、としか思わないよね。
それでいいじゃん
そういえば、かつてのg++って、なんかオプションでC++のコードをC言語のコードに変換できたよな？
継承もオーバーロードもインターフェースも OO の本質ではない
OO はプログラムを考える時に値と機能（変数と関数）を、
機能主体の分割（関数化・APIライブラリ化）ではなく、
動作部品単位で分割するようにした方が分かりやすいぜ、
って、設計のための概念だからだ
もちろん、そういう設計をする以上、継承やらが使えた方が便利だし、
今となっては OO 対応の言語を使わない意味は無い
ただ、継承やらの末端の機能にこだわるマが、
クラス設計としては見通しが最悪なプログラムを書いて、
プロジェクト全体で OO 禁止になったりする事があるから
木を見て森を見ずには注意しような
OO はプログラムを考える時に値と機能（変数と関数）を、
機能主体の分割（関数化・APIライブラリ化）ではなく、
動作部品単位で分割するようにした方が分かりやすいぜ、
って、設計のための概念だからだ
もちろん、そういう設計をする以上、継承やらが使えた方が便利だし、
今となっては OO 対応の言語を使わない意味は無い
ただ、継承やらの末端の機能にこだわるマが、
クラス設計としては見通しが最悪なプログラムを書いて、
プロジェクト全体で OO 禁止になったりする事があるから
木を見て森を見ずには注意しような
おまいら>>22は無視ですかそうですか。。
>>57
C言語の話を書いてあるだけでスレタイと無関係
C言語の話を書いてあるだけでスレタイと無関係
>>58
わかりましたすみません
わかりましたすみません
>>58
Cで継承もオーバロードもできるって書いてあるじゃん
Cで継承もオーバロードもできるって書いてあるじゃん
>>61
アホはレスせんでいいぞｗ
アホはレスせんでいいぞｗ
>>60
しつっこいから見に行ってみたけど、これ、「C言語でオブジェクト指向やってると思いこむためのコードの書き方」でないの。
メソッドもどきは、関数の先頭を Staff_ で統一してるだけだし。
強固な意志と思想を持ったプログラマであれば、こういうコードでもOOのカプセル化などを達成できるだろうけど、
そうでない大半のプログラマは、面倒くさくなってグローバル変数入れたりして、破綻させちゃうよ。
しつっこいから見に行ってみたけど、これ、「C言語でオブジェクト指向やってると思いこむためのコードの書き方」でないの。
メソッドもどきは、関数の先頭を Staff_ で統一してるだけだし。
強固な意志と思想を持ったプログラマであれば、こういうコードでもOOのカプセル化などを達成できるだろうけど、
そうでない大半のプログラマは、面倒くさくなってグローバル変数入れたりして、破綻させちゃうよ。
>>60
昔のC++コンパイラはバイナリじゃなくてC言語のソースを生成してた
つまりC++のソースをコンパイルするとCのソースが生成されて、
それをコンパイルするとバイナリになった。
CでOOを別に書けん事も無いが、それは「C言語であってC++言語ではない」
昔のC++コンパイラはバイナリじゃなくてC言語のソースを生成してた
つまりC++のソースをコンパイルするとCのソースが生成されて、
それをコンパイルするとバイナリになった。
CでOOを別に書けん事も無いが、それは「C言語であってC++言語ではない」
そこでObjective-Cですよ
スレタイ厨は半年ROMってろ
OOPはOOPLでなくてもできる
ここはOOPLのスレでは無いからスレ違いという程でもなかろう
非OOPLでOOPやることはあまり実用的じゃないけどな
ここはOOPLのスレでは無いからスレ違いという程でもなかろう
非OOPLでOOPやることはあまり実用的じゃないけどな
>>67がスレタイとは関係の無い実のある話をしてくれるそうです
オブジェクト指向が嫌われる原因は、
設計と実装が一体化するからだろう
プログラムはできん、と言ってSEを自称する連中が多く、
UMLなどを学習する素地がないため、
PGがオブジェクト指向を学習しても設計ができてないため、
OOの本質である設計から実装へのスムーズな移行ができてない
簡単に言えば、設計でOOを活用できる人材が少ないということだ
設計と実装が一体化するからだろう
プログラムはできん、と言ってSEを自称する連中が多く、
UMLなどを学習する素地がないため、
PGがオブジェクト指向を学習しても設計ができてないため、
OOの本質である設計から実装へのスムーズな移行ができてない
簡単に言えば、設計でOOを活用できる人材が少ないということだ
class 電卓キー {
計算();
};
これが理解できるものは上級者。
計算();
};
これが理解できるものは上級者。
72 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 18:41:22
「電卓キー」を表現するなら、こうじゃないの。
interface 電卓キー {
「=」キー();
}
「計算」は実装クラス側にあって、
class 電卓 implements 電卓キー {
「=」キー() {
計算;
}
}
interface 電卓キー {
「=」キー();
}
「計算」は実装クラス側にあって、
class 電卓 implements 電卓キー {
「=」キー() {
計算;
}
}
73 ：仕様書無しさん：2007/07/01(日) 18:41:47
>>72
ココ電球はやめたのか？
ココ電球はやめたのか？
>>73
実装の話はしてないんじゃ・・・
実装の話はしてないんじゃ・・・
76 ：仕様書無しさん：2007/07/01(日) 18:46:32
>>75
設計とも言えないくらい穴のある設計ですね。
設計とも言えないくらい穴のある設計ですね。
77 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 18:46:57
>>74
「ココ電球」って何ですか？
「ココ電球」って何ですか？
自演発覚の瞬間を見た
(・∀・)
class 電卓キー {
計算();
};
やはり思った通りだな。
一見稚拙な設計に見えるこのクラスの奥が見えるものと、見えない香具師に分かれたな。
計算();
};
やはり思った通りだな。
一見稚拙な設計に見えるこのクラスの奥が見えるものと、見えない香具師に分かれたな。
81 ：格之進 ◆xiPQGz7lVI ：2007/07/01(日) 19:12:20
いや、そうやって、オブジェクト指向を、
なんかの奥義みたいに言うもんだから、
嫌われるんじゃないの？
なんかの奥義みたいに言うもんだから、
嫌われるんじゃないの？
またお前らＵＩ無視ですか．．．
83 ：仕様書無しさん：2007/07/01(日) 19:14:24
>>84
浅いな。
浅いな。
ところで何この糞コテ
87 ：仕様書無しさん：2007/07/01(日) 19:19:50
オブジェクト指向は奥義なのです。
88 ：仕様書無しさん：2007/07/01(日) 19:35:19
>>80
………で、答えは？
………で、答えは？
もう既出で答えられず顔真っ赤なんだろ？
ていうか、万人にわからん時点で糞設計ということは確定してるがな
なんのためのオブジェクト指向なのか・・・
もう色々履き違えてるよねｗ
なんのためのオブジェクト指向なのか・・・
もう色々履き違えてるよねｗ
VB.netの初心者本を本屋で見てみたら
「まるでVBの代替として使うような」章分けになっていた
困るねコレじゃ たぶんそれでも使えるからOKってことなんだろうけどさ
「まるでVBの代替として使うような」章分けになっていた
困るねコレじゃ たぶんそれでも使えるからOKってことなんだろうけどさ
こんなわからんもん出して悦にいってる自分を恥じれよｗ
客から
windowsの関数電卓くらいの仕様は想定して言ってるんだろうね？
とか言われて作り直しになる未来が予想できる
客から
windowsの関数電卓くらいの仕様は想定して言ってるんだろうね？
とか言われて作り直しになる未来が予想できる
ＶＢ．Ｎｅｔは糞
あれだったらＶＣやったほうがいい
ＭＳが自由に改変できるような言語を使ってちゃ駄目
あれだったらＶＣやったほうがいい
ＭＳが自由に改変できるような言語を使ってちゃ駄目
オブジェクト指向は達人用の道具なので、万人向けではないのでは？
>>94
設計技術でわかりにくいとかすでに目的が不明ｗ
設計技術でわかりにくいとかすでに目的が不明ｗ
97 ：仕様書無しさん：2007/07/01(日) 20:03:58
>>95-96
しかし、分かりにくいのは確か。
しかし、分かりにくいのは確か。
>>97
じゃあ、つかえねぇんだよｗ
じゃあ、つかえねぇんだよｗ
本格的にオブジェクト指向されてなくても、
クラスなどの構造で、ある程度汚いながらも分割されていたほうが遥かにマシ。
クラスなどの構造で、ある程度汚いながらも分割されていたほうが遥かにマシ。
101 ：仕様書無しさん：2007/07/01(日) 20:19:13
指向とはそういうものだよ。
だから、OOは
使う機会が無ければ、使わなくても済む技術。
不要だと思う人は、使わなければいいだけ。
ただし、大手のプロジェクトに参加するなら、必ずOOと対面する。
そのときにアセっても、後悔するだけ。
使う機会が無ければ、使わなくても済む技術。
不要だと思う人は、使わなければいいだけ。
ただし、大手のプロジェクトに参加するなら、必ずOOと対面する。
そのときにアセっても、後悔するだけ。
楽譜が書けるからといって、名曲が作れるわけではない。
これに等しい。
これに等しい。
おれなんか最初から自然にオブジェクト指向だったよ。
向いてるのかな？
向いてるのかな？
107 ：仕様書無しさん：2007/07/01(日) 20:31:47
確率を確立と書くのは、何故なんだぜ？
名曲を作るヒントの一つにオブジェクト指向があるわけなので、
名曲が作れないからといって、オブジェクト指向を否定するのはどうかな。
名曲が作れないからといって、オブジェクト指向を否定するのはどうかな。
110 ：仕様書無しさん：2007/07/01(日) 20:36:31
>>108
単なる変換ミスでーす。
単なる変換ミスでーす。
どこぞのアホが、義務教育で確率を確立と書くように改めたんだって偽情報が反乱してた時期があってな。
それからと言うもの、確率を確立と書く奴らは信用してないんだよ。
チラシの裏でスマンコ
それからと言うもの、確率を確立と書く奴らは信用してないんだよ。
チラシの裏でスマンコ
そうだよね。
文字が書けても、文学が作れるわけではない。
楽譜が書けても、名曲が作れるわけではない。
おいらは向いてないのかな？
文字が書けても、文学が作れるわけではない。
楽譜が書けても、名曲が作れるわけではない。
おいらは向いてないのかな？
そうか！オブジェクト指向は芸術だったんだ！
まあ、誰もプログラムに芸術なんて求めていないけどな。
確実に動くものを早く高品質に仕上げてほしいだけだ。
確実に動くものを早く高品質に仕上げてほしいだけだ。
匠の技か。ワクワクするぜ。
>>115
それならオブジェクト指向をお勧めするよ。
それならオブジェクト指向をお勧めするよ。
学問に王道なし。設計も同じ。
119 ：仕様書無しさん：2007/07/01(日) 21:03:52
オブジェクト指向はいいけど
アスペクト指向だけは納得いかない
アスペクト指向だけは納得いかない
アスペクト便利じゃん
121 ：仕様書無しさん：2007/07/01(日) 21:31:41
ディポジット指向プログラミングの時代が来る。
ディスポーザブル指向？
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
俺の場合は原因は下痢だな
ちょっともれちゃって・・・・
OOで設計できる奴が少ないだけだろ
JavaやC++がわからん奴が設計すれば
機能分割したものを作ってしまいがち
JavaやC++がわからん奴が設計すれば
機能分割したものを作ってしまいがち
せっかくのオブジェクト指向なのに、クラス分けと機能分けを混同して、同じ概念を複数別々に実装してるプロジェクトを結構見かける。
同じ概念なんだから、そこは同じインターフェースで実装しないと。とか、別会社同士で歩調が取れる訳も無くw
案の定、座礁しかかってるww
同じ概念なんだから、そこは同じインターフェースで実装しないと。とか、別会社同士で歩調が取れる訳も無くw
案の定、座礁しかかってるww
XX業務クラスってか？ありがち
>>126
インターフェースわざわざ一致させる意味がわからない
別部署が担当することになったらさらに意味がない
ちゃんと説明できた上で煽ってんの？ん？
それとも本読んだらそう書いてあっただけ？
なんかただ煽ればいいみたいな奴多くて嫌なんだよね
インターフェースわざわざ一致させる意味がわからない
別部署が担当することになったらさらに意味がない
ちゃんと説明できた上で煽ってんの？ん？
それとも本読んだらそう書いてあっただけ？
なんかただ煽ればいいみたいな奴多くて嫌なんだよね
おまいらが全員死んでオレのクローンが開発すれば
あっという間に開発は終わる。
・・・世界も終わる。
あっという間に開発は終わる。
・・・世界も終わる。
UML覚えるのがねえ
覚えるまでもなく、見りゃわかんだろ
JavaやC++の経験があっても無理な奴は無理。
作業分担がしやすいとか、テストを作りやすいとか、
あとでツブシがきく、というような設計は、
それなりの設計＋コーディングの経験をつまないと。
こういうのは頭でっかちの若い奴にやらせないで、
徒弟制にして、ちゃんと技術力のある人から継承してかないと
ダメだと、マジで思う。
作業分担がしやすいとか、テストを作りやすいとか、
あとでツブシがきく、というような設計は、
それなりの設計＋コーディングの経験をつまないと。
こういうのは頭でっかちの若い奴にやらせないで、
徒弟制にして、ちゃんと技術力のある人から継承してかないと
ダメだと、マジで思う。
UMLは出発点に過ぎないよね
ツールの扱いとか作図に時間かかる、ってことで敬遠されることもあるし、
見てもわからんって言う人は存在するし
ツールの扱いとか作図に時間かかる、ってことで敬遠されることもあるし、
見てもわからんって言う人は存在するし
>>136
技術のあるなしってどうやって判断するつもりだよ
技術のあるなしってどうやって判断するつもりだよ
>>137
継承関係を表した図なのか
状態遷移図なのか
関連図なのか
インスタンスの有り方を表した図なのか
わからんのでもうそういうクラス関連の図はいらんｗ
作ってる奴ですら間違いに気付いてない
文句付けると大抵逆上する
もう一枚たりとも書くなといいたい
継承関係を表した図なのか
状態遷移図なのか
関連図なのか
インスタンスの有り方を表した図なのか
わからんのでもうそういうクラス関連の図はいらんｗ
作ってる奴ですら間違いに気付いてない
文句付けると大抵逆上する
もう一枚たりとも書くなといいたい
>>135
ああ、無駄なクラスが山のように作られてるよ。
この時だけは使うクラスはこっち。あの時だけはこっちを使うってな。
もうね、ポリモフィズムもなにもあったもんじゃねえ。
しかも使い分ける用にその間を取り持つクラスを作ってる有り様。
ああ、無駄なクラスが山のように作られてるよ。
この時だけは使うクラスはこっち。あの時だけはこっちを使うってな。
もうね、ポリモフィズムもなにもあったもんじゃねえ。
しかも使い分ける用にその間を取り持つクラスを作ってる有り様。
「汎化ってなんですか？」
協力会社の先輩後輩がこういう会話をしてた。
OOには一般的でない言葉が多すぎる。
協力会社の先輩後輩がこういう会話をしてた。
OOには一般的でない言葉が多すぎる。
構造化は一般的な言葉か？
C/C++で分散開発なんて聞いたことねえからJavaなんじゃね？
Javaならグローバル変数ねえぞ
Javaならグローバル変数ねえぞ
147 ：仕様書無しさん：2007/07/01(日) 23:43:46
>>146
なら医学や法学も嫌われてるのか？
なら医学や法学も嫌われてるのか？
150 ：仕様書無しさん：2007/07/01(日) 23:45:43
>>141
そこで何故継承を使わない。
そこで何故継承を使わない。
汎化だってニュアンスでわかんだろ普通
ああ、一般化？みたいな感じで
ああ、一般化？みたいな感じで
>>143
グローバル変数なんて使わずとも、
クラス設計が糞なシステムは、無駄に肥大化するし、保守にも莫大なコストがかかる。
それぞれが思い付くまま勝手に少しづつ仕様の違う似たようなクラスを量産している。
しかもベースクラスからの派生とか言う方法でもなく、勝手にインターフェースを独自仕様で作っている。
仕様変更なんてかかった日にゃあ、何人死人が出るかわからない状況。
グローバル変数なんて使わずとも、
クラス設計が糞なシステムは、無駄に肥大化するし、保守にも莫大なコストがかかる。
それぞれが思い付くまま勝手に少しづつ仕様の違う似たようなクラスを量産している。
しかもベースクラスからの派生とか言う方法でもなく、勝手にインターフェースを独自仕様で作っている。
仕様変更なんてかかった日にゃあ、何人死人が出るかわからない状況。
>>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;
}
先生！こうやればいいと思います。
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;
}
>>151
ニュアンスで仕事しないでくれよ・・
ニュアンスで仕事しないでくれよ・・
157 ：仕様書無しさん：2007/07/01(日) 23:49:24
>>154
それはあなたの会社がｒｙ
それはあなたの会社がｒｙ
そうか、設計段階で破綻してたんだ。納得。
160 ：仕様書無しさん：2007/07/01(日) 23:51:47
>>153
頭いいな、おまえ。
頭いいな、おまえ。
>>160
悪魔を誉めるなw
悪魔を誉めるなw
いや・・・構造化という言葉を知らないのはさすがに。
言語研修を終えたばかりの新人でもあるまいし。
新人でも「構造化構文」ぐらいは教わるのでは？
言葉を知らなくても確かに開発は出来るだろうが。
言語研修を終えたばかりの新人でもあるまいし。
新人でも「構造化構文」ぐらいは教わるのでは？
言葉を知らなくても確かに開発は出来るだろうが。
ろくすっぽ言葉しらねえで開発してたくせに、
OOは用語が一般的じゃないからダメだ？いいわけくせえよ
OOは用語が一般的じゃないからダメだ？いいわけくせえよ
165 ：仕様書無しさん：2007/07/01(日) 23:57:35
OOの悪い所。
抽象化を人任せ。
抽象化を人任せ。
つか、人は自分で集めるもんだろw
どんだけ受身なんだよ
どんだけ受身なんだよ
新しいパラダイムには新しい言葉が付き物なのだが
>>166
宗教やってんじゃないんだから
宗教やってんじゃないんだから
>>28
http://pc11.2ch.net/test/read.cgi/prog/1179153355/
●下記の話題は何度繰り返されても結論が出ず、無駄に荒れるだけなので避けましょう
・オブジェクト指向
http://pc11.2ch.net/test/read.cgi/prog/1179153355/
●下記の話題は何度繰り返されても結論が出ず、無駄に荒れるだけなので避けましょう
・オブジェクト指向
175 ：仕様書無しさん：2007/07/02(月) 00:04:36
開発者が人材確保しなければならないスレはここですか？
つうか、人足にOOの知識なんていらんのだよ。
設計する奴らの問題。
設計する奴らの問題。
>>176
ここらしいです
ここらしいです
つか別にいいんだよ。人集めできようができまいが
だが、OOの是非を論じるときに「開発者の質」って問題は
切り分けたほうがいいんじゃね？
構造化なら雑魚集めてもうまくいくか？いかないだろ
だが、OOの是非を論じるときに「開発者の質」って問題は
切り分けたほうがいいんじゃね？
構造化なら雑魚集めてもうまくいくか？いかないだろ
>>177
いやそれはいるだろ。普通に
いやそれはいるだろ。普通に
>>168
なんだその、ならべると７つの大罪みたいでカッコイイなｗ
なんだその、ならべると７つの大罪みたいでカッコイイなｗ
182 ：仕様書無しさん：2007/07/02(月) 00:13:34
思い出した事。
オブジェクト指向には、
普通のオブジェクト指向とＣ＋＋型オブジェクト指向がある。
オブジェクト指向には、
普通のオブジェクト指向とＣ＋＋型オブジェクト指向がある。
>>181
ないす！
ないす！
>>184
責任逃れのＯＯって事か？
責任逃れのＯＯって事か？
>>186
責任逃れというより、「設計専任」「実装専任」って存在がそもそも不要
責任逃れというより、「設計専任」「実装専任」って存在がそもそも不要
>>1-190
だから・・・
だから・・・
>>190
だからOO使う限りそのやり方じゃうまくいくはずねーって
だからOO使う限りそのやり方じゃうまくいくはずねーって
>>192
ならOO使わなきゃいいじゃんw
ならOO使わなきゃいいじゃんw
でも正直オブジェクト指向ってもんが見えてきたよな
元のオブジェクト単位でどうこうってのも確かな理論があっていいって言ってるわけじゃねぇしな
その上にあれこれ無駄なもん積み上げても結局本質はあやふやなまま
まさに砂上の楼閣
これが現状ですよ
元のオブジェクト単位でどうこうってのも確かな理論があっていいって言ってるわけじゃねぇしな
その上にあれこれ無駄なもん積み上げても結局本質はあやふやなまま
まさに砂上の楼閣
これが現状ですよ
なあOOだと設計も実装も兼任なんて、誰が言ったんだ？
それじゃあ、設計の人数多すぎるし、実装の人数少なすぎねえか？
それじゃあ、設計の人数多すぎるし、実装の人数少なすぎねえか？
人足ってなんて読むの？にんそく？じんそく？ひとあし？
なんか上の方で用語がどうのこうの言ってたけど、
用語使わないと他人に説明できない技術は「身についた技術」とは言えないと思うぞ。
ただまぁ、用語が通じる相手の方がコミュニケーションが楽なのは当たり前だが。
用語使わないと他人に説明できない技術は「身についた技術」とは言えないと思うぞ。
ただまぁ、用語が通じる相手の方がコミュニケーションが楽なのは当たり前だが。
>>199
用語ってそういうもんだろ
用語ってそういうもんだろ
>>196
おめー、原理主義者の俺だってそんぐれーは知ってるぞｗ
おめーの宗派が何かは知らないけど勉強不足じゃね？
とりあえずオブジェクト指向は設計〜実装までシームレスだかなんだかってのが売り文句だったんだぜ
そのためにクラスなんだぜ
おめー、原理主義者の俺だってそんぐれーは知ってるぞｗ
おめーの宗派が何かは知らないけど勉強不足じゃね？
とりあえずオブジェクト指向は設計〜実装までシームレスだかなんだかってのが売り文句だったんだぜ
そのためにクラスなんだぜ
言語を覚えましたって奴が設計出来るとは限らない。
OOの話はその辺を複雑化した後抽象的な表現にする流れが多いと思う。
実装方法と言語のOO要素をごちゃ混ぜにしてクラス分けで全て解決ですよ
みたいな流れになる。
単純化と具象化をモットーとする構造化をなぜ先にやらず、
いきなりOOなのかが疑問だ。
論理的思考が出来ていてこその抽象化なのになぜそれを否定するのか？
今も昔も実装技術と設計技術と言語習得は似ている様で違う。
OOPなら全部まとめて面倒見れるんだ？
OOの話はその辺を複雑化した後抽象的な表現にする流れが多いと思う。
実装方法と言語のOO要素をごちゃ混ぜにしてクラス分けで全て解決ですよ
みたいな流れになる。
単純化と具象化をモットーとする構造化をなぜ先にやらず、
いきなりOOなのかが疑問だ。
論理的思考が出来ていてこその抽象化なのになぜそれを否定するのか？
今も昔も実装技術と設計技術と言語習得は似ている様で違う。
OOPなら全部まとめて面倒見れるんだ？
ああ、おまいらの勘違いか。
別に設計と実装が別人でもいいんだろ。
やっぱし、人足に設計までさせるなや。
別に設計と実装が別人でもいいんだろ。
やっぱし、人足に設計までさせるなや。
上のは用語自体の説明のことじゃね？
「汎化ってなんですか？」
ってらしいから。
そういうことを教えるのが鬱って話でしょ。
「汎化ってなんですか？」
ってらしいから。
そういうことを教えるのが鬱って話でしょ。
>>206
たぶんお前わかってねえぞ
たぶんお前わかってねえぞ
>>205
構造化知らずにいきなりOOって、お前がいいだした珍説だろ
構造化知らずにいきなりOOって、お前がいいだした珍説だろ
ところで、おまいら、どれが誰の言った書き込みか分かるのか？
C++に詳しい人が多そうなんで質問。
class A:B<A>;
こんなクラスをたまに見るけど、
こういうのはどういう時に使うのか教えてください。
class A:B<A>;
こんなクラスをたまに見るけど、
こういうのはどういう時に使うのか教えてください。
>>212
証明？やぶから棒になにを言い出すんだ
証明？やぶから棒になにを言い出すんだ
>>211
スーパークラスが導出先クラスの型によって生成されるクラスだよ。
他にもポリシーのような使い方もある、とりあえずModern C++ Design見ながら使い倒してみるといい。
おれはBのクラスの上に共通の抽象スーパークラスを入れるのが得意技。
boost系のソースコードにもその種の面白いのが沢山あるよ。
スーパークラスが導出先クラスの型によって生成されるクラスだよ。
他にもポリシーのような使い方もある、とりあえずModern C++ Design見ながら使い倒してみるといい。
おれはBのクラスの上に共通の抽象スーパークラスを入れるのが得意技。
boost系のソースコードにもその種の面白いのが沢山あるよ。
なぜ素人にオブジェクト指向（言語）なんて使わせるんだ？
なぜ素人がプログラム作ってるんだ？
昔からある疑問だ。
いきなり屑みたいな文章が増えて嫌になった。
>>141見たいなのがオブジェクト指向の実際なんだろ？
なぜ素人がプログラム作ってるんだ？
昔からある疑問だ。
いきなり屑みたいな文章が増えて嫌になった。
>>141見たいなのがオブジェクト指向の実際なんだろ？
まああれだ。
OOってのは過去の開発で失敗したことを失敗しないようにと考えられたわけだ。
ところが資格などの統一見解が無いので
OOが実装されてる言語を扱う技術者はそれなりに理解するが
OOの設計を行う技術者（実装をしない連中）は学習しないわけだ。
となると、当然設計から実装へのシームレスなんてもんは期待できんわけ。
ってことでOK？
OOってのは過去の開発で失敗したことを失敗しないようにと考えられたわけだ。
ところが資格などの統一見解が無いので
OOが実装されてる言語を扱う技術者はそれなりに理解するが
OOの設計を行う技術者（実装をしない連中）は学習しないわけだ。
となると、当然設計から実装へのシームレスなんてもんは期待できんわけ。
ってことでOK？
>>223
だから構造化に資格があるのかと小一時間
だから構造化に資格があるのかと小一時間
いかざるお？日本語おかしいおw
220のつづき
そうそう、この種の話題はオブジェクト指向ではなくてテンプレートジェネリックスまたはテンプレートメタプログラミングの領域になるので、それらしいスレにいってみるといいと思う。
唯一オブジェクト指向を超られそうで、かつ実用的手プログラム技術ネタだと思うんで熱いよ、行き着くところまでいくと最終的にはHaskellマンセーになるかも知れないがw
C++は増築が行き過ぎて少し複雑になりすぎたからな
そうそう、この種の話題はオブジェクト指向ではなくてテンプレートジェネリックスまたはテンプレートメタプログラミングの領域になるので、それらしいスレにいってみるといいと思う。
唯一オブジェクト指向を超られそうで、かつ実用的手プログラム技術ネタだと思うんで熱いよ、行き着くところまでいくと最終的にはHaskellマンセーになるかも知れないがw
C++は増築が行き過ぎて少し複雑になりすぎたからな
関数単位に分割する方法が構造化手法で，責務単位に分割する方法がオブジェクト指向
こう考えれば分かりやすいのだけど、
オブジェクト指向はやたらと用語が多いし、
へんな例が多くて一層混乱してるってのは事実。
こう考えれば分かりやすいのだけど、
オブジェクト指向はやたらと用語が多いし、
へんな例が多くて一層混乱してるってのは事実。
>>229
半可通な知識で語ったら恥ずかしい目にあうよ、それとは全然関係ないから。
半可通な知識で語ったら恥ずかしい目にあうよ、それとは全然関係ないから。
>>230
関数自体が責務単位だからＯＯ＝構造化だよな？
関数自体が責務単位だからＯＯ＝構造化だよな？
>>234
Cなんかの関数が表してるのは、いわゆる「機能」だろ？
Cなんかの関数が表してるのは、いわゆる「機能」だろ？
オブジェクト指向って、Windowsで窓やダイアログ単位で実装してくうちに考えついたんじゃねえの？ とか思う今日このごろ。
>>237
「何を」と「誰が」っていう点で違う
「何を」と「誰が」っていう点で違う
技術者の学習不足も原因の一つだろうが、
OOの話題が何かと混乱してるは事実。
OOがわかりにくい、って話があるのはあんたらも知ってるだろ。
そんな状況のものに手を出す奴がどれだけいるかだな。
少なくとも今の偽装請負があたりまえのままではダメだな。
OOの話題が何かと混乱してるは事実。
OOがわかりにくい、って話があるのはあんたらも知ってるだろ。
そんな状況のものに手を出す奴がどれだけいるかだな。
少なくとも今の偽装請負があたりまえのままではダメだな。
>>239
じゃあ、「誰が」で機能分けしちゃえば、構造化プログラムもOOだな。
じゃあ、「誰が」で機能分けしちゃえば、構造化プログラムもOOだな。
242 ：格之進 ◆xiPQGz7lVI ：2007/07/02(月) 01:19:15
>>241
うん。。いわゆるOOだなそれ、普通に。
うん。。いわゆるOOだなそれ、普通に。
>>243
じゃあ、ゲーム屋さんがアセンブラで組んでた頃からOOやってたって話も、まんざら嘘じゃないんだね？
じゃあ、ゲーム屋さんがアセンブラで組んでた頃からOOやってたって話も、まんざら嘘じゃないんだね？
>>246
飛躍しすぎだろ
飛躍しすぎだろ
>>220
ありがとう。Modernはtypelistでtree作ってくあたりでお腹いっぱいに…。
オブジェクト指向的に見ると、集合Aの中に集合Bがあって、
さらに集合Bの中に集合Aがあるわけでおかしくなりますね。
そういうわけで、単に実装の都合で、こういうクラスがでてくるのだと思います。
このクラスが必要になる簡単な例なんてないでしょうか？
ありがとう。Modernはtypelistでtree作ってくあたりでお腹いっぱいに…。
オブジェクト指向的に見ると、集合Aの中に集合Bがあって、
さらに集合Bの中に集合Aがあるわけでおかしくなりますね。
そういうわけで、単に実装の都合で、こういうクラスがでてくるのだと思います。
このクラスが必要になる簡単な例なんてないでしょうか？
>>248
うっせー。空気嫁
うっせー。空気嫁
250 ：格之進 ◆xiPQGz7lVI ：2007/07/02(月) 01:29:26
>>248
それは数学の集合の事かと、ついでにいうと数学的な集合でも、それを「指す物」であれば入れちゃっても問題ないですよ。
集合にはならくても領域(クラス)にはなるから。
例ですか、うーん、その前にもう少し理解が進まないと難しいかも。
boostのtype_traitsとか見て助走を付けてごらん、そのあとその使い方を想像してみるべし夢広がリングです。
それは数学の集合の事かと、ついでにいうと数学的な集合でも、それを「指す物」であれば入れちゃっても問題ないですよ。
集合にはならくても領域(クラス)にはなるから。
例ですか、うーん、その前にもう少し理解が進まないと難しいかも。
boostのtype_traitsとか見て助走を付けてごらん、そのあとその使い方を想像してみるべし夢広がリングです。
今の職場にいる限りはOOなんかまったく関係ないな
と思う今日この頃
と思う今日この頃
そらそうだOOPLを使っていなければ
255 ：仕様書無しさん：2007/07/02(月) 03:00:28
毎日毎日代わり映えしない自作自演ご苦労
256 ：仕様書無しさん：2007/07/02(月) 07:22:39
オブジェクト指向、って
「クラスライブラリ屋」だけがやってれば十分だと思う。
それを使うだけでいい側は手続き型っぽく書ければ十分じゃないか？
単発開発の案件なのに、抽象クラス作って継承してるの２つだけとか
全く足かせでしかない。
ライブラリそのものを売り物にでもしてなけりゃ
現実的には再利用性なんてYAGNIだよ。
「クラスライブラリ屋」だけがやってれば十分だと思う。
それを使うだけでいい側は手続き型っぽく書ければ十分じゃないか？
単発開発の案件なのに、抽象クラス作って継承してるの２つだけとか
全く足かせでしかない。
ライブラリそのものを売り物にでもしてなけりゃ
現実的には再利用性なんてYAGNIだよ。
計算機
>>256
なかなかの見識かと。
結果として再利用性のあるものを生産するためには、事実上、余計な工数がかかる。
OOの最大の売りは再利用性なのだが、
そんな「将来必要となるかも知れない」という再利用性なぞに工数はかけていられない。
正しい。正しいけど。再利用の夢を捨てきれない者にそれを理解させるのは(ry
なかなかの見識かと。
結果として再利用性のあるものを生産するためには、事実上、余計な工数がかかる。
OOの最大の売りは再利用性なのだが、
そんな「将来必要となるかも知れない」という再利用性なぞに工数はかけていられない。
正しい。正しいけど。再利用の夢を捨てきれない者にそれを理解させるのは(ry
259 ：仕様書無しさん：2007/07/02(月) 13:01:32
疎結合はOOだけが実現できる特性ではない
再利用がなければ最初の手間は無駄にしかならないのは確か。
それは数が多ければ多いほどに無視のできない差になる。
それでも私はオブジェクトを推したくなる。
理由がないのに推すのはただの信者でしかないがなww
それは数が多ければ多いほどに無視のできない差になる。
それでも私はオブジェクトを推したくなる。
理由がないのに推すのはただの信者でしかないがなww
不思議なのは、使わない奴らの不満の声。
不要だと思うのなら黙っておればよかろう。
不要だと思うのなら黙っておればよかろう。
264 ：仕様書無しさん：2007/07/02(月) 21:09:22
なんかのクラスを継承した時点で再利用じゃね?
>>264
正解
正解
266 ：仕様書無しさん：2007/07/02(月) 21:51:43
OOの再利用性を生かすべき場面は、
COBOLプログラマが言うところの「共通ライブラリ」じゃないかな
COBOLプログラマが言うところの「共通ライブラリ」じゃないかな
267 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/02(月) 21:56:18
ゲームでは「ギャラクシアン」（１９８２ごろ）に移動物体を Objectと言っていた。
回路図にもそう描いてあったし、プログラマーも「オブジェ」って呼んでた。
回路図にもそう描いてあったし、プログラマーも「オブジェ」って呼んでた。
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
最初から完全に設計しきって始めるか、
途中で必要に応じて粘土のようにクラスを変形させながら進めるか。
そのどちらかならうまくいく。
中途半端に設計して中途半端に手戻りを許さないスケジュールだったりするのが最悪。
途中で必要に応じて粘土のようにクラスを変形させながら進めるか。
そのどちらかならうまくいく。
中途半端に設計して中途半端に手戻りを許さないスケジュールだったりするのが最悪。
同意。FとかHとかNとかそんなんばっか。
オブジェクト指向に関するお勧めの書籍を教えれ。
>>274
いい加減秋田
いい加減秋田
再利用性を信じている香具師は勉強不足なのが丸出し。
感覚指向とか雰囲気指向の奴らにオブジェクト指向は無理がある。
278 ：仕様書無しさん：2007/07/02(月) 23:09:51
>>272
後者はデスマになるから止めとけ。
後者はデスマになるから止めとけ。
指向 ってのは誰がつけたんだ？
なんとか指向って言ってれば売れるご時勢なのか？
なんとか指向って言ってれば売れるご時勢なのか？
至高ってつけたのは海原雄山
違うよ
帝都新聞だよ
帝都新聞だよ
282 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/02(月) 23:44:48
>>5
前スレ825の意見は的外れだ。
ライブラリを使う側も、それらのライブラリを使ってアプリを作る事を考えれば、労力は似たような物だ。
また俺はOO万能だとは言っていない。OOは修正が少なく、速度を要求される物には向かないと言っている。
第一、OOの場合はライブラリと、クラスやアプリケーションの区切りは、作成者の任意になる。
ライブラリとアプリを区切っている段階で、825は構造化の人だと思われる。
OOを勉強するのが偉いとは言っていないが、OOをマスターしている人と、マスターしていない人がいたら、
他の条件が同じなら、マスターしている人の方が偉いだろう。
新人研修は俺の部下がやっているが、話を聞くと優秀な新人は数カ月でWEB-DBアプリを作る所まで来るらしい。
CよりJavaの方が習得も早いそうだ。やっぱり教え方と素直さが大切なんじゃね？
前スレ825の意見は的外れだ。
ライブラリを使う側も、それらのライブラリを使ってアプリを作る事を考えれば、労力は似たような物だ。
また俺はOO万能だとは言っていない。OOは修正が少なく、速度を要求される物には向かないと言っている。
第一、OOの場合はライブラリと、クラスやアプリケーションの区切りは、作成者の任意になる。
ライブラリとアプリを区切っている段階で、825は構造化の人だと思われる。
OOを勉強するのが偉いとは言っていないが、OOをマスターしている人と、マスターしていない人がいたら、
他の条件が同じなら、マスターしている人の方が偉いだろう。
新人研修は俺の部下がやっているが、話を聞くと優秀な新人は数カ月でWEB-DBアプリを作る所まで来るらしい。
CよりJavaの方が習得も早いそうだ。やっぱり教え方と素直さが大切なんじゃね？
>>272
インクリメンタル手法を思い違いしてるんじゃないか？
インクリメンタル手法を思い違いしてるんじゃないか？
284 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/03(火) 00:21:15
おじゃばのジョークは判りにくいんだよ
Simula〜、うしろ、うしろ
つまらんよ
どういう機能が再利用し易いか？
という定理みたいなもんがあるのかねぇ。
という定理みたいなもんがあるのかねぇ。
転職を頻繁に繰り返すなら簡単な名簿を毎回作り、
同じ会社に骨を埋めるのなら、最初に本格的なものを作り、
後から付け足していくのと同じ感覚で、、、
ってのはなんか誤解してるかなww
俺の頭の中では後者のような流れにオブジェクトと思ってるけど。
同じ会社に骨を埋めるのなら、最初に本格的なものを作り、
後から付け足していくのと同じ感覚で、、、
ってのはなんか誤解してるかなww
俺の頭の中では後者のような流れにオブジェクトと思ってるけど。
[オブジェクト指向]
戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。
戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。
全体をコーディネートする人がいないと、老舗旅館みたいになるよ。
どちらも逃げ出すのが大変ｗ
どちらも逃げ出すのが大変ｗ
292 ：仕様書無しさん：2007/07/03(火) 09:40:09
老舗旅館は宣伝さえうまくいけば
客は来るよ
客は来るよ
なお、C++とPythonでは二人の亀に乗る亀もおり（以下略）
>>287
抽象度が高いものほど再利用性も高い
抽象度が高いものほど再利用性も高い
設計やりきってから実装すればOKとかいってる奴
図とか自然言語で設計するのが
エディタ上でコード書きながら設計するのより速いわけないだろ
図とか自然言語で設計するのが
エディタ上でコード書きながら設計するのより速いわけないだろ
>>295
その「設計」は保守のための文書を残すための作業。
だから理論的にはその設計はリリース後でも良いのだが。
頭が古い人を納得させるのが大変 とか
文書を今作成しても間に合う とかの理由で(ry
そして言いにくいのだがｽﾚﾁｶﾞｲ
その「設計」は保守のための文書を残すための作業。
だから理論的にはその設計はリリース後でも良いのだが。
頭が古い人を納得させるのが大変 とか
文書を今作成しても間に合う とかの理由で(ry
そして言いにくいのだがｽﾚﾁｶﾞｲ
>>296
ｽﾚﾁｶﾞｲついでに聞くけど、設計に「その」とか「どの」とかあんの？
ｽﾚﾁｶﾞｲついでに聞くけど、設計に「その」とか「どの」とかあんの？
良く出来たフレームワークに乗っかるだけなら、実装ポイントのサンプルだけ見て、
「ああ、そういうものなんだ。」って思うだけで別に中身の機構について深く考える必要ないんじゃないか。
要するに、ドキュメントは実装ポイントのHOWTOだけ書いてあればよろし。
内部的な詳細はコメントで語れ。ドキュメントジェネレータが解する形式で。
「ああ、そういうものなんだ。」って思うだけで別に中身の機構について深く考える必要ないんじゃないか。
要するに、ドキュメントは実装ポイントのHOWTOだけ書いてあればよろし。
内部的な詳細はコメントで語れ。ドキュメントジェネレータが解する形式で。
家の設計図は柱の組み方も見ただけで分かるくらいに詳細に描くよ。
なのにプログラムの設計図はどうしてあんなにいいかげんなの？
なのにプログラムの設計図はどうしてあんなにいいかげんなの？
プログラムの設計図はソースコードだよ
バイナリが成果物
バイナリが成果物
>>300
支持なのだが。その正しい認識を獲得していない人がね。大杉
支持なのだが。その正しい認識を獲得していない人がね。大杉
ウェブサイトを家や本や雑誌に例えて批判するのがナンセンスなように、
プログラムを建築に例えて批判するのはナンセンスだ。
だいたいお金も納期も設計者も法整備も労働者に対する配慮も無いじゃないか。
プログラムを建築に例えて批判するのはナンセンスだ。
だいたいお金も納期も設計者も法整備も労働者に対する配慮も無いじゃないか。
設計っていうと、なんか唯一無二の正解がありそうな作業に感じる
デザインっていうことばをそのまま訳さずに使う方がいいとおもう
デザインっていうことばをそのまま訳さずに使う方がいいとおもう
>>300
スクリプト言語の場合はどうなるの?
スクリプト言語の場合はどうなるの?
305 ：格之進 ◆xiPQGz7lVI ：2007/07/03(火) 23:17:16
まあ、建築といっても、かまくらから高層ビルまで、
いろんなレベルのものがあるわけで、
必要とされる精度によって、設計図の精度も変わってくるのは当然でしょう。
かまくら作るときに、三面図作ったりしないように、
スクリプト言語で使い捨てのコードを書くのに、設計図はいらない。
いろんなレベルのものがあるわけで、
必要とされる精度によって、設計図の精度も変わってくるのは当然でしょう。
かまくら作るときに、三面図作ったりしないように、
スクリプト言語で使い捨てのコードを書くのに、設計図はいらない。
>>305
スクリプト言語で作り上げたweb上のお城も使い捨て？
スクリプト言語で作り上げたweb上のお城も使い捨て？
最近はフレームワークから自動で吐かれたスクリプトもあるからなあ。
そうなるとバイナリっつーか成果物の方に入ってしまうんじゃ？
そうなるとバイナリっつーか成果物の方に入ってしまうんじゃ？
そんなこといいだしたらC++のテンプレートとかどうなる？
>>308
オブジェクト指向って、設計理論じゃないの？
オブジェクト指向って、設計理論じゃないの？
少なくとも「理論」ではないだろ
>>311
それとコーディング＝設計と、どう関係ある？
それとコーディング＝設計と、どう関係ある？
314 ：格之進 ◆xiPQGz7lVI ：2007/07/03(火) 23:41:18
現状、ソースコード以上に厳密に簡潔に設計を表現できるものは存在しない。
LL言語なんか抽象度高いから特に自然言語の冗長性が顕著にあらわれて、
設計書書いててもいらいらする。直接コード書かせてくれと。
LL言語なんか抽象度高いから特に自然言語の冗長性が顕著にあらわれて、
設計書書いててもいらいらする。直接コード書かせてくれと。
複数人で作業の必要があるのならインターフェース合わせと振る舞いの概要さえ決めておけば済む話では無かろうか？
保守で必要なのは外部仕様とコメントだけな。
保守で必要なのは外部仕様とコメントだけな。
神は細部に宿る。
そして悪魔も細部に宿る。
ソースコードが設計書、というのは間違いではないが、
ソースだけで業務を把握することは不可能。
ソースに書いてあるのは実行結果が中心であり、
なんのためにその結果を求めるかは分からない。
という当たり前のことはおまぃら分かって喋ってんだよな？
ソースだけで業務を把握することは不可能。
ソースに書いてあるのは実行結果が中心であり、
なんのためにその結果を求めるかは分からない。
という当たり前のことはおまぃら分かって喋ってんだよな？
>>320
煽りたいだけの馬鹿を相手にしないのw
煽りたいだけの馬鹿を相手にしないのw
んだからドキュメントは概要と最低限の決め事だけでいいよって話。
コーダーにまわすなら細部までキッチリ書く必要あるんだろうけど。
コーダーにまわすなら細部までキッチリ書く必要あるんだろうけど。
２年生レベルだとそうなんだろうな
324 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/04(水) 00:31:17
UML書くのが好きな人っている？
いい加減めんどくさいんだよね
時間かかるし
いい加減めんどくさいんだよね
時間かかるし
モデリングセッションでホワイトボードに書き出した奴をデジカメでパチリとやればいいよ。
後はソースからリバースで吐き出してくれるツール使うとか。
後はソースからリバースで吐き出してくれるツール使うとか。
>>329が基本仕様と業務設計の違いを教えてくれるそうです
設計って、例えば飛行機の設計には、重心や揚力などの基本的な計算も含まれるんだけどね。
それを含めて、設計じゃね？
それを含めて、設計じゃね？
わかってないなあ
設計ってのは、やることを書くんじゃなくて、
やらないことをはっきりさせるのが重要なんだよ
設計ってのは、やることを書くんじゃなくて、
やらないことをはっきりさせるのが重要なんだよ
それを含めて、つかそれ普通に設計じゃね？
よくわからん
よくわからん
スペックとデザイン、って英語で書いた方が通りが良くなるから不思議だ。
もっとも日本ではデザインと書くと意匠を意味する事が多いが。
もっとも日本ではデザインと書くと意匠を意味する事が多いが。
なんのために＝要求
なにをやるか＝仕様
どうやってやるか＝設計
なにをやるか＝仕様
どうやってやるか＝設計
要するに俺らのやってる事はオブジェクト指向どうのこうのより前に工業ですら無いわけさ。
かといって著作業でもない。ふふふ。
かといって著作業でもない。ふふふ。
>>325
クラス図最高
クラス図最高
>>337
最高にいらん
最高にいらん
アセンブラで組んでた頃は、サブルーチンの総マシンサイクルや使用スタックサイズなんてぇのも要求されたもんだよ。
340 ：仕様書無しさん：2007/07/04(水) 01:17:11
>>338
詳細なインタフェース仕様書とかフロー書かされるよりマシだろｗ
詳細なインタフェース仕様書とかフロー書かされるよりマシだろｗ
>>335
「要求仕様設計書」なんてタイトルのドキュメントがあるとなんかドキドキするな。
「要求仕様設計書」なんてタイトルのドキュメントがあるとなんかドキドキするな。
345 ：仕様書無しさん：2007/07/04(水) 02:24:32
オブジェクト指向が嫌い、使いこなせない人は以下のどれかに５つ以上に当てはまる人である。
・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている人
・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている人
347 ：仕様書無しさん：2007/07/04(水) 02:41:58
・保守管理のコストより、実行時間などの動作コストの方がより重要だと感じている人
・後先を考えず、新しい物にすぐ飛びつく人
・旧来の物との整合性を検証しない人
・コーディングは○投げすれば良いと思っている人
・言語仕様をマスターしなくても開発できると思っている人
・その場しのぎのパッチワークに全く嫌悪感を感じない人
・世界は自分のために存在していると思っている人
・機能を全て使いたがる人
・機能を全て自分で作りたがる人
・自己に固い信念を持っていて絶対に変えられない人
・学校で覚えたことが死ぬまで使えると思っている人
・ポーランド記法を多用する人
・アルゴリズム、ロジックで全てを表現できると思っている人
・後先を考えず、新しい物にすぐ飛びつく人
・旧来の物との整合性を検証しない人
・コーディングは○投げすれば良いと思っている人
・言語仕様をマスターしなくても開発できると思っている人
・その場しのぎのパッチワークに全く嫌悪感を感じない人
・世界は自分のために存在していると思っている人
・機能を全て使いたがる人
・機能を全て自分で作りたがる人
・自己に固い信念を持っていて絶対に変えられない人
・学校で覚えたことが死ぬまで使えると思っている人
・ポーランド記法を多用する人
・アルゴリズム、ロジックで全てを表現できると思っている人
348 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/04(水) 03:11:54
オブジェクト指向を進める人、使いこなせていると自称する人は以下のどれかに５つ以上に当てはまる人である。
・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている
・整理整頓が苦手な人
・物事を秩序立てて考えることができない人
・役割分担が苦手で何でも抱え込もうとする人
・プロジェクトの全てを把握できる、覚えられる、など自分の力を過信している人
・計画的に物事を組み立てるのが苦手な人
・やたらと物事を結びつけたがる人
・協調性という言葉に関心のない人
・あえて汚い事に優越感の様な物を抱いている人
・人が嫌がるのを見て楽しめる人
・自分にしかできないといった様な事に生き甲斐を見いだしている人
・社会的なパーソナリティーに欠陥のある人
・楽天的で将来を考えていない人
・注意力に問題のある人
・上下の階層、グループという集合などに嫌悪感を持っている
なんかこの業界に多そうなのばかりだな。
350 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/04(水) 09:31:10
オブジェクト指向が苦手な人のほとんどは、以下の項目の3つ以上に当てはまる。
・構造化プログラミングに染まっている。
・思い込みが激しい。
・新しい事を覚えるのが苦手。
・構造化プログラミングに染まっている。
・思い込みが激しい。
・新しい事を覚えるのが苦手。
351 ：仕様書無しさん：2007/07/04(水) 09:40:48
オブジェクト指向プログラミングと構造化プログラミングは排他的じゃないよ
352 ：仕様書無しさん：2007/07/04(水) 09:51:45
ハッキリ言って電球が嫌い
電球は追い詰められると逃げるからなｗ
ライブラリ使うだけでもOOPの恩恵は受けられるだろ。
Cのライブラリで
corp_libname_namespace_verb_args(this, ...)
なんて関数がずらずら並んでるの見るとゲンナリする。
Cのライブラリで
corp_libname_namespace_verb_args(this, ...)
なんて関数がずらずら並んでるの見るとゲンナリする。
356 ：仕様書無しさん：2007/07/04(水) 12:49:42
>>346
＞そのままオブジェクト指向を推奨してる人の傾向じゃね？
まぁ、そもそも向いてない人が推奨してるからカオス化してるんじゃないかと。
普通、プログラミングをすればC言語でもオブジェクト指向のコードになっていく。
さすがに言語仕様がOOじゃないから完全なOOじゃないが。
良いプログラミングになればなるほど、OOに近づいていく。
移植性、保守性、論理性、可読性、再利用性、そういった物を考慮するとね。
＞そのままオブジェクト指向を推奨してる人の傾向じゃね？
まぁ、そもそも向いてない人が推奨してるからカオス化してるんじゃないかと。
普通、プログラミングをすればC言語でもオブジェクト指向のコードになっていく。
さすがに言語仕様がOOじゃないから完全なOOじゃないが。
良いプログラミングになればなるほど、OOに近づいていく。
移植性、保守性、論理性、可読性、再利用性、そういった物を考慮するとね。
357 ：仕様書無しさん：2007/07/04(水) 16:56:17
プログラミングの安全性を高めようとすると、柔軟性が無くなる。
逆に柔軟性を高めようとすると、安全性が無くなる。
で、その中間をとろうとすると、今度は人間がプログラムを読めなくなる。
何時解決する事やら…
逆に柔軟性を高めようとすると、安全性が無くなる。
で、その中間をとろうとすると、今度は人間がプログラムを読めなくなる。
何時解決する事やら…
あるある…orz
360 ：仕様書無しさん：2007/07/04(水) 19:05:20
粒
ではなくて
層
であると愚考するが
ではなくて
層
であると愚考するが
362 ：仕様書無しさん：2007/07/04(水) 20:06:10
継承、ポリモフィズム、再利用性、構造化、保守性……全てオブジェクト指向の恩恵ﾆﾀﾞ
OOマンセーなやつら、エディタ何使ってる？
365 ：格之進 ◆xiPQGz7lVI ：2007/07/04(水) 21:15:44
まあ、OOなんて手段だから、マンセーなんてありえないんだが。
いまんとこ、UMLとJavaでやってるけど、必要とあらば、
Cやアセンブラで非OOなプログラムも組むよ。
オブジェクト指向言語を使うなら、エディタは、
やはり継承関係を追えるようになっていないと、不便だね。
結局、単体のエディタよりも、Eclipse のような IDE を使うことになると思うよ。
いまんとこ、UMLとJavaでやってるけど、必要とあらば、
Cやアセンブラで非OOなプログラムも組むよ。
オブジェクト指向言語を使うなら、エディタは、
やはり継承関係を追えるようになっていないと、不便だね。
結局、単体のエディタよりも、Eclipse のような IDE を使うことになると思うよ。
OOなんて所詮どーでもいいんです。
癒し系(死語)の優しいおねぇたんと一緒に仕事できればシヤワセなんです。
所詮俺なんて・・・
癒し系(死語)の優しいおねぇたんと一緒に仕事できればシヤワセなんです。
所詮俺なんて・・・
と、いう意味で
SmalltalkのGoldbergおねたん
CLU/X WindowのLiskovおねたん
COBOLのAmazing Graceおねたん
この業界おねたんに事欠かないね♥
むさ苦しいおぢさんがひたすらジケーンする物性業界とは天と地ほど差がある・・・
SmalltalkのGoldbergおねたん
CLU/X WindowのLiskovおねたん
COBOLのAmazing Graceおねたん
この業界おねたんに事欠かないね♥
むさ苦しいおぢさんがひたすらジケーンする物性業界とは天と地ほど差がある・・・
麻酔たん＠Appleの富豪的プログラミングの次は
やっぱ癒し系プログラミングだろ
やっぱ癒し系プログラミングだろ
いま、組んでるプログラムは全部void*なんだけどすげー見易いし、わかりやすい
つ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();
};
どっちを進化させても、もう片方に近づくことはない。
最初の設計思想が違う。
C言語でもオブジェクト指向になる？
ならないだろう。C言語でクラスを自作するのは大変だぞ。
構造化の良いソースとOOの良いソースは、モジュールの分割単位が全く違う。縦切りと横切りぐらい違う。
例えば電卓をクラス化するとしよう。
構造化の人はこう組む。
class Computer{
public:
int compute(string stmt);
};
OOの人はこう組む。
class Computer{
public:
void push0();
void push1();
void push2();
:
int getAnswer();
};
どっちを進化させても、もう片方に近づくことはない。
最初の設計思想が違う。
push0なんてメソッド書きやがる人は(´･д･`) ﾔﾀﾞ
おじゃばはネタなのか、釣りなのか、天然の愚図なのか。
だいたいGUI部分と電卓の計算機の部分がいっしょになってるのが納得いかねぇ
手持ちの電卓分解してみろといいたい
っていうかちゃんと仕組みまで再現しろよ
そこで電卓を電卓たるように具現化するに一番いい簡略化をしろよ
センスが感じられないｗ
手持ちの電卓分解してみろといいたい
っていうかちゃんと仕組みまで再現しろよ
そこで電卓を電卓たるように具現化するに一番いい簡略化をしろよ
センスが感じられないｗ
かなしいけれど、おじゃばの底力を見た気がしたｗ
・・・つ、釣られないぞ
378 ：sage：2007/07/04(水) 23:02:51
「例えば電卓」だ？電卓なめんなよ。
俺がこの間買った電卓、[2][0][0][+][2][0][%]って感じで押すと
200に20%増しで「240」って表示されるぞ。
あと[1][0][×][2][=] で「20」と表示された後[5][=]と押すと「50」って出る。
どうやら「10×」までの部分が記憶されてるらしい。
そんな機能あること20になるまで知らなかったぞ。
俺がこの間買った電卓、[2][0][0][+][2][0][%]って感じで押すと
200に20%増しで「240」って表示されるぞ。
あと[1][0][×][2][=] で「20」と表示された後[5][=]と押すと「50」って出る。
どうやら「10×」までの部分が記憶されてるらしい。
そんな機能あること20になるまで知らなかったぞ。
電卓を設計するとなりゃ
とりあえず内部の計算機の部分と外のケース（電卓）の部分にわけるだろ？
電卓クラス（液晶パネル、ボタン、計算機の関連を制御）
液晶パネルクラス（数字を表示する。計算機の表示レジスタを画面に反映。）
ボタンクラス（自分の記号がなんであるか知っている、ユーザの押下を検出。）
計算機クラス（表示レジスタと計算クラスの関連を制御）
表示レジスタクラス（ここにぶち込まれたものが表示される）
計算クラス（入力された文字列を解析→計算し、結果、経過を返す。
文字列は電卓クラスから計算機クラスを通して渡される。
押されたボタンの記号が文字列をして流れてくる。例：「１＋１＝」←これが文字列）
即興だがこんな感じでどうだろうか？
とりあえず内部の計算機の部分と外のケース（電卓）の部分にわけるだろ？
電卓クラス（液晶パネル、ボタン、計算機の関連を制御）
液晶パネルクラス（数字を表示する。計算機の表示レジスタを画面に反映。）
ボタンクラス（自分の記号がなんであるか知っている、ユーザの押下を検出。）
計算機クラス（表示レジスタと計算クラスの関連を制御）
表示レジスタクラス（ここにぶち込まれたものが表示される）
計算クラス（入力された文字列を解析→計算し、結果、経過を返す。
文字列は電卓クラスから計算機クラスを通して渡される。
押されたボタンの記号が文字列をして流れてくる。例：「１＋１＝」←これが文字列）
即興だがこんな感じでどうだろうか？
物理的な構造を真似ても意味が無いだろw
いったいどこまでここはネタスレなんだかw
いったいどこまでここはネタスレなんだかw
テラカオスｗ
>>380
>物理的な構造を真似ても意味が無いだろ
俺はあると思うぜ
眼に見えるものだから相手との認識が一致しやすい
絵に書いて見せるから相手を理解させやすい
そういうもんだと思うぜ
多分、王道は無いと思うんだ。俺は。
>物理的な構造を真似ても意味が無いだろ
俺はあると思うぜ
眼に見えるものだから相手との認識が一致しやすい
絵に書いて見せるから相手を理解させやすい
そういうもんだと思うぜ
多分、王道は無いと思うんだ。俺は。
じゃあ、本体の裏蓋止めるネジや、電池、・・・ああ、ソーラー電卓なら太陽電池も必要だよ。
おまいら本当に電卓のＯＯもできないのん？
おなはなしにならない。
おなはなしにならない。
>>383
だから、大事なものだけ
相手を理解させるために必要なものだけ選定する作業が必要になる
自分が必要だと思うものを強引にこじつける能力だと思うんだよね
俺は
例えば電卓だって座標が必要になれば俺は外枠のケースをクラスにして座標をもたせるとかするよｗ
だから、大事なものだけ
相手を理解させるために必要なものだけ選定する作業が必要になる
自分が必要だと思うものを強引にこじつける能力だと思うんだよね
俺は
例えば電卓だって座標が必要になれば俺は外枠のケースをクラスにして座標をもたせるとかするよｗ
ＯＯは本質を抽象化するのだよ。
俺もよく帰りの電車とかで
色んなものをオブジェクト指向で設計してみたりするけどな
カツラを髪の毛の派生にするか、帽子の派生にするかでかなり悩んだが
色んなものをオブジェクト指向で設計してみたりするけどな
カツラを髪の毛の派生にするか、帽子の派生にするかでかなり悩んだが
細かいこと言い出したらボタンにだって座標・縦横サイズが必要だしね
意外と外れて無いぜ
ネジははめ込み式のケースなのでないｗ
意外と外れて無いぜ
ネジははめ込み式のケースなのでないｗ
電卓なんて、
入力 → 計算 → 出力
この３っつのクラスで十分。
入力 → 計算 → 出力
この３っつのクラスで十分。
そうさ、おまいらが持つセンスの本質をブースとするのがＯＯさ。
電卓の本質はインタープリタだよ。
>>391
そういうのあったなぁｗ
そういうのあったなぁｗ
新入社員向け課題としての「電卓」をマジで分類すると：
HP関数電卓： Forthインタプリタを核にスタックマシンを構成
CASIO電卓： Forthインタプリタに中置演算子プリプロセッサを追加
数式電卓： プログラミング言語の数式パーサにアクション記述。
暇があったらスクリプト言語で数式処理機能(微積分、数式簡約化等)を追加。
多項式イデアルの表現方法に迷い、課題提出期限に間に合わず入社３ヶ月で退社。
って感じかな。
10年位前に調べた所では、多項式イデアルの最適な表現方法やら、
広範囲に適用可能な数式の簡約化方法ってなんか難しいテーマらすぃ。
そしてそのレベルで悩める達人ならば、OOなんてお茶の子なんじゃないかな。
HP関数電卓： Forthインタプリタを核にスタックマシンを構成
CASIO電卓： Forthインタプリタに中置演算子プリプロセッサを追加
数式電卓： プログラミング言語の数式パーサにアクション記述。
暇があったらスクリプト言語で数式処理機能(微積分、数式簡約化等)を追加。
多項式イデアルの表現方法に迷い、課題提出期限に間に合わず入社３ヶ月で退社。
って感じかな。
10年位前に調べた所では、多項式イデアルの最適な表現方法やら、
広範囲に適用可能な数式の簡約化方法ってなんか難しいテーマらすぃ。
そしてそのレベルで悩める達人ならば、OOなんてお茶の子なんじゃないかな。
電卓はインタープリタなので構文解析も必要なのさ。
おまいらにはちと難かったか。すまん。
おまいらにはちと難かったか。すまん。
>>392
あのな、実物の電卓だって、ボタンと石（集積回路）と液晶だけしかないっつうの。
あのな、実物の電卓だって、ボタンと石（集積回路）と液晶だけしかないっつうの。
>>391で正しいと思う
インタープリタって言葉の意味を、よーく考えてみないといけない
インタープリタって言葉の意味を、よーく考えてみないといけない
ってなテーマは、ここ２ちゃんでも狸系カテ趣味板に行けばやってる。
・・・OO議論するなら、それくらい押さえとけよな。
・・・OO議論するなら、それくらい押さえとけよな。
結論から言うと、電卓で表層の部品しか見えない香具師にはＯＯは無理って言うこと。
じゃ、おやすみ。
じゃ、おやすみ。
同じように、オセロで石が見える香具師もＯＯは無理。
ポットで水が見える香具師も上に同じ。
ポットで水が見える香具師も上に同じ。
昔、５万円ぐらいした電卓（ポケコン？）って何ができてあんなに高かったの？
ＯＯは万人には無理な概念なのさ。
ああ、でもな
入力、処理 出力
この３っつは、全ての基本クラスだ。
入力、処理 出力
この３っつは、全ての基本クラスだ。
いやむしろ俺は「インタプリタ」って概念を知ってるからこそ
電卓がインタプリタである、と考えることができるんだと思う
つまり、実物を「既に知っている概念」に押し込めることで扱いやすくする。
オブジェクト指向とはそういう技術。
電卓がインタプリタである、と考えることができるんだと思う
つまり、実物を「既に知っている概念」に押し込めることで扱いやすくする。
オブジェクト指向とはそういう技術。
オブジェクト指向、ってくくりで話してるけど
クラス指向とプロトタイプ指向で大きく違うと思うんだけど。
クラス指向とプロトタイプ指向で大きく違うと思うんだけど。
>>403
あたりまえだけど、この概念は強力すぎて香具師には活用できないよ。
あたりまえだけど、この概念は強力すぎて香具師には活用できないよ。
>>403
ライトセーバーと同様に強力すぎてマスタ以外には使いこなせない。
ライトセーバーと同様に強力すぎてマスタ以外には使いこなせない。
原則、このスレのオブジェクト指向＝クラス指向のことでいいだろ。
>>404
なんだ、OOで電卓するにはインタプリタ知識が必要、でおしまいか。
俺は数式処理からベンキョして、関数型言語逝って、
「現場向け実用パラダイム」としてOOやったから、
努力足りない奴に「OOの研究者にしか判らない理屈を言うな」とか言われると
すんげぇムカつく。
なんだ、OOで電卓するにはインタプリタ知識が必要、でおしまいか。
俺は数式処理からベンキョして、関数型言語逝って、
「現場向け実用パラダイム」としてOOやったから、
努力足りない奴に「OOの研究者にしか判らない理屈を言うな」とか言われると
すんげぇムカつく。
>>409
日本語でｒｙ
日本語でｒｙ
・入出力
・データ
・処理
ってクラス構成もあると
・データ
・処理
ってクラス構成もあると
おまいら本当にＯＯの勉強してるのかぁ？
レベル低すぎないか。
レベル低すぎないか。
だいたい「OOの研究者」なんて今時いねぇだろ。
10年前なら分散オブジェクトの未来形としての「エージェント指向」、
10〜5年前ならポストOO的テーマの一つとして「アスペクト指向」
とかあったわけだが、今だと
・OOを教育目的として使ったり
・OOを含む、ソフトウェア/システム開発上の諸問題を
CMU SEI的観点から研究
みたいなんじゃねぇの。
10年前なら分散オブジェクトの未来形としての「エージェント指向」、
10〜5年前ならポストOO的テーマの一つとして「アスペクト指向」
とかあったわけだが、今だと
・OOを教育目的として使ったり
・OOを含む、ソフトウェア/システム開発上の諸問題を
CMU SEI的観点から研究
みたいなんじゃねぇの。
超お勧めのＯＯ本があるけど教えてやろうか？
エージェント指向はどっかいった
アスペクト指向はJavaドカタの必需品
アスペクト指向はJavaドカタの必需品
頭のおかしい人がきちゃった
きちたぁ
やヴぁいみんなにげｒ
今日からは、オブジェクティブエージェンタブルアスペクト指向で行こう
計算機をインタプリタとして扱うのは>379のオマケみたいなもんで
本質はそこじゃないだろｗ
本質はそこじゃないだろｗ
422 ：仕様書無しさん：2007/07/04(水) 23:47:31
やばくなると相手を中傷って、こいつおじゃば？
>>421
またまた俺様解釈か？
またまた俺様解釈か？
ここのスレにトグロしてる人って、
「日本最初のOO専業コンサル会社」の創始者？
ちょっと信じがたい雑言ばっかだな。
「日本最初のOO専業コンサル会社」の創始者？
ちょっと信じがたい雑言ばっかだな。
じゃあインタプリタのクラス設計やるよ！
・入力
・トークン抽出
・辞書
・コマンド
・レジスタ
・出力
・電池
・太陽電池
・ネジ
・ふた
・バックライト
あとは？
・入力
・トークン抽出
・辞書
・コマンド
・レジスタ
・出力
・電池
・太陽電池
・ネジ
・ふた
・バックライト
あとは？
アミダのトグロでデッドローック攻撃！
電卓の本質はインタプリタである。
>>421
本質が見いだせないＯＯ不適格者。
本質が見いだせないＯＯ不適格者。
電卓の本質は数式処理である。
数式とは、OOとは異なる、より精緻なモデリング技法である。
従って、OOによる電卓モデリングなどというものは、
「ダイヤブロックでDNA模型を作りますた」程度の児戯に過ぎない。
数式とは、OOとは異なる、より精緻なモデリング技法である。
従って、OOによる電卓モデリングなどというものは、
「ダイヤブロックでDNA模型を作りますた」程度の児戯に過ぎない。
>>429
それは本質ではなく実質。
それは本質ではなく実質。
むしろOOのメリットは「萌えプログラミング」にある。
ぬるぽたんハァハァ
ORまっぴんぐたん萌え萌え
ぬるぽたんハァハァ
ORまっぴんぐたん萌え萌え
>>425
それは機能抽出？
それは機能抽出？
>>433
素直になって勉強し直そう。素直が一番。がんばれ。
素直になって勉強し直そう。素直が一番。がんばれ。
このスレの本質： かみ合わない議論を延々続ける社会不適応者のオナーニ
ＯＯは実質ではなく、本質を抽象化してインターフェースする技術なのだ。
そろそろ殺伐としてきました
頭がおかしい人をからかうのって、意外とつまんねえな。
何を言っても反応がワンパターン。
何を言っても反応がワンパターン。
439 ：仕様書無しさん：2007/07/04(水) 23:59:54
GUIクラス
ボタン配置等
数字
一桁シフトして数字レジスタに値を格納
ファンクション
計算クラスに値を渡す
数字レジスタ
数字を記憶
計算クラス
計算の関数を格納
数字レジスタの値を計算
こんな設計でどう？
ボタン配置等
数字
一桁シフトして数字レジスタに値を格納
ファンクション
計算クラスに値を渡す
数字レジスタ
数字を記憶
計算クラス
計算の関数を格納
数字レジスタの値を計算
こんな設計でどう？
じゃあなにかい？
Windows付属の電卓ソフトはOOじゃ表現できないってえのかい？
Windows付属の電卓ソフトはOOじゃ表現できないってえのかい？
多項式イデアル萌え
数式処理をOOで実装しようというなら、
まずは多項式イデアルのデータ構造の議論から始めないとダメでしょ。
まずは多項式イデアルのデータ構造の議論から始めないとダメでしょ。
ＯＯはこのようにセンスをブーストするので
レベルの差がハッキリしすぎて、教えてやっても逆切れされてしまう悲しい技術なのです。
レベルの差がハッキリしすぎて、教えてやっても逆切れされてしまう悲しい技術なのです。
多項式イデアルのデータ構造を検討するには、まず
非多項式時間で処理可能な数式簡約化アルゴリズムを検討せねば・・・
非多項式時間で処理可能な数式簡約化アルゴリズムを検討せねば・・・
>>445
10年位前だと、ホロノミック基底がよさそうってな話になってたね
10年位前だと、ホロノミック基底がよさそうってな話になってたね
計算クラスで四則計算からなにからを派生クラスとして作成して、
ボタン操作から意味抽出されたパラメータを取り出すクラスから呼び出すって感じ？
ボタン操作から意味抽出されたパラメータを取り出すクラスから呼び出すって感じ？
448 ：仕様書無しさん：2007/07/05(木) 00:06:29
>>444
記憶クラスにしようかなと最初思ったけど、
電卓だから単なるグローバル変数でも良いかなと思った。
でも一応、レジスタという名前で小ささをアピールしてクラス化したｗ
あ。もし、億とか兆とか無量大数まで
計算させる場合はこの方が都合が良いかｗ
記憶クラスにしようかなと最初思ったけど、
電卓だから単なるグローバル変数でも良いかなと思った。
でも一応、レジスタという名前で小ささをアピールしてクラス化したｗ
あ。もし、億とか兆とか無量大数まで
計算させる場合はこの方が都合が良いかｗ
生意気な若い人の論文によれば(
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を作ることであるはずだが まだまだ道は遠い。
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を作ることであるはずだが まだまだ道は遠い。
なんだか、設計というのが物事を単純化させる作業ということ真逆な方向に行ってるねぇ
電卓など所詮初心者プログラミング課題。
現時点において、一流のプログラマ兼マセマティシャンが
本当に解くべき最前線というのは、
例えば数式処理システムを本質的に進化させる数学的アルゴリズムの探索である。
現時点において、一流のプログラマ兼マセマティシャンが
本当に解くべき最前線というのは、
例えば数式処理システムを本質的に進化させる数学的アルゴリズムの探索である。
453 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 00:13:46
なんだ数式処理って？
コンピューターを計算に使ってるやつなんかほとんどいないぞ
コンピューターを計算に使ってるやつなんかほとんどいないぞ
新着レス 2007/07/05(木) 00:14
453 名前： あぼ〜ん [あぼ〜ん] 投稿日： あぼ〜ん
あぼ〜ん
453 名前： あぼ〜ん [あぼ〜ん] 投稿日： あぼ〜ん
あぼ〜ん
455 ：仕様書無しさん：2007/07/05(木) 00:15:14
時々思うんだけど、業務システムとかは単純な加減乗除と
データのコピーしかやってないんだよね。
それに特化したアーキテクチャのCPU・OS・システムを
組んだ方が効率がいいんじゃないかと時々思う。
データのコピーしかやってないんだよね。
それに特化したアーキテクチャのCPU・OS・システムを
組んだ方が効率がいいんじゃないかと時々思う。
ヒント： それに特化したアーキテクチャのCPU・OS・システムは、
ホラリス統計機〜汎用機〜オフコン として知られている
ホラリス統計機〜汎用機〜オフコン として知られている
Wヒント： 有能な人間は、業務システムなどという単純作業には我慢できない。
「複雑な計算」の例が３Dゲームとは
とんだ底辺プログラマだな
とんだ底辺プログラマだな
すげーｗおじゃば大量だぜｗ
業務システムとか３Dゲームなんてのは、
有能な人間が取り組む重要なテーマ (遺伝子解析、地球環境シミュレーション、etc.)
の補助となる計算チップ/計算システムを構築するためのスポンサー的存在に過ぎんだろｗ
つまり、PCやゲーム機のCPUの処理能力が、何故不必要に高いか、って話なわけだが、
あれは要するに並列計算機をコストダウンするためなんだよね
有能な人間が取り組む重要なテーマ (遺伝子解析、地球環境シミュレーション、etc.)
の補助となる計算チップ/計算システムを構築するためのスポンサー的存在に過ぎんだろｗ
つまり、PCやゲーム機のCPUの処理能力が、何故不必要に高いか、って話なわけだが、
あれは要するに並列計算機をコストダウンするためなんだよね
数式処理の話しても、いつものパターンで流そうとする
低脳っぷりに爆笑した
やっぱバカはバカだなぁ〜
低脳っぷりに爆笑した
やっぱバカはバカだなぁ〜
465 ：仕様書無しさん：2007/07/05(木) 00:36:05
466 ：仕様書無しさん：2007/07/05(木) 00:36:39
>>462
というか、ゲームが大好きな奴らが集まって何にでも使える
一般家電的なコンピューターを作ってたら、誰も予想しなかったくらい
滅茶苦茶に高性能化したので、こっちに全部ブッ込んじまえば良いや的な
流れで今があるんだよ。
結局、進化の過程のいびつさが言語仕様に反映されてて、
エレガントで直感的じゃないってのも嫌われる理由の一つにあるのか？
というか、ゲームが大好きな奴らが集まって何にでも使える
一般家電的なコンピューターを作ってたら、誰も予想しなかったくらい
滅茶苦茶に高性能化したので、こっちに全部ブッ込んじまえば良いや的な
流れで今があるんだよ。
結局、進化の過程のいびつさが言語仕様に反映されてて、
エレガントで直感的じゃないってのも嫌われる理由の一つにあるのか？
それをいっちゃ、所詮コンピュータの面倒を見るだけの使用人ですからねぇ それだけの事ですよ。
簡単な話題になるとレスをたくさん付ける人がいるねｗ
で、数式処理って、只の記号処理なんだよね？
コンパイラがオプティマイズかけるようなもんさ。
コンパイラがオプティマイズかけるようなもんさ。
こんなにも「無理」「無理」と言われるOOを学習する意味あるのか？
ただでさえ人材が少ないのに、
OO「無理」なやつらばかりじゃ仕事にならんだろ
ただでさえ人材が少ないのに、
OO「無理」なやつらばかりじゃ仕事にならんだろ
OOが無理なんじゃなくって、分散開発でOOとか無理な事やってるのが悪い。
フィルタ。
OOくらい齧らないで、「人材」たりえんのじゃないか？
>>466
また知ったかか。無理すんなよ。
cellチップの共同開発は、次世代マルチコアCPUの開発費捻出に困ったIBMの苦肉の策だし、
GPUの当初目的は、スパコンの計算速度とデータ量に見合った、データ可視化装置
(サイエンティフィック・ビジュアリゼーションWS)の実現にある。
要するに、有能な人が使う道具を限られた予算で実現し発展させていくために、
一般大衆向けの大量生産品とのコラボレーションが行われたって事。
そしてもっと素晴らしいのは、その「有能な人のための道具」が充分安価に提供された事で
第三世界の研究者や学生であっても、有能ならばそれを本来の目的で使いこなせる時代になったって事。
業務システムでひぃひぃ言うレベルの人には無関係だけどねｗ
また知ったかか。無理すんなよ。
cellチップの共同開発は、次世代マルチコアCPUの開発費捻出に困ったIBMの苦肉の策だし、
GPUの当初目的は、スパコンの計算速度とデータ量に見合った、データ可視化装置
(サイエンティフィック・ビジュアリゼーションWS)の実現にある。
要するに、有能な人が使う道具を限られた予算で実現し発展させていくために、
一般大衆向けの大量生産品とのコラボレーションが行われたって事。
そしてもっと素晴らしいのは、その「有能な人のための道具」が充分安価に提供された事で
第三世界の研究者や学生であっても、有能ならばそれを本来の目的で使いこなせる時代になったって事。
業務システムでひぃひぃ言うレベルの人には無関係だけどねｗ
>>471
適性のない人材も確かに存在するが、
彼らは学習してもダメなのか、学習していないだけかが不明だし。
「OO」って単語をオブジェクト指向と読みかえることができる奴が
どれほどいるのか怪しいし。
不勉強というよりも分野が多すぎてノータッチってのが多そう。
適性のない人材も確かに存在するが、
彼らは学習してもダメなのか、学習していないだけかが不明だし。
「OO」って単語をオブジェクト指向と読みかえることができる奴が
どれほどいるのか怪しいし。
不勉強というよりも分野が多すぎてノータッチってのが多そう。
>>470
只の記号処理じゃないことって、この世に存在するの？
只の記号処理じゃないことって、この世に存在するの？
バカスレ
このスレの住人て、なんでこんなにレベル低いの？
高校生？
高校生？
>>479
なら、正解だろ？ それで？
なら、正解だろ？ それで？
中学生もいますよー
結局自作自演がメインだから、自作自演者のレベルがスレに如実に現れるニョロ
オマイが先に言ったんだからな！
OOよりもガーデニング検定がんばった方がよさげ
このスレの住人の割合
このスレが100人の村とすると・・・
C言語を理解： 約３名
じゃわ言語を理解： 約２名
構造化プログラミング命： 約１.5名
OO命： 約1.5名
その他：
こんなスレなどどーでもいいと思っている： 97名
このスレが100人の村とすると・・・
C言語を理解： 約３名
じゃわ言語を理解： 約２名
構造化プログラミング命： 約１.5名
OO命： 約1.5名
その他：
こんなスレなどどーでもいいと思っている： 97名
５人侵入者がいるな
>>489
１００人もいないろ
１００人もいないろ
まぁ実際書き込んでるのは３人がいいとこだな
じゃ、番号！
１！
１！
俺はこのスレほとんど来ないんだけど。
このスレ毎日50〜100レス単位で伸びてるな。
もしかしてたった２人で会話してんの？
一人で自作自演の可能性もあるな
このスレ毎日50〜100レス単位で伸びてるな。
もしかしてたった２人で会話してんの？
一人で自作自演の可能性もあるな
こんなかんじ？
学生×1
ドカタ×1〜2
ヒキ×1
学生×1
ドカタ×1〜2
ヒキ×1
>>494
おまえと俺とで、２人は確実だ。
おまえと俺とで、２人は確実だ。
かみ合ってない会話ばっかで、自演はなさげ
結論：ヒキ学生ときどきドカタが一名で回しているスレ
>>499
ほー。わざとかみ合わない会話を自作自演してるだけじゃんお前
ほー。わざとかみ合わない会話を自作自演してるだけじゃんお前
退屈な人の退屈なスレ
寝る
寝る
なんのためのわざとだよｗ
で、おまいら、オブジェクト指向の方は、理解出来たのか？
まだやってたんかｗｗｗｗ
中身ゼロだな、ここ
507 ：仕様書無しさん：2007/07/05(木) 01:13:28
ああ。俺分かっちゃった。
（3D以外のゲームプログラミングに）OOは要らない。
（もの凄くハードウェア寄りの組み込み開発に）OOは要らない。
いや、（業務システム開発には）OOが必須。
と延々やってるんだと。
（3D以外のゲームプログラミングに）OOは要らない。
（もの凄くハードウェア寄りの組み込み開発に）OOは要らない。
いや、（業務システム開発には）OOが必須。
と延々やってるんだと。
insert01
select02
select03
・
・
・
こんなクラス設計やっちゃうみかかが年金システムか
select02
select03
・
・
・
こんなクラス設計やっちゃうみかかが年金システムか
1. 業務システムは奴隷に任せとけばおｋ
その中身がOOかOOじゃないか、などという仔細な問題に拘る必要なない
2. 奴隷じゃない人は、もっと有意義なテーマを志しましょう
3. このスレ終了
その中身がOOかOOじゃないか、などという仔細な問題に拘る必要なない
2. 奴隷じゃない人は、もっと有意義なテーマを志しましょう
3. このスレ終了
業務と言う観点から見たら
結局、出来上がればいいんだろ？
と言う人から、
美しいコード、美しいロジック（自称）を追求する奴の差なんて
ほとんど無い。
と書く事さえ意味が無い。
何が言いたいかというと、設計技法、プログラミング技法を
どうやって習得するかの話題が先ではないのかと思う。
結局、出来上がればいいんだろ？
と言う人から、
美しいコード、美しいロジック（自称）を追求する奴の差なんて
ほとんど無い。
と書く事さえ意味が無い。
何が言いたいかというと、設計技法、プログラミング技法を
どうやって習得するかの話題が先ではないのかと思う。
というか、業務やってる連中はOO理解してないヤツばっかだから
一人でOO設計しててもかなり空しい
「何いかにもC++知ってますみたいなコード書いてんの？ｗ」みたいな
一人でOO設計しててもかなり空しい
「何いかにもC++知ってますみたいなコード書いてんの？ｗ」みたいな
以前、バリバリなフレームワークをJava, Perl, C++の三つで書いたら、
「うん、彼のコードはなかなか綺麗だよ」って軽く流されてめげた。
ちなみにその発言者は、自作オプソのメンテをRuby作者に任せたっつーその筋の人だったりする・・・
「うん、彼のコードはなかなか綺麗だよ」って軽く流されてめげた。
ちなみにその発言者は、自作オプソのメンテをRuby作者に任せたっつーその筋の人だったりする・・・
そいえばRuby作者っていえば、ObjectStoreのためのGCシステム開発もしてんだよね。
・・・俺はObjectStoreはパスしたな〜。ORマッピングの方が気になってたし。
意外とMatzと同じような経歴をたどってたにも関わらず、現在では(ピー)な俺・・・・
・・・俺はObjectStoreはパスしたな〜。ORマッピングの方が気になってたし。
意外とMatzと同じような経歴をたどってたにも関わらず、現在では(ピー)な俺・・・・
>>516
きみのあたまの中身はお花畑だという事を理解した
きみのあたまの中身はお花畑だという事を理解した
オブジェクト指向って名前をどーにかしないとな。
めんどいから Java言語標準設計論 とかにすりゃあいい
略して ジャバロン！！！！だせーー！！！
めんどいから Java言語標準設計論 とかにすりゃあいい
略して ジャバロン！！！！だせーー！！！
520 ：仕様書無しさん：2007/07/05(木) 01:27:55
>>476
それってかなり大昔の話でしょ。
五インチフロッピーが全盛くらいの。
それと今の状況は全く違うと思うよ。
パラダイムシフトは95年辺りだよ。
それまではワークステーションはUNIXだったが、
Windowsが使えるレベルになったのでx86が台頭してきた。
それってかなり大昔の話でしょ。
五インチフロッピーが全盛くらいの。
それと今の状況は全く違うと思うよ。
パラダイムシフトは95年辺りだよ。
それまではワークステーションはUNIXだったが、
Windowsが使えるレベルになったのでx86が台頭してきた。
今更OOにこだわりを持つよりも
今扱うべきテーマはRonR with Agileだたーりして
今扱うべきテーマはRonR with Agileだたーりして
>>520
おじゃば発見
おじゃば発見
OOｲﾗﾈつって、じゃあ関数型やるか？っていったら
よけい誰もやらねえだろうしなあ。
よけい誰もやらねえだろうしなあ。
構造化を突き詰めると当たり前のようにOOになるんだから、別に名前なんて無くてもいいよ。
526 ：仕様書無しさん：2007/07/05(木) 01:29:22
>>526
JSPとかぶるし、ジャバロンの方が耳に残るｗ
JSPとかぶるし、ジャバロンの方が耳に残るｗ
宿題スレに宿題丸投げしてるような学生が行き着くところかｗ
学生がやってもしゃあねえべ
>>527
むしろ今までの方が変だよね。
学生時代に論理型言語や関数型言語で研究テーマこなしてた
プログラミング好きな学生(修士含む)が、
プログラミングが好きだから現場指向の会社に行くと
途端にCだJavaだCOBOLだって低レベルな言語やらされる無駄
むしろ今までの方が変だよね。
学生時代に論理型言語や関数型言語で研究テーマこなしてた
プログラミング好きな学生(修士含む)が、
プログラミングが好きだから現場指向の会社に行くと
途端にCだJavaだCOBOLだって低レベルな言語やらされる無駄
現場でやってもしゃーねーべ T T
学生がやってもしゃあねえだろ
つかそういう意味ではOOやる学生だっているだろ
つかそういう意味ではOOやる学生だっているだろ
言語なんて出来て当たり前でしょ
OOは必要性が問われないから、出来ない奴が多いだけで、
必要性が問われれば学習する奴も増えるでしょ
OOは必要性が問われないから、出来ない奴が多いだけで、
必要性が問われれば学習する奴も増えるでしょ
>>520
お花畑ちゃんにマジレス
1995がパラダイムシフト？はぁ？
1995頃、まともに使い物になるOpenGLマシンつうと、
DEC Alpha載せたWS/Windowsマシンしか見当たらなかったよ。
そりゃ、CADとかライトな目的ではIntelマシンも使われてたけどね（HAHAHA
cellに至っては、21世紀に入ってからだろ（PUPUPU
お花畑ちゃんにマジレス
1995がパラダイムシフト？はぁ？
1995頃、まともに使い物になるOpenGLマシンつうと、
DEC Alpha載せたWS/Windowsマシンしか見当たらなかったよ。
そりゃ、CADとかライトな目的ではIntelマシンも使われてたけどね（HAHAHA
cellに至っては、21世紀に入ってからだろ（PUPUPU
カプンコがPS3のゲームエンジン開発者募集してるよ。
大阪だけど。
大阪だけど。
Cellのミドルウェア開発やってみてーな
先週、求職で某研究所逝ったら、
下請けが「さんそうけん」というソフトウェア会社だと言われた。
俺の役目は、顧客とそのソフトウェア会社の中継ぎ。
聞いた事ねぇソフトハウスだなぁ〜って言ったら、・・・
ってなレベルの俺様が降臨しましたよ〜
下請けが「さんそうけん」というソフトウェア会社だと言われた。
俺の役目は、顧客とそのソフトウェア会社の中継ぎ。
聞いた事ねぇソフトハウスだなぁ〜って言ったら、・・・
ってなレベルの俺様が降臨しましたよ〜
爽健美茶が出てきて吹いたｗ
うん、よく似た名前のハードウェア系ベンチャーがあってね、
俺はうっかりそこの事だと思ったわけよ。
そしたら「産総研」だって。「下請け」つったのは性質の悪いジョーク。
顧客は国内トップレベルの基礎研究所だって・・・・あそこはな、俺が学生時代にあこがれてた基礎研なんだけど・・・ぶつぶつ
俺はうっかりそこの事だと思ったわけよ。
そしたら「産総研」だって。「下請け」つったのは性質の悪いジョーク。
顧客は国内トップレベルの基礎研究所だって・・・・あそこはな、俺が学生時代にあこがれてた基礎研なんだけど・・・ぶつぶつ
545 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:46:09
sin cos
cos -sin
の１軸回転の行列を３軸やって（ここまでは１フレームに一回だけしか計算しない）
ポリゴンの頂点座標を世界座標から上の行列をかけて視点座標に変換して、表示しない物体は切り捨てて
後はz/Lの投影変換してクリップしてポリゴンは終わり。
衝突はいいとして地面とか壁とか面倒だな。
煙や火は関数持ってくるんだろうな。
cos -sin
の１軸回転の行列を３軸やって（ここまでは１フレームに一回だけしか計算しない）
ポリゴンの頂点座標を世界座標から上の行列をかけて視点座標に変換して、表示しない物体は切り捨てて
後はz/Lの投影変換してクリップしてポリゴンは終わり。
衝突はいいとして地面とか壁とか面倒だな。
煙や火は関数持ってくるんだろうな。
>>544
で、その身の程知らずが、この廃墟に何の御用？
で、その身の程知らずが、この廃墟に何の御用？
ってな自慢話をするから、嫌われるのだとおもた（切腹
>>545
その３Dオブジェに関節があると、３軸回転を何度も繰り返すんだよぉ〜♪
その３Dオブジェに関節があると、３軸回転を何度も繰り返すんだよぉ〜♪
549 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:49:18
そかツリーでもって変換変換ね
鎖なんかの物理シミュレーションは難しいな。
鎖なんかの物理シミュレーションは難しいな。
お前の頭じゃ一生理解できんだろ
マジレスすると、このおっさんシェーディングの説明できねぇんだろうな、とか思った
552 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:51:15
相互作用型はちょっと俺には無理
OOが分かってなくても、
動くものは作れるし設計もできる現実
動くものは作れるし設計もできる現実
554 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:51:50
ギザギザ取りだろ
つくたことあるよ
つくたことあるよ
セガサターンの時代には、３Dオブジェのデータ構造が、まったくそのマンマ計算プログラムだったなぁ。
ギザギザ鳥？はぁ？
面の法線と光線の内積とって面の光度きめにゃあかんだろギザ
面の法線と光線の内積とって面の光度きめにゃあかんだろギザ
557 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:54:15
軽いね
その程度でいいの？
その程度でいいの？
シェーディングは、色のグラデーションで表示物の表面をなめらかな曲面に見せかける手法だよ。
559 ：仕様書無しさん：2007/07/05(木) 01:55:13
シェーディング. シェディングとは、光源、物体、視点の位置情報などから面に陰影づけを行う方法のことで、還元するとJ.Kajiyaによって示されたレンダリング方程式の解を求める事に帰着します。 レンダリング方程式. Iout(Θout)=E(Θout)+∫l=1 nρl(Θout ...
>>559
はいはいPower CPUのマルチコア版乙乙
はいはいPower CPUのマルチコア版乙乙
>>560
自分の言葉で書けw
自分の言葉で書けw
564 ：仕様書無しさん：2007/07/05(木) 01:57:29
>>536
あと、お前アホだな。
アメリカの開発経緯は日本みたいにお上主導の計画経済じゃねぇよ。
よく言えば自由で開かれた開発、悪く言えばベンチャーを切り張り取って付けた行き当たりばったりだ。
お前の言うように綺麗な開発経緯なんて存在しねーよ。
後付の泊付けだ。
あと、お前アホだな。
アメリカの開発経緯は日本みたいにお上主導の計画経済じゃねぇよ。
よく言えば自由で開かれた開発、悪く言えばベンチャーを切り張り取って付けた行き当たりばったりだ。
お前の言うように綺麗な開発経緯なんて存在しねーよ。
後付の泊付けだ。
565 ：仕様書無しさん：2007/07/05(木) 01:57:39
566 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:57:58
ちょととまて
頭の中で作図チェックしてみる
頭の中で作図チェックしてみる
>>564
お前の反論はすぐ論点がずれるからダメだ
挙句に、デタラメを並べ出すがらゴミ
どうせ論点ずらすなら
「日本は軍需産業が小さいため、民生品に高度先端技術がつぎこまれる傾向がある。
この結果、国外の軍需/先端科学産業は、日本の民生品技術とコラボレーションする傾向が強まっている」
とかなんとかそっちの方向に行けばいいのに。
お前の文を読んでガックリきたぞ。マジ
お前の反論はすぐ論点がずれるからダメだ
挙句に、デタラメを並べ出すがらゴミ
どうせ論点ずらすなら
「日本は軍需産業が小さいため、民生品に高度先端技術がつぎこまれる傾向がある。
この結果、国外の軍需/先端科学産業は、日本の民生品技術とコラボレーションする傾向が強まっている」
とかなんとかそっちの方向に行けばいいのに。
お前の文を読んでガックリきたぞ。マジ
回転行列は、左上から右下に向かって対角線がcosです
なお書き方として、転置して横ベクトルを使う形式と(DirectX)、そのまま縦ベクトルを使う形式があります(一般的な教科書)。
どちらであってもcosは対角線になるのだ
なお書き方として、転置して横ベクトルを使う形式と(DirectX)、そのまま縦ベクトルを使う形式があります(一般的な教科書)。
どちらであってもcosは対角線になるのだ
569 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:01:56
cos -sin
sin cos
かな？
sin cos
かな？
おまぃら二人
スレチガイですよ
スレチガイですよ
571 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:02:50
いいやんなもん
暗記しなくても
暗記しなくても
ほっといてやれ
573 ：仕様書無しさん：2007/07/05(木) 02:03:37
ああ。なんだ。ゲーム機の話しか。
ゲームの世界とPCの世界がごっちゃになってるから困る。
ゲームの世界とPCの世界がごっちゃになってるから困る。
すれ違いが4人いるとみた
やっぱネーミングが悪い。「オブジェクト」指向
このネーミングだから、元ゲームプログラマ廃人がのこのこと現れるんだ。
このネーミングだから、元ゲームプログラマ廃人がのこのこと現れるんだ。
576 ：仕様書無しさん：2007/07/05(木) 02:06:40
やっぱ、ゲームプログラマが荒らしてんだよ。
ゲームプログラミングはロジック主体だから。
オブジェクト指向とか、再利用性とか意味無いし。
ゲームプログラミングはロジック主体だから。
オブジェクト指向とか、再利用性とか意味無いし。
まぁ技術的には
ゲームプログラマ ＞＞＞＞＞ 業務プログラマ
だな。凡人レベルの給料比較すると、正反対だけど
ゲームプログラマ ＞＞＞＞＞ 業務プログラマ
だな。凡人レベルの給料比較すると、正反対だけど
578 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:08:15
逆だね
ゲームはオブジェクト指向が向いている部分が多い。
ゲームはオブジェクト指向が向いている部分が多い。
エンジン部分は高度なOOじゃないか？
580 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:09:12
炎とか波とかははオブジェクト指向では無理だな
技術レベル的には、もっと下が居るよ
ゲームプログラマ ＞＞＞＞＞ 業務プログラマ ＞＞＞＞＞ 有象無象の業務アプリ設計者
ゲームプログラマ ＞＞＞＞＞ 業務プログラマ ＞＞＞＞＞ 有象無象の業務アプリ設計者
OOをやってるからすばらしい、という前提は正しいのか？
584 ：仕様書無しさん：2007/07/05(木) 02:10:33
>>567
日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
まぐれ当たりが何本か出る程度だよ。
それにそれを育てようともしない風土だし、結局枯れる。
それを延々繰り返してるんだな。
金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
まぐれ当たりが何本か出る程度だよ。
それにそれを育てようともしない風土だし、結局枯れる。
それを延々繰り返してるんだな。
金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
なんかさ、ココが３Dレンダリングの話でいきいきしてるの見て、
ちょっとだけ嬉しくなった。こいつ変な話ばっかりする奴だと思ってたけど、
彼は彼なりに好きな分野があるのね。で、今は何やってる人なの？
ちょっとだけ嬉しくなった。こいつ変な話ばっかりする奴だと思ってたけど、
彼は彼なりに好きな分野があるのね。で、今は何やってる人なの？
587 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:13:02
航空産業などにいますが
588 ：仕様書無しさん：2007/07/05(木) 02:13:15
>>582
シューティングとかアクション系でOOとか要らないじゃん。
下手すると、関数呼び出しすらオーバーヘッドが問題になって使わず、
とんでもないプログラムを延々書く。
逆に、RPGとかシミュレーション系は多用するだろうけど。
前者にしか関わらない人間はOO要らないと言うでしょ。
シューティングとかアクション系でOOとか要らないじゃん。
下手すると、関数呼び出しすらオーバーヘッドが問題になって使わず、
とんでもないプログラムを延々書く。
逆に、RPGとかシミュレーション系は多用するだろうけど。
前者にしか関わらない人間はOO要らないと言うでしょ。
589 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:13:33
かっちょえええ
> 日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
開発技術？どの分野の話してんの？
開発技術って一体何？
> 金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
体言止めすな。ちゃんとしまいまで説明せい。
いい加減な言葉をいい加減な態度で示す奴には虫唾が走る
開発技術？どの分野の話してんの？
開発技術って一体何？
> 金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
体言止めすな。ちゃんとしまいまで説明せい。
いい加減な言葉をいい加減な態度で示す奴には虫唾が走る
>>582
Strategy使ったほうよくね？
Strategy使ったほうよくね？
>>588
実際にやってたからw おまいの話は真実味が無いwww
実際にやってたからw おまいの話は真実味が無いwww
ココってNASDA関係やってたっけ？
それともダイヤモンドマーク関係？
そういえば、宇宙ステーション計画どうなったんだろう・・・
それともダイヤモンドマーク関係？
そういえば、宇宙ステーション計画どうなったんだろう・・・
MIPS R3000の開発やった事ある人居る？
>>591
だからStrategyだってw
だからStrategyだってw
596 ：仕様書無しさん：2007/07/05(木) 02:17:21
>>586
・大学の研究レベルが低い
・学生の質が一部を除いて低い
・中学高校教育のレベルが低い。システム的な問題がある。時代遅れ。
能力のある人間を伸ばしていない。
・院卒をデタラメに扱う社会
・開発投資をしない会社風土
・日本独特の先輩後輩文化による文化硬直化。
それによる革新の欠如、革新の破壊、芽を摘む
・高度に管理しすぎる官僚制
社会が減点主義の鎖に繋がれる
などなど上げればキリがない。
・大学の研究レベルが低い
・学生の質が一部を除いて低い
・中学高校教育のレベルが低い。システム的な問題がある。時代遅れ。
能力のある人間を伸ばしていない。
・院卒をデタラメに扱う社会
・開発投資をしない会社風土
・日本独特の先輩後輩文化による文化硬直化。
それによる革新の欠如、革新の破壊、芽を摘む
・高度に管理しすぎる官僚制
社会が減点主義の鎖に繋がれる
などなど上げればキリがない。
OOを学習しても発揮する場が無い
こんな人が多そう
こんな人が多そう
返事がないのはガセの印
>>596
へー。じゃもう海外移住済だよね？そんなに文句あるんだから
へー。じゃもう海外移住済だよね？そんなに文句あるんだから
>>594
それって、PS？
それって、PS？
601 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:19:59
R3000 ・・・ソニーのWSだっけ？
ひたすらスレ違いな奴が多すぎ
603 ：仕様書無しさん：2007/07/05(木) 02:20:59
>>597
OOの利点をしっかりプレゼン出来ればいいと思う
OOの利点をしっかりプレゼン出来ればいいと思う
つか、もう寝る('A`)ﾉｼ
・国内大学の研究レベルは低いというよりは、産業向けの実用的研究と方向が乖離しているのが問題。
・逆に産業分野の研究は、製品開発に焦点が絞られすぎていて、本当の意味の基礎開発が不充分。
・例の青色LED発明以降、ポス毒の就職状況は改善されてるらすぃ。
・社会の硬直化：これはしょーがねぇな。横の人と同じ事してればいいと考えるのが農耕民族だからなｗ
・逆に産業分野の研究は、製品開発に焦点が絞られすぎていて、本当の意味の基礎開発が不充分。
・例の青色LED発明以降、ポス毒の就職状況は改善されてるらすぃ。
・社会の硬直化：これはしょーがねぇな。横の人と同じ事してればいいと考えるのが農耕民族だからなｗ
> 基礎開発
基礎研究のまてぃがい
あと、国内の教育環境はなぁ・・・難しいよなぁ・・・俺の時代は飛び級すらなく、ひたすら灰色の日々・・・
これの改善は、草の根レベルでやるっきゃないっしょ。そして金持ちだけが優れた教育を受けられる格差社会へ・・・
基礎研究のまてぃがい
あと、国内の教育環境はなぁ・・・難しいよなぁ・・・俺の時代は飛び級すらなく、ひたすら灰色の日々・・・
これの改善は、草の根レベルでやるっきゃないっしょ。そして金持ちだけが優れた教育を受けられる格差社会へ・・・
611 ：仕様書無しさん：2007/07/05(木) 02:33:53
何も、アメリカ型にする必要はない。
大資本家も居ない。規制も緩くない。期待もない。
日本で一番金を持っているのは国。
高度に組まれた規制を緩めれば、問題点ばかりが出る。
海外の投資家が積極的に日本に投資しようと考えることはまず無い。
ハゲタカが技術だけを買い叩いていくだけ。
日本の場合は、大学は浮世離れしすぎで、産業は目先のことを考えすぎる。
だから、政府や大企業が研究所をどんどん作って、
院卒をねじ込んで研究をどんどんさせるべき。
国内での雇用を拡大し、人材を確保する。同時に人材育成にもなる。
あらゆる理系分野でやるべき。
そうすることで、相互作用で市場が拡大する。
大資本家も居ない。規制も緩くない。期待もない。
日本で一番金を持っているのは国。
高度に組まれた規制を緩めれば、問題点ばかりが出る。
海外の投資家が積極的に日本に投資しようと考えることはまず無い。
ハゲタカが技術だけを買い叩いていくだけ。
日本の場合は、大学は浮世離れしすぎで、産業は目先のことを考えすぎる。
だから、政府や大企業が研究所をどんどん作って、
院卒をねじ込んで研究をどんどんさせるべき。
国内での雇用を拡大し、人材を確保する。同時に人材育成にもなる。
あらゆる理系分野でやるべき。
そうすることで、相互作用で市場が拡大する。
はいはい、必死必死
613 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:39:02
ちょっと前ならここでシグマの話題になったのに・・・
NEXT Step だっけ？ OOやったの？
615 ：仕様書無しさん：2007/07/05(木) 02:44:31
日本にはベル研、ローレンス・リバモア研究所のような、
大卒、院卒を受け入れる研究所がない。
だから育たない。
大卒、院卒を受け入れる研究所がない。
だから育たない。
616 ：仕様書無しさん：2007/07/05(木) 02:46:05
それ、目的設定が重要だな
第五世代レベルじゃ寸足らず
地球環境問題じゃ根拠や切迫感に欠ける
敗戦後、吉田爺や白州次郎が立てた｢輸出立国｣に相当する、おっきなスローガン
第五世代レベルじゃ寸足らず
地球環境問題じゃ根拠や切迫感に欠ける
敗戦後、吉田爺や白州次郎が立てた｢輸出立国｣に相当する、おっきなスローガン
とにかくこのスレを埋めたいらしい。
619 ：仕様書無しさん：2007/07/05(木) 02:50:13
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やら。まあ結局はその人の実力次第だけど。
最近転職活動していて、ああ、あの時応募しとけば・・・とかどうでもいい妄想に悩まされて
ここ数年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かつ駄目っぽい開発が残ってしまっている、と。
あれを兎に角改善しないとダメだと思う。
10年前の俺の壮大な妄想では、Java と OOを踏み絵にして駄目っぽい開発を改善/峻別/排除して理想郷を実現する予定で、
実際業界は一時期その方向に傾きかけてたんだけど(爆笑)
結局10年後、Javaかつ駄目っぽい開発が残ってしまっている、と。
10年もやってて「IT」なんてバズワード使う人もいるんだね。
627 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 19:32:46
技術的な話をすると客が逃げる
業務系と組込系以外に未経験でもぐりこめるとこありませんか？
629 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 19:51:13
>>628
カプコン
カプコン
>>577
それはゲームのシステム屋でしょ？
エンジン作ったりする奴の話。
アプリ層しか出来ないゲームプログラマのレベルは酷いぞ。
仕様書なんて書けないし出てこない。
基本口頭で、今時言った言わないで争ってるんだぞ。
それはゲームのシステム屋でしょ？
エンジン作ったりする奴の話。
アプリ層しか出来ないゲームプログラマのレベルは酷いぞ。
仕様書なんて書けないし出てこない。
基本口頭で、今時言った言わないで争ってるんだぞ。
>>628
ココ電の会社
ココ電の会社
632 ：仕様書無しさん：2007/07/05(木) 21:46:55
ITつう単語は最初ガートナーあたりが流行らせた単語だろ。
俺は、この業界ちょっと小馬鹿にしたニュアンスで揶揄する時にITって使うな。
あと素人相手に3Kバカ業界って説明するのが面倒な時とか
俺は、この業界ちょっと小馬鹿にしたニュアンスで揶揄する時にITって使うな。
あと素人相手に3Kバカ業界って説明するのが面倒な時とか
単語の起源も知らないような雛っ子に限って、
よく判らない業界バズワードにいちいち敏感に反応するのなｗ
ﾁｮｰ笑える
よく判らない業界バズワードにいちいち敏感に反応するのなｗ
ﾁｮｰ笑える
でも、仕様を書かせたら、まるっきりダメなのがゲーム屋
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
なんでそんな変なサイクルになるんだろうね？
ＯＯを理解してるのは１００人に１人くらいだな。
サイクル？
違う、廃品利用だ。
違う、廃品利用だ。
構造化を理解しているのは１０人に１人くらいだね。
>>641
基本情報処理試験の本買ったら載ってたぞ
基本情報処理試験の本買ったら載ってたぞ
>>642
あら、そうなの。でも、これはおいらの経験値だす。
あら、そうなの。でも、これはおいらの経験値だす。
美しいコーディングをする人は本当に少ないね。
んなこといったらOOだってソフ開の対策本に載ってるよ
しかしプログラミングは奥が深いよな
2年前でも結構OO理解してたつもりだけど
今ソース見ると恥ずかしいｗ
2年前でも結構OO理解してたつもりだけど
今ソース見ると恥ずかしいｗ
昔の一種、二種よりは大分マシになったな
美しさなんて時代や背景によって随分感じ方も変わるもんだ
>>646
HSPを美しく書く奴こそ本物。
HSPを美しく書く奴こそ本物。
おまいらオブジェクト指向がわからないから
延々とスレ違いを続けてるんだな
延々とスレ違いを続けてるんだな
ここはそういうスレだろ
クラスと継承とポリモがわかってればOK
あとはクラスが性格と動作を担ってることがわかればいい
動物→猫→三毛猫
Win32API→MFC
これで分からんって奴が不思議
動物→猫→三毛猫
Win32API→MFC
これで分からんって奴が不思議
656 ：仕様書無しさん：2007/07/06(金) 02:16:27
>>655
クラスの組み方が分からないと実戦で使うのは無理だろう。
クラスの組み方が分からないと実戦で使うのは無理だろう。
>>634
昔は確かにゲーム屋といえば、実質オブジェクト指向らしい概念が無かった時代から、それらしい機能を実装していたり
プロトタイプ開発といった概念なども持っていてこここそが最先端といえたと思う。
でも今はどうかな、もうすでに一種の分野になっているので、多方面をこなせる万能屋ではないよ、個別分野になれば知識レベルで完全に負ける。
昔と違って知識範囲が広がったので万能系は、全てに関わる必要のあるOS屋、言語屋だけだろうと思われる。
昔は確かにゲーム屋といえば、実質オブジェクト指向らしい概念が無かった時代から、それらしい機能を実装していたり
プロトタイプ開発といった概念なども持っていてこここそが最先端といえたと思う。
でも今はどうかな、もうすでに一種の分野になっているので、多方面をこなせる万能屋ではないよ、個別分野になれば知識レベルで完全に負ける。
昔と違って知識範囲が広がったので万能系は、全てに関わる必要のある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
いざとなったらそいつに恨みを集中させて切ればいいし、会社としては楽
だけど時代遅れのやり方で、役員は楽だけど競争に弱い。
だからバタバタと吸収されて減っていった。
だけど時代遅れのやり方で、役員は楽だけど競争に弱い。
だからバタバタと吸収されて減っていった。
>>657
つ スレタイ
つ スレタイ
661 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/06(金) 08:49:51
【文化】 新作「機動戦士ガンダム００」放映を機に「ガンダム」関連売上高、今期最高めざす…バンダイナムコ
http://news22.2ch.net/test/read.cgi/newsplus/1183674740/
http://news22.2ch.net/test/read.cgi/newsplus/1183674740/
>>657
僕は３D関係の数学知ってますって奴が実装技術に優れた物を持っていない場合、
その技術を持ってる奴と組んで仕事するとかでいいと思う。
全員が全員大学院卒並の数学出来なくても問題ない。
リアルタイムマルチタスクな組み込み系では、結局オブジェクト的な考えが
一番効率よかったから、ここでいうOOとはちがうかもしれないけど、むかしから使われてきている。
僕は３D関係の数学知ってますって奴が実装技術に優れた物を持っていない場合、
その技術を持ってる奴と組んで仕事するとかでいいと思う。
全員が全員大学院卒並の数学出来なくても問題ない。
リアルタイムマルチタスクな組み込み系では、結局オブジェクト的な考えが
一番効率よかったから、ここでいうOOとはちがうかもしれないけど、むかしから使われてきている。
663 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/06(金) 22:08:48
かなり話が流れてしまったが、OOの話をする事にする。
俺が構造化とOOの違いを電卓で示して見たが、何やら話が変な方向に行ってしまったようだ。
別に電卓を作ろうと言う意図ではない。
OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
OO電卓の場合、計算結果を内部に持つ必要があり、push0()が動作になっている。
構造化電卓の場合は、状態を持っていない。
俺が構造化とOOの違いを電卓で示して見たが、何やら話が変な方向に行ってしまったようだ。
別に電卓を作ろうと言う意図ではない。
OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
OO電卓の場合、計算結果を内部に持つ必要があり、push0()が動作になっている。
構造化電卓の場合は、状態を持っていない。
664 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/06(金) 22:11:27
ではこれらがどう影響するか考えてみよう。
最初に足し算と引き算のみに対応した物を作るとしよう。
多分、構造化電卓の方が分かりやすく少ないコードで作成する事が出来るだろう。
OO電卓の方はまどろっこしく感じるかもしれない。
次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
回避方法もあるが、基本的に呼び出している場所も全部修正になる。
まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。
次にOO電卓の場合はどうだろう。
ボタンの追加はメソッドの追加になる。適切に分割されていれば、他のボタンへの影響は少ない。
ボタン追加の10個や20個は問題ないだろう。
また変更前のクラスを親クラスにしextendsすれば、親クラスへの影響はない。
変更前を使うのも、変更後を使うのも自由だ。呼び出していた所を修正する必要もない。
つまりこれが構造化とOOの違いになる。
変更が少ないシステムなら構造化、修正が多いシステムはOOが適している訳が分かっただろうか？
最初に足し算と引き算のみに対応した物を作るとしよう。
多分、構造化電卓の方が分かりやすく少ないコードで作成する事が出来るだろう。
OO電卓の方はまどろっこしく感じるかもしれない。
次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
回避方法もあるが、基本的に呼び出している場所も全部修正になる。
まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。
次にOO電卓の場合はどうだろう。
ボタンの追加はメソッドの追加になる。適切に分割されていれば、他のボタンへの影響は少ない。
ボタン追加の10個や20個は問題ないだろう。
また変更前のクラスを親クラスにしextendsすれば、親クラスへの影響はない。
変更前を使うのも、変更後を使うのも自由だ。呼び出していた所を修正する必要もない。
つまりこれが構造化とOOの違いになる。
変更が少ないシステムなら構造化、修正が多いシステムはOOが適している訳が分かっただろうか？
まんどくせい
ボタンクラスと計算クラス作って、ボタンごとに呼び出す計算クラスの派生クラスの機能実装しる！
ボタンクラスと計算クラス作って、ボタンごとに呼び出す計算クラスの派生クラスの機能実装しる！
>>664
構造化なら掛け算と割り算を追加するだけで動くはず。
全部小さな部品として作ってあればそれで行ける。
それが細分化の真骨頂。
ちまちました最小機能毎に関数を作っておいて
ある程度の塊に組み上げる。
この塊は作り直しか、再設計だがちまちました部品は手付かずが普通。
OOだから、構造化だからじゃない、設計が糞という前提ありきだろ？
構造化を馬鹿にすんな。
関数の中にバージョンフラグ？ そんな糞設計が構造化だなんて、
勘違いしないでよね。
構造化なら掛け算と割り算を追加するだけで動くはず。
全部小さな部品として作ってあればそれで行ける。
それが細分化の真骨頂。
ちまちました最小機能毎に関数を作っておいて
ある程度の塊に組み上げる。
この塊は作り直しか、再設計だがちまちました部品は手付かずが普通。
OOだから、構造化だからじゃない、設計が糞という前提ありきだろ？
構造化を馬鹿にすんな。
関数の中にバージョンフラグ？ そんな糞設計が構造化だなんて、
勘違いしないでよね。
＞かなり話が流れてしまったが
流してんのお前だろ
流してんのお前だろ
よく居る、全体を見通せず目先の処理だけを動かしたいが為
変なフラグを幾つも作り、ロクに管理も出来ないような奴が、
作るとすれば、継承出来ない構造化の方が優れている面もあるんじゃないか？
結局クラス内部の動作の把握が必要になるのなら、関数単位で機能を固められる
構造化にもメリットがあるんじゃないかと思う。
継承すべきじゃないところを継承したお陰で関係箇所全滅という事もありうる。
技術じゃなくて教育とか人こそが問題なんだよ。
変なフラグを幾つも作り、ロクに管理も出来ないような奴が、
作るとすれば、継承出来ない構造化の方が優れている面もあるんじゃないか？
結局クラス内部の動作の把握が必要になるのなら、関数単位で機能を固められる
構造化にもメリットがあるんじゃないかと思う。
継承すべきじゃないところを継承したお陰で関係箇所全滅という事もありうる。
技術じゃなくて教育とか人こそが問題なんだよ。
＞次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
＞作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
＞引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
＞回避方法もあるが、基本的に呼び出している場所も全部修正になる。
＞まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。
それって、構造化の技法使ってないやん。
キー入力割り込み
↓
キーの値ゲット
↓
関数へのポインタ配列を使いキーの値をインデックスにして
該当処理をcall （この方式は各メソッド毎の処理を呼び出すときにOOのコンパイラも愛用してる）
↓
キー入力待ち
Cやアセンブラでこんな処理作った事あるよ。
構造化ヽ(´ー｀)ノﾏﾝｾｰ
＞作成していない限り、複雑な処理になるだろう。もし、仕様変更前と変更後の両方を使いたいとなったら、
＞引数にバージョンフラグなどを追加して、関数の中にifが追加になったりするだろう。
＞回避方法もあるが、基本的に呼び出している場所も全部修正になる。
＞まあ、相当設計者が良くない限り、ボタンが5個も追加されれば、混沌としたコードになるだろう。
それって、構造化の技法使ってないやん。
キー入力割り込み
↓
キーの値ゲット
↓
関数へのポインタ配列を使いキーの値をインデックスにして
該当処理をcall （この方式は各メソッド毎の処理を呼び出すときにOOのコンパイラも愛用してる）
↓
キー入力待ち
Cやアセンブラでこんな処理作った事あるよ。
構造化ヽ(´ー｀)ノﾏﾝｾｰ
670 ：仕様書無しさん：2007/07/06(金) 23:25:48
>>663
＞OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
そこじゃない… そこじゃないんだ…
＞構造化電卓の場合は、状態を持っていない。
いろいろ突っ込みたい事はあるが一つにしておく。
⇒説得力無いわ。
＞OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
そこじゃない… そこじゃないんだ…
＞構造化電卓の場合は、状態を持っていない。
いろいろ突っ込みたい事はあるが一つにしておく。
⇒説得力無いわ。
671 ：仕様書無しさん：2007/07/06(金) 23:40:18
電卓をOOでと聞いて
MVCの話かなと思った
けど全然ちがかった
MVCの話かなと思った
けど全然ちがかった
モデル、ビュー、コントロールという考え方は、OOでも有効だよ。
はぁ?
スレ違いのバカレスはほっとけ
要はOOが嫌いと言ってる連中がなぜ嫌いなのかってことだろ
それってOOが浸透してないってだけじゃん
要はOOが嫌いと言ってる連中がなぜ嫌いなのかってことだろ
それってOOが浸透してないってだけじゃん
つーか、それぞれの部品の動作とかを定義すりゃあいい話で、
延々とどーでもいいレスを書いてる奴は分かってないだけ
延々とどーでもいいレスを書いてる奴は分かってないだけ
>>673
見込になし
見込になし
ゲームがどうのこうのとかレス打ってる奴。
お前ら仕事できるようになったら来いや。
初心者はまず本を読んで学習してこい。
お前ら仕事できるようになったら来いや。
初心者はまず本を読んで学習してこい。
OOが問題になるのはPGじゃなくてSE。
SEが分かってないから業務レベルの設計を書きまくり、
クラス設計なんかは知らん、
というスタンスのためPGが翻訳する必要が出てくる。
また、この場合でもPGが優秀な奴じゃないと対応が不可能であり、
結局はOOが分かってないSEが昔どおりの設計をやってるだけため、
Javaが機能分類されてるだとかの話になるだけ。
SEが分かってないから業務レベルの設計を書きまくり、
クラス設計なんかは知らん、
というスタンスのためPGが翻訳する必要が出てくる。
また、この場合でもPGが優秀な奴じゃないと対応が不可能であり、
結局はOOが分かってないSEが昔どおりの設計をやってるだけため、
Javaが機能分類されてるだとかの話になるだけ。
>>680
激しく禿同。と言いたいところだが酔っ払って眠いんだな。
激しく禿同。と言いたいところだが酔っ払って眠いんだな。
根本的にOOのレスを打てない奴は分かってないだけで、
雑談スレに行けばいいのに粘着してるだけだろ
雑談スレに行けばいいのに粘着してるだけだろ
Javaとかで"何とかUtil"ってクラス作る奴馬鹿だろ
>ボタン追加の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を作成する選択するのは何故か
それを選ぶのは流行であったり、安易な選択ではないのか？
おおスゲーｗー・・・言い切ってやがる！
やがて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は嫌われているのか？
>>683
なんで？
なんで？
687 ：仕様書無しさん：2007/07/07(土) 01:16:07
>>884
わっふるわっふるｗ
わっふるわっふるｗ
689 ：仕様書無しさん：2007/07/07(土) 01:17:31
690 ：仕様書無しさん：2007/07/07(土) 01:18:19
691 ：仕様書無しさん：2007/07/07(土) 01:19:23
>>689←誤爆でーす(^-^)
>>686
たいてい単なる関数ライブラリだから
たいてい単なる関数ライブラリだから
１．OO理解せずに嫌っているヤツがいる
２．漏れはOO理解してるけど嫌いだ
がループしてね？
個人的にOO理解した上で嫌いってのは変だと思う
それってOOが設計の一手法って事を理解してないってことだろ？
手法の一つだから使うべきところで使えばいいし、
使う必要の無いところでは使わなければいい
使い捨てのテキスト整形用のプログラムとか、
高度なgrepがやりたくて書いたperlシェルとか
まさかOOではやらねだろ？
OOが嫌われる他の可能性だけど、
万能っぽく振りかざすから他の連中に嫌われる、
ってーのはあるかもな
２．漏れはOO理解してるけど嫌いだ
がループしてね？
個人的にOO理解した上で嫌いってのは変だと思う
それってOOが設計の一手法って事を理解してないってことだろ？
手法の一つだから使うべきところで使えばいいし、
使う必要の無いところでは使わなければいい
使い捨てのテキスト整形用のプログラムとか、
高度なgrepがやりたくて書いたperlシェルとか
まさかOOではやらねだろ？
OOが嫌われる他の可能性だけど、
万能っぽく振りかざすから他の連中に嫌われる、
ってーのはあるかもな
電卓の本質はインタプリタだ、って話があったけど
OOの本質は「物事を本質と本質でないものに分解すること」
じゃないんだよな。
もちろんそれも大事な要素なんだけど。
OOの本質は「物事と物事のつなぎ方」の方にある。
OOの本質は「物事を本質と本質でないものに分解すること」
じゃないんだよな。
もちろんそれも大事な要素なんだけど。
OOの本質は「物事と物事のつなぎ方」の方にある。
>>693
だって自作のクラスをインスタンス化して引数に渡してるんだぜ
だって自作のクラスをインスタンス化して引数に渡してるんだぜ
>>695
私もおおむね同意だし、
そもそも、使いやすく見渡しのいい適当なレベルの
モデルが手に入れば何指向だろうがどうでもいいと思っている。
ただし、そのような本質論を語りだすといつのまにか荒れる。
あなたがあなたの主観を押し付けているように見えるからだ。
私もおおむね同意だし、
そもそも、使いやすく見渡しのいい適当なレベルの
モデルが手に入れば何指向だろうがどうでもいいと思っている。
ただし、そのような本質論を語りだすといつのまにか荒れる。
あなたがあなたの主観を押し付けているように見えるからだ。
>>696
頻度によるね。
あきらかにクラスに移動してしまったほうがいいぐらい呼び出し頻度が多くて、
移動しても不自然じゃなければクラスに持たせたほうがいい。
それか、クラス自体にstaticメソッドを持たせるべき。
素朴なコレクションいじりとか、横断的に発生するのとかは
Utilクラスに持たせちゃっていいと思う。
頻度によるね。
あきらかにクラスに移動してしまったほうがいいぐらい呼び出し頻度が多くて、
移動しても不自然じゃなければクラスに持たせたほうがいい。
それか、クラス自体にstaticメソッドを持たせるべき。
素朴なコレクションいじりとか、横断的に発生するのとかは
Utilクラスに持たせちゃっていいと思う。
呼び出し頻度なんか関係ないだろw
OOの設計というのは、いかにブロックを組み、バラバラにできるかということ。
あっちのブロックの組と、こっちのブロックの組と、いかにバラバラにして組み直せるかって事。
OOの設計というのは、いかにブロックを組み、バラバラにできるかということ。
あっちのブロックの組と、こっちのブロックの組と、いかにバラバラにして組み直せるかって事。
俺は頻度とか考えずCRCカードの考え方でクラス作るなぁ。
たいていメソッドを持たせるクラスの候補は複数あるので、
Utilクラスとかは作らずにクラス数を減らす方向で行く。
理論的にはよく分からないが経験的には、
そっちの方が使う側も単純に書ける気がする。
たいていメソッドを持たせるクラスの候補は複数あるので、
Utilクラスとかは作らずにクラス数を減らす方向で行く。
理論的にはよく分からないが経験的には、
そっちの方が使う側も単純に書ける気がする。
704 ：仕様書無しさん：2007/07/07(土) 01:54:13
>>694
OO中途半端だから嫌い。
OO中途半端だから嫌い。
まあ、ブロックのばらしかたは各自のセンスでいんじゃね？
ここOO相談室じゃないし
OOわからないってのは「何でばらすか？」がわかってないってことかねえ
ここOO相談室じゃないし
OOわからないってのは「何でばらすか？」がわかってないってことかねえ
まったく異なるシステムの為に作ったあるクラスを、また全く違うシステムに組み入れる事を容易にさせるためにやるんだよ。クラス設計って言うのは。
ま、それも再利用のひとつだわな
>>705
最初あたりはJavaだったら、
「関数ポインタないのでインタフェースか抽象クラスにしてバラします」
ぐらいの意識でいいんじゃないかと思う。
# 一応VB6でもインタフェースあるので、この程度だと出来る。
最初あたりはJavaだったら、
「関数ポインタないのでインタフェースか抽象クラスにしてバラします」
ぐらいの意識でいいんじゃないかと思う。
# 一応VB6でもインタフェースあるので、この程度だと出来る。
>>706
それは大概フレームワークと呼ぶものじゃない？
ま、クラス設計とか以上に縛りがあるけど。
あるいはまったく違うシステムに組み入れられるのは
クラスというよりは、クラスの抽出手順、つまりデザインパターン。
どこかでやった作業を最終的に別の成果物に転用できるのは
気分がいいけど、発表する場所がふつうはないんだよな。
それは大概フレームワークと呼ぶものじゃない？
ま、クラス設計とか以上に縛りがあるけど。
あるいはまったく違うシステムに組み入れられるのは
クラスというよりは、クラスの抽出手順、つまりデザインパターン。
どこかでやった作業を最終的に別の成果物に転用できるのは
気分がいいけど、発表する場所がふつうはないんだよな。
まったく違うシステムに持ってくのももちろん再利用だけど、
まずは同じシステムの中で再利用されるケースがおおいわな。
まずは同じシステムの中で再利用されるケースがおおいわな。
つか、歴代使ってる老舗のタレみたいな処理は、ラッパーで包んでしまうから、
それでいいんじゃね？ クラスなんて考えなくてもさ。
それでいいんじゃね？ クラスなんて考えなくてもさ。
その手の物って探すと既にあったりしないか?
処理は好き勝手に変えたいわけさ。
処理を変えたいし、さりとて変更コストは安くあげたい。
さて、どうする？ってところがスタート地点かねえ
処理を変えたいし、さりとて変更コストは安くあげたい。
さて、どうする？ってところがスタート地点かねえ
>>712
自社製品の使い古されたシーケンス処理の実装とか、探しても出て来ねえよw
自社製品の使い古されたシーケンス処理の実装とか、探しても出て来ねえよw
>>714
その手のかw
その手のかw
OOって結局、ｵﾚｵﾚ指向の次元の間は
これ以上は普及しないだろうな。
というか、話せば話すほど
全員が違う事を言い出すっていう時点で
そういう類のものっていう認識は持たないとまずいんじゃないかな。
悪い意味じゃなくね。
これ以上は普及しないだろうな。
というか、話せば話すほど
全員が違う事を言い出すっていう時点で
そういう類のものっていう認識は持たないとまずいんじゃないかな。
悪い意味じゃなくね。
道は一本しかないけど、道すがらいろんな景色が見えてるってだけの気もするけど
オプソのコードなんか見てても、「あ、これはめずらしいOOだ！」なんてのは無い品
オプソのコードなんか見てても、「あ、これはめずらしいOOだ！」なんてのは無い品
そうそうJIS規格のボルトとナットみたいな訳にはいかないよ。
>>671の力量は未知数だ。
ただ、２ｃｈで偉そうな事いう奴は凄いんだろうね。
たかが知れるほど凄いのに論破の一つもしない。
さあ、高レベルな話はまだですか？
低レベルに理解できるように説明してこその高レベルだよ。
電卓のコードでも書いて見せてよ。
高レベルなら5分ぐらいで出来るだろ？
ただ、２ｃｈで偉そうな事いう奴は凄いんだろうね。
たかが知れるほど凄いのに論破の一つもしない。
さあ、高レベルな話はまだですか？
低レベルに理解できるように説明してこその高レベルだよ。
電卓のコードでも書いて見せてよ。
高レベルなら5分ぐらいで出来るだろ？
粘着されるからかね。
電卓の設計には、CommandパターンとInterpreterパターンが適用できる。
UndoするならMementoパターンで行こう。
UndoするならMementoパターンで行こう。
724 ：仕様書無しさん：2007/07/07(土) 07:59:10
仕様書に〜パターンて書きたいなら
仕様書ごとにデザパタ一冊買って添付しなきゃ駄目だよなｗ
仕様書ごとにデザパタ一冊買って添付しなきゃ駄目だよなｗ
>>724
頑張って勉強しよう。素直が一番。
頑張って勉強しよう。素直が一番。
727 ：仕様書無しさん：2007/07/07(土) 09:04:23
嫌われようがなんであろうが、
Windowsの開発が.Netに移行してんだから
OO必須になってくのはしょーがない
Windowsの開発が.Netに移行してんだから
OO必須になってくのはしょーがない
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する
はい次誰か仕様書けｗｗｗ
電卓は初期化を行い、初期値として0が表示される
2.ユーザは、電卓の数値キーを押し数値を入力する (もしくは3に移行)
有効桁数は12桁、浮動小数点数を含み、
有効な数値範囲は10^12-1〜10^-11とする
有効桁数を超えたキー入力は無視する
電卓は入力された数値を順次表示する
数値クリアキー[CE]を押すと、数値入力をやりなおす事ができる
3.ユーザは、演算子キー(＋−×÷)を押す
電卓は次の数値入力を待つ (2に移行)
3'.ユーザは、[＝]キーを押し、計算結果を得る
電卓は 以前の計算結果もしくは以前の数値入力(Reg1)と、
新しい数値入力(Reg2)に、3で入力された演算子を適用し
新しい計算結果を得る
演算中に演算エラー(0割り)や桁溢れ/桁落ちが発生した場合は、
エラー表示(0E)をする
4.ユーザはクリアキー[C]を押し、次の計算に移る (2に移行)
電卓は初期値として0を表示する
5.ユーザは、電源キーを押し電源をoffする
はい次誰か仕様書けｗｗｗ
ユーザーは別に電卓のボタンを押したいわけじゃないだろ
式を計算してくれればそれでいいわけなんだがなんでみんなキーとかこだわるんだ？
式を計算してくれればそれでいいわけなんだがなんでみんなキーとかこだわるんだ？
そのとおりだな。
というか、ソフト開発やってんだからソフトだけを言ってりゃいいだろ。
電卓のボタンだとか、液晶だとか、
どう考えても専門外。
こんなこと言い出したらボタンの反発ゴム？の設計とかまでに話が及ぶだろ。
ボタンを押されたあとの計算ロジックだけ考えてりゃいいんだよ。
というか、ソフト開発やってんだからソフトだけを言ってりゃいいだろ。
電卓のボタンだとか、液晶だとか、
どう考えても専門外。
こんなこと言い出したらボタンの反発ゴム？の設計とかまでに話が及ぶだろ。
ボタンを押されたあとの計算ロジックだけ考えてりゃいいんだよ。
バッカみてぇな質問だな。
答は簡単。ふつー電卓って言った場合は
通常の数式処理(演算子順位文法)ではなく
HP電卓流スタック演算に中置演算子を適用したような形態を指すからさ。
つまり、
普通の数式処理： 1+2*3=7
HP電卓流処理： 1+2*3=9
答は簡単。ふつー電卓って言った場合は
通常の数式処理(演算子順位文法)ではなく
HP電卓流スタック演算に中置演算子を適用したような形態を指すからさ。
つまり、
普通の数式処理： 1+2*3=7
HP電卓流処理： 1+2*3=9
キー入力ってのを物理的なキーの話だと思っているあたりで、
こいつはド素人だからしょうがないんだなぁって思った
こいつはド素人だからしょうがないんだなぁって思った
>>732
何を言いたいのかさっぱりわからん
何を言いたいのかさっぱりわからん
入力/演算方式： 演算子順位無視の順次入力/演算
・二つの数値と、一つの演算子を入力し、計算結果を順次表示する
・入力の順番は、[数値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]
・二つの数値と、一つの演算子を入力し、計算結果を順次表示する
・入力の順番は、[数値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]
ド素人向け解説
手計算の場合：
１＋２×３＝１＋（２×３）＝１＋６＝７
※乗除演算は、加減演算よりも優先する
HP流電卓計算の場合：
１＋２×３＝（１＋２）×３＝３×３＝９
※演算子の優先順位は考慮せず、ひたすら左側から順番に計算する
手計算の場合：
１＋２×３＝１＋（２×３）＝１＋６＝７
※乗除演算は、加減演算よりも優先する
HP流電卓計算の場合：
１＋２×３＝（１＋２）×３＝３×３＝９
※演算子の優先順位は考慮せず、ひたすら左側から順番に計算する
キチガイ発狂！！！！
HPの電卓っていったら普通逆ポーランド記法じゃねーの？
涙目ｗｗｗｗｗｗｗ
スレ違いがすさまじいな
キチガイが頑張ってるな
電卓テーマでキー入力するのが気に入らないって
どれだけキチガイなんだコイツｗｗｗ
お前は何を話題にしたいんだよこのキチガイめ
電卓テーマでキー入力するのが気に入らないって
どれだけキチガイなんだコイツｗｗｗ
お前は何を話題にしたいんだよこのキチガイめ
本来オブジェクト指向って奴は学ぶのではなくて、
手続き型言語とかで開発している人たちが
こうなれば効率いいなぁ・・・って感じで産まれたもんじゃんか。
なんで、デザパタとかやる若い人ってちょっと可哀想なきがする
手続き型言語とかで開発している人たちが
こうなれば効率いいなぁ・・・って感じで産まれたもんじゃんか。
なんで、デザパタとかやる若い人ってちょっと可哀想なきがする
仕様も出たことだし、誰か設計しろよｗ
あ、ちなみに仕様にはちゃんと穴があるから、
それも発見するようにｗ
あ、ちなみに仕様にはちゃんと穴があるから、
それも発見するようにｗ
相変わらずバカが目先の課題から逃げ回っているなｗｗｗ
電卓の設計もできねぇなんて、どれだけバカなんだコイツ
電卓の設計もできねぇなんて、どれだけバカなんだコイツ
電卓なんて、プログラミング実習の最初の週でやるようなテーマだろ
それすらこなせないとは、小学生レベルだな
それすらこなせないとは、小学生レベルだな
751 ：仕様書無しさん：2007/07/07(土) 10:11:09
電卓で重宝したのはカシオのCM-100だったな。
予備着含めて３つは買ったものだが、結局全部壊れちまった。
再販してくれないかなぁ・・・
予備着含めて３つは買ったものだが、結局全部壊れちまった。
再販してくれないかなぁ・・・
OOのスレで電卓に必死なのな
↓じゃキミ、電卓の設計ヤレ
電卓終了。
>746
デザインパターンをいきなりやる若い人って、そんなにいるのかな？
身近にはおらんっす。
デザインパターンをいきなりやる若い人って、そんなにいるのかな？
身近にはおらんっす。
756 ：格之進 ◆xiPQGz7lVI ：2007/07/07(土) 10:16:41
かわいそうなのは、「やらされている」人ですね。
自分の興味で’勉強する分には、
（人によっては）面白いんじゃないでしょうか。
自分の興味で’勉強する分には、
（人によっては）面白いんじゃないでしょうか。
逃げた逃げた〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
小学生なみに幼稚な奴が
OOでも構造化でも電卓の設計できず
逃げたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ほんとレベル低いなお前
小学生なみに幼稚な奴が
OOでも構造化でも電卓の設計できず
逃げたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ほんとレベル低いなお前
∧＿∧
（ ´∀｀）
（ ）
｜ ｜ |
（_＿）＿）
（ ´∀｀）
（ ）
｜ ｜ |
（_＿）＿）
小学生のぼっちゃん向けヒント
[キー入力]＼
＼
[コントローラ]→[計算機]
／ ←
[結果表示]／
[キー入力]＼
＼
[コントローラ]→[計算機]
／ ←
[結果表示]／
761 ：格之進 ◆xiPQGz7lVI ：2007/07/07(土) 10:27:57
>>759
無理に勉強する必要は無いと思います。
ある程度実務経験のあるひとなら、
「そんなことはもうやってる」というような内容が多いでしょう。
デザインパターンは分かりきったことを整理して名前をつけただけだ、
という言い方をする人もいますから。
ただ、例えば Java の標準クラスライブラリにしても、
Factory とか、 Composite とか言う言葉がよくでてくるので、
そういうライブラリやフレームワークなどを理解する際には、
知っておいたほうが、理解が早いでしょうね。
無理に勉強する必要は無いと思います。
ある程度実務経験のあるひとなら、
「そんなことはもうやってる」というような内容が多いでしょう。
デザインパターンは分かりきったことを整理して名前をつけただけだ、
という言い方をする人もいますから。
ただ、例えば Java の標準クラスライブラリにしても、
Factory とか、 Composite とか言う言葉がよくでてくるので、
そういうライブラリやフレームワークなどを理解する際には、
知っておいたほうが、理解が早いでしょうね。
バカコテが何を言おうと、こいつ電卓の設計もできないクズですから
↓はい、キミは電卓の設計くらいできるよね？
さっさと設計文書書けよ
さっさと設計文書書けよ
電卓設計で「コントローラ」ってのは、何か違和感あるな。
コントローラの責務は何よ？
コントローラの責務は何よ？
結論
電卓でクラスこねくり回す設計するやつはｱﾌｫ
電卓でクラスこねくり回す設計するやつはｱﾌｫ
電卓なんていうトイプログラムすらこなせない
痴呆老人が粘着するスレ
痴呆老人が粘着するスレ
>>768
それはどうかな。
キミがいつもこのスレで議論にならない議論を繰り返しているから、
ちょっとからかってみただけだよ。
キミはいつも繰言を繰り返すだけで、
まともな設計図など出した事がないだろう。
キミは一体何のためにこのスレに粘着しているの？
それはどうかな。
キミがいつもこのスレで議論にならない議論を繰り返しているから、
ちょっとからかってみただけだよ。
キミはいつも繰言を繰り返すだけで、
まともな設計図など出した事がないだろう。
キミは一体何のためにこのスレに粘着しているの？
OOが苦手な分野ってあんの？
>>769
ヒント： 引き篭もり自称トレーダ
ヒント： 引き篭もり自称トレーダ
結論： このスレに粘着している人物は、プログラミング/設計の素養などない引き篭もり
774の必死さに合掌
電卓のコア部分は数字か演算子を受け取ればいい。
class Caluculater :
+ putNumber(int number)
+ putOperator(Operator op)
実計算は Operator を派生した各クラスに数字を渡してお任せ。
各派生オペレータは名前空間や代替手段で纏めておく。
class Caluculater :
+ putNumber(int number)
+ putOperator(Operator op)
実計算は Operator を派生した各クラスに数字を渡してお任せ。
各派生オペレータは名前空間や代替手段で纏めておく。
最近の電卓の太陽電池の部分のプログラミングが問題だな
>>776
最終行意味不明
ってかなんでこんな簡単な話で荒れる事ができるのか、
このスレのレベルの低さに脱帽した
>>777
またキチガイの話題ずらしか
半導体のプログラミング？
寝言は寝て言えキチガイ
最終行意味不明
ってかなんでこんな簡単な話で荒れる事ができるのか、
このスレのレベルの低さに脱帽した
>>777
またキチガイの話題ずらしか
半導体のプログラミング？
寝言は寝て言えキチガイ
>>778
お前が荒らしてんだろ
お前が荒らしてんだろ
太陽電池のプログラミング(ｗ
荒してるんじゃねぇよ
てめぇのバカさ加減をからかってるだけだよ
てめぇのバカさ加減をからかってるだけだよ
黒太陽の毒電波を受信する太陽電池プログラミングｗ
月食どうする?
毒電波トレーダ
786 ：仕様書無しさん：2007/07/07(土) 15:10:35
このあと200レスかけても、設計なんて全然できねぇんだろうな
悲惨すぎる粘着人生
悲惨すぎる粘着人生
つスレタイ
言い訳だけのダメダメ人生
OO嫌なら構造化で設計してみろ
お前の場合、OOだ構造化だ言う前に、
設計能力もプログラミング能力もないクズだろ
OO嫌なら構造化で設計してみろ
お前の場合、OOだ構造化だ言う前に、
設計能力もプログラミング能力もないクズだろ
技術は体系立てて学ぶもの。
いきなりオブジェクト指向から入っても理解できない。
だからオブジェクト指向は嫌われる。
いきなりオブジェクト指向から入っても理解できない。
だからオブジェクト指向は嫌われる。
790 ：仕様書無しさん：2007/07/07(土) 15:57:43
言い訳はわかったからはやく設計出せよ
電卓なんて初心者レベルの入門課題だぞ？
電卓なんて初心者レベルの入門課題だぞ？
設計だしたら次は実装だからな
さぁ、そろそろオセロの設計でもするかぁ！
はやく電卓とオセロの設計だせ
お前もう半年遅れだぞ
そろそろクビだろ、いくら進入社員レベルとはいえ
お前もう半年遅れだぞ
そろそろクビだろ、いくら進入社員レベルとはいえ
794 ：仕様書無しさん：2007/07/07(土) 16:02:44
↓以下1000までグダグダ言い訳するだけで
一向に成果を出せないクズ人生が続く
一向に成果を出せないクズ人生が続く
2chにいりびたりのお前よ。
自分の胸に手をあてて己の姿を客観的に分析してみろ。
自分の胸に手をあてて己の姿を客観的に分析してみろ。
796 ：仕様書無しさん：2007/07/07(土) 16:08:08
↑鏡見てろバーカｗ
５年前２ちゃんに居た人物が未だにウダウダやってる姿を見ると
「ダメな奴は何をやってもダメ」という２ちゃん迷言を思い出して爆笑がとまらない
５年前２ちゃんに居た人物が未だにウダウダやってる姿を見ると
「ダメな奴は何をやってもダメ」という２ちゃん迷言を思い出して爆笑がとまらない
相手にすんな
>>794
その悲惨さと粘着ぶり、素敵です！！
その悲惨さと粘着ぶり、素敵です！！
だからあいてすんなっつの
電卓の本質はインタプリタとして、
オセロの本質は何だろう？
オセロの本質は何だろう？
以後、本質・設計の話はスルーで
えっ、じゃぁ何の話する？
なぜオブジェクト指向は嫌われているのか？
について
について
オブジェクト指向の本を読んでも、ちっとも素敵な設計が出来ないから
オブジェクト指向は嫌われる。
オブジェクト指向は嫌われる。
嫌われてはいない。その他大勢に敬遠されているだけ。
人間は急激な変化を嫌います。それがどんなに自分にとって有益であったとしても。
オブジェクト指向は穏やかだね。
808 ：仕様書無しさん：2007/07/07(土) 17:21:35
設計などしたことのない人間が何を言っても説得力なし
キミの人生は無意味だ
キミの人生は無意味だ
OO厨の考えてる設計って
まさかデザパタ決める事じゃないよな？
まさかデザパタ決める事じゃないよな？
オブジェクト指向＝＝デザパタ
>>1
嫌われてねーよwww
嫌われてねーよwww
デザパタ＝＝奥義
>>811
あえて狂人を装った方がスレが賑わうからなｗ
あえて狂人を装った方がスレが賑わうからなｗ
デザパタの適用数が多いほど設計は美しくなる。
これ常識。
これ常識。
本質・設計・デザパタは荒れる元
スルー汁
スルー汁
ＭＶＣこそオブジェクト指向の神髄なり。
デザパタを使うかどうかはともかく、引き出しを増やすという意味では、
当然知らないよりは知ってた方がいい。
当然知らないよりは知ってた方がいい。
ＢＣＥが適切なのにＭＶＣの乱用が目立つのは
やはり Golden Hammer によるものか。
やはり Golden Hammer によるものか。
BCEが適切って、ASP.NET以外ねーよ
820 ：仕様書無しさん：2007/07/07(土) 18:20:31
狂人が狂人を装う倒錯スレ
>>814
プログラムは一見すっきりするけど
実際は糞な結果になる事もあるよ。
例えば、不必要なオブザーバーやメディエーターの適応等。
前にも書かれているけど
デザパタはただの名称だから。
極論すれば、命名規則みたいなもの。
プログラムは一見すっきりするけど
実際は糞な結果になる事もあるよ。
例えば、不必要なオブザーバーやメディエーターの適応等。
前にも書かれているけど
デザパタはただの名称だから。
極論すれば、命名規則みたいなもの。
>>819
そうなのか。知らなかった。
そうなのか。知らなかった。
823 ：仕様書無しさん：2007/07/07(土) 19:47:03
構造化とそうでない設計の違いも説明出来ない奴が
OOと構造化をうんぬん言える訳がないよな。
OOと構造化をうんぬん言える訳がないよな。
824 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 19:57:22
ええええ
OO厨って電卓作れないの？
OO厨って電卓作れないの？
>>824
おじゃばのﾗｲﾊﾞﾙｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
おじゃばのﾗｲﾊﾞﾙｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
826 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:08:30
イベント[0123456789] -> レジスタA=レジスタAX10＋[x] ：表示モードA 表示
イベント[クリア]ー>レジスタA＝０； ：表示モードA 表示
イベント[全クリア]ー＞レジスタA=レジスタB＝０ ：表示モードA 表示
イベント[＋ーX/]レジスタB=レジスタA[演算]レジスタB： ：表示モードB 表示
[レジスタ]を表示モードにしたがって数値を数字で表示
イベント[クリア]ー>レジスタA＝０； ：表示モードA 表示
イベント[全クリア]ー＞レジスタA=レジスタB＝０ ：表示モードA 表示
イベント[＋ーX/]レジスタB=レジスタA[演算]レジスタB： ：表示モードB 表示
[レジスタ]を表示モードにしたがって数値を数字で表示
電卓なんてただのStackマシン扱いにしといた方がいい。
829 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:15:03
メッセージはウインドウズならすでにあるから
レジスタオブジェクトかレジスタ変数かの違いくらいだな
ウインドウズ以外ならメッセージ機構や電卓描画まで自分で作る事になるだろう。
イベント[ANY]->電卓オブジェクト
として
イベントのディスパッチャーを電卓オブジェクト内につくり、仕分けして826を呼び出せばそれらしくなる。
レジスタオブジェクトかレジスタ変数かの違いくらいだな
ウインドウズ以外ならメッセージ機構や電卓描画まで自分で作る事になるだろう。
イベント[ANY]->電卓オブジェクト
として
イベントのディスパッチャーを電卓オブジェクト内につくり、仕分けして826を呼び出せばそれらしくなる。
830 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:20:59
＞イベント[0123456789] -> レジスタA=レジスタAX10＋[x]
電卓の味噌はここね。入力による桁シフトという特殊動作
これを思いつかないようではダメダメ
電卓の味噌はここね。入力による桁シフトという特殊動作
これを思いつかないようではダメダメ
ボタンオブシェクとは当然フライウェイトパターンだよな。
スレタイに戻って考えると、業務ではたいていチームで開発するんだけど、
全員が同じ程度、理解力や柔軟性を持ち知識や実務経験も等しければ
オブジェクト指向での開発はうまくいくのだと思う。
例えば大卒上がりで研修を終えた新人が現場に投入されだしている時期だが、
新人にドキュメント込みで開発中の既存のソースとか読ませると、飲み込みの
早い奴と遅い奴の差が非常に出るわけだ。
構造化時代ならば時間の問題だけど、オブジェクト指向とかだと本人のセンスとか
柔軟性とかで「そこまで考えられません（泣）」なんて事もあったりする。
上としてみれば、新人確保が難しい時期なのでパフォーマンスが悪くても育てたい。
でも、現場に投入してみると、現場の連中からは「使えないのでチェンジ！！」って事に
なったりす。
で、現場も上も「こりゃだめだ」になったりするケースとか多くないか？
全員が同じ程度、理解力や柔軟性を持ち知識や実務経験も等しければ
オブジェクト指向での開発はうまくいくのだと思う。
例えば大卒上がりで研修を終えた新人が現場に投入されだしている時期だが、
新人にドキュメント込みで開発中の既存のソースとか読ませると、飲み込みの
早い奴と遅い奴の差が非常に出るわけだ。
構造化時代ならば時間の問題だけど、オブジェクト指向とかだと本人のセンスとか
柔軟性とかで「そこまで考えられません（泣）」なんて事もあったりする。
上としてみれば、新人確保が難しい時期なのでパフォーマンスが悪くても育てたい。
でも、現場に投入してみると、現場の連中からは「使えないのでチェンジ！！」って事に
なったりす。
で、現場も上も「こりゃだめだ」になったりするケースとか多くないか？
834 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:35:23
レジスタ（置数器）はコンピューターの発明当初からあったけど
デザインパターンにはない
デザパタ厨が敗北した原因はここらへんだろう。
デザインパターンにはない
デザパタ厨が敗北した原因はここらへんだろう。
電卓は仕様が既に決定している（そしてバグは誰が見てもバグだと言える）時点で
OOの対象としては不適切だと思うが
OOの対象としては不適切だと思うが
教育なんてのは、、無いよな。今も昔も。
>>883
そりゃデスマなんて言葉は当時はなかったが・・・なんて言葉遊びはどうでもよくて、
今もあるわけじゃない。嫌われる原因ってやっぱ「最初のハードルが高すぎる」
って事なんだと思っているよ。
>>835
そうかもしれないけどさ、人類補完計画なみにならない限り、難しいと思ってる
そりゃデスマなんて言葉は当時はなかったが・・・なんて言葉遊びはどうでもよくて、
今もあるわけじゃない。嫌われる原因ってやっぱ「最初のハードルが高すぎる」
って事なんだと思っているよ。
>>835
そうかもしれないけどさ、人類補完計画なみにならない限り、難しいと思ってる
というか少なくともクラスベースのOOは
Cでやってた構造化プログラミングのノウハウを
言語仕様に移しただけって気もするが。
Cでやってた構造化プログラミングのノウハウを
言語仕様に移しただけって気もするが。
841 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:54:03
評論だけしかできないOO厨
ぷ
ぷ
OOとか構造化以外にどんなのあるっけ？
>>831
￣|￣￣|￣￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|∧ｼﾞｰ
￣|￣￣|￣￣|ﾟ ) ／i
￣￣|￣￣|￣|∪｀ﾞ:ﾞ:｀''':,'.´ -‐i
￣|￣￣|￣￣|: .:: _;.;. :.‐'ﾞﾞ~ ￣
￣￣|￣￣|￣| U
￣|￣￣|￣￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|∧ｼﾞｰ
￣|￣￣|￣￣|ﾟ ) ／i
￣￣|￣￣|￣|∪｀ﾞ:ﾞ:｀''':,'.´ -‐i
￣|￣￣|￣￣|: .:: _;.;. :.‐'ﾞﾞ~ ￣
￣￣|￣￣|￣| U
>>839
構造化時代に出てきた問題はコードの量が増えた事による人件費を
押さえる為にでてきた。それの弊害は理解する力の薄い、最近の本を
よまぬ若者がおおくなり、プログラマ向きではない奴が無理にプログラマ
になっちまうケース。
昔は力仕事でなんとかなっていたけど、今の開発スタイルでは無理多すぎ
>>840
正解。Cでやると面倒なあれこれを言語レベルで包括したのがC++。
構造化時代に出てきた問題はコードの量が増えた事による人件費を
押さえる為にでてきた。それの弊害は理解する力の薄い、最近の本を
よまぬ若者がおおくなり、プログラマ向きではない奴が無理にプログラマ
になっちまうケース。
昔は力仕事でなんとかなっていたけど、今の開発スタイルでは無理多すぎ
>>840
正解。Cでやると面倒なあれこれを言語レベルで包括したのがC++。
ココ電球って冗談のつもりでやってるのか？
それとも電卓使った事がないのか？
それとも電卓使った事がないのか？
848 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 21:25:04
ああ、レジスタは文字列にした方がいいな
849 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 21:26:53
いいかげん誰か相手してやれよ、↑のひと。
ヤです
俺も嫌です
>>844の文章がすげー読みにくい件について
雰囲気を感じるんだよ雰囲気を。気合が足りんわばかもんが。
考えるな。感じるんだ。
ジェダイの騎士
Ruby on Rails やってみ。きっとOOが好きになる。
>>857
(ﾉ∀`)ｱﾁｬｰ
(ﾉ∀`)ｱﾁｬｰ
>>844の文章ﾜﾛﾀ
>>858
Rails の上じゃぁな。好きになっても実力はつかないよん。
Rails の上じゃぁな。好きになっても実力はつかないよん。
>>862
VC++もな
VC++もな
railsのソースを読めばいいんじゃないか？
>>864
それはいいね。
それはいいね。
>>865
結構よみにくいぞ
結構よみにくいぞ
MVC にしろ、 BCE にしろ、OO を中途半端にかじった奴が見たら、
「こんなのはOOじゃない」と言い出しそうだが。
「こんなのはOOじゃない」と言い出しそうだが。
868 ：仕様書無しさん：2007/07/07(土) 22:49:57
このスレのレベルが低い原因
自分では何も書けないクズが
他人の意見に根拠のない誹謗中傷を繰り返すため、
クズにでも物事が理解できるように話題のレベルを下げるため、
連鎖的に話題レベルが低下し続ける
批判ばかりで自分の意見のないお前のことだよ
さっさと死ね
自分では何も書けないクズが
他人の意見に根拠のない誹謗中傷を繰り返すため、
クズにでも物事が理解できるように話題のレベルを下げるため、
連鎖的に話題レベルが低下し続ける
批判ばかりで自分の意見のないお前のことだよ
さっさと死ね
キチガイスレ
ぶ
また荒らしが始まったか
また荒らしが始まったか
ココ電球の設計？はVBっぽいな。
GUIからイベント拾って、あとはいきなりロジックを書き出すパターン。
Document-Viewアーキテクチャつうか、VisualStudio〜VBっぽいつうか
GUIからイベント拾って、あとはいきなりロジックを書き出すパターン。
Document-Viewアーキテクチャつうか、VisualStudio〜VBっぽいつうか
あと、まともそうな設計を拾っていくと・・・
>>379 これ、物理的実体に拘泥しているように見えながら、
結構いいモデルを出している。
まぁ 入力、計算、出力 つう当たり前の要素を当たり前に拾っている、
その当たり前さがいい。
>>425 こいつはゴミだな。プログラムのﾌﾟの字も知らないキチガイ。
>>439 こいつはたぶん>>379の延長線上で考えているんだろうけど、
そもそも設計書とか書いた経験がねぇんだろうな。未開人
>>379 これ、物理的実体に拘泥しているように見えながら、
結構いいモデルを出している。
まぁ 入力、計算、出力 つう当たり前の要素を当たり前に拾っている、
その当たり前さがいい。
>>425 こいつはゴミだな。プログラムのﾌﾟの字も知らないキチガイ。
>>439 こいつはたぶん>>379の延長線上で考えているんだろうけど、
そもそも設計書とか書いた経験がねぇんだろうな。未開人
まぁそれ以外の書き込み(俺の書き込み除く)は、
ゴミというか、存在意義が認められないクズだ
なんでこんなくだんない話に一週間も毎晩毎晩張り付いているの？
そんなにお前の人生は寂しく空しく下らないのか（ｈａｈａｈａ
ゴミというか、存在意義が認められないクズだ
なんでこんなくだんない話に一週間も毎晩毎晩張り付いているの？
そんなにお前の人生は寂しく空しく下らないのか（ｈａｈａｈａ
>>873
ひどい言葉を書いてしまうほど、悲しいことがあったのですか？
周りにいい友人がいらっしゃらないのでしょうか、
それとも趣味などの興味あることがないのでしょうか。
あなたにはあなたの魅力がありますから大丈夫ですよ＾＾
明日はお休みならショッピングでもして気分転換しましょうね！
ひどい言葉を書いてしまうほど、悲しいことがあったのですか？
周りにいい友人がいらっしゃらないのでしょうか、
それとも趣味などの興味あることがないのでしょうか。
あなたにはあなたの魅力がありますから大丈夫ですよ＾＾
明日はお休みならショッピングでもして気分転換しましょうね！
>>872
冗談だよな？
冗談だよな？
スルーしろつったべ？
>>872
マジかぁｗ
マジかぁｗ
このスレ笑えるね
879 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/08(日) 02:44:17
別の課題だすと評論厨は黙り込むからね。
880 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/08(日) 02:48:38
>>872
おまいには「時計」を課題として与える事にする。
おまいには「時計」を課題として与える事にする。
>>839
OOがなぜ出てきたか？
初期の頃の理由はいろいろあるんだろうが、
庶民のレベルでの実際のところは、
プログラムできない奴ができるように思い込む為程度の理由でしかないと思うよ。
OO厨の基本は、
OOでやっても再利用時の問題は軽減できないのにできると思い込み、
継承を繰り返し悦に浸って、かえって再利用どころじゃなくない状況を生み出す。
（クラス図は継承が無いとなんか寂しいんだろうし、継承じゃなくて移譲にすると繋ぎのコード書くの面倒なのかもな）
また、潔癖なOO厨はOO以外を認めない為、無理矢理にOOのコードを書いたりもする。
ろくなIDEも無いのに、読みにくいだろ。無理すんなよ、バカ。
もう全部バカの思い込みなのに、バカはOO以外をバカとか言ったりとかもしてほんとバカ。
OOがなぜ出てきたか？
初期の頃の理由はいろいろあるんだろうが、
庶民のレベルでの実際のところは、
プログラムできない奴ができるように思い込む為程度の理由でしかないと思うよ。
OO厨の基本は、
OOでやっても再利用時の問題は軽減できないのにできると思い込み、
継承を繰り返し悦に浸って、かえって再利用どころじゃなくない状況を生み出す。
（クラス図は継承が無いとなんか寂しいんだろうし、継承じゃなくて移譲にすると繋ぎのコード書くの面倒なのかもな）
また、潔癖なOO厨はOO以外を認めない為、無理矢理にOOのコードを書いたりもする。
ろくなIDEも無いのに、読みにくいだろ。無理すんなよ、バカ。
もう全部バカの思い込みなのに、バカはOO以外をバカとか言ったりとかもしてほんとバカ。
882 ：仕様書無しさん：2007/07/08(日) 04:17:34
キチガイスレ
時計の本質はなんだ？
884 ：仕様書無しさん：2007/07/08(日) 09:01:06
電卓の設計もできない奴が話題ずらしに必死ｗ
せんせー電卓できますた
while gets
puts eval "#{$_}"
end
while gets
puts eval "#{$_}"
end
幼児退行症の一種だろ
できない事があると、それを解決せずによりレベルの低い問いかけを発する症状
引き篭もり自称トレーダに多い症状だｗ
できない事があると、それを解決せずによりレベルの低い問いかけを発する症状
引き篭もり自称トレーダに多い症状だｗ
いつ電卓つくってくれるんだよ。口だけか？
誰からも相手にされない人間になってしまうぞ。
誰からも相手にされない人間になってしまうぞ。
>>887
面倒くさいし、もったいないしな。
面倒くさいし、もったいないしな。
>>842
機能ベースのモジュール分割。
C言語で関数スコープ、ファイルスコープのstaticな変数を使うアレ。
モジュールがデータ(状態とか)を保持する場合で構造化ではないし、
機能によるモジュール分割なので、オブジェクト指向でもない。
機能ベースのモジュール分割。
C言語で関数スコープ、ファイルスコープのstaticな変数を使うアレ。
モジュールがデータ(状態とか)を保持する場合で構造化ではないし、
機能によるモジュール分割なので、オブジェクト指向でもない。
電卓厨必死だなｗｗ
891 ：仕様書無しさん：2007/07/08(日) 19:55:24
オブジェクト指向の何が巧妙って
データとメソッドが近い位置に存在することでキャッシュメモリにヒットしやすい、
それでいてconstもあるから無駄なメモリを消費しない、
ってところだよな
データとメソッドが近い位置に存在することでキャッシュメモリにヒットしやすい、
それでいてconstもあるから無駄なメモリを消費しない、
ってところだよな
>>891
リンカの出力をちゃんと調べた方がよくないか？
リンカの出力をちゃんと調べた方がよくないか？
>>891
普通データキャッシュと命令キャッシュは別々で、しかもキャッシュアルゴリズムからして違うが。
ついでにconstについてだが、C++のメンバ関数のconstのことなら付けておく事による最適化作用はないぞ。
付けても外から書き換える手段が存在するし、実際const付きの関数を使ってメンバ変数を書き換える方法はキャストやmutableのような物を頼らなくても簡単にできる。
普通データキャッシュと命令キャッシュは別々で、しかもキャッシュアルゴリズムからして違うが。
ついでにconstについてだが、C++のメンバ関数のconstのことなら付けておく事による最適化作用はないぞ。
付けても外から書き換える手段が存在するし、実際const付きの関数を使ってメンバ変数を書き換える方法はキャストやmutableのような物を頼らなくても簡単にできる。
普通コードセグメントとデータセグメントは別だしな。
クラスがもつVMTへのポインタが纏まってるだけ。
クラスがもつVMTへのポインタが纏まってるだけ。
>>891
多いですよね。困ったもんだ。技術は体系立てて学ばないとね。
多いですよね。困ったもんだ。技術は体系立てて学ばないとね。
俺には>>891がキチガイに見えてしまうんよ
>>891の人気にしっと
899 ：仕様書無しさん：2007/07/08(日) 21:53:06
JVM環境でも命令キャッシュとデータキャッシュ別々にキャッシュされるか？
constじゃなくてstaticだね
constじゃなくてstaticだね
Java信者はいつもこうだ
OOを導入したことで
プロジェクトが成功した・失敗した、ってことがある人いる？
プロジェクトが成功した・失敗した、ってことがある人いる？
今日もキチガイスレ
毎日一人で書き込みご苦労さん
よっぽど暇な人生を送っているのだろうね
よっぽど暇な人生を送っているのだろうね
>>899
んなもんはVMの実装次第じゃねぇの？
んなもんはVMの実装次第じゃねぇの？
906 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 00:24:12
キチガイじゃなくてただのアホじゃん。
キチガイに失礼だろ
キチガイに失礼だろ
↑キチガイ
なんだこのスレ
別に嫌われてないだろ
というか物凄い基本的な話、たとえば人物情報の記録で
name[i] address[i] tel[i] ・・・
その扱いが
print_(" ･･･" ,name[i], addres[i] ,tel[i]);
とあるのを
p[i].name p[i].address p[i].tel
という形にして
p[i].print(); ( p::print(" ･･･", name, address, tel); )
とした方がまとまる、「超ベースは」そういうものなわけで。
定義量が一見若干増えたりするが、結果的に安定したり見やすくなったり改変が楽になったりする。場合が多くなる。
少なくとも、後者の書き方をしていく指向−志向を持つ人間は「嫌われている」のか？
前者の書き方で通すプログラマだけが歓迎、なのか>>1の周囲では。
オブジェクト指向自体を嫌う、ということは実際そういうレベルのことになってしまうわけだろう揚げ足取りじゃなく。
別に嫌われてないだろ
というか物凄い基本的な話、たとえば人物情報の記録で
name[i] address[i] tel[i] ・・・
その扱いが
print_(" ･･･" ,name[i], addres[i] ,tel[i]);
とあるのを
p[i].name p[i].address p[i].tel
という形にして
p[i].print(); ( p::print(" ･･･", name, address, tel); )
とした方がまとまる、「超ベースは」そういうものなわけで。
定義量が一見若干増えたりするが、結果的に安定したり見やすくなったり改変が楽になったりする。場合が多くなる。
少なくとも、後者の書き方をしていく指向−志向を持つ人間は「嫌われている」のか？
前者の書き方で通すプログラマだけが歓迎、なのか>>1の周囲では。
オブジェクト指向自体を嫌う、ということは実際そういうレベルのことになってしまうわけだろう揚げ足取りじゃなく。
それはCでちょっと気を利かせれば出来るレベルよね
前提をはっきりさせないから話がずれてるだけじゃねーの？
OOが嫌いなのか、
それともOOを取り巻く環境（何を学習すればよいか明確でない等）への不満なのか、
それともOOを理解している人がいないことによる失敗プロジェクトが嫌いなのか、
などなど、前提を決めてからじゃないと。
OOが嫌いなのか、
それともOOを取り巻く環境（何を学習すればよいか明確でない等）への不満なのか、
それともOOを理解している人がいないことによる失敗プロジェクトが嫌いなのか、
などなど、前提を決めてからじゃないと。
ぶっちゃけC++やJavaの言語仕様がめんどくさいからじゃねーか?
嫌ってるのってC++使えないC使いかVB.NET使えないVB6使いぐらいじゃないの？
あとコード書けない設計者とかかな？
あとコード書けない設計者とかかな？
VB.NETに移行できないVB6使い多すぎ。
話を聞いてみれば、VB6自体を分かってないことがあるし。
というか、上役が.NetはOO必須ってのを理解してないままだからなあ。
そういう奴がいる時点で終わってるし。
話を聞いてみれば、VB6自体を分かってないことがあるし。
というか、上役が.NetはOO必須ってのを理解してないままだからなあ。
そういう奴がいる時点で終わってるし。
VB.netは基本的に旧VBの延長でいけるにはいける
というか解説本ではオブジェクト指向であることを隠蔽しているようにすら見える
というか解説本ではオブジェクト指向であることを隠蔽しているようにすら見える
VB6の良さはコントロール配列にあると思ってる俺からすれば
VB.netは所詮MSに支配された糞ツール
オブジェクト指向云々よりツールとして駄目だと思う
VB.netは所詮MSに支配された糞ツール
オブジェクト指向云々よりツールとして駄目だと思う
クラスモジュールの使いどころがわからないVB6使いは多そう。
というか構造化もモジュールの再利用も何も考えてないので
イベントハンドラにごっそりコード書く奴大杉。
というか構造化もモジュールの再利用も何も考えてないので
イベントハンドラにごっそりコード書く奴大杉。
てか、VB6がそういう使い方じゃなくて
サクって作ってハイおしまい的な使い方が主
これで大規模とか言ったら死にかねないが
もうホントその場限りの小規模ツールにはこれしかないってぐらいよかった
サクって作ってハイおしまい的な使い方が主
これで大規模とか言ったら死にかねないが
もうホントその場限りの小規模ツールにはこれしかないってぐらいよかった
privateとpublicの違いが分からん奴おるからな。
その概念分かってる奴の中にも、カプセル化、というと？マークでる奴いるし。
概念分かってれば言葉なんていくらでもついてくるからいいんだけど、
クラスモジュール使ったことのないVB6使いは
継承でいくらか振り落とされるのかもしれんな。
その概念分かってる奴の中にも、カプセル化、というと？マークでる奴いるし。
概念分かってれば言葉なんていくらでもついてくるからいいんだけど、
クラスモジュール使ったことのないVB6使いは
継承でいくらか振り落とされるのかもしれんな。
ダメなVB6使いの例。
イベント用フラグが乱立し、各イベントメソッドでフラグ制御の嵐。
クラスモジュール？なんですかそれ？って奴を何人見たことか。。。
イベント用フラグが乱立し、各イベントメソッドでフラグ制御の嵐。
クラスモジュール？なんですかそれ？って奴を何人見たことか。。。
920 ：仕様書無しさん：2007/07/09(月) 09:09:45
何かするたびに
イベントフラグチェックプロシージャを呼び出して
コントロールを設定してから
処理を始める、とかだなｗ
イベントフラグチェックプロシージャを呼び出して
コントロールを設定してから
処理を始める、とかだなｗ
921 ：仕様書無しさん：2007/07/09(月) 11:26:48
昔VBでバイトしてとき
イベントハンドラの中が小さくなるように書いたら
文句言われたよ。
イベントハンドラの中が小さくなるように書いたら
文句言われたよ。
まあ、そういうところならクラス図書いてクラス構成決めて・・なんてやってられるか！
だろうな。イベントもスコープも何もかもがスパゲッティ。
そのくせ妙な規約馬鹿なコードだったりする。
だろうな。イベントもスコープも何もかもがスパゲッティ。
そのくせ妙な規約馬鹿なコードだったりする。
データと機能を分離させる事もまたOOPの技術(iterator pattern)なんだよなぁ
やばい混乱してきたわ
やばい混乱してきたわ
926 ：仕様書無しさん：2007/07/09(月) 16:37:35
オマエは意味不明な主張で議論をかき回した挙げ句に
自分自身でも何を主張しているのか判らなくなる自滅パターンが多過ぎる。
アルツハイマー入ってるだろ
自分自身でも何を主張しているのか判らなくなる自滅パターンが多過ぎる。
アルツハイマー入ってるだろ
電卓が作れない
気がついたらいつも同じスレばかり見てる
そして今だ 電卓来ない
あきらめずに煽るレスを入れるけど
すぐに流れて行くよ
OOPがあれば 楽に電卓できるハズだけど
何回やっても何回やっても 電卓が作れないよ
たまに出てくる狂ったようなクソ設計 >>371
気がついたらいつも同じスレばかり見てる
そして今だ 電卓来ない
あきらめずに煽るレスを入れるけど
すぐに流れて行くよ
OOPがあれば 楽に電卓できるハズだけど
何回やっても何回やっても 電卓が作れないよ
たまに出てくる狂ったようなクソ設計 >>371
public interface CalcService {
値 足算(値 val1, 値 val2);
値 引算(値 val1, 値 val2);
値 乗算(値 val1, 値 val2);
値 除算(値 val1, 値 val2);
}
値 足算(値 val1, 値 val2);
値 引算(値 val1, 値 val2);
値 乗算(値 val1, 値 val2);
値 除算(値 val1, 値 val2);
}
結局おじゃばって分かってないな。
>371なんて計算機のUIの話だよな。
本質的にOOする人は>929だな
>371なんて計算機のUIの話だよな。
本質的にOOする人は>929だな
関数オブジェクトか
これらを引数にとる合成関数オブジェクトとか用意すれば
複雑な式も動的に構成できちゃうんだよな
これらを引数にとる合成関数オブジェクトとか用意すれば
複雑な式も動的に構成できちゃうんだよな
>932
おいおい。。
おいおい。。
AMD
AMD
>>929
本質的にやるなら、電卓に加減乗除以外の機能が増えることを予想して
基底クラスもしくはインターフェースとして Operator を定義し
それを派生もしくは実装する形で加算クラス減産クラス乗算クラス除算クラスを定義するんじゃね？
本質的にやるなら、電卓に加減乗除以外の機能が増えることを予想して
基底クラスもしくはインターフェースとして Operator を定義し
それを派生もしくは実装する形で加算クラス減産クラス乗算クラス除算クラスを定義するんじゃね？
class SuperClassDentaku{
public:
virtual void push0key() = 0;
virtual void push1key() = 0;
virtual void push2key() = 0;
:
virtual pushAnswerkey() = 0;
};
public:
virtual void push0key() = 0;
virtual void push1key() = 0;
virtual void push2key() = 0;
:
virtual pushAnswerkey() = 0;
};
AMD
I'v got a respons 939 of this thread.
Its AMD
hahahahaha
Its AMD
hahahahaha
calc.addFunc<Plue>();
みたいに機能追加できたら楽しいなぁとか
みたいに機能追加できたら楽しいなぁとか
ミスった、>>930だった
電卓はもういいべ
943 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 21:14:01
OOの設計は普通の設計の１００倍かかる事は判った。
電球が普通の設計を見せてくれるそうです。
>>936
IFの内部ではそういうクラス群があるかもね
IFの内部ではそういうクラス群があるかもね
もうこうなったら、
クロージャなり内部クラスなりをモデルのハッシュに突っ込んどいて
コントローラからハッシュのキーだけ渡しちゃえよ。
クロージャなり内部クラスなりをモデルのハッシュに突っ込んどいて
コントローラからハッシュのキーだけ渡しちゃえよ。
Operatorなんか定義してたら、関数電卓作るの大変だろｗ
950 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/09(月) 21:56:31
>>666,668
とりあえず、継承使わずに変更前と変更後を、フラグなしで使い分けるにはどうすればいいか教てくれ。
>>669
回答の意図が分からない。
ボタンを増やしてもコードに修正が入らないと言っているのかな？
>>670
どこだ？
>>671
高レベルな違いを見せてくれ。
>>673
MVCとOOは無関係。
とりあえず、継承使わずに変更前と変更後を、フラグなしで使い分けるにはどうすればいいか教てくれ。
>>669
回答の意図が分からない。
ボタンを増やしてもコードに修正が入らないと言っているのかな？
>>670
どこだ？
>>671
高レベルな違いを見せてくれ。
>>673
MVCとOOは無関係。
>>949
単純に片方の数の配列の数だけで１０の桁数乗・・・ｗ
単純に片方の数の配列の数だけで１０の桁数乗・・・ｗ
>>949
自動車のエンジンコントロールの関数はそんな感じ
自動車のエンジンコントロールの関数はそんな感じ
953 ：仕様書無しさん：2007/07/09(月) 22:07:51
電卓設計すらできないOO設計レベルだと、OOを使って仕事できるレベルに程遠いじゃね。
おまいらって、実は仕事でOO使ってないだろ、どうよ？
えっ、おれ？、ま、使ってるふりしている感じかな。
おまいらって、実は仕事でOO使ってないだろ、どうよ？
えっ、おれ？、ま、使ってるふりしている感じかな。
954 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 22:26:30
955 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/09(月) 22:29:54
>>684
>うわｗ・・ｱｲﾀﾀﾀ・・第一に親クラスへの影響がないかどうかはOOの範疇ではない。
何でアクセスコントロールの話が出て来るのか分からない。何の話？
あと「aggregationを使え」って具体的にどう組めって事だ？
>断じて違うね、自由なのは呼び出す側じゃない、幾重にも継承され、まったく似たような動作が
具体的に何の事言っている？標準クラスの事か？それとも自作のクラスを「幾重にも継承」して
使っているのか？
>うへぇ・・・反吐が出そう・・・alogrithmとcontainerの違いすら認識できんのか・・・・・orz
アルゴリズムもコンテナも理解しているが、なぜここでその話が出て来るのか分からない。
>ココで問う、あなたはscratchから継承されうるpublic classを作成する選択するのは何故か
>それを選ぶのは流行であったり、安易な選択ではないのか？
何言っているんだ？継承使うは安易だと言っているのか？
とりあえず、英語が入っている文章は軒並み意味不明だ。
>うわｗ・・ｱｲﾀﾀﾀ・・第一に親クラスへの影響がないかどうかはOOの範疇ではない。
何でアクセスコントロールの話が出て来るのか分からない。何の話？
あと「aggregationを使え」って具体的にどう組めって事だ？
>断じて違うね、自由なのは呼び出す側じゃない、幾重にも継承され、まったく似たような動作が
具体的に何の事言っている？標準クラスの事か？それとも自作のクラスを「幾重にも継承」して
使っているのか？
>うへぇ・・・反吐が出そう・・・alogrithmとcontainerの違いすら認識できんのか・・・・・orz
アルゴリズムもコンテナも理解しているが、なぜここでその話が出て来るのか分からない。
>ココで問う、あなたはscratchから継承されうるpublic classを作成する選択するのは何故か
>それを選ぶのは流行であったり、安易な選択ではないのか？
何言っているんだ？継承使うは安易だと言っているのか？
とりあえず、英語が入っている文章は軒並み意味不明だ。
956 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 22:35:23
ハッシュにフライウエイトにメメント。
意味判ってないで書いてるやつが常駐してるな。
意味判ってないで書いてるやつが常駐してるな。
957 ：仕様書無しさん：2007/07/09(月) 22:41:49
最近のム版の流行語、読み手依存って知ってる？
全ての文は読み手依存なんだよ。
全ての文は読み手依存なんだよ。
とりあえずコンピュータにプッシュなんちゃらっていうメソッド作るのはヒドイｗ
>>957
それどういう意味？なんか興味がある
それどういう意味？なんか興味がある
遅い言語が多いからだろ。
といって速い言語でやろうとするとついていけない人が続出。
といって速い言語でやろうとするとついていけない人が続出。
メメントって映画あったよね？
遅い速いなんて問題じゃねーよばか
>>961
メメントをOOで設計か
メメントをOOで設計か
965 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/10(火) 23:37:50
次スレのタイトル
【オブジェクト指向はやっぱり詐欺だったのか？】
【オブジェクト指向はやっぱり詐欺だったのか？】
クラスと継承とインターフェースあたりが分かればいいでしょ。
わからんちんには、
「ゲームの自機と敵キャラがキャラクラスのインスタンス」
「攻撃メソッドを自機が使えばレーザー、ボスが使えばボスキャラ攻撃」
とか大雑把なこと言えばわかってくれる、、、こともある。
わからんちんには、
「ゲームの自機と敵キャラがキャラクラスのインスタンス」
「攻撃メソッドを自機が使えばレーザー、ボスが使えばボスキャラ攻撃」
とか大雑把なこと言えばわかってくれる、、、こともある。
弾１個１個もインスタンスなんじゃねw
どんだけ〜
どんだけ〜
ラーメンもインスタンスだよな
969 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/11(水) 00:54:27
弾一個一個インスタンスにするよ。当然
実行時バインディング
最近どこの板のどのスレもただレスつけて欲しい為だけに
釣りレス撒いて暇つぶしてるアホばっかになったな。
釣りレス撒いて暇つぶしてるアホばっかになったな。
なんで自分の理解できないものは皆が理解できないと思い込むのだろう？
なんで自分がやっと理解できたものは皆はあまり理解できていないと思い込むのだろう？
なんで風呂に入ったあとに足の側面をこすると垢がいっぱいでてくるんだろう？
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
↓↓↓↓↓ ↓↓↓↓↓
↓↓↓↓↓ ↓↓↓↓↓
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
>>971
COBOLer以下のレベルの奴が「バカの振り」してるから、もう目も当てらんない惨状だ
COBOLer以下のレベルの奴が「バカの振り」してるから、もう目も当てらんない惨状だ
じゃあ次スレはこれで
「なぜオブジェクト指向修得者が少ないのか」
「なぜオブジェクト指向修得者が少ないのか」
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
↓↓↓↓↓ ↓↓↓↓↓
↓↓↓↓↓ ↓↓↓↓↓
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
じゃあ次スレはこれでどうだ？
「なぜオブジェクト指向は使い物にならないのか？」
なんか釣りみたいだな
「なぜオブジェクト指向は使い物にならないのか？」
なんか釣りみたいだな
使い物にならない奴がなにかごしょごしょつぶやいているようだな
社会の底辺って感じｗｗｗ
社会の底辺って感じｗｗｗ
ごしょごしょっつーか
ごにょごにょだな
ごにょごにょだな
985 ：仕様書無しさん：2007/07/11(水) 01:41:38
なに第三者視点でかたっちゃってるをだかｗｗｗ
話の本題は、キミが社会人として使い物にならないという話なわけだが
話の本題は、キミが社会人として使い物にならないという話なわけだが
986 ：仕様書無しさん：2007/07/11(水) 01:42:42
なに第三者視点で騙っちゃってるんだかｗｗｗ
話の本題は、キミが社会人として使い物にならないという話なわけだが
話の本題は、キミが社会人として使い物にならないという話なわけだが
なに第三者視点でかたっちゃってるをだかｗｗｗ
話の本題は、キミが社会人として使い物にならないという話なわけだが
話の本題は、キミが社会人として使い物にならないという話なわけだが
をだか
訂正しときました
訂正しときました
次スレのタイトル
【PGは】なぜオブジェクト指向は嫌われているのか？2【ドンキホーテ】
【PGは】なぜオブジェクト指向は嫌われているのか？2【ドンキホーテ】
次スレのタイトル
【ココ電】なぜオブジェクト指向を嫌っているのか？2【おじゃばさま】
【ココ電】なぜオブジェクト指向を嫌っているのか？2【おじゃばさま】
991 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/11(水) 22:26:26
次スレのタイトル
【いいかげん】なぜオブジェクト指向をマスターしようとしないのか？2【学習しろよ】
【いいかげん】なぜオブジェクト指向をマスターしようとしないのか？2【学習しろよ】
おじゃばvsココ電のガチバトル見せてよ
本当のマスターは開祖だけでは無いのか？
ニュートン力学知らなくたってブランコには乗れる
>>994
壊滅的なレベルの低さの日本の高校物理
まさかF=maの数式遊びでセンター余裕とかありえないｗ
ちょっと気体の話が入るだけで後全部F=ma
お前、そんなに馬鹿でどうすんのかとｗ
andそれすら怪しい教師
日本の物理は普通に終わってると思うｗ
壊滅的なレベルの低さの日本の高校物理
まさかF=maの数式遊びでセンター余裕とかありえないｗ
ちょっと気体の話が入るだけで後全部F=ma
お前、そんなに馬鹿でどうすんのかとｗ
andそれすら怪しい教師
日本の物理は普通に終わってると思うｗ
私も前々回と前回のテストを見ましたけど、
日本の学力は本気でやばいですね。
自分の入試の時点で「これは満点を取って当たり前だな」で、
既に期待はしていませんでしたけど、
最近のテストはさらにひどくなっていますし。
基本が大切といいながら、
基本すらカバーせずに点数が取れるテストってなんだろうね。
日本の学力は本気でやばいですね。
自分の入試の時点で「これは満点を取って当たり前だな」で、
既に期待はしていませんでしたけど、
最近のテストはさらにひどくなっていますし。
基本が大切といいながら、
基本すらカバーせずに点数が取れるテストってなんだろうね。
そうか本来は東大京大の二次レベルでも理系なら数学物理は余裕で満点取れて然るべきなんですね
高校範囲の知識だけでとか言われたら9割型の学生には無理だと思いますけど
とすれば自主的に大学教養レベルぐらいはやって当たり前と
誰の導きもなしにそこまで辿り着ける人間がどれだけいる事やら
高校範囲の知識だけでとか言われたら9割型の学生には無理だと思いますけど
とすれば自主的に大学教養レベルぐらいはやって当たり前と
誰の導きもなしにそこまで辿り着ける人間がどれだけいる事やら
つか、生物や化学と違って
物理だけ全く理解できてないやつが公式だけ書き殴ったような教科書に
なってるからF=maを使い倒して問題を解く力がつかない
物理ってどういうもん？って理解する以前に門前払いをしてしまってるのが問題だと思う
物理だけ全く理解できてないやつが公式だけ書き殴ったような教科書に
なってるからF=maを使い倒して問題を解く力がつかない
物理ってどういうもん？って理解する以前に門前払いをしてしまってるのが問題だと思う
999 ：仕様書無しさん：2007/07/12(木) 07:25:58
だれか次スレヨロ
【タイトル】
なぜオブジェクト指向は電卓も作れないのか？
【内容】
前スレ
なぜオブジェクト指向は嫌われているのか？
http://pc11.2ch.net/test/read.cgi/prog/1183255047/
【タイトル】
なぜオブジェクト指向は電卓も作れないのか？
【内容】
前スレ
なぜオブジェクト指向は嫌われているのか？
http://pc11.2ch.net/test/read.cgi/prog/1183255047/
いまどきOOに文句言うなんて、どれだけ頭が馬鹿なんだよ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。