1 ：
仕様書無しさん ：
2007/07/01(日) 10:57:27 2 ：
仕様書無しさん ：2007/07/01(日) 11:04:35
考えれば考えるほど嫌いになっていく。
モジュールの結合度の問題について何も理解してないから
前スレの
>>853 なんて、その典型
オブジェクト指向以前に、抽象データ型の利点が理解できない奴がいるとは驚いた
おじゃぱが
おじゃばは基本的に休日はレスしない
7 ：
仕様書無しさん ：2007/07/01(日) 11:58:12
電卓のクラスを作ってみよう。
前すれのくだんねー議論に横レス
溶岩流アンチパターンの一因について盛り上がっていたね。
11 ：
仕様書無しさん ：2007/07/01(日) 12:48:48
前スレのリゾットメソッド君には驚いたな
オブジェクト指向が嫌われる理由
上役が分からなくても、自分たちが価値を見出して活用できればいいのでないの？
自分たち、ってのは誰を指してんだ？
>>15 自分たち＝オブジェクト指向をコードで実践するプログラマたち
って思ってくれ。
わからんちんは教育するしかないな。
わからんちんが見込みなければ、オブジェクト指向はあきらめて、
構造化でも何でも理解できる方法論使ってやってくれ。
用語を統一してくれと何度か思ったけど、もうどうでもいいや
>>16 なぜオブジェクト指向は嫌われているか・・・わかったよ！
>>16 なぜオブジェクト指向は嫌われているか・・・わかったよ！
20 ：
仕様書無しさん ：2007/07/01(日) 14:29:59
学校でC言語学んでいるとですが
まずC言語を学んでください
23 ：
仕様書無しさん ：2007/07/01(日) 14:33:45
Cは（当然言語だが）OOPを言語レベルでサポートしていない
>>20 Cの標準関数でも引数にオブジェクトへの参照を必要とする関数群（fprintfとかね）は
広い意味で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でもオブジェクト指向的なコードは書けるよ。
新コテハンかと思ったらココ電かよ・・・
統計とったわけでも無いのに属人的な問題にしてしまうのは思考停止
日本語でおｋ
34 ：
格之進 ◆xiPQGz7lVI ：2007/07/01(日) 15:17:04
オブジェクト指向といっても、要するに一つの道具なんだから、
>>30 クラスベースのOOなプログラミングはCでは無理。
>>35 第一引数に構造体を突っ込むのと何が違うの？
つまり、fopenとかそんなのみたいなもん
面倒なだけで不可能ではない。
>>36 それを強制・支援するクラスって概念が無いから、約束事を決めてコーディングしないと
いけないからだお。
CではOOっぽく作れるだけで、
>>30 C++でも最後には機械語になる。
OOPの動きを真似て良い所だけをつまんで使うのが由。
アセンブラレベルでの働きは、昔からよく使われている手法だし。
継承の真似事、仮想関数の真似事（直前まで呼び出し先が未定）を
する感じの物はCやアセンブラでよく作った。
>>39 継承やインターフェースなんて大して重要でもねーよ
しかも両方後付けじゃねぇか
>>42 重要でもねーよ？
CでOOっぽく作ることは確かにできるが
そんなことするぐらいならC++の方がいいだろ
オーバーロードなんかはどうすんだ？
>>43 構造体と関数へのポインタでゴリゴリやんだよ。
>>43 そりゃＯＯを表現するのになきゃいけないもんか？
俺は使ってねぇけど
混乱の元だから
すでにC/C++それぞれの役割分担はだいたい決まっている話なので、どうでもいい。
Cでもマクロを駆使して継承やインターフェースを実現させてるシステムはあるよ。
>>47 お前、オブジェクト単位で表現することよりもＣ＋＋のテンプレートとか
妙な小細工機能使ってＯＯを理解してると思い込む性質だろ？
言語に頼るのはＯＯとは言わない。
>>49 そういうことじゃなくて、
>>48 みたいなことをあんたはわざわざやるのか、ってこと。
ラクして作りゃあいいのに
OO以前の話じゃん
まあ、結局、CからC++ や Java 移っても、
それでいいじゃん
>>51 だったらわかってないとは言わないじゃん
意味不明
そういえば、かつてのg++って、なんかオプションでC++のコードをC言語のコードに変換できたよな？
継承もオーバーロードもインターフェースも OO の本質ではない
>>57 C言語の話を書いてあるだけでスレタイと無関係
>>58 Cで継承もオーバロードもできるって書いてあるじゃん
>>60 もう一回書くぞ
"C言語の話"を書いてあるだけで"スレタイ"とは無関係
>>60 しつっこいから見に行ってみたけど、これ、「C言語でオブジェクト指向やってると思いこむためのコードの書き方」でないの。
メソッドもどきは、関数の先頭を Staff_ で統一してるだけだし。
強固な意志と思想を持ったプログラマであれば、こういうコードでもOOのカプセル化などを達成できるだろうけど、
そうでない大半のプログラマは、面倒くさくなってグローバル変数入れたりして、破綻させちゃうよ。
>>60 昔のC++コンパイラはバイナリじゃなくてC言語のソースを生成してた
つまりC++のソースをコンパイルするとCのソースが生成されて、
それをコンパイルするとバイナリになった。
CでOOを別に書けん事も無いが、それは「C言語であってC++言語ではない」
そこでObjective-Cですよ
スレタイ厨は半年ROMってろ
OOPはOOPLでなくてもできる
>>67 がスレタイとは関係の無い実のある話をしてくれるそうです
オブジェクト指向が嫌われる原因は、
class 電卓キー {
「電卓キー」を表現するなら、こうじゃないの。
73 ：
仕様書無しさん ：2007/07/01(日) 18:41:47
>>71 どうやってアクセスするんだか。
そもそも、どう使うのか。
というより、初心者でも解りそうだが。
76 ：
仕様書無しさん ：2007/07/01(日) 18:46:32
>>75 設計とも言えないくらい穴のある設計ですね。
自演発覚の瞬間を見た
(・∀・)
class 電卓キー {
いや、そうやって、オブジェクト指向を、
またお前らＵＩ無視ですか．．．
83 ：
仕様書無しさん ：2007/07/01(日) 19:14:24
>>80 お前そんな設計でもないもの見せられても、ちゃんと設計しろ。としか言えない訳よ。
まずデータ構造からだ。
どんなデータを扱うか？それが分からないとクラスの奥も何もないぞ。
>>80 おまい、計算ボタンひとつひとつを継承クラスにしてしまおうって魂胆だろ？
ところで何この糞コテ
87 ：
仕様書無しさん ：2007/07/01(日) 19:19:50
オブジェクト指向は奥義なのです。
88 ：
仕様書無しさん ：2007/07/01(日) 19:35:19
もう既出で答えられず顔真っ赤なんだろ？
ていうか、万人にわからん時点で糞設計ということは確定してるがな
VB.netの初心者本を本屋で見てみたら
こんなわからんもん出して悦にいってる自分を恥じれよｗ
ＶＢ．Ｎｅｔは糞
オブジェクト指向は達人用の道具なので、万人向けではないのでは？
>>94 そんなオブジェクト指向なら、無い方がいい。
オブジェクト指向とは、そんな難解な暗号制作技術じゃない。
>>94 設計技術でわかりにくいとかすでに目的が不明ｗ
97 ：
仕様書無しさん ：2007/07/01(日) 20:03:58
>>97 まさか、その分かりにくいと言うのが、
英語やドイツ語圏の人に日本語見せる程度の分かりにくさだろう？
覚えずに分かりにくいも何もネエよ。
本格的にオブジェクト指向されてなくても、
101 ：
仕様書無しさん ：2007/07/01(日) 20:19:13
>>98 そのとうり。
全く以て使えない。
>>99 覚えた所で使いこなせるか？
と、言われると。
どうだろう？と、首を傾げてしてしまうほどの世界。
指向とはそういうものだよ。
だから、OOは
楽譜が書けるからといって、名曲が作れるわけではない。
>>104 そうだね
でも、他人に自分の作曲した作品を伝える為には便利だよ。
尤も、相手が楽譜を読めればの話だけどさ。
今なら演奏そのものを録音してしまえばいいとかそんな話してるのと同じ。
おれなんか最初から自然にオブジェクト指向だったよ。
107 ：
仕様書無しさん ：2007/07/01(日) 20:31:47
>>106 向いてるんじゃね？
ただし、オブジェクト指向嫌いになる確立あり。
確率を確立と書くのは、何故なんだぜ？
名曲を作るヒントの一つにオブジェクト指向があるわけなので、
110 ：
仕様書無しさん ：2007/07/01(日) 20:36:31
どこぞのアホが、義務教育で確率を確立と書くように改めたんだって偽情報が反乱してた時期があってな。
そうだよね。
そうか！オブジェクト指向は芸術だったんだ！
>>113 それをいうならプログラムはだろ？
頭悪いのなｗ
まあ、誰もプログラムに芸術なんて求めていないけどな。
匠の技か。ワクワクするぜ。
>>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
OOで設計できる奴が少ないだけだろ
せっかくのオブジェクト指向なのに、クラス分けと機能分けを混同して、同じ概念を複数別々に実装してるプロジェクトを結構見かける。
XX業務クラスってか？ありがち
>>126 インターフェースわざわざ一致させる意味がわからない
別部署が担当することになったらさらに意味がない
ちゃんと説明できた上で煽ってんの？ん？
それとも本読んだらそう書いてあっただけ？
なんかただ煽ればいいみたいな奴多くて嫌なんだよね
おまいらが全員死んでオレのクローンが開発すれば
>>129 クローン分のお前のおとんとおかんと妹が必要じゃね？
ひきこもりだろうから友だちは必要なさそうだけど
UML覚えるのがねえ
>>131 大半がUMAの知識で代用できる
新しく覚えることはほとんどない
覚えるまでもなく、見りゃわかんだろ
>>128 一回きりの使い捨てプロジェクトなら、いいけどね。
これから新規で使うプラットフォームのためのクラスなんだよ。
もうね、その割にクラス構成とか、グッチャグチャ。
>>134 グチャグチャの根本的原因がお前のいうことのような気が全くしねぇの
単純にグローバル変数とか普通に使ってあるからキモイことになってるだけなんじゃねぇの？
JavaやC++の経験があっても無理な奴は無理。
UMLは出発点に過ぎないよね
>>136 技術のあるなしってどうやって判断するつもりだよ
>>137 継承関係を表した図なのか
状態遷移図なのか
関連図なのか
インスタンスの有り方を表した図なのか
わからんのでもうそういうクラス関連の図はいらんｗ
作ってる奴ですら間違いに気付いてない
文句付けると大抵逆上する
もう一枚たりとも書くなといいたい
>>136 前半は同意
後半は、具体的にどうすればいいか不明？
>>135 ああ、無駄なクラスが山のように作られてるよ。
この時だけは使うクラスはこっち。あの時だけはこっちを使うってな。
もうね、ポリモフィズムもなにもあったもんじゃねえ。
しかも使い分ける用にその間を取り持つクラスを作ってる有り様。
「汎化ってなんですか？」
>>141 お前のいってることが意味不明
俺、そんなことで困ったことねぇし
普通にグローバル変数が使ってあってキタネェだけなんだろ？
構造化は一般的な言葉か？
C/C++で分散開発なんて聞いたことねえからJavaなんじゃね？
>>142 まさしくOOが嫌われる原因だな
自分が学習してたとしてもわからんちんに説明するときに
どうしても用語の壁にぶちあたる
147 ：
仕様書無しさん ：2007/07/01(日) 23:43:46
>>146 あたんねーだろ普通
実は自分もよくわかってねぇもん説明してっから変な言葉使って誤魔化そうとしてんだろ
理解してないのバレバレ・・・みたいなｗ
>>144 構造化って言葉は知らなくても開発できるからね
でもOOは設計から実装するときに翻訳が発生する
150 ：
仕様書無しさん ：2007/07/01(日) 23:45:43
汎化だってニュアンスでわかんだろ普通
>>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;
}
>>148 そうか？
146じゃねーけどクラス図わかんねー奴なんかごろごろいるぞ
多数の協力会社からかき集められた連中なんかはほとんどわかってねーし
>>150 ベースクラスが無いから。
つうか、雨後のタケノコのように一斉に足りない機能を追加し始めたからw
157 ：
仕様書無しさん ：2007/07/01(日) 23:49:24
そうか、設計段階で破綻してたんだ。納得。
160 ：
仕様書無しさん ：2007/07/01(日) 23:51:47
いや・・・構造化という言葉を知らないのはさすがに。
>>157 お、あんたんところは人材に恵まれてんだな
うらやましい限りだ
～～言語できますか？のみで集められた連中は悲惨だぞ
こういう集め方を改めないSIerが悪いんだけどな
ろくすっぽ言葉しらねえで開発してたくせに、
165 ：
仕様書無しさん ：2007/07/01(日) 23:57:35
OOの悪い所。
つか、人は自分で集めるもんだろw
新しいパラダイムには新しい言葉が付き物なのだが
>>164 汎化、特化、継承、集約、委譲、あとは略。
これらを見てOOを知らない人が敬遠せずに素直に学習すると思ってる？
辟易する奴がいてもおかしくないだろ。
>>168 辟易する奴がいてもおかしくないし、全く否定はしないが
そいつらは置き去りでいいだろ。
なんであわせる必要がある？
>>171 考えて書いてくれよ・・・
工程はそいつら込みで引いてあんだから置き去りにはできんだろ
>>169 宗教？いみわからん
適当に人足あつめて「こいつら使えません＞＜」
で、結論が「OOは習得するのは難しいからダメだわ」
おかしいだろ
>>172 だから人を選別できない理由はなんだよ
おまえが集められる側だからだろうが
175 ：
仕様書無しさん ：2007/07/02(月) 00:04:36
>>163 OOの説教たれたり駄目出しする会社だ
OOがもっと流行って欲しい気もするが安っぽくなるは嫌と難しいところだな
開発者が人材確保しなければならないスレはここですか？
つうか、人足にOOの知識なんていらんのだよ。
つか別にいいんだよ。人集めできようができまいが
>>168 なんだその、ならべると７つの大罪みたいでカッコイイなｗ
182 ：
仕様書無しさん ：2007/07/02(月) 00:13:34
思い出した事。
>>180 コーディングスタイル教えて、設計書与えれば、与作でもコードは書けるぜ。
ダメなのは、コーダーに設計レベルを要求する姿勢。
分業しようぜ。
>>183 なにいってんの
設計・実装を分離しないためのOOだぜ？
>>186 責任逃れというより、「設計専任」「実装専任」って存在がそもそも不要
>>187 不要なのは、00分かってる奴らを集めて初めて言えよ。
分からねえ人足集めて来て、設計までやらすからくだらねえクラス量産するんだろw
>>188 だからさっきから言ってんだろ
人足集めるスタイルを変えないでOOして使えねーって
結論だすこと自体おかしいだろって
>>189 だから、現状に合わせて、設計はしっかり集める側でやって、
人足にはコーディングとテストだけしてもらえって。
>>190 だからOO使う限りそのやり方じゃうまくいくはずねーって
>>193 OO使わないほうがいいのはおまえだろ
俺は人足を使わないw
でも正直オブジェクト指向ってもんが見えてきたよな
なあOOだと設計も実装も兼任なんて、誰が言ったんだ？
人足ってなんて読むの？にんそく？じんそく？ひとあし？
>>196 メイヤーとかストラウストラップ
その他多数
なんか上の方で用語がどうのこうの言ってたけど、
>>196 兼任なんて誰も言ってねーだろ
設計と実装を「分離しない」ためのOO。
なので設計者と実装者は別でも構わん
>>196 おめー、原理主義者の俺だってそんぐれーは知ってるぞｗ
おめーの宗派が何かは知らないけど勉強不足じゃね？
とりあえずオブジェクト指向は設計～実装までシームレスだかなんだかってのが売り文句だったんだぜ
そのためにクラスなんだぜ
>>199 激しく同意
用語知らんから伝わらんってのはいいわけ
技術者が説明できなくてなんのための技術者か？
説明嫌ならさっさと辞めろといいたい
言語を覚えましたって奴が設計出来るとは限らない。
ああ、おまいらの勘違いか。
上のは用語自体の説明のことじゃね？
>>205 構造化知らずにいきなりOOって、お前がいいだした珍説だろ
ところで、おまいら、どれが誰の言った書き込みか分かるのか？
C++に詳しい人が多そうなんで質問。
class A:B<A>;
こんなクラスをたまに見るけど、
こういうのはどういう時に使うのか教えてください。
>>209 証明してよ。
今時構造化知ってるやつ居るのか？
>>213 いきなりハズレだし。
誰が誰だかわからねえのに、オマイが先に言い出したとか、言うなよw
>>141 それは技術を使わない
土方方式
クラス定義したからOOPだよと言ってるだけだ。
言語使用がOOP出来るだけの物。
>>212 構造化とOOは対立してない
OOがいい、構造化はダメ
構造化がいい、OOはダメ
ってのは分かってない証拠だ
>>217 それは同意。
構造化を押し進めると、OO的な構成になる。
>>211 スーパークラスが導出先クラスの型によって生成されるクラスだよ。
他にもポリシーのような使い方もある、とりあえずModern C++ Design見ながら使い倒してみるといい。
おれはBのクラスの上に共通の抽象スーパークラスを入れるのが得意技。
boost系のソースコードにもその種の面白いのが沢山あるよ。
なぜ素人にオブジェクト指向（言語）なんて使わせるんだ？
なぜ素人がプログラム作ってるんだ？
昔からある疑問だ。
いきなり屑みたいな文章が増えて嫌になった。
>>141 見たいなのがオブジェクト指向の実際なんだろ？
まああれだ。
>>222 あ？
だってよ、構造化じゃマルチタスクに対応できねえもんw
構造化した先に、各機能を同時に使えるようにとか言い出したら、オブジェクト指向に行かざるおえなかったよなぁ？
>>223 だから構造化に資格があるのかと小一時間
いかざるお？日本語おかしいおw
220のつづき
>>224 構造化でマルチタスクできるけど、釣り？
キムチ臭いよﾌﾟｹﾞﾗ
>>227 OOを越えるも何も、OOで抽象化がカバーしきれなかった「アルゴリズム」
の抽象だろ。そもそも被ってない。
関数単位に分割する方法が構造化手法で，責務単位に分割する方法がオブジェクト指向
>>228 構造化がマルチタスクで使えるかどうか
それは実装の問題じゃ？
>>229 半可通な知識で語ったら恥ずかしい目にあうよ、それとは全然関係ないから。
>>232 あれ？そうなんだ
まあひとまずスマンね
>>230 関数自体が責務単位だからＯＯ＝構造化だよな？
>>234 Cなんかの関数が表してるのは、いわゆる「機能」だろ？
>>231 プログラムの設計手法とマルチタスク動作を混合して
抽象化した結果、
OOPじゃなければマルチタスクに対応できない。
というオブジェクト指向的解が導きだされたんだろう。
オブジェクト指向って、Windowsで窓やダイアログ単位で実装してくうちに考えついたんじゃねえの？ とか思う今日このごろ。
技術者の学習不足も原因の一つだろうが、
>>239 じゃあ、「誰が」で機能分けしちゃえば、構造化プログラムもOOだな。
>>238 今の若いものは知らんじゃろうが、
昔、Alto ちゅうワークステーションがあってのう・・・。
>>238 原理主義者の俺が説明すると
はじめは気体分子のシミュレーションが目的だった
分子１つの動作と衝突したときの動作のプログラムを組んで
一斉に動かすとどんなもんじゃいボケが
って感じだった
>>242 だからココ電に戻せって
あぼ～ん指定してるんだから出てくんなよ
>>241 うん。。いわゆるOOだなそれ、普通に。
>>243 じゃあ、ゲーム屋さんがアセンブラで組んでた頃からOOやってたって話も、まんざら嘘じゃないんだね？
>>220 ありがとう。Modernはtypelistでtree作ってくあたりでお腹いっぱいに…。
オブジェクト指向的に見ると、集合Aの中に集合Bがあって、
さらに集合Bの中に集合Aがあるわけでおかしくなりますね。
そういうわけで、単に実装の都合で、こういうクラスがでてくるのだと思います。
このクラスが必要になる簡単な例なんてないでしょうか？
>>244 多分、信じてもらえないでしょうけど、人違いですよ。
あなたは少し、2chのやりすぎで、疲れているのだと思います。
>>248 それは数学の集合の事かと、ついでにいうと数学的な集合でも、それを「指す物」であれば入れちゃっても問題ないですよ。
集合にはならくても領域(クラス)にはなるから。
例ですか、うーん、その前にもう少し理解が進まないと難しいかも。
boostのtype_traitsとか見て助走を付けてごらん、そのあとその使い方を想像してみるべし夢広がリングです。
>>251 お前もクレクレにレスつけてんじゃねーよボケが
スレタイ千回嫁
今の職場にいる限りはOOなんかまったく関係ないな
そらそうだOOPLを使っていなければ
255 ：
仕様書無しさん ：2007/07/02(月) 03:00:28
256 ：
仕様書無しさん ：2007/07/02(月) 07:22:39
オブジェクト指向、って
計算機
>>256 なかなかの見識かと。
結果として再利用性のあるものを生産するためには、事実上、余計な工数がかかる。
OOの最大の売りは再利用性なのだが、
そんな「将来必要となるかも知れない」という再利用性なぞに工数はかけていられない。
正しい。正しいけど。再利用の夢を捨てきれない者にそれを理解させるのは(ry
259 ：
仕様書無しさん ：2007/07/02(月) 13:01:32
>>258 まあ、再利用性は見込めないかも知れんが。
プログラムの依存性を少なくして、デスマ予防が出来るメリットはある。
疎結合はOOだけが実現できる特性ではない
再利用がなければ最初の手間は無駄にしかならないのは確か。
不思議なのは、使わない奴らの不満の声。
>>261 それは貴方の仕事が同一のシステムをある程度以上の長期間、
保守／バージョンアップをする仕事であるから
ではないのか？
264 ：
仕様書無しさん ：2007/07/02(月) 21:09:22
なんかのクラスを継承した時点で再利用じゃね?
266 ：
仕様書無しさん ：2007/07/02(月) 21:51:43
OOの再利用性を生かすべき場面は、
267 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/02(月) 21:56:18
ゲームでは「ギャラクシアン」（１９８２ごろ）に移動物体を Objectと言っていた。
>>256 YAGNIであってもOCPがまるっきり無視されていいわけじゃないぞ
変更が入ったときあっちこっち直してまわるのはだめ
>>267 そんなの珍しくもないし、他の会社でも似たような造りだったし。
まったくプログラムを擬人化してる辺りは、既にＯＯだったし。
270 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/02(月) 22:23:36
最初にオブジェを使ったのがギャラクシアンなのだ。
271 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/02(月) 22:24:38
回路を考えたのはアタリで、そのルーツは軍用ディスプレイだったと聞く。
272 ：
仕様書無しさん ：2007/07/02(月) 22:27:44
最初から完全に設計しきって始めるか、
同意。FとかHとかNとかそんなんばっか。
オブジェクト指向に関するお勧めの書籍を教えれ。
再利用性を信じている香具師は勉強不足なのが丸出し。
感覚指向とか雰囲気指向の奴らにオブジェクト指向は無理がある。
278 ：
仕様書無しさん ：2007/07/02(月) 23:09:51
指向 ってのは誰がつけたんだ？
至高ってつけたのは海原雄山
違うよ
282 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/02(月) 23:44:48
>>5 前スレ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～、うしろ、うしろ
つまらんよ
どういう機能が再利用し易いか？
転職を頻繁に繰り返すなら簡単な名簿を毎回作り、
[オブジェクト指向]
>>289 ｗｗｗコピペ？
親亀を構成するクラスのそのまた下の下の下はどうなっているかを
考えるのはオブジェクト思考じゃないんだろうね。
全体をコーディネートする人がいないと、老舗旅館みたいになるよ。
292 ：
仕様書無しさん ：2007/07/03(火) 09:40:09
老舗旅館は宣伝さえうまくいけば
なお、C++とPythonでは二人の亀に乗る亀もおり（以下略）
設計やりきってから実装すればOKとかいってる奴
>>295 その「設計」は保守のための文書を残すための作業。
だから理論的にはその設計はリリース後でも良いのだが。
頭が古い人を納得させるのが大変 とか
文書を今作成しても間に合う とかの理由で(ry
そして言いにくいのだがｽﾚﾁｶﾞｲ
>>296 ｽﾚﾁｶﾞｲついでに聞くけど、設計に「その」とか「どの」とかあんの？
良く出来たフレームワークに乗っかるだけなら、実装ポイントのサンプルだけ見て、
家の設計図は柱の組み方も見ただけで分かるくらいに詳細に描くよ。
プログラムの設計図はソースコードだよ
>>300 支持なのだが。その正しい認識を獲得していない人がね。大杉
ウェブサイトを家や本や雑誌に例えて批判するのがナンセンスなように、
設計っていうと、なんか唯一無二の正解がありそうな作業に感じる
まあ、建築といっても、かまくらから高層ビルまで、
>>300 鋳造の型を持って来て、「これが設計図だ！」と言ってるようなもんだな。
それを作るのに設計が必要って話をしてるんじゃねえの？
>>305 スクリプト言語で作り上げたweb上のお城も使い捨て？
>>306 まあそんなのは設計の定義次第だから、各自好きなように考えればいいやな。
だけど、
>それを作るのに設計が必要って話をしてるんじゃねえの？
どこでそんな話してる？
最近はフレームワークから自動で吐かれたスクリプトもあるからなあ。
そんなこといいだしたらC++のテンプレートとかどうなる？
>>308 オブジェクト指向って、設計理論じゃないの？
少なくとも「理論」ではないだろ
>>311 それとコーディング＝設計と、どう関係ある？
>>307 いや、
>スクリプト言語で使い捨てのコードを書くのに
というのは「ありがちな例」として引き合いに出しただけで、
スクリプト言語で書かれたから使い捨てという意味ではないよ。
現状、ソースコード以上に厳密に簡潔に設計を表現できるものは存在しない。
複数人で作業の必要があるのならインターフェース合わせと振る舞いの概要さえ決めておけば済む話では無かろうか？
>>316 トップから降りてくるところはインタフェース合わせだけでいいけど、
モデルってボトムアップで設計しなきゃうまくつくれないし。
ボトムアップで積み上げる部分が小さけりゃOOのメリットも少い。
神は細部に宿る。
そして悪魔も細部に宿る。
ソースコードが設計書、というのは間違いではないが、
んだからドキュメントは概要と最低限の決め事だけでいいよって話。
２年生レベルだとそうなんだろうな
324 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/04(水) 00:31:17
>>292 老舗旅館が増築に増築を繰り返して迷路のようになった巨大木造建築で火災が発生すると大量死するという例えだよ
（適）マークが作られたのはそういう事件があったから。
UML書くのが好きな人っている？
>>325 全般的に不要だが
なかでも一番いらんのがシーケンス図だな
モデリングセッションでホワイトボードに書き出した奴をデジカメでパチリとやればいいよ。
>>320 何をなすか、は「仕様」だろ
設計とは違う
>>329 が基本仕様と業務設計の違いを教えてくれるそうです
設計って、例えば飛行機の設計には、重心や揚力などの基本的な計算も含まれるんだけどね。
わかってないなあ
それを含めて、つかそれ普通に設計じゃね？
スペックとデザイン、って英語で書いた方が通りが良くなるから不思議だ。
なんのために＝要求
要するに俺らのやってる事はオブジェクト指向どうのこうのより前に工業ですら無いわけさ。
アセンブラで組んでた頃は、サブルーチンの総マシンサイクルや使用スタックサイズなんてぇのも要求されたもんだよ。
340 ：
仕様書無しさん ：2007/07/04(水) 01:17:11
>>336 そもそも工業じゃねえし。
システム開発は職人芸。
>>338 詳細なインタフェース仕様書とかフロー書かされるよりマシだろｗ
>>336 >>339 レス内容以前に、会話が成立してない。
ココ電クラスのコミュニケーション力のなさ。
つか本人だろ。
343 ：
339 ：2007/07/04(水) 01:21:36
>>342 ソフトウエア作りは工業だって話だろ。
おまえはこのスレの何を見てるんだ？
>>335 「要求仕様設計書」なんてタイトルのドキュメントがあるとなんかドキドキするな。
345 ：
仕様書無しさん ：2007/07/04(水) 02:24:32
オブジェクト指向が嫌い、使いこなせない人は以下のどれかに５つ以上に当てはまる人である。
>>345 そのままオブジェクト指向を推奨してる人の傾向じゃね？
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の恩恵は受けられるだろ。
>>354 わかるわかる
クラスのメソッドでも長い名前の見ると
大概オブジェクトの粒度が間違ってる
356 ：
仕様書無しさん ：2007/07/04(水) 12:49:42
>>346 ＞そのままオブジェクト指向を推奨してる人の傾向じゃね？
まぁ、そもそも向いてない人が推奨してるからカオス化してるんじゃないかと。
普通、プログラミングをすればC言語でもオブジェクト指向のコードになっていく。
さすがに言語仕様がOOじゃないから完全なOOじゃないが。
良いプログラミングになればなるほど、OOに近づいていく。
移植性、保守性、論理性、可読性、再利用性、そういった物を考慮するとね。
357 ：
仕様書無しさん ：2007/07/04(水) 16:56:17
プログラミングの安全性を高めようとすると、柔軟性が無くなる。
>>357 プロダクトごとに落としどころを決めろ、
としか言えんな・・・。
あるある…orz
360 ：
仕様書無しさん ：2007/07/04(水) 19:05:20
>>357 安全性を高めた「粒」を集めて柔軟性に結びつけるのがOOPですよ。
まぁ粒が細かくなって多種多様になるとやっぱり読めなくなるけどね。
粒
362 ：
仕様書無しさん ：2007/07/04(水) 20:06:10
>>357 それは言語仕様に拘束される。
日本にまともなプログラミング言語開発者が居ないので問題が起こる。
本来は言語を拡張して対応すべき問題。
仕様やコーディング規則でやるのは限界がある。
継承、ポリモフィズム、再利用性、構造化、保守性……全てオブジェクト指向の恩恵ﾆﾀﾞ
OOマンセーなやつら、エディタ何使ってる？
まあ、OOなんて手段だから、マンセーなんてありえないんだが。
OOなんて所詮どーでもいいんです。
と、いう意味で
麻酔たん＠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();
};
どっちを進化させても、もう片方に近づくことはない。
最初の設計思想が違う。
push0なんてメソッド書きやがる人は(´･д･`) ﾔﾀﾞ
おじゃばはネタなのか、釣りなのか、天然の愚図なのか。
だいたいGUI部分と電卓の計算機の部分がいっしょになってるのが納得いかねぇ
かなしいけれど、おじゃばの底力を見た気がしたｗ
・・・つ、釣られないぞ
378 ：
sage ：2007/07/04(水) 23:02:51
「例えば電卓」だ？電卓なめんなよ。
電卓を設計するとなりゃ
物理的な構造を真似ても意味が無いだろw
テラカオスｗ
>>380 >物理的な構造を真似ても意味が無いだろ
俺はあると思うぜ
眼に見えるものだから相手との認識が一致しやすい
絵に書いて見せるから相手を理解させやすい
そういうもんだと思うぜ
多分、王道は無いと思うんだ。俺は。
じゃあ、本体の裏蓋止めるネジや、電池、・・・ああ、ソーラー電卓なら太陽電池も必要だよ。
おまいら本当に電卓のＯＯもできないのん？
>>383 だから、大事なものだけ
相手を理解させるために必要なものだけ選定する作業が必要になる
自分が必要だと思うものを強引にこじつける能力だと思うんだよね
俺は
例えば電卓だって座標が必要になれば俺は外枠のケースをクラスにして座標をもたせるとかするよｗ
ＯＯは本質を抽象化するのだよ。
俺もよく帰りの電車とかで
細かいこと言い出したらボタンにだって座標・縦横サイズが必要だしね
電卓なんて、
そうさ、おまいらが持つセンスの本質をブースとするのがＯＯさ。
電卓の本質はインタープリタだよ。
>>389 それは
>>379 の計算機部分でしかない
たまには他の人の設計も見ておくといいと思う
誰がどこまでを想定しててどのレベルで話してるのか一致させる能力がないと
作っても作り直しになっちゃうぞ
新入社員向け課題としての「電卓」をマジで分類すると：
電卓はインタープリタなので構文解析も必要なのさ。
>>392 あのな、実物の電卓だって、ボタンと石（集積回路）と液晶だけしかないっつうの。
>>391 で正しいと思う
インタープリタって言葉の意味を、よーく考えてみないといけない
398 ：
394 ：2007/07/04(水) 23:28:51
ってなテーマは、ここ２ちゃんでも狸系カテ趣味板に行けばやってる。
結論から言うと、電卓で表層の部品しか見えない香具師にはＯＯは無理って言うこと。
同じように、オセロで石が見える香具師もＯＯは無理。
昔、５万円ぐらいした電卓（ポケコン？）って何ができてあんなに高かったの？
ＯＯは万人には無理な概念なのさ。
ああ、でもな
いやむしろ俺は「インタプリタ」って概念を知ってるからこそ
オブジェクト指向、ってくくりで話してるけど
>>403 あたりまえだけど、この概念は強力すぎて香具師には活用できないよ。
>>403 ライトセーバーと同様に強力すぎてマスタ以外には使いこなせない。
原則、このスレのオブジェクト指向＝クラス指向のことでいいだろ。
>>404 なんだ、OOで電卓するにはインタプリタ知識が必要、でおしまいか。
俺は数式処理からベンキョして、関数型言語逝って、
「現場向け実用パラダイム」としてOOやったから、
努力足りない奴に「OOの研究者にしか判らない理屈を言うな」とか言われると
すんげぇムカつく。
・入出力
おまいら本当にＯＯの勉強してるのかぁ？
だいたい「OOの研究者」なんて今時いねぇだろ。
超お勧めのＯＯ本があるけど教えてやろうか？
エージェント指向はどっかいった
>>410 何が判らなかったの？
キミが理解できなかった点をちゃんと説明してくれたら、
俺ももうちょっと噛み砕いて説明してあげるよ。
きちんと整理してわからない点を説明してくれたまえ
頭のおかしい人がきちゃった
きちたぁ
やヴぁいみんなにげｒ
今日からは、オブジェクティブエージェンタブルアスペクト指向で行こう
計算機をインタプリタとして扱うのは>379のオマケみたいなもんで
422 ：
仕様書無しさん ：2007/07/04(水) 23:47:31
やばくなると相手を中傷って、こいつおじゃば？
ここのスレにトグロしてる人って、
じゃあインタプリタのクラス設計やるよ！
アミダのトグロでデッドローック攻撃！
電卓の本質はインタプリタである。
電卓の本質は数式処理である。
むしろOOのメリットは「萌えプログラミング」にある。
433 ：
429 ：2007/07/04(水) 23:56:56
>>430 あのさ、あんたやっぱ議論に値しないわ。
実質言い出したら数値処理だろ。
そして数値処理の実現機構はMPU的ロジックだろ。
あんた一生言葉遊びで人生潰しちゃえばどう？
>>433 素直になって勉強し直そう。素直が一番。がんばれ。
このスレの本質： かみ合わない議論を延々続ける社会不適応者のオナーニ
ＯＯは実質ではなく、本質を抽象化してインターフェースする技術なのだ。
そろそろ殺伐としてきました
頭がおかしい人をからかうのって、意外とつまんねえな。
439 ：
仕様書無しさん ：2007/07/04(水) 23:59:54
GUIクラス
じゃあなにかい？
数式処理をOOで実装しようというなら、
ＯＯはこのようにセンスをブーストするので
>>439 どうだろうね？
レジスタって、実際には変数１個と対応でしょ？
クラスにするほどのものかなぁ・・・
多項式イデアルのデータ構造を検討するには、まず
>>445 10年位前だと、ホロノミック基底がよさそうってな話になってたね
計算クラスで四則計算からなにからを派生クラスとして作成して、
448 ：
仕様書無しさん ：2007/07/05(木) 00:06:29
>>444 記憶クラスにしようかなと最初思ったけど、
電卓だから単なるグローバル変数でも良いかなと思った。
でも一応、レジスタという名前で小ささをアピールしてクラス化したｗ
あ。もし、億とか兆とか無量大数まで
計算させる場合はこの方が都合が良いかｗ
生意気な若い人の論文によれば(
>>448 そか、もしかすると２６個のレジスタになるかもしれないし、
リンゴとみかんを分けて処理しないといけないかもしれないからねw
なんだか、設計というのが物事を単純化させる作業ということ真逆な方向に行ってるねぇ
電卓など所詮初心者プログラミング課題。
453 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 00:13:46
なんだ数式処理って？
新着レス 2007/07/05(木) 00:14
455 ：
仕様書無しさん ：2007/07/05(木) 00:15:14
時々思うんだけど、業務システムとかは単純な加減乗除と
ヒント： それに特化したアーキテクチャのCPU・OS・システムは、
>>455 君の目の前のパソコンだって、そんなに高度な計算をやる事に特化してる訳じゃないよ。
所詮は四則計算の繰り返しが９９％じゃね？
３Dのゲームでもしない限りはw
Wヒント： 有能な人間は、業務システムなどという単純作業には我慢できない。
「複雑な計算」の例が３Dゲームとは
>>459 高度な複雑な計算だって、所詮は四則計算の繰り返しでしかないんだし、
３Dゲームって煽ったのは、ベクトル計算を鬼のように最適化しなくちゃユーザーが黙ってないからさw
すげーｗおじゃば大量だぜｗ
業務システムとか３Dゲームなんてのは、
数式処理の話しても、いつものパターンで流そうとする
>>462 ９９％無駄にアイドル状態のパソコンに何故高性能を求められるかって？
ユーザーが馬鹿だからさ。
465 ：
仕様書無しさん ：2007/07/05(木) 00:36:05
>>462 まあ並列計算機を実際に使うのは
有能な人間をサポートする計算職人に過ぎないけどね
466 ：
仕様書無しさん ：2007/07/05(木) 00:36:39
>>462 というか、ゲームが大好きな奴らが集まって何にでも使える
一般家電的なコンピューターを作ってたら、誰も予想しなかったくらい
滅茶苦茶に高性能化したので、こっちに全部ブッ込んじまえば良いや的な
流れで今があるんだよ。
結局、進化の過程のいびつさが言語仕様に反映されてて、
エレガントで直感的じゃないってのも嫌われる理由の一つにあるのか？
>>462 でも、そういうことがなぜ大事かというと、
業務計算やったり、ゲームやったりしてる日常を守るためなんでないかな？
一概にどっちが上とかはいえないような。
それをいっちゃ、所詮コンピュータの面倒を見るだけの使用人ですからねぇ それだけの事ですよ。
簡単な話題になるとレスをたくさん付ける人がいるねｗ
で、数式処理って、只の記号処理なんだよね？
こんなにも「無理」「無理」と言われるOOを学習する意味あるのか？
OOが無理なんじゃなくって、分散開発でOOとか無理な事やってるのが悪い。
>>462 まあ並列計算機を実際に使うのは
有能な人間をサポートする計算職人に過ぎないけどね
フィルタ。
OOくらい齧らないで、「人材」たりえんのじゃないか？
>>466 また知ったかか。無理すんなよ。
cellチップの共同開発は、次世代マルチコアCPUの開発費捻出に困ったIBMの苦肉の策だし、
GPUの当初目的は、スパコンの計算速度とデータ量に見合った、データ可視化装置
(サイエンティフィック・ビジュアリゼーションWS)の実現にある。
要するに、有能な人が使う道具を限られた予算で実現し発展させていくために、
一般大衆向けの大量生産品とのコラボレーションが行われたって事。
そしてもっと素晴らしいのは、その「有能な人のための道具」が充分安価に提供された事で
第三世界の研究者や学生であっても、有能ならばそれを本来の目的で使いこなせる時代になったって事。
業務システムでひぃひぃ言うレベルの人には無関係だけどねｗ
>>471 適性のない人材も確かに存在するが、
彼らは学習してもダメなのか、学習していないだけかが不明だし。
「OO」って単語をオブジェクト指向と読みかえることができる奴が
どれほどいるのか怪しいし。
不勉強というよりも分野が多すぎてノータッチってのが多そう。
>>471 つか、全然無理じゃないから。
最初のハードルだけちょっと高くて、多少のメリットを得るところくらいまでは誰でも到達可。
Cのポインタ使いこなすくらいの難易度
>>470 只の記号処理じゃないことって、この世に存在するの？
バカスレ
このスレの住人て、なんでこんなにレベル低いの？
中学生もいますよー
結局自作自演がメインだから、自作自演者のレベルがスレに如実に現れるニョロ
>>481 煽りがヘタですねえ
ま、厨房ならその程度でしょうねえ
オマイが先に言ったんだからな！
>>484 それくらいにしとけ
またこいつ発狂するぞ
OOよりもガーデニング検定がんばった方がよさげ
このスレの住人の割合
５人侵入者がいるな
まぁ実際書き込んでるのは３人がいいとこだな
じゃ、番号！
俺はこのスレほとんど来ないんだけど。
>>494 正解。いつも書いてるのは一人。
だから内容が無いよう
こんなかんじ？
>>497 自作自演の芸が細かいな。なんちゃって。
ほとんどお前一人でやってるだろこのスレ。
かみ合ってない会話ばっかで、自演はなさげ
結論：ヒキ学生ときどきドカタが一名で回しているスレ
>>499 ほー。わざとかみ合わない会話を自作自演してるだけじゃんお前
退屈な人の退屈なスレ
なんのためのわざとだよｗ
で、おまいら、オブジェクト指向の方は、理解出来たのか？
まだやってたんかｗｗｗｗ
中身ゼロだな、ここ
507 ：
仕様書無しさん ：2007/07/05(木) 01:13:28
ああ。俺分かっちゃった。
insert01
>>507 うんにゃ。
ちみは理解してない。
特に３行目。
（空白行含む）
1. 業務システムは奴隷に任せとけばおｋ
業務と言う観点から見たら
>>507 そんな明確な意思は感じ取れないな
このスレは「ポインタ死ね」スレとおなじ趣
>>482 >>470 の記述には、「数式処理はこの世に存在する」という以上の意味は無いということ。
というか、業務やってる連中はOO理解してないヤツばっかだから
以前、バリバリなフレームワークをJava, Perl, C++の三つで書いたら、
>>513 最初からそういうことだってw
やっと気付いたの？
そいえばRuby作者っていえば、ObjectStoreのためのGCシステム開発もしてんだよね。
>>516 きみのあたまの中身はお花畑だという事を理解した
オブジェクト指向って名前をどーにかしないとな。
520 ：
仕様書無しさん ：2007/07/05(木) 01:27:55
>>476 それってかなり大昔の話でしょ。
五インチフロッピーが全盛くらいの。
それと今の状況は全く違うと思うよ。
パラダイムシフトは95年辺りだよ。
それまではワークステーションはUNIXだったが、
Windowsが使えるレベルになったのでx86が台頭してきた。
今更OOにこだわりを持つよりも
OOｲﾗﾈつって、じゃあ関数型やるか？っていったら
>>520 お花畑2号発見
なんで知りもしない話に知ったか始めるの？
だからキミは相手にされないんだよ
構造化を突き詰めると当たり前のようにOOになるんだから、別に名前なんて無くてもいいよ。
526 ：
仕様書無しさん ：2007/07/05(木) 01:29:22
>>519 Java Standard Poricy Programming
で、JSPPで良いんじゃね？
>>523 あ、それ大丈夫。
情報科学～コンピュータサイエンス出身の学生さんがやってくれるから
>>526 JSPとかぶるし、ジャバロンの方が耳に残るｗ
宿題スレに宿題丸投げしてるような学生が行き着くところかｗ
学生がやってもしゃあねえべ
>>527 むしろ今までの方が変だよね。
学生時代に論理型言語や関数型言語で研究テーマこなしてた
プログラミング好きな学生(修士含む)が、
プログラミングが好きだから現場指向の会社に行くと
途端にCだJavaだCOBOLだって低レベルな言語やらされる無駄
現場でやってもしゃーねーべ T T
>>530 無料で出来るぜ。
学校ごと教授ごと巻き込めw
学生がやってもしゃあねえだろ
言語なんて出来て当たり前でしょ
>>520 お花畑ちゃんにマジレス
1995がパラダイムシフト？はぁ？
1995頃、まともに使い物になるOpenGLマシンつうと、
DEC Alpha載せたWS/Windowsマシンしか見当たらなかったよ。
そりゃ、CADとかライトな目的ではIntelマシンも使われてたけどね（HAHAHA
cellに至っては、21世紀に入ってからだろ（PUPUPU
カプンコがPS3のゲームエンジン開発者募集してるよ。
Cellのミドルウェア開発やってみてーな
>>535 OOに限らず、開発を効率化する「何か」の必要性は問われてるでしょ
つか、必要ありきで学習するなんて妄想杉
はじめに技術ありきで、必要は生み出されるもの
>>537 無理だ無理。
PS３のエンジン開発は、その道の専門が何年もかけてつくらんと。
先週、求職で某研究所逝ったら、
>>541 >さんそうけん
ぐぐったら、
もしかして「産総研」？ とか聞かれたよw
爽健美茶が出てきて吹いたｗ
うん、よく似た名前のハードウェア系ベンチャーがあってね、
545 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 01:46:09
sin cos
>>544 で、その身の程知らずが、この廃墟に何の御用？
ってな自慢話をするから、嫌われるのだとおもた（切腹
>>545 その３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
>>536 cellの原型は９０年代初頭からあったよ。
シェーディング. シェディングとは、光源、物体、視点の位置情報などから面に陰影づけを行う方法のことで、還元するとJ.Kajiyaによって示されたレンダリング方程式の解を求める事に帰着します。 レンダリング方程式. Iout(Θout)=E(Θout)+∫l=1 nρl(Θout ...
>>545 なぁココ、その行列間違っているぞ
転置したとしても間違ってるからw
>>559 はいはいPower CPUのマルチコア版乙乙
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です
569 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:01:56
cos -sin
おまぃら二人
571 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:02:50
いいやんなもん
ほっといてやれ
573 ：
仕様書無しさん ：2007/07/05(木) 02:03:37
ああ。なんだ。ゲーム機の話しか。
すれ違いが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
炎とか波とかははオブジェクト指向では無理だな
技術レベル的には、もっと下が居るよ
>>576 おまい、ゲームプログラムなんてOOを２０年前からやってんだぞ。
敵キャラの性格作るのに、ベースの敵クラスから派生クラス作って性格に肉付けするんだぞ。
OOをやってるからすばらしい、という前提は正しいのか？
584 ：
仕様書無しさん ：2007/07/05(木) 02:10:33
>>567 日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
まぐれ当たりが何本か出る程度だよ。
それにそれを育てようともしない風土だし、結局枯れる。
それを延々繰り返してるんだな。
金融とかの投資環境とか大企業の姿勢とか、そういう社会的なモン。
なんかさ、ココが３Dレンダリングの話でいきいきしてるの見て、
>>584 ・・・・おまえは大前健一クラスの批評家かっつーの。
根拠示せ根拠
587 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:13:02
航空産業などにいますが
588 ：
仕様書無しさん ：2007/07/05(木) 02:13:15
>>582 シューティングとかアクション系でOOとか要らないじゃん。
下手すると、関数呼び出しすらオーバーヘッドが問題になって使わず、
とんでもないプログラムを延々書く。
逆に、RPGとかシミュレーション系は多用するだろうけど。
前者にしか関わらない人間はOO要らないと言うでしょ。
589 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:13:33
かっちょえええ
> 日本は製造技術は高いが、開発技術はごく一部を除いてそんなに高いとは言えない。
>>588 実際にやってたからw おまいの話は真実味が無いwww
ココってNASDA関係やってたっけ？
MIPS R3000の開発やった事ある人居る？
596 ：
仕様書無しさん ：2007/07/05(木) 02:17:21
>>586 ・大学の研究レベルが低い
・学生の質が一部を除いて低い
・中学高校教育のレベルが低い。システム的な問題がある。時代遅れ。
能力のある人間を伸ばしていない。
・院卒をデタラメに扱う社会
・開発投資をしない会社風土
・日本独特の先輩後輩文化による文化硬直化。
それによる革新の欠如、革新の破壊、芽を摘む
・高度に管理しすぎる官僚制
社会が減点主義の鎖に繋がれる
などなど上げればキリがない。
OOを学習しても発揮する場が無い
返事がないのはガセの印
>>596 へー。じゃもう海外移住済だよね？そんなに文句あるんだから
601 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:19:59
R3000 ・・・ソニーのWSだっけ？
ひたすらスレ違いな奴が多すぎ
603 ：
仕様書無しさん ：2007/07/05(木) 02:20:59
>>599 ・問題点を見つめること
・問題点を見ないようにすること
・問題点から逃げること
この３つは全て違う。
>>597 OOの利点をしっかりプレゼン出来ればいいと思う
つか、もう寝る('A`)ﾉｼ
・国内大学の研究レベルは低いというよりは、産業向けの実用的研究と方向が乖離しているのが問題。
608 ：
607 ：2007/07/05(木) 02:28:58
> 基礎開発
>>606 あら。やっぱり居たのね。
奥さんお元気？
>>607 スレ違いなのは分かっているが
まで読んだ
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
それ、目的設定が重要だな
>>611 =615
OOとの関連性が無い内容で、
日本語の学習がより一層必要です
とにかくこのスレを埋めたいらしい。
619 ：
仕様書無しさん ：2007/07/05(木) 02:50:13
>>615 まあメーカー系研究所はフツー入れるんじゃねえ？
OB系の実績があればの話だけど。
620 ：
仕様書無しさん ：2007/07/05(木) 02:53:09
>>616 スローガンとか一過性のカンフル剤じゃダメだと思う。
開発投資が成果を生む、人材確保に繋がる、
そういった社会サイクルを形成しないとダメなんだと思う。
そういう政治家や企業家や思想家を、
今時の日本で見たことがないからダメなんだろう。
621 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 02:57:28
いっぽうアメリカはアポロ計画を立ち上げた
622 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/05(木) 03:01:22
やっぱ人工知能だよなあ
623 ：
仕様書無しさん ：2007/07/05(木) 03:06:40
話題がぐっと卑近になるけどw
624 ：
仕様書無しさん ：2007/07/05(木) 03:08:03
思想的な面から言えば、日本の現代の科学思想不足は異常。
625 ：
仕様書無しさん ：2007/07/05(木) 03:21:34
とりあえずIT分野に限定すると、業務系や組込系で3Kっぽい開発してる所、あれが随分と業界イメージを悪くしている。
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
>>577 それはゲームのシステム屋でしょ？
エンジン作ったりする奴の話。
アプリ層しか出来ないゲームプログラマのレベルは酷いぞ。
仕様書なんて書けないし出てこない。
基本口頭で、今時言った言わないで争ってるんだぞ。
632 ：
仕様書無しさん ：2007/07/05(木) 21:46:55
ITつう単語は最初ガートナーあたりが流行らせた単語だろ。
単語の起源も知らないような雛っ子に限って、
>>630 それでも技術レベルはゲーム屋の方が残念ながら上だわな。
OS屋、コンパイラ屋、ゲーム屋はスクリプト屋とかSQL屋なんかよりぜんぜん上だよ。
でも、仕様を書かせたら、まるっきりダメなのがゲーム屋
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だってソフ開の対策本に載ってるよ
しかしプログラミングは奥が深いよな
>>645 俺、いままで資格の勉強なんてしたことなかったんだけど
最近心変わりして、基本情報処理試験の本買ってみたら結構役に立つ情報が多くて感動した
昔の一種、二種よりは大分マシになったな
美しさなんて時代や背景によって随分感じ方も変わるもんだ
>>634 酷いね。
でもﾎﾘｴもんはスクリプト屋上がりだったか。
儲けるのが上手いのは案外そういう方面の奴なんだろうね。
おまいらオブジェクト指向がわからないから
ここはそういうスレだろ
クラスと継承とポリモがわかってればOK
あとはクラスが性格と動作を担ってることがわかればいい
656 ：
仕様書無しさん ：2007/07/06(金) 02:16:27
>>655 クラスの組み方が分からないと実戦で使うのは無理だろう。
>>634 昔は確かにゲーム屋といえば、実質オブジェクト指向らしい概念が無かった時代から、それらしい機能を実装していたり
プロトタイプ開発といった概念なども持っていてこここそが最先端といえたと思う。
でも今はどうかな、もうすでに一種の分野になっているので、多方面をこなせる万能屋ではないよ、個別分野になれば知識レベルで完全に負ける。
昔と違って知識範囲が広がったので万能系は、全てに関わる必要のあるOS屋、言語屋だけだろうと思われる。
658 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/06(金) 03:13:42
>>638 プログラマーを憎みながらこき使うことができる人間の屑にしかできない仕事だから適任なのだ。
659 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/06(金) 03:17:02
いざとなったらそいつに恨みを集中させて切ればいいし、会社としては楽
661 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/06(金) 08:49:51
>>657 僕は３D関係の数学知ってますって奴が実装技術に優れた物を持っていない場合、
その技術を持ってる奴と組んで仕事するとかでいいと思う。
全員が全員大学院卒並の数学出来なくても問題ない。
リアルタイムマルチタスクな組み込み系では、結局オブジェクト的な考えが
一番効率よかったから、ここでいうOOとはちがうかもしれないけど、むかしから使われてきている。
663 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/06(金) 22:08:48
かなり話が流れてしまったが、OOの話をする事にする。
664 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/06(金) 22:11:27
ではこれらがどう影響するか考えてみよう。
まんどくせい
>>664 構造化なら掛け算と割り算を追加するだけで動くはず。
全部小さな部品として作ってあればそれで行ける。
それが細分化の真骨頂。
ちまちました最小機能毎に関数を作っておいて
ある程度の塊に組み上げる。
この塊は作り直しか、再設計だがちまちました部品は手付かずが普通。
OOだから、構造化だからじゃない、設計が糞という前提ありきだろ？
構造化を馬鹿にすんな。
関数の中にバージョンフラグ？ そんな糞設計が構造化だなんて、
勘違いしないでよね。
＞かなり話が流れてしまったが
よく居る、全体を見通せず目先の処理だけを動かしたいが為
＞次に後から掛け算と割り算を追加したとする。構造化電卓の方は、設計者がその仕様変更を想定して
670 ：
仕様書無しさん ：2007/07/06(金) 23:25:48
>>663 ＞OOの重要な点は「状態を持つ」と言う事と、「メソッドが動作になっている」と言う事だ。
そこじゃない… そこじゃないんだ…
＞構造化電卓の場合は、状態を持っていない。
いろいろ突っ込みたい事はあるが一つにしておく。
⇒説得力無いわ。
671 ：
仕様書無しさん ：2007/07/06(金) 23:40:18
>>664 >>668 ↑こんな構造化とOOの違いについてを、低レベルな話しで討論しているやつの技量はたかがしれている。
電卓をOOでと聞いて
モデル、ビュー、コントロールという考え方は、OOでも有効だよ。
はぁ?
スレ違いのバカレスはほっとけ
つーか、それぞれの部品の動作とかを定義すりゃあいい話で、
ゲームがどうのこうのとかレス打ってる奴。
680 ：
671 ：2007/07/07(土) 00:58:22
OOが問題になるのはPGじゃなくてSE。
>>680 激しく禿同。と言いたいところだが酔っ払って眠いんだな。
根本的にOOのレスを打てない奴は分かってないだけで、
Javaとかで"何とかUtil"ってクラス作る奴馬鹿だろ
>ボタン追加の10個や20個は問題ないだろう。
685 ：
仕様書無しさん ：2007/07/07(土) 01:13:24
687 ：
仕様書無しさん ：2007/07/07(土) 01:16:07
>>679 何を期待しているかは知らないが、答えは一つなのだから自分で考えてはどうだろうか。
>>884 そこじゃな(ry
689 ：
仕様書無しさん ：2007/07/07(土) 01:17:31
690 ：
仕様書無しさん ：2007/07/07(土) 01:18:19
691 ：
仕様書無しさん ：2007/07/07(土) 01:19:23
>>692 それの何がいけないのか。
C#にはstatic classだってあるぞ？
１．OO理解せずに嫌っているヤツがいる
電卓の本質はインタプリタだ、って話があったけど
>>693 だって自作のクラスをインスタンス化して引数に渡してるんだぜ
>>695 私もおおむね同意だし、
そもそも、使いやすく見渡しのいい適当なレベルの
モデルが手に入れば何指向だろうがどうでもいいと思っている。
ただし、そのような本質論を語りだすといつのまにか荒れる。
あなたがあなたの主観を押し付けているように見えるからだ。
>>696 頻度によるね。
あきらかにクラスに移動してしまったほうがいいぐらい呼び出し頻度が多くて、
移動しても不自然じゃなければクラスに持たせたほうがいい。
それか、クラス自体にstaticメソッドを持たせるべき。
素朴なコレクションいじりとか、横断的に発生するのとかは
Utilクラスに持たせちゃっていいと思う。
呼び出し頻度なんか関係ないだろw
>>700 ブロックばらすのにもセンスとか考える時間とか色々必要があるから、
頻度とかモデル以外の視点で決定してしまうのもひとつの手だよ。
いくらオブジェクト同士がかかわってても
>>700 理想。これが行き着く姿。だから再利用って話になる。
それを誰も分かろうとしない。
俺は頻度とか考えずCRCカードの考え方でクラス作るなぁ。
704 ：
仕様書無しさん ：2007/07/07(土) 01:54:13
まあ、ブロックのばらしかたは各自のセンスでいんじゃね？
まったく異なるシステムの為に作ったあるクラスを、また全く違うシステムに組み入れる事を容易にさせるためにやるんだよ。クラス設計って言うのは。
ま、それも再利用のひとつだわな
>>705 最初あたりはJavaだったら、
「関数ポインタないのでインタフェースか抽象クラスにしてバラします」
ぐらいの意識でいいんじゃないかと思う。
# 一応VB6でもインタフェースあるので、この程度だと出来る。
>>706 それは大概フレームワークと呼ぶものじゃない？
ま、クラス設計とか以上に縛りがあるけど。
あるいはまったく違うシステムに組み入れられるのは
クラスというよりは、クラスの抽出手順、つまりデザインパターン。
どこかでやった作業を最終的に別の成果物に転用できるのは
気分がいいけど、発表する場所がふつうはないんだよな。
まったく違うシステムに持ってくのももちろん再利用だけど、
つか、歴代使ってる老舗のタレみたいな処理は、ラッパーで包んでしまうから、
その手の物って探すと既にあったりしないか?
処理は好き勝手に変えたいわけさ。
>>712 自社製品の使い古されたシーケンス処理の実装とか、探しても出て来ねえよw
>>713 以下も追加して：
＋ある程度のパフォーマンスは見限る。
テストを行い問題がありそうならプロファイラを用いて、
問題の箇所にだけあまり一般的とは言えない処理を記述して高速化を図る。
OOって結局、ｵﾚｵﾚ指向の次元の間は
道は一本しかないけど、道すがらいろんな景色が見えてるってだけの気もするけど
そうそうJIS規格のボルトとナットみたいな訳にはいかないよ。
>>687 答えは一つだね。
理解したよ。
何の意味も無く、実も無いという事。
なるほど、達人は違うな。
>>671 の力量は未知数だ。
ただ、２ｃｈで偉そうな事いう奴は凄いんだろうね。
たかが知れるほど凄いのに論破の一つもしない。
さあ、高レベルな話はまだですか？
低レベルに理解できるように説明してこその高レベルだよ。
電卓のコードでも書いて見せてよ。
高レベルなら5分ぐらいで出来るだろ？
粘着されるからかね。
電卓の設計には、CommandパターンとInterpreterパターンが適用できる。
724 ：
仕様書無しさん ：2007/07/07(土) 07:59:10
>>723 何語？
昔、そういうパターンまとめたのあった気がするけどそれが何か全く覚えてないやｗ
悪いけど内容まで詳しく書いてみてくれない？
仕様書に～パターンて書きたいなら
727 ：
仕様書無しさん ：2007/07/07(土) 09:04:23
>>694 ２．漏れはOO理解してるけど嫌いだ
は間違い。
２．漏れはOO理解してるけど、おじゃぱって奴は嫌いだ
が正解
嫌われようがなんであろうが、
1.ユーザは、電源キーを押し電源を入れる
ユーザーは別に電卓のボタンを押したいわけじゃないだろ
そのとおりだな。
バッカみてぇな質問だな。
キー入力ってのを物理的なキーの話だと思っているあたりで、
入力/演算方式： 演算子順位無視の順次入力/演算
>>734 キミがバカだからさ。
まずは、手計算で 1+2×3 を計算し、
次に電卓で同じ計算をして、
計算結果が同じか違うか確認してみろｗｗｗｗ
ド素人向け解説
>>736 あのな、そんなの誰でもわかるだろ。
どういう流れで喋ってんだ？と聞いてんだけど。
キチガイ発狂！！！！
HPの電卓っていったら普通逆ポーランド記法じゃねーの？
スレ違いがすさまじいな
キチガイが頑張ってるな
>>743 どうしたぼっちゃん？
何か悲しいことでもあったのか？
>>740 正確には上に書いたように、
HP電卓流処理を中置演算子に代えたもの＝通常の電卓の処理
を説明している
ちゃんと最初から読めよ
本来オブジェクト指向って奴は学ぶのではなくて、
仕様も出たことだし、誰か設計しろよｗ
相変わらずバカが目先の課題から逃げ回っているなｗｗｗ
電卓なんて、プログラミング実習の最初の週でやるようなテーマだろ
751 ：
仕様書無しさん ：2007/07/07(土) 10:11:09
電卓で重宝したのはカシオのCM-100だったな。
OOのスレで電卓に必死なのな
↓じゃキミ、電卓の設計ヤレ
電卓終了。
>746
かわいそうなのは、「やらされている」人ですね。
逃げた逃げた～～～～～～～～～～～～～～～～～～～～～～～～
∧＿∧
>>756 デザパタってやっぱ勉強しといた方がいいだろうか？
まだ全然見たことなくてね。興味はあるんだけどね。
小学生のぼっちゃん向けヒント
>>759 無理に勉強する必要は無いと思います。
ある程度実務経験のあるひとなら、
「そんなことはもうやってる」というような内容が多いでしょう。
デザインパターンは分かりきったことを整理して名前をつけただけだ、
という言い方をする人もいますから。
ただ、例えば Java の標準クラスライブラリにしても、
Factory とか、 Composite とか言う言葉がよくでてくるので、
そういうライブラリやフレームワークなどを理解する際には、
知っておいたほうが、理解が早いでしょうね。
バカコテが何を言おうと、こいつ電卓の設計もできないクズですから
↓はい、キミは電卓の設計くらいできるよね？
>>761 なるほど。
本屋行ったときにでもちょっと見てみるかな。
電卓設計で「コントローラ」ってのは、何か違和感あるな。
結論
電卓なんていうトイプログラムすらこなせない
>>757 お前が一番レベル低いだろ
精神的にな。。
>>768 それはどうかな。
キミがいつもこのスレで議論にならない議論を繰り返しているから、
ちょっとからかってみただけだよ。
キミはいつも繰言を繰り返すだけで、
まともな設計図など出した事がないだろう。
キミは一体何のためにこのスレに粘着しているの？
>>765 電卓程度にMVC適用ってのは、ちょっと大げさかもしれん。
普通のコントローラの設計でいくと、
入力、出力、モデル を有機的に結びつける「つなぎ」の役目なんだけど。
OOが苦手な分野ってあんの？
>>769 >キミはいつも繰言を繰り返すだけで、
ヘンな日本語だな
774の必死さに合掌
電卓のコア部分は数字か演算子を受け取ればいい。
最近の電卓の太陽電池の部分のプログラミングが問題だな
>>776 最終行意味不明
ってかなんでこんな簡単な話で荒れる事ができるのか、
このスレのレベルの低さに脱帽した
>>777 またキチガイの話題ずらしか
半導体のプログラミング？
寝言は寝て言えキチガイ
太陽電池のプログラミング(ｗ
荒してるんじゃねぇよ
黒太陽の毒電波を受信する太陽電池プログラミングｗ
月食どうする?
毒電波トレーダ
>>778 大量のクラスが全部公開されてると名前喰い杉
一つに纏めておけば、使いたい時は using すりゃいいし
使いたくないとしても喰う名前は一つだけだ
786 ：
仕様書無しさん ：2007/07/07(土) 15:10:35
このあと200レスかけても、設計なんて全然できねぇんだろうな
つスレタイ
言い訳だけのダメダメ人生
技術は体系立てて学ぶもの。
790 ：
仕様書無しさん ：2007/07/07(土) 15:57:43
言い訳はわかったからはやく設計出せよ
設計だしたら次は実装だからな
さぁ、そろそろオセロの設計でもするかぁ！
はやく電卓とオセロの設計だせ
794 ：
仕様書無しさん ：2007/07/07(土) 16:02:44
↓以下1000までグダグダ言い訳するだけで
2chにいりびたりのお前よ。
796 ：
仕様書無しさん ：2007/07/07(土) 16:08:08
↑鏡見てろバーカｗ
相手にすんな
だからあいてすんなっつの
電卓の本質はインタプリタとして、
以後、本質・設計の話はスルーで
えっ、じゃぁ何の話する？
なぜオブジェクト指向は嫌われているのか？
オブジェクト指向の本を読んでも、ちっとも素敵な設計が出来ないから
嫌われてはいない。その他大勢に敬遠されているだけ。
人間は急激な変化を嫌います。それがどんなに自分にとって有益であったとしても。
オブジェクト指向は穏やかだね。
808 ：
仕様書無しさん ：2007/07/07(土) 17:21:35
設計などしたことのない人間が何を言っても説得力なし
OO厨の考えてる設計って
オブジェクト指向＝＝デザパタ
デザパタ＝＝奥義
>>811 あえて狂人を装った方がスレが賑わうからなｗ
デザパタの適用数が多いほど設計は美しくなる。
本質・設計・デザパタは荒れる元
ＭＶＣこそオブジェクト指向の神髄なり。
デザパタを使うかどうかはともかく、引き出しを増やすという意味では、
ＢＣＥが適切なのにＭＶＣの乱用が目立つのは
BCEが適切って、ASP.NET以外ねーよ
820 ：
仕様書無しさん ：2007/07/07(土) 18:20:31
狂人が狂人を装う倒錯スレ
>>814 プログラムは一見すっきりするけど
実際は糞な結果になる事もあるよ。
例えば、不必要なオブザーバーやメディエーターの適応等。
前にも書かれているけど
デザパタはただの名称だから。
極論すれば、命名規則みたいなもの。
823 ：
仕様書無しさん ：2007/07/07(土) 19:47:03
構造化とそうでない設計の違いも説明出来ない奴が
824 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 19:57:22
ええええ
>>824 おじゃばのﾗｲﾊﾞﾙｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
826 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:08:30
イベント[0123456789] -> レジスタA=レジスタAX10＋[x] ：表示モードA 表示
電卓なんてただのStackマシン扱いにしといた方がいい。
>>823 マスター、構造化はOOに含まれるんだろ？
829 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:15:03
メッセージはウインドウズならすでにあるから
830 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:20:59
＞イベント[0123456789] -> レジスタA=レジスタAX10＋[x]
ボタンオブシェクとは当然フライウェイトパターンだよな。
スレタイに戻って考えると、業務ではたいていチームで開発するんだけど、
>>832 とはいえ構造化時代にデスマがなかったかというと、そんなことはないよな
そこから考え始めるべきでは
834 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:35:23
レジスタ（置数器）はコンピューターの発明当初からあったけど
>>832 ただのコミュニケーション不足か
教育不足なだけと思われ
それはOOかとは直接関係ない。
電卓は仕様が既に決定している（そしてバグは誰が見てもバグだと言える）時点で
教育なんてのは、、無いよな。今も昔も。
>>883 そりゃデスマなんて言葉は当時はなかったが・・・なんて言葉遊びはどうでもよくて、
今もあるわけじゃない。嫌われる原因ってやっぱ「最初のハードルが高すぎる」
って事なんだと思っているよ。
>>835 そうかもしれないけどさ、人類補完計画なみにならない限り、難しいと思ってる
>>838 そうじゃなくて、OOが何で出てきたかっていうこと。
構造化で問題がなきゃOOなんて出てこなかった。
というか少なくともクラスベースのOOは
841 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 20:54:03
評論だけしかできないOO厨
OOとか構造化以外にどんなのあるっけ？
>>831 ￣|￣￣|￣￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|∧ｼﾞｰ
￣|￣￣|￣￣|ﾟ ) ／i
￣￣|￣￣|￣|∪｀ﾞ:ﾞ:｀''':,'.´ -‐i
￣|￣￣|￣￣|: .:: _;.;. :.‐'ﾞﾞ~ ￣
￣￣|￣￣|￣| U
>>839 構造化時代に出てきた問題はコードの量が増えた事による人件費を
押さえる為にでてきた。それの弊害は理解する力の薄い、最近の本を
よまぬ若者がおおくなり、プログラマ向きではない奴が無理にプログラマ
になっちまうケース。
昔は力仕事でなんとかなっていたけど、今の開発スタイルでは無理多すぎ
>>840 正解。Cでやると面倒なあれこれを言語レベルで包括したのがC++。
>>832 Javaの言語仕様見てると、
優秀な奴がクラス設計をして、
どうでもいいやつがメソッドの実装を行うように
出来てるような気がしてくるんだけど、
違うかな?
ココ電球って冗談のつもりでやってるのか？
848 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 21:25:04
ああ、レジスタは文字列にした方がいいな
849 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/07(土) 21:26:53
>>847 お、答えが出た後えらそうに講釈たれるやつが出てきたな。
それもデザパタの一種か？
いいかげん誰か相手してやれよ、↑のひと。
ヤです
俺も嫌です
>>853 ごめん。かなり酔っ払っていて、自分でも何をいっているのか良く分かってない。
俺自身はオブジェクト指向はスキ。
雰囲気を感じるんだよ雰囲気を。気合が足りんわばかもんが。
考えるな。感じるんだ。
ジェダイの騎士
Ruby on Rails やってみ。きっとOOが好きになる。
>>858 Rails の上じゃぁな。好きになっても実力はつかないよん。
>>861 いいよお、つかんで
.NETもJavaも、似たようなもんだわ
railsのソースを読めばいいんじゃないか？
MVC にしろ、 BCE にしろ、OO を中途半端にかじった奴が見たら、
868 ：
仕様書無しさん ：2007/07/07(土) 22:49:57
このスレのレベルが低い原因
ぶ
ココ電球の設計？はVBっぽいな。
あと、まともそうな設計を拾っていくと・・・
>>379 これ、物理的実体に拘泥しているように見えながら、
結構いいモデルを出している。
まぁ 入力、計算、出力 つう当たり前の要素を当たり前に拾っている、
その当たり前さがいい。
>>425 こいつはゴミだな。プログラムのﾌﾟの字も知らないキチガイ。
>>439 こいつはたぶん
>>379 の延長線上で考えているんだろうけど、
そもそも設計書とか書いた経験がねぇんだろうな。未開人
まぁそれ以外の書き込み(俺の書き込み除く)は、
>>873 ひどい言葉を書いてしまうほど、悲しいことがあったのですか？
周りにいい友人がいらっしゃらないのでしょうか、
それとも趣味などの興味あることがないのでしょうか。
あなたにはあなたの魅力がありますから大丈夫ですよ＾＾
明日はお休みならショッピングでもして気分転換しましょうね！
スルーしろつったべ？
このスレ笑えるね
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以外をバカとか言ったりとかもしてほんとバカ。
882 ：
仕様書無しさん ：2007/07/08(日) 04:17:34
キチガイスレ
時計の本質はなんだ？
884 ：
仕様書無しさん ：2007/07/08(日) 09:01:06
電卓の設計もできない奴が話題ずらしに必死ｗ
せんせー電卓できますた
幼児退行症の一種だろ
いつ電卓つくってくれるんだよ。口だけか？
>>842 機能ベースのモジュール分割。
C言語で関数スコープ、ファイルスコープのstaticな変数を使うアレ。
モジュールがデータ(状態とか)を保持する場合で構造化ではないし、
機能によるモジュール分割なので、オブジェクト指向でもない。
電卓厨必死だなｗｗ
891 ：
仕様書無しさん ：2007/07/08(日) 19:55:24
オブジェクト指向の何が巧妙って
>>891 はあ？
おまい、自分の環境だけが全てだと思ってる？
>>891 リンカの出力をちゃんと調べた方がよくないか？
>>891 普通データキャッシュと命令キャッシュは別々で、しかもキャッシュアルゴリズムからして違うが。
ついでにconstについてだが、C++のメンバ関数のconstのことなら付けておく事による最適化作用はないぞ。
付けても外から書き換える手段が存在するし、実際const付きの関数を使ってメンバ変数を書き換える方法はキャストやmutableのような物を頼らなくても簡単にできる。
普通コードセグメントとデータセグメントは別だしな。
>>891 多いですよね。困ったもんだ。技術は体系立てて学ばないとね。
899 ：
仕様書無しさん ：2007/07/08(日) 21:53:06
JVM環境でも命令キャッシュとデータキャッシュ別々にキャッシュされるか？
Java信者はいつもこうだ
OOを導入したことで
今日もキチガイスレ
毎日一人で書き込みご苦労さん
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 の周囲では。
オブジェクト指向自体を嫌う、ということは実際そういうレベルのことになってしまうわけだろう揚げ足取りじゃなく。
それはCでちょっと気を利かせれば出来るレベルよね
前提をはっきりさせないから話がずれてるだけじゃねーの？
ぶっちゃけC++やJavaの言語仕様がめんどくさいからじゃねーか?
嫌ってるのってC++使えないC使いかVB.NET使えないVB6使いぐらいじゃないの？
VB.NETに移行できないVB6使い多すぎ。
VB.netは基本的に旧VBの延長でいけるにはいける
VB6の良さはコントロール配列にあると思ってる俺からすれば
クラスモジュールの使いどころがわからないVB6使いは多そう。
てか、VB6がそういう使い方じゃなくて
privateとpublicの違いが分からん奴おるからな。
ダメなVB6使いの例。
920 ：
仕様書無しさん ：2007/07/09(月) 09:09:45
何かするたびに
921 ：
仕様書無しさん ：2007/07/09(月) 11:26:48
>>908 前スレ
>>999 で面白いから立てたって言ったじゃないか～（泣）
で…そのコード結局意味あるの？
オブジェクト指向でもないし。
昔VBでバイトしてとき
まあ、そういうところならクラス図書いてクラス構成決めて・・なんてやってられるか！
>>921 少なくともデータ (p) に機能 (print) を持たせている、その一点のみで
OOP だと言い張ることは可能だと思うが。
データと機能を分離させる事もまたOOPの技術(iterator pattern)なんだよなぁ
926 ：
仕様書無しさん ：2007/07/09(月) 16:37:35
オマエは意味不明な主張で議論をかき回した挙げ句に
電卓が作れない
気がついたらいつも同じスレばかり見てる
そして今だ 電卓来ない
あきらめずに煽るレスを入れるけど
すぐに流れて行くよ
OOPがあれば 楽に電卓できるハズだけど
何回やっても何回やっても 電卓が作れないよ
たまに出てくる狂ったようなクソ設計
>>371 public interface CalcService {
結局おじゃばって分かってないな。
関数オブジェクトか
>932
AMD
AMD
>>929 本質的にやるなら、電卓に加減乗除以外の機能が増えることを予想して
基底クラスもしくはインターフェースとして Operator を定義し
それを派生もしくは実装する形で加算クラス減産クラス乗算クラス除算クラスを定義するんじゃね？
class SuperClassDentaku{
AMD
I'v got a respons 939 of this thread.
calc.addFunc<Plue>();
941 ：
936 ：2007/07/09(月) 20:20:01
電卓はもういいべ
943 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 21:14:01
OOの設計は普通の設計の１００倍かかる事は判った。
電球が普通の設計を見せてくれるそうです。
>>936 IFの内部ではそういうクラス群があるかもね
>>936 物による。
四則演算しかしないとはっきりしてるなら
ベタでもいいちゃいい。
組み込み系とかはね。
でも業務系だったら936の通りバラした方がいいけどね。
もうこうなったら、
Operatorなんか定義してたら、関数電卓作るの大変だろｗ
>>947 ちょっとバカバカしいこと思いついた。
その電卓が出力しうる演算結果を全てハッシュにもっといて、
入力値によってマップから演算結果を引っ張り出す、みたいな電卓。
950 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/09(月) 21:56:31
>>666 ,668
とりあえず、継承使わずに変更前と変更後を、フラグなしで使い分けるにはどうすればいいか教てくれ。
>>669 回答の意図が分からない。
ボタンを増やしてもコードに修正が入らないと言っているのかな？
>>670 どこだ？
>>671 高レベルな違いを見せてくれ。
>>673 MVCとOOは無関係。
>>949 単純に片方の数の配列の数だけで１０の桁数乗・・・ｗ
>>949 自動車のエンジンコントロールの関数はそんな感じ
953 ：
仕様書無しさん ：2007/07/09(月) 22:07:51
電卓設計すらできないOO設計レベルだと、OOを使って仕事できるレベルに程遠いじゃね。
954 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/07/09(月) 22:26:30
>>949 ハッシュの必要ないじゃん
そんなのは２０年前にやったわ
955 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/09(月) 22:29:54
>>684 >うわｗ・・ｱｲﾀﾀﾀ・・第一に親クラスへの影響がないかどうかは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
最近のム版の流行語、読み手依存って知ってる？
とりあえずコンピュータにプッシュなんちゃらっていうメソッド作るのはヒドイｗ
遅い言語が多いからだろ。
メメントって映画あったよね？
>>960 遅い言語とか早い言語って言葉をはじめて目にするのですが、
遅い言語はスクリプト物やjavaは.netとか？
早い言語はC/C++やアセンブラ？
な感じですか？
遅い速いなんて問題じゃねーよばか
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以下のレベルの奴が「バカの振り」してるから、もう目も当てらんない惨状だ
じゃあ次スレはこれで
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
↑↑↑↑↑頭のおかしい人物が自作自演で埋め立て中↑↑↑↑↑
>>971 いまどき2chに拘っているのは、
時代の流れすら読めない真性引き篭もり廃人だけだろ。
はっきりいってこのスレに居る奴、社会に出て使い物になるとは思えない。
じゃあ次スレはこれでどうだ？
使い物にならない奴がなにかごしょごしょつぶやいているようだな
ごしょごしょっつーか
985 ：
仕様書無しさん ：2007/07/11(水) 01:41:38
なに第三者視点でかたっちゃってるをだかｗｗｗ
986 ：
仕様書無しさん ：2007/07/11(水) 01:42:42
なに第三者視点で騙っちゃってるんだかｗｗｗ
なに第三者視点でかたっちゃってるをだかｗｗｗ
988 ：
985 ：2007/07/11(水) 02:04:50
をだか
次スレのタイトル
次スレのタイトル
991 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/07/11(水) 22:26:26
次スレのタイトル
おじゃばvsココ電のガチバトル見せてよ
本当のマスターは開祖だけでは無いのか？
ニュートン力学知らなくたってブランコには乗れる
>>994 壊滅的なレベルの低さの日本の高校物理
まさかF=maの数式遊びでセンター余裕とかありえないｗ
ちょっと気体の話が入るだけで後全部F=ma
お前、そんなに馬鹿でどうすんのかとｗ
andそれすら怪しい教師
日本の物理は普通に終わってると思うｗ
私も前々回と前回のテストを見ましたけど、
そうか本来は東大京大の二次レベルでも理系なら数学物理は余裕で満点取れて然るべきなんですね
つか、生物や化学と違って
999 ：
仕様書無しさん ：2007/07/12(木) 07:25:58
いまどきOOに文句言うなんて、どれだけ頭が馬鹿なんだよ
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。