なぜ？
理解できる奴とできない奴の差が激しいからだろ
やる気の問題だろ
作業現場で使ってるか使ってないかの差
動物クラスの猫クラスの三毛猫クラスはオブジェクト指向？
上から言われて使ってるところなどない
気の利いたやり方ってのは、現場で勝手に導入するもんだ
工程管理はどうやってんの？
業務フロー書け、って言われてんのにクラス図とか？
資格を導入すればオサマル話なんだがな
勝手にアクティビティ図に変えて納品してたらそれで定着した
うまくいくとこはうまくいくんだな。
うちみたいに学習意欲の低い連中と高い連中がばらばらだと、
どうしても低い連中がお荷物になり、結局天の声で駄目になる。
うちもかわりゃしねーって
業務フローはアクティビティ図
>>10 リスク回避しかしない、つまんねー奴が多すぎだよなあ…。
間違っても利益に結びついてない。
まあ業務フローをアクティビティ図に帰るのはハードル低いわな
その他は、案外とユースケースが評判いいな元請には
クラス図は納品しても、あいつらどうせ見てないからな
手書きで書くような感覚のモデリングツール誰か作ってくれ
マジで
いつまでたっても定番ツールが無いってのはちょと困る
EA安いから買ってもらったよ
それじゃだめか？
なんつーの？
手書きで周りに説明するときに、おらおら～って感じで書くじゃん
そこで「お～！それだよそれ！」みたいなのが出来るじゃん
それをさ～、そのまま使いたいんだよね
ツールで清書して～とかやってると時間かかるし鮮度？が落ちるし
単に絵を描くのがめんどいだけなんだけどね
18 ：
仕様書無しさん：2007/06/09(土) 01:39:55
>>17 ホワイトボードに手書きで書いてデジカメで撮影すれば？
あるいはスキャン機能付ホワイトボードを買うとか。
19 ：
仕様書無しさん：2007/06/09(土) 01:41:36
オブジェクト思考はどんなものか知らないが、
C++でいうそれは分岐処理の隠蔽にしかみえない。
分岐処理は見えた方がいいと思うが・・・。
また、処理があちこちに飛んでしまい、コードが読みずらいな。
抽象化とかよく言うが、モデル作る人の視点が変われば
同じ物でも違う形に抽象化されると思うが、クラスの宣言に視点が明記されないので理解に苦しむ。
>>19 何をするかってのと,、どうやってやるかってのを分離したいんだよね
根本的な話なんだが、
オブジェクト指向
って、なんでこんなとっつきにくい名前つけたんだろうな
23 ：
17：2007/06/09(土) 02:01:33
ぶ
mimioすげー！
これこれ！こういうのが欲しーーーー！！
オブジェクト指向も適度に使えば効果的。
オブジェクト指向マニアがデザインパターンを乱用したり
標準ライブラリのクラスや機能をフルに使い出したりすると誰も読めないコードになる。
mimioって、これどういう仕組みだろ
wiiのリモコンみたいなってんのかな
そんなわけないよな
>標準ライブラリのクラスや機能をフルに
そうかあ？俺様クラスの方がタチ悪くね？
mimioは赤外線で色を判定して、
三角測量で位置を判定してる
らしい
>>22 「～する」事に着目するVerb指向(多分、こんな単語は無い）に対して、
「～を」扱うかに着目するからObject指向と命名したと妄想
オブジェクト指向って楽なのは楽なんだけど
実装が分散しちゃうのがねぇ
差分継承するのに基底クラスの実装を理解してないと危ないけど
それが幾重にも継承されてたりすると涙がちょちょぎれる
オブジェクト指向を使いこなして成果を出すには、それなりの分量の勉強が必要なのは誰しもが認めると思う。
でも、日経コンピュータ6/11号の『「高度ＩＴ人材育成」その理想と現実』というレポートを見ると、教育界は未熟で
「海外は新人が即戦力だが、日本の学校で学んだ新人は戦力に３年かかる」というのが定説。
また、産業界もＩＴ企業の技術力を評価せず（金を出さず）リスク回避に汲々とするユーザ企業。
無理を聞き現場を過酷に追い込むベンダー。
ＩＴエンジニアは技術を身につける場もないし、もし身につけても評価されない人事制度。
（地位・金銭での報いなし）
そして、学生に３Ｋ業界とみなされ（事実、そのとおりだが）ＩＴ分野に優秀な人材がこない。
ってことで、経団連でも「日本のＩＴ人材は崖っぷち。このままでは基幹産業の競争力に悪影響が出る。
人的資源の質・量不足が今後のわが国のＩＴ化のアキレス腱となることが懸念される。／2005年」
と危機感を抱いているそうだ。
結局そんなこんなで、ＯＢＪ程度の勉強ではマスター不可能なオブジェクト指向は広まらない。
31 ：
仕様書無しさん：2007/06/09(土) 08:35:42
>>30 医者、弁護士並みの勉強量が必要なのに、薄給だからな。自業自得やろ。
> 教育界は未熟で 「海外は新人が即戦力だが、
FizzBuzz問題を見ると、そうでもなさそうな気がするが。。。
OOとUMLって切り離せないものなの？
>>32 日本はさらに酷いんじゃない？
FizzBuzzは若干ジョーク的な側面もあると思われ。
>>33 一般的には切り離さない方が理解しやすい。
だけど、どれもコレも導入するもんじゃない。
目の前の仕事こなすのに精一杯で新しいスキルを学習する意欲や時間が削がれてんだろ。
構造的な問題がある。まぁ時間があっても覚える気の無い奴が多すぎるというのも問題だが。
周りがみんな優秀なら問題が解決するんだよな
わけの分からん派遣会社から下手くそがやってきて、
そいつのフォローで時間取られまくり
以前選抜チームみたいなのに呼ばれたことがあったけど
そんときはホントに仕事がラクだった
アプリも優秀だし、残業も無かったし、内部勉強会みたいなのもやってたし
いや派遣もだめだがプロパもだめだろ
特に部署移動なくて糞文化に染まりきってる奴
いるな、そういう奴
会社命令で資格だけは取ってるが
言葉だけ知ってるのでCMMやらPMBOKを
分からないまま導入しましょう、なんて言い出したり
はぁ・・
この仕事なめてる奴が多すぎる。経営者にも問題意識が無いからいっこうに改善されない。
気持ちよくＯＯやるには、研究部門に入るか個人レベルでやってくしかないのが現状。
だんだだん
侍ジャイアンツか
42 ：
仕様書無しさん：2007/06/09(土) 13:48:45
なぜロータリーエンジンは賛否両論なのか、に近いものがあるね。
素晴らしい発明であることと、広く普及、定着することは別なんだろうな。
できる奴はクラスを開発させる
できない奴はクラスを使うだけにすればどうにかなるもんですよ。
クラスってのはサブルーチンとかと同じで、それがないことで
外部機能を実現できなくなるってことないからなあ
直感的には理解が難しいだろうな
クラスじゃなくて構造体で定数定義する方法がほしい
クラスでもいいけど文字列の場合はコンストラクタがないと直で使えない
class clsA{
const String cstAAA = "abcde";
}
clsA.cstAAA
とかをスタティックに使えるようにならんかなあ
いや、C/C++で。
>>47 C++なら構造体にコンストラクタ作れば良いんじゃないか．
うお！？
構造体にコンストラクタ！？そんなんあんの！？
う～む、ちょっと勉強してくる
まーでもそこまでやるとクラス使うのと変わりないからあまり意味は無いけど，
C++の構造体は実は殆どクラスと違いがない．
ここは素人さんの集まりか？
++をC+αとして使う人の集まりじゃないか？
>>50 デフォルトのアクセス制御がpublicなのがstruct
デフォルトのアクセス制御がprivateなのがclass
そのくらいの違いしかないような
55 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/09(土) 16:13:33
データベースでコボラーが１カラムのtextに全部のデーターを書き込んでる例が紹介されていたが
OOでデーターベースオブジェクトだああああ つっておんなじことを推奨しているのには呆れた。
OOちゅは現代のコボラー
電球もデータベースにいれるならば、１カラムで済みそうだな。
型？
Boolean で十分。
頭の中１バイトもねーただろｗ
57 ：
仕様書無しさん：2007/06/09(土) 16:37:35
オブジェクト指向を理解しているつもりの奴の中にも
デザインパターンの知識もないようななんちゃってオブジェクト野郎が
いるから話はややこしい。
３層スキーマや正規化の知識すらないのにデータベース技術者を自称するシロートと同類。
ビットからテラバイトまでこんなにレベルの違う単位の情報を
過ちの許されない環境で一貫した手法で精密に扱おうというの
だから、IT技術者は微生物から恐竜までを専門にした生物学者
のようなもの。まじめにやってたら普通の人は気が狂って当然。
>>57 自分を利口そうに見せるのがお上手ですね。
オブジェクトって物？英文法で言うところの目的（動作の対象）？
61 ：
仕様書無しさん：2007/06/09(土) 17:46:40
どちらも同じ概念の延長にあるので、どちらも、というべきかな。
画面系はいいけど、重いバッチ処理はまだまだCOBOLでしょ
OOとバッチは案外相性が良いって、なんかで見たことあるなあ
64 ：
仕様書無しさん：2007/06/09(土) 21:36:14
オブジェクト指向で作ると工数が増える場合があるから。
以上。
>>64 テストと保守を考えれば工数は減る筈。
もしかして、作りっぱなし系の会社？
まあときどきはオブジェクトからのが考えやすいこともあるし
そういうときだけつかえばいいんじゃね
優柔不断な人は嫌いよ
>>68 単体テスト（コードテスト）とサイクルテストが出来るのがＯＯの魅力かと
この辺はテストの方法にもよるから一概には言えんか。
OOを使うことによるメリットってなに？
実務はまだやったこと無いんだけど
本を５冊ほど読んだ感じでは、
で、結局何がよくなるの？？？
って印象があるますです
本を５冊読んで分からないんならここで説明されても無理。
体で覚えろ。
>>70 つ □６冊目
「なぜオブジェクト指向で作るのか？」って本読んでダメなら諦めろ。
実務ではまったくOOに触ることが無いんですが、
自分で物作ってやってみまふ
「なぜ、あなたはJavaでオブジェクト指向開発ができないのか」
これ、作りながらやってみよっと
「オブジェクト指向でなぜつくるのか」
は読みました。最初に買った本です
諦めたくないのでがんがってみま～すｂ
>>74 「何がよくなる」って所は書いてあるじゃん。
「本当に？」ってのは実務で経験しないと、そりゃ解らんよ。
サンプルプログラム程度の規模だとそう思うのは当然。
あと、クラスライブラリとかフレームワーク類を利用している時点で、よくなっている部分を十分に利用しているとも言う。
Windowsを利用している時点でオブジェクト指向の恩恵は受けています。
も、も、もう一回読んでみます！
わたし、ちょっと理解するのが遅いんだぁ＾ー＾；
78 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/10(日) 00:31:06
「オブジェクト指向を判る」とは 現実とどんなに乖離していてもオブジェクト指向が有用と信じ込む事です。
異論を唱える人は理解して無い人なのです。
コテハンはスルーでお願いします
相手にした場合は荒らしとみなされることがあります
最初からオブジェクト指向で作っていたらそのありがたみは実感できないかもな。
ポインタやらデータの複雑な内部構造や変数・制御構造のスパゲッチに振り回された経験が無いと。
81 ：
仕様書無しさん：2007/06/10(日) 03:10:31
>>39 デジタル家電も、その辺考えてないメーカーは利益が出なくなって来ていると思うが。。。
>>78 現実をコードでそのまんま表現するのがオブジェクト指向って勘違いは、10年くらい前にはよくあったな。
>>82 んで、デザパタ見て「全然話と違うじゃねーか」ってな。
84 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/10(日) 09:45:06
>>81 あほか
経営者の身になって考えたら OOに移行するコストとそれがもたらす利益を考えるだろ
せいぜいどっこいどっこいだ。
そしてリスクを考慮すると取り入れる余地など無い。
コテハンは華麗にスルーしましょう
>>85 いや、
ココ電球スレッドなので積極的に会話していきましょう。
OOを導入するためには現場全体の理解がないと難しい
>>84 ココ電のクセに珍しい。
言い方は極論だが、うちの会社的にはあながち外れてない。
うちの会社では、これまでに実績がある過去の資産の流用に引きずられて
設計思想自体が凝り固まってる。
これまで出して来た流れの商品のソフトウェアは
気軽にリファクタリング、作り直し出来ないのは事実。
まぁボチボチ「何とかしないとね」という流れが社内に出来上がりつつあるのも事実だが。
89 ：
57：2007/06/10(日) 11:45:58
日本の自称IT技術者の技術の稚拙さは絶望的だな。
このスレ見てつくづく思った。
グーグルやマイクロソフトに肩を並べる日本企業など夢のまた夢か。
マイクロソフトの悪口ばかり言うくせに技術レベルは
MSの足元どころか技術者と言えるかどうかもあやしいレベル。
なんなのこの現状は？
独学で何かを１から勉強する習慣が身につかない
教育システムが悪いのか？
単にソフトじゃなくてハードで勝負してきた国だからだろ。
91 ：
仕様書無しさん：2007/06/10(日) 12:14:35
>>89 底辺PG板みて、全てのPGのレベルを計るお前の能力のなさに脱帽。
とりあえず自省が先だな。
やはり教育レベルが低かったのか？
コテハンに釣られて話題がOOからはずれてることに気が付かない奴痛すぎ
93 ：
仕様書無しさん：2007/06/10(日) 12:26:54
>>92 個人の話なんかどうでもいいからスレの趣旨に沿った話しろ、カス。
94 ：
仕様書無しさん：2007/06/10(日) 12:27:39
欧米なんかでは普通の掲示板でもそこそこ高度な議論がされたりするんだが、この板ときたら。
@ITがまぁまぁ普通レベルつぅ感じ？ あとはあってもただの質問板。
だから、たぶん日本の一般的なIT技術者のレベルって一部を除いて相当低いんだと感じる。
カスなんて言ってる暇があるならスレの趣旨に沿った話をしろ
>>94 >>93のような匿名性を悪い方向に利用して、安易に誹謗中傷する奴がいるからな
こういう奴に期待してもしょうがない
97 ：
仕様書無しさん：2007/06/10(日) 12:30:05
>>94 まあ、お前がPG名乗れる位だからな。
アメリカだったら無理だろ？
>>95 これ以上ないくらいつまらない返しありがとう。
予想通り最悪のレスでした。
98 ：
仕様書無しさん：2007/06/10(日) 12:31:50
>>96 底辺PGの低レベルな論議だけの板で、低レベルな他人に期待するとは
下には下がいるもんだな。
俺にとっては便所の落書きどころか、便所そのものだから
クソを垂れ流しに来てんだが。
ハイレベルな論議がやりたいなら、よそでやるよ。
つか、まともでハイレベルなレスってどれだよ（笑
どうぞ気にせず書いてくれたまえよ。
くれたまえよ（笑）
>>89 ここはいきなりIT技術者として働かされる未経験者のレベルと思ってくれ。
プログラマー板じゃなく、プログラム板に逝ってくれ。
┌───────────────────
│あ、どうもｽｲﾏｾﾝ、
>>98がお騒がせしました･･･
└───v───────────────
／⌒＼ っ ／＼
/'⌒'ヽ ＼ っ／＼ |
（●．●） ）／ |: | すぐ連れて逝きますんで･･･
>冊/ .／ |: /
/⌒ ミﾐ ＼ 〆
/ ／ |::|λ| |
|√7ミ |::| ﾄ、 |
|:／ V＿ハ |
／| i | ∧|∧
и .i Ｎ /⌒ ヽ）
>>1 λﾍ、| i .ＮV | | |
Ｖ＼Ｗ （ 、 ∪
|｜ |
∪∪
104 ：
1：2007/06/10(日) 12:49:23
お、オレ！？
106 ：
1：2007/06/10(日) 13:25:00
そうか、賛否両論なのは自分のせいなんですね
でもしねと言われてとてもショックです
自分はしにますが
>>105を訴えることにします
あなたの安易な書き込みで人がしにますがあなたもただではしなないでしょうね
日時告知の公開でとか？
108 ：
仕様書無しさん：2007/06/10(日) 18:40:18
まあ、ここは２ちゃんねるだから
しね、とか言うのは「キミかわいいよ」みたいなもんだ。
>108
しね
114 ：
仕様書無しさん：2007/06/10(日) 22:53:22
プログラムを上から下の流れでしか理解出来ない人には、
オブジェクト指向はなかなか理解出来ないと思う
UMLモデリングツールとか使えば、状況も変わるんでね？
115 ：
仕様書無しさん：2007/06/10(日) 23:53:25
標準であるライブラリのオブジェクトを使うのは当然だが、
独自にわざわざオブジェクトを生成しないといけない状況って少ない。
再利用？とりあえず動くプログラムすら作るのに、うーんうーんとうなってる奴が、未来のことを考える余裕があると思う？
116 ：
仕様書無しさん：2007/06/11(月) 00:01:50
継承継承してるプログラムは読みにくいだろ。特にDQNには。
ぱっと見で分かりづらいからデスマには不向きです。
>>115 データを構造体のようにクラス化しているのもOOの一部。
処理の流れをメソッドの呼び出し合いで実装しているのも然り。
継承を使えばOOのメリットのいくつかを受けることができるけど、継承使わなくてもOO的デザインにはなる。
OO ＝ デザインパターンと勘違いしている人多いんじゃないの？
クラス図で大体の構成決め手からつくれよ。
場当たり的に作ってくから無闇に階層ふかくなったり、
オレオレ構造になったりするんだよ。
119 ：
仕様書無しさん：2007/06/11(月) 01:21:23
UMLとか言ってるやつは、目的と手段が入れ替わってる奴が多い。
オブジェクト思考とか言ってる奴は、それ以外のものを知らない上に、
実はOO自体もよくわかってないことが多い。理解できてるのはカプセル化程度。
こういう人たちにはそんな事よりも、
基本的なアルゴリズムや複数言語の習得や計算機アーキテクチャ等を勉強させた方が、
効率化につながるんじゃないかと思う。
120 ：
仕様書無しさん：2007/06/11(月) 05:55:57
複数言語も取得したいんだけどな
C/C++以外の仕事もやってみたいんだが、何故かC/C++に回される・・・ﾄﾎﾎ
121 ：
仕様書無しさん：2007/06/11(月) 05:57:46
>>80 そういう経験に慣れてしまって「そういうもの」と納得してしまってる人も多いように思う。
従来の方法に比べると
関連ある実装部分が全部ばらばらの場所に記述されてしまうのが
最大の難点
オブジェクト指向は
・オブジェクトの品質は各作成者が保証する
というのが前提だけど保証できる技術者がいないから
結局瓦壊する
だから、それは人の配置でそうならないようにするのよ
ﾀﾞﾒPGにはメソッドの実装だけやらせとけばいい
125 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/11(月) 09:56:50
オブジェクト指向を本を読んだだけで習得するのは難しい。ほぼ無理と言っていい。
実際にコーディングをして試行錯誤を重ねれば、半年～1年半でほとんどの人が習得出来る。
本を5冊読んでる人は、100冊読んでも無駄だから止めた方がいい。
126 ：
仕様書無しさん：2007/06/11(月) 10:27:56
そこらのハッカーの作ったソース見てみろよ
９９％がＣ＋＋コンパイラを使った、Ｃのソースだから
ハッカーの作業は、実務ではなくマシンに忠実な低レベルアクセスがモットーだ
むしろオブジェクト指向言語じゃない言語でオブジェクト指向やっちゃう
129 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/11(月) 18:57:37
Cなんか宣言文とか忘れたな。
で？
131 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/11(月) 20:30:50
もうCには戻れないということだ。
>>126 ハッカーの場合は、C++コンパイラが生成するコードの特性を踏まえた上での選択だから。
一回でもＯＯの世界に入り込んじゃうと、もう普通の体には戻れない。
どうしても抽象的な概念にまで落とし込まないと気が済まない。
でもって、複数の全く異なる処理を同じI/Fで済ませたくなる。
もうね、これとこれは同じクラスの派生関係でくくれるだろうとか、考え出すと止まらない。
そんなことが出来るくらいなら
ワザワザ書かないってばｗ
あんまり派生にこだわり過ぎると今度は、
処理を切り離す用件が発生した時に
予想もしなかった問題が浮上することが
あるから程々にしとけよ
たとえば派生した側の処理を別のアプリに埋め込んで
利用しようとかしたときに、その派生もとのスーパーセット
全部複写して持ってこなきゃいけなかったりするからな。
138 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/11(月) 23:05:48
派生スパゲティー作って会社に来なくなるのがオチ
オブジェクト指向は結局ソースが常に変化することになる
テストした箇所は触らない大規模プロジェクトとは水と油
再利用＝コード変化なしって勘違いしてる奴多すぎ
それでもコピペで阿鼻叫喚・地獄絵図となったソースよりはマシ
派生という名の下に今後一生使われないような
無能クラスがたくさん生み出される
そしてそのうちにどのクラスにバグがあるのかが分からなくなり
その派生、スーパークラスが全て使用不可になる
オブジェクト指向がある分野において極めて有効に働くのは事実だが
盲信するバカ達がなんでもかんでもオブジェクト指向でやっちゃうから困る
要はこだわりすぎ
まずは「仕様どおりに動く」のが前提
それがあっての保守や拡張なんだから
メソッドとか単体で関数化できるものは極力関数化すること。
クラスにアタッチする必要の無いメソッドまで内部に展開する
必要は皆無だよ。
ネームスペースの使い方知らないやつとか隠蔽できるから便利
なんて感じで内部展開のメソッドを大量生成しちゃうのとか、
コードの肥大化につながるからな。
オブジェクト指向がなくなったらいわゆる上流SEの半分以上がゴミになるな
ガキの落書きみたいな設計図書くのが仕事なんだから
>>145 日程が遅れると当り散らすのが仕事かと思ってたよ。
>>142 プロジェクトの後半で派生が沢山ある基底クラスを修正するのはホント怖い。
書き換えずにその局面で必要なだけの専用の新しいメソッド作ってしまう。
デスマのときの親クラスのバグほど怖いものはない
しかも******pとか引数にあるし
ポポポポポポインタとか初めてみたわ
メイドインチャイナ嫌すぎる
>>150 ワロタｗｗｗ
俺はいわゆる数値オブジェクトはクラス化するのは十分ありだと思うけど
プロシージャまでクラス化するのはまじで狂ってると思う
さらに自称SEが設計するとメンバーがないのに無意味にインスタンス化するように
なってることがままあって笑える
クラスと名前空間を混同してる人も多い
lambdaとかあると便利だよ
ユースケース図とかなんの役にもたたず誰の目にもふれないような落書きをもってきて
「さあ、設計したぞ、これに沿って実装しろ。バグは全て実装において発生するんだから
ちゃんと直せよ。」
みたいなこと言われるとマジでブチ切れそうになる
ガントチャート一本だけよりはマシだわ
俺はUMLの中でユースケースが最強とおもってる
糞みたいな画面設計を持ってこられると作る気が失せる
プログラミング言語はそれを使わないと物が作れないから
担当者は必然的に学習するが
ソフトウエア工学は知らなくても一応物が作れるため
OOを含め多くの技術者から敬遠されている
オブジェクト指向って無能者が中間搾取するための仕組みだろ
158 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 08:39:19
OOはソフトウエア工学ではない。
ふざけんな
159 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 08:40:31
そういえば血液型性格論を科学と信じているやつもいたなあ。
似非科学、似非技術を見抜けないのはセンスの無い証拠。
160 ：
仕様書無しさん：2007/06/12(火) 08:55:06
オブジェクト指向がもっとも効果がでるのは、やっぱゲームプログラミング？
161 ：
仕様書無しさん：2007/06/12(火) 09:11:55
営業
オブジェクト指向とその工法は、日本の企業の体質に合ってるんだよ。
完全に分業可能で全体を通して誰かが把握してる訳でも無いのに出来上がる。
結果、思いもよらないところに問題が発生するとか、
163 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/12(火) 09:26:20
>>142 一生使われない派生クラスが大量発生？
派生クラスというのは必要になった時に作られる物だから、使われない派生クラスが大量発生と言うのは
何かおかしい。使わないのに派生クラスを作っているって事か？
どのクラスにバグがあるか分からなくなる？自作したクラスをそんなに多段継承すると言う事か？
普通は1段か2段程度の継承で、それも追加された機能をオーバーライドするので、バグは絞り込みやすい。
それに派生クラスにバグがあって、基底クラスが使用不能ってのは根本的におかしい。
多分、142の言うOOってのは、間違ったOOだと思う。
あと基底クラスにバグがあると大変ってのは当然の事で、それは構造の問題と言うより、テストしてない
と言うのが問題となる。構造化の共通関数でバグが出て問題となるのと変らない。
確かに構造的なバグもあるが、問題になるバグのほとんどが、基本的なテストすれば分かる程度の物だ。
つーかどっちもちゃんとテストしろよ。
ちゃんとﾕﾆｯﾄﾃｽﾄ書けよっ
バグの不在は（たとえいかなるテストをしても）証明できない
166 ：
仕様書無しさん：2007/06/12(火) 12:06:52
>クラスと名前空間を混同してる人も多い
クラスと構造体を混同している人も多い
テストはどこで妥協するかだろ
考えられる全パターンやろうとすると莫大な工数かかるし
理想が現実にならないのは
テストがすべて自動化できないせい
169 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 21:31:52
ゲーデルの不完全性定理ね
170 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/12(火) 21:34:38
>>167 重要なのは全ルート試験。全分岐と全ループの動作試験を行う。
パターン試験は抜粋で良い。
>>168 テストの全自動化はプログラマの夢だな。
しかしデバッカの登場以来、テストの進化はほとんどない。
171 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/12(火) 21:37:15
>>165 バグの不在は証明できなくても、指定したパラメータで動作する事は証明できる。
172 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 21:39:57
必死だな
カバレッジ厨って最近の傾向？
カバレッジを１００％にすることがテスト品質って信じ込んでいるアホいるんだが、どうにかならないのかな。
どうやっても通らないようなコード（特殊な例外処理）とか、テストしようがないし。
エラー処理を色々仕込んでいたら、カバレッジ下がるから消せって言われるし。
客は１００％でなければ納品不可って言うけど、パターン試験不足のカバレッジ１００％は大喜び。
174 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 21:46:07
フローチャートを赤鉛筆で塗りつぶしていく時が一番充実しているのです
>>173 未到達のコードはしかたないとして、エラー処理は100%あたりまえでしょ。
>>175 そういう意味じゃない。
引数チェックとかのエラー処理とかしかテストコード書かない。
正常系は1本通して終わり。
177 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 21:53:55
フロッピー抜きテストとか今はやらんかな
OOが理解できない化石世代のオッサンが火病ってるだけか
179 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/12(火) 22:06:57
>>173 単体試験でパスカバレッジを100%にするのは当然の事だ。
もしどうしても通らない異常系があるなら、その異常系処理自体不要だが、大体はやるのが面倒だという
理由が多い。デバッカやソース修正を使えば、試験できないルートなど無い。
実際にはパターン試験不足でカバレッジ100%と言う事例は少ない。
カバレッジ100%の人は、大体は十分なパターン試験も行う。
文句を言う奴の多くは、パターン試験も不十分だし、カバレッジも不十分だ。
ﾃｽﾄ書いてる奴がﾊﾞｸﾞってたり
181 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/12(火) 22:35:33
ハードでテストパターン書いてたからな
テスタビリティーはもうばっちし
そうかそれはよかったな
OOの話題をしれ
アホコテハンはスルーしれ
184 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 00:06:26
アンチOOの話題じゃん
185 ：
仕様書無しさん：2007/06/13(水) 00:11:43
ガーベジコレクタってOOの仕組みなん？
それを言ったら例外とかもか
>>185 しょっぱなで読む気が失せる
「プログラマを目指す人々の中にも，
「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。
そこで，
Rubyを題材にオブジェクト指向という考え方について説明していきます。」
なんでRubyなん？
もっとメジャーな言語あるだろ
188 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 00:18:03
ガベコレはBASICのころからついてました。
７０年代のパソコンBASICにもガベコレありましたよ。
189 ：
仕様書無しさん：2007/06/13(水) 00:25:06
ガベコレとOOPは直接の関係はない。
ただ、多数のオブジェクトが動的に生成、消滅を繰り返す場合
ガベコレがないと、やっとれんよ（消滅せずにメモリーリークするとか）
というわけで、OOPにはガベコレが必要と主張する人もいる。
たしかエッフェルというプログラミング言語を作った人がそうだった。
オブジェクト指向って名前が意味不明
初めて聞いたときは全然イメージわかんかったし
実際に勉強しだしたのはそれから何年も経ってから
根本的に名前が好奇心をくすぐらないんだよね
>>189 オブジェクト指向でなぜつくるのか？
のP.111に「パッケージ」「例外」「ガーベジコレクション」の３つが、
進化したOOPの仕組みとして書いてあるよ
Matzが書いてるんだからRubyにきまってるだろ
193 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 00:38:03
捏造だな
いいかげんなもんだ。
>>190 同意。
オブジェクト的プログラミングとでも言っておけば
まだとっつきやすい。
何を指向してるのかのイメージがわかないよね。
何スレか前にオレが説明したろーが
客体指向だってよ
OOPやっててラクだと思ったのはオーバーロードだな
あとはポリモ
メソッド名が統一できるってのはやっぱラクだわ
今ベタCやってるけど関数名バラバラでめんどくさい・・・
197 ：
仕様書無しさん：2007/06/13(水) 00:50:57
Bjarne StroustrupはC++に代表されるOOPLは給料をあげるための壮大な
悪ふざけだって逝ってるじゃん
はいはい終了～
--
「非常に複雑で習得するのが難しいため、誰にもプログラマ市場をあふれさせることが
できないような言語があったとしたら、どうだろう。」
Stroustrup： あれは単なるジョークの筈だったんです。 人々があの本を真剣に受け
取るとは思っても見ませんでした。 脳みそを半分でも持っている人なら、オブジェクト
指向プログラミングは非直感的で、不合理で、効率が悪いということを見て取れます。
Stroustrup： そして、再利用可能コードに関しては、実際にコードを再利用している
会社のことを聞いたことがありますか？
あとは多態性と多用性の２つともいい感じだな
オーバーロードとポリモーフィズムと多態性と多用性の
４つがあればラクでいいよね
199 ：
仕様書無しさん：2007/06/13(水) 00:53:50
Stroustrup： あなたは本当にそれを信じているのですね。 あなたはこれまでに、C++ の
プロジェクトで働いたことはありますか？
つまりこういうことです。
最初に私は、小さなプロジェクトだけが動くような落とし穴を充分こしらえました。 オペレータ
オーバロードを例に取りましょう。 プロジェクトの終わりには、殆どのモジュールが使っているで
しょう。 人々はたいてい、オペレータオーバロードを使うべきだと感じてるからです。
彼らが受けたトレーニングコースの例のようにね。 そうすると、同じオペレータなのに、違う
モジュールでは全く異なる意味になります。 モジュールが100やそこらあるときに、全てを
一つにまとめられますか。 データ隠蔽だってそうです。 あちこちの会社で、人々が彼らの
モジュールをお互いにコミュニケートさせるときの問題を聞くと・・・
私は笑いをこらえることができません。
半年ROMってろ
>>198 ∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
202 ：
仕様書無しさん：2007/06/13(水) 01:20:09
オブジェクト指向勉強するにはどういう本がお勧め?
うちではもうOOは当たり前の存在。皆が普通に理解し使っている。
お前らけっこう大変そうだな。ただ、すねてばかりじゃ進歩はないぞ。
204 ：
199：2007/06/13(水) 01:29:29
>>202 Expart C Programming
プログラミング言語C++ 第3版
Effective C++
MoreEffective C++
Exceptional C++ Style
Effective STL
Modern C++ Design
Effective Java
注意 全部読んでからはじめること
205 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 02:01:17
>>203 で、よく聞いてみるとOOPL使ってるだけで
きったねーコードを自慢しまくってるというｦﾁ
ココ電、いつまでもそんなにすねるなよ。お前ももう年でOOが難しいと思うのも無理無いが
もう少し広い視点をもった方がいいな。きっとお前でも少しは理解できるようになるって。
がんばれっ。
そうだなぁ
非OOPLが殆ど使われなくなったらOOを信用してみよう。
>>204 >Exceptional C++ Style
はメソッドを否定してるじゃん
>Effective STL
STLのデザイナはオブジェクト指向を嫌いだと言ってるぞ
209 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 08:51:03
■JavaなどのOOPLの状態遷移は擬似状態遷移である
ところでUMLの状態遷移が擬似状態遷移であることを知っている人はこのスレにいるだろうか？
UMLはハードの状態遷移から朴って来たものだけど、現実のプログラムにプロセスが存在するがゆえに
真の状態遷移とは異なる動作をするのだ。
昔、マジでOOやってたときに気づいたものだけど、これはだめだろう。
設計に使えない。意図した動作とずれが生じてしまう。
真の状態遷移と同じにするには、サブルーチンコールではなく、本当にメッセージを投げてプロセスを分離しなければならない。
ちなみに状態遷移図は３０年前から扱っている。
遷移状態を持ったプログラムを読んでいるだけで状態遷移図が頭のなかに浮かび、
禁止された遷移、本来の遷移とか即座に見える。
>209
それは書いた人の着眼点の問題。
ＵＭＬ自体とはなんの関係も無い
211 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/13(水) 09:35:07
「オブジェクト指向」の日本語が分かりにくいのは、「オブジェクト」に対する適切な日本語訳がないからだ。
ほとんどは「物体」でも問題ないが、実体の無い物もあるので、「オブジェクト」が一番いい。
無理に日本語訳するなら、「物定義型」プログラミングと言う所だろう。
構造化プログラミングを長くやっていると、仕様を聞いた段階でも「処理の流れ（状態遷移）」が浮かぶ
ようになる。構造化からOOに行く人は、この処理の流れを細かく分解して、オブジェクト毎に編成し直す
事になる。最初はこれが大変な作業だが、そのうち慣れる。
最初からOOの人は、仕様を聞いた段階で「オブジェクト」が浮かぶ。
212 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/13(水) 09:59:53
>>197 それは「C++の複雑さ」を「オブジェクト指向の複雑さ」と間違えている。
C++のtemplateとoperatorは悪意があれば、ソースコードを芸術的なまでに難解に出来る事は周知の事実。
しかしtemplateとoperatorはOOと直接関係は無い。
再利用に関しても、OOの再利用は「修正が入った時の再利用性」だが、「別プロジェクトでの再利用」と
間違えている。OOは非効率だが直感的だ。
本の著者でもこの手の勘違いをしている人は多い。外国人も日本人以上に分かってない人も多い。
>>196 >OOPやっててラクだと思ったのはオーバーロードだな
はい、OOPとは関係ありませんね。
>>212 おじゃばさま、かっこいい。
で、おじゃばさまが推奨のOOPの良書はなんですか？
褒め殺しktkr
216 ：
仕様書無しさん：2007/06/13(水) 12:43:14
197はジョークサイトのネタだろ（ｗ
204もネタだし（ｗ
217 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/13(水) 19:22:16
システム開発のような明確な答えがない世界では、明確な答えが用意されていて答え合わせをするだけの、
学校のテストのような勉強方法は通用しない。
本を読めば習得出来るとか、デザインパターンのような型に当てはめればうまくいくとか考えている人は、
早急に考え方を改める必要がある。開発の世界の基本は「試行錯誤」だ。
何か作って機能追加を繰り返せば、そのうち分かると思う。
218 ：
仕様書無しさん：2007/06/13(水) 19:27:02
219 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 19:28:27
オブジェクト指向とかいっても
Cのほうが美しいﾓﾝ！
221 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 19:34:07
ステートマシンA
状態１ ステートマシンBを起動し、状態２に移行する
↓
状態２ 終了状態
ステートマシンB
状態1 ステートマシンAが終了するのを待って状態２に移行する
↓
状態２ 処理 終わったら状態３に移行する
↓
状態３ 終了
222 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 19:37:23
この例だと 真のステートマシンなら問題ないが
OOPLだと（マイナーな言語はしらね）ステートマシンBの状態１で止まってしまう。
実装の問題
224 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 19:47:01
いやいや。
ここいらへんを正しく理解していないと大きなシステムで必ずずっこけるぞ。
Listener書けよ
226 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 21:02:59
UMLではこうした問題の一部を解決するのに 「フォーク」 という端子を導入した。
フォーク=forkだ。
あきれたことに、これもパクリだ。
UNIX系でCで組んだ事のある人なら知ってるだろうけど、あのforkだ。
しかも解説書にはカタカナで「フォーク」と書いてあるところが痛々しい。
何も知らない初心者をだまして、新しい概念であるように見せかけて金をふんだくろうとしている魂胆がみえみえだ。
forkなんて仕方なく使うけど、実装としてはかなり奇形児である。 OOしか知らない香具師に売りつける分には問題ないと思ってるのか・・・
227 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 21:09:34
問題はさらに大きくなる。
OO支持者なんか大抵はマルチスレッド（マルチプロセス）プログラミングの素養が無い。
そんなのにそれとは意識させずにマルチスレッドを使わせてしまうのは大問題である。
ロックの輪ができるとシステムが止まってしまうが、ステートマシン間で意図しないロックループができてしまうことや
データーベースのロックとステートマシンのロックが合わさって大きなロックループができてしまう恐れもある。
228 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 21:13:41
それから状態図としてプロセスを意識せずに抽象化していたはずなのに
これでは状態図を扱うときにいちいちプロセスを想像しながら書かなければならない。
これはUMLが設計図としてすでに破綻している証拠である。
最初からフローチャートで書いて、状態遷移図は参考程度のあまり精密で無いものをつければ十分ではないか。
マルチスレッドの素養があるやつなんかいないぞ。
#シングルではなく最初からマルチで教えれば素養になるかも知れないが。
レス番飛びすぎ
UMLけなす前にちゃんとシーケンス図とかアクティビティ図とか使えよ。
232 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 21:39:54
シーケンス図は通信からのパクリだし
アクティビティ図はフローチャートだし
なんでそんな前からあるもののパクリを自慢するのか
233 ：
仕様書無しさん：2007/06/13(水) 22:05:57
>>232 それが、ココ電を筆頭としたITドカタクオリティ
>>232 表現方法を統一したのがUMLなのに
オリジナリティをもとめてどうする
>>232 誰も自慢しとらん。
「フローチャートはUMLでも使われてる」というとるだけだ。
なのに「状態遷移図だけでは設計書として成り立たない」という事柄が
何故「UMLが設計図としてすでに破綻している」というところに繋がるのかね？
大体UMLなんて「既存の設計書の書き方や表記法を統一して、ひとまとめにしたもの」だろうに。
お前の書いたフローチャートなんて、他人にとったら暗号に等しいことを知れ。
程度の低いコテハンに釣られるなよ
スルーしろ、スルー
237 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 22:26:47
どっかの宗教の教義を暗記するのと変わらん。
宗教に入ってない人には全く意味が無い。
このコテハン、なんかマジで言ってそうで嫌だなぁ・・・
239 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 22:31:18
ソフトウエアの外注の仕方
まず値段交渉をして見積もりを出させる。
次に、「ところでお宅ではオブジェクト指向扱えます？」と聞く
扱えると答えたら、じゃあそれオブジェクト指向で組んでください。
といって値段を２割負けさせる。
２割くらい効率があがるんでしょ？
こことおんなしことν速とかbiz+でやるからな・・このオッサン
痛々しくてみてられん
241 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 22:40:08
技術論で反論しろよ
個人攻撃してどうする。
>>234 アクティビティ図みたいにデータフローと制御フローを一緒にして
オリジナルより質の悪いものになってたらアホみたいだわな。
いいからもう相手にすんな
アクティビティ図はBPMくらいおおまかな粒度に使うのがちょうどいい
見た目もきれい
OOPで開発効率が上がる
という扇動を信じている人がまだいるのか
246 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 23:03:33
えええ？
アクティビティー図がデーターフローだって？
なにそれ？
OOPはまたナニだが、再利用率が上がれば開発効率が上がるという上からのお達しが。
再利用率 なんていう言葉は神話でそ。
何にも知らない上からのお達しとやらで
言われる通りにしてたらどうなる。
249 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 23:12:52
サブルーチンだって昔からある再利用モジュールだけど
OO厨にはサブルーチン設計ができない人も多い。
サブルーチン設計さえ使いこなせてない人にクラスの再利用なんか無理だと思う。
なんだ？サブルーチン設計って
UMLは懐の深い設計ツールだぞ。拡張を許容してるから標準スタイルが
気に入らなきゃ自分で使い易いように拡張すればいいんだよ。
ま、頭の固いおっさんには無理な話かも知らんが、ＵＭＬの使いずらい
からＯＯＰはダメって展開には無理があるぞ。
サブルーチン設計って何なんだよ。
機能分割のことか？
253 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 23:33:00
サブルーチン設計とは
サブルーチンを再利用可能性が高いように設計する事だ。
インターフェース形式、１サブルーチン１処理、汎用機能
世間一般にはそんな用語は無いがな。
サブルーチンって言うと昔のBASICにあった再利用性が低い関数モドキしか思い浮かばん。
256 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 23:51:09
おいおい サブルーチン設計も知らないで再利用やろうとしてるのか？
無謀というか馬鹿というか・・・
257 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/13(水) 23:54:43
クラスの再利用はつまるところサブルーチンであるメソッドの再利用に他ならないぞ。
それをすっ飛ばして再利用しようなんて夢だけ追っているのか？
構造化設計とどうちがうんだ。
相手にすんなって
アホがウツルぞ
260 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 00:06:05
スルー推奨で
OOってこだわりすぎると
途中参入者が迷うんだよね
一つの業務をこなすのに必要なクラス＋メソッドが散在してるんで
「こういうメソッドありませんか？」
ってな話になりがち
クラス設計は機能分割の延長線上には存在せんぞ。残念だったな。
だから業務を実装するときにいろんなクラスを使う必要が
出てくる可能性がある
>>209 OOPが出てきた当初は「並列処理が出来る！」と盛んに宣伝されてたね。
GUIの今ならタイマータスクとあわせて使ってマルチタスクもどき、
マルチコアを使ってマルチスレッドも出来るんだろうけど、
昔のシングルコアのCPUで真の並列処理なんて出来ないだろうに。
>>217 自分でテスト問題を作って、自分で答えて、自分で採点するのがシステム開発
だと思うんだ。
>>227 マルチタスクをマルチCPUシステムでやってこれた漏れには素養があるんだなｗ
>>256 オブジェクト指向で設計することにより、
モジュール結合度が弱く、モジュール強度が強くなるような設計がしやすいんだと思う。
構造化プログラミングとは、すべてのプログラムは連接、判断、前判定反復の３つの基本制御構造を組合せて
書くことが出来る、というものでオブジェクト施工プログラミングとは相反しない。
ここは楽しいね。
いい息抜きになる。
>>264 構造化設計でつくったほうがとっちらかるぞ。
なにしろ、どこにどんな関数があるかなんてノーヒントだからな。
自演かよ
269 ：
266：2007/06/14(木) 00:34:49
どこにどんな関数／メソッド／クラスがあるかなんて
大昔から根本的な解決を見ていない問題だろ。
どうして構造化設計と構造化プログラミングを同一視するかｗ
>>267 まあそうだけど、共通関数.cppみたいになるしね
クラスはまあ良くはなりやすいんだけど、
大規模プロジェクトになると同じようなクラスメソッドが
散乱する傾向が強いしね
273 ：
266：2007/06/14(木) 00:40:59
>>271 行のあけ方が足りなかったかｗ
同一視してないから２行空けたんだ。
ここは設計についてだけ論じる（わめく）場所じゃないと思ってた。
共通部品の設計をわからんちんにやらすと
とんでもない目に遭うのは設計手法に関係なく一緒だな
275 ：
仕様書無しさん：2007/06/14(木) 00:45:49
マ板がネタ板であることを実感するスレだな（ｗ
＞モジュール結合度が弱く、モジュール強度が強く
まあ、これにつきるだろ。
昔なんて、全ての処理で使うための引数をずるずる引きずり回して、
再利用のためにコードはフラグまみれ。副作用しっぱなしで処理結果の問い合わせ不能、テストはデバッガ依存。
状態保持のためにワーク領域切りまくり。単純なデータ型しかあつかえず、コードはやたら冗長でネストが異常に深くなる。
「この処理にくる時点ではXXという状態はありえない」など、コード上に表現されない
暗黙的な仕様の依存関係を破壊するのが恐くて、一度かいたコードは変更不可。
処理には主語がなく、恣意的に切られて適切な命名がされない。
こんなだぞw
共通部品ってなんだよ。OOPは全てが共通部品のつもりで書け。
業務は部品をアセンブルする役目のものだけが知ってればいいんだ。
>277自分に酔ってる匂いがぷんぷんするようなレスだな
なんかしらんが、すまん
親クラスだらけって、何がいいたいかちとわからん。
クラスとポリモと継承がわかってりゃええよ
282 ：
266：2007/06/14(木) 01:09:17
漏れのようなｵｻｰﾝにもようやくわかってきた。
今はオブジェクト指向プログラム言語以外のプログラム言語に習熟した若い人は少ないんだろう。
だから、一昔前の
>>276のような状態が当たり前の現場を見ていない。
それに、オブジェクト指向では原則的に
＞モジュール結合度が弱く、モジュール強度が強く なるようにしか作れない。
だから、それ以外のプログラムって物の想像がつかないか難しいんだろう。
自演乙
>>282 過信は禁物だよ。OOPでも
＞モジュール結合度が弱く、モジュール強度が強く
ならないようにもつくれるし。
単に若い人たちは反復開発の経験がすくないから、
あえてプログラミングに制約を課すことで長期的にメリットを得るという
発想が直感的でないのだとおもう。
OOP以外の話題だけど、
>>170や
>>173 テスト関連の話題。
ユニットテスト出来ない例外処理なんて設計の無駄。
エラー処理を色々仕込むていっても１メソッド１例外じゃない？1メソッド＝１処理だろ。
ユニットテスト出来ない例外なんて本当に必要なのか問いただせ。
設計変えれば例外処理はほぼ全てフレームワーク側でカバー出来るはず。
詳細設計以後開発する実装コードは例外処理なんてまず書かないやり方がいいって。
あと、
>カバレッジを１００％にすることがテスト品質って信じ込んでいるアホいるんだが、どうにかならないのかな。
こういう不満は現場で言うべき。コミュニケーションもっととってお互いに成長しようや
カバレッジも自分でテストコード書くんじゃなくソースドキュメントから自動生成させればある程度網羅出来る。
if文等の条件分岐も網羅出来る奴なかったっけ？
拡張したC言語がまさにそれやってた覚えがある。
関数の宣言前に事前条件事後条件を与えるタイプの言語。
ひどい自演を見た
メイヤーですら表明によるメソッド仕様の完全記述は非現実的と割り切っている。
テストケースのカバレッジ網羅性など気にしても益は少いだろう。
|┌──────┐ |||
| | (^---^) ？ . | |||
| | γ. ・,,,,・丶 ｶ | ◎ |||
| | ｌ..( o o）ﾊﾞ .| |||
| | | .. (,,ﾟДﾟ） .| |||
| | `'ｰ---‐'''' . | 電子|||
|└──────┘ﾚﾝｼﾞ.|||
|￣￣￣￣￣￣￣￣￣￣￣|
理解度の差があろうがなかろうが、
現場を仕切るリーダーにOOの素養が無ければ
どうしようもないな
結局そんなポン助は言語で人集めるんだしな
290 ：
仕様書無しさん：2007/06/14(木) 02:12:30
今時はOOじゃなくてDSLだろ。取り残され過ぎ。
ま、DSL自作なんて大多数のOO廚にゃ無理なんだろうが。設計も実装も。
そうだな
今はDSLiteの時代だな
ドラクエもプレステ捨てたしな
D言語が優れてるのでD言語使いましょう
って言ってるのと大差ないな
Dコンパイラってもう出てんのね
また学習ネタが増えた・・・
294 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/14(木) 09:52:22
>>221 例が具体的でないので分かりにくいが、根本的に間違っている。
OOの場合は「状態」を持つのはクラスである。つまり「ステートマシン1」と「ステートマシン2」で
状態を共有するような設計自体が間違いだ。
OOの場合は相互に影響する「状態（ステート）」があったとしたら、それは1つのクラス内で持ち、
他のクラスには影響しないようにする。つまりステートマシン1と2を分解して、ステートクラスAの
フィールド変数に持ち、それに関連する処理をクラスAのメソッドにする。
ステートに関係ない処理はクラスAから排除して、クラスBやCに実装する。
ベテランの構造化Cプログラマは、電球のような設計をす。経験が長ければ長いほど、「処理の流れ」を
考えてしまって、それに捕らわれてしまう。
だから言っているだろう。処理を分解して組み直せと。
>>290 書き出しが「イマドキ」な奴って、どうしてこう莫迦なんだろう…
頭が今時だからさ
今時政治犯として逮捕され
今なんどきですか？
299 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 18:43:26
落語の時そばかよ
300 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 18:50:55
おじゃばはお里が知れてしまったな。
ドキュメントビューアーキテクチャのようなビュー分離をやった事が無いように見受けられる。
Javaでは表示クラスが発行するGraphicsオブジェクトを使わないとグラフィック表示が作れないようになっており
自然とビュー分離が強制されるようになっている。
分離したビューではステートモデルが最良にしてほとんど唯一の推奨される構造で、
業務アプリでそれ以外の構造をとるやつはプログラミングの才能が無い。
301 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 18:53:11
ビジネスロジック
ステート１ 初期化
ステート２ 案内入力
ステート３ 処理１
・・・
ビュー
ステート１ 画面初期化
ステート２ 案内表示
ステート３ なにもしない
・・・
302 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 19:09:42
といった具合に おじゃばが「根本的に間違っている」といっている
ステートマシンの状態の共有はこの場合必然なのだ。
他のやり方だとこんなのがある
１）作りながら これはこの場合表示しちゃだめとかこれは表示したいとか気づくたびにif文やフラグを追加していって
フラグをビジネスロジックでスイッチするプログラム
２） １）をさらに大規模にしていったものでif文とフラグがごちゃごちゃになったあほの作品
初期化も何も分けられていないので、 画面遷移で A→B→Cという遷移の仕様で作ったものを
A→Cと仕様変更されると破綻して回復不能の動作不良に陥り、作った本人にも治せなくなる。
３） １）を作っているうちにすべての表示物をモジュール化した上で全部にフラグをつけ、ビジネスロジックでフラグを集中管理する。
ちょっと頭がいいけどフラグ管理が大変
４例外） すべての表示物をオブジェクトや構造体変数として定義し、表示に必要な型不定の物体を必要なだけ登録し、
表示は描画ルーチンに任せるやり方。
コンピューターグラフィックスやゲームで使われる。
303 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 19:12:45
５）画面が変わるたびにCanvasなどの表示クラスごと廃棄して新しいのを定義していくやり方。
それぞれほとんど静止画面しか作れないので不便。
これはひどい
すくなくとも10年は古いぞ。。
ココ電って、あれだろ
これ何のクラスだろ？とか何のメソッドだろ？とか
思っても、直感的にわからなきゃスルーするタイプだろ
306 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/14(木) 20:01:54
「ドキュメントビュアーアーキテクチャ？」だが、何の事か分からない。
ビューと処理の分離の事を言っているのか？ビューと処理の分離と言うのは、表示用のデータと処理の
依存性を少なくしようという意味で、ビュー側に処理を入れようという意味ではない。
だからビュー側に処理を入れる自体が間違いだ。処理がないから状態の共有は不要。
前提が間違っているので、それ以降の文はコメント不能。
これはおじゃばの言うとおりだな
309 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 21:16:32
はあああああ？
誰がビューに処理を入れろってかいた？
もうだめ
まるっきり判ってない。
310 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 21:18:19
おじゃばはアプリ作った事が無いWEB屋さんだと判明した。
もうだめ
１）作りながら これはこの場合表示しちゃだめとかこれは表示したいとか気づくたびにif文やフラグを追加していって
フラグをビジネスロジックでスイッチするプログラム
書いてるわけだが
312 ：
仕様書無しさん：2007/06/14(木) 21:24:14
>>310 ココ電
>おじゃばはアプリ作った事が無いWEB屋さんだと判明した。
おじゃばの一番痛いとこつくなよ、それはおじゃばには禁句なんだよ。
本人、一番気にしてるんところなんだから。
313 ：
仕様書無しさん：2007/06/14(木) 21:40:47
おじゃばさま質問でーーす。
おじゃばさまは
仕事でJava以外の言語でクラスライブラリを用いたアプリ作ったことありますか？
ドキュメントビューアーキテクチャ知らないんですか？、使ったことないんですか？
314 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 21:40:48
分離したビューではステートモデルが最良にしてほとんど唯一の推奨される構造で、
他のやり方だとこんなのがある
>>311 315 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/14(木) 21:42:39
出来合いのコントロールを並べていくだけなら そりゃあ表示ルーチンなんて知らないだろ。
Paint( Graphics g )
を作ったこと無いんだろう
ココ電はいったい何を言いたいんだ？ おまいの説明はいつもながら解り難いなぁ..
ココ電のコテ外しの術、見破ったり。
318 ：
仕様書無しさん：2007/06/14(木) 21:50:17
ココ電
おじゃばは、VC++を用いて開発やったことないと思うぞ
319 ：
仕様書無しさん：2007/06/14(木) 21:56:25
>>318 Paint( Graphics g )って書いてるから常識的に考えてJavaなのだが、、
doc-viewアーキテクチャはMFCの話だろ
swingはMVC
321 ：
仕様書無しさん：2007/06/14(木) 21:57:32
Javaであっても「MVC」ぐらいは知ってるよな。
ｼﾗﾈｴから、わけわからんことほざいてんだろ
ココ電はANAの障害もOO厨がどうのこうのと嬉しそうにほざいてた基地外だからな。
視野の狭さと妄想癖は折り紙付き。まともに取り合わない方がいい。
賛成 … 最近OOを齧った人。または夢見がちな人。
反対 … 最近OOPを導入して痛い目に合った人。または単なる怠け者。
沈黙 … 理想と現実の違いを知ってる人。またはデスマーチ中の人。
>>302 3のパターンをつくろうとして、めんどうになって４のパターンが普通じゃね？
１と２は破綻するのが最初から目に見えてる。
コテハン２人
おまぃら隔離スレ立ててそっちでやれ
ここはOOのスレ
OOPを導入中のデスマな俺がやってきましたよ
言語はC++（細かいことはほっとけ）
しかし、集まった連中はC（++ではない）で集められた連中で
設計の時点でOOは無視され、おもいっきり業務よりのプロジェクト分割
ただ、コアを作ってるPGが超レベル高くて、
物自体の安定度は超凄
納期デスマってやつですな OOはどこかに飛んでいきましたが
328 ：
仕様書無しさん：2007/06/15(金) 01:53:02
C++を採用した時点で運命が決まったようなものだな（ｗ
C++で、まともにOOPになっているプログラムなんて見たことない。
329 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/15(金) 01:57:33
それが ２）やるやついるんだよ
で、画面遷移の順番変わってデスマーチ
>328
JavaでもOOもどきが多いからな
言語仕様だけが先行してて技術者は言語だけを覚えるから
概念の話などしても伝わらないしな
OOが分からないっていう消極的な理由ならまだいいけど、
クラスを５個６個つくっただけで「把握できなくなるからやめてくれ」とか
拒否されると萎えるぜ。
「クラスが多すぎて把握できない」ってよく聞くけど、何をそんなに把握したいんだろうか。
OOP説明されると判った気になるが、
いざ作ろうとすると途方にくれる(´･ω･｀) 。。。
人のクラスを使うぐらいがオイラの限界。
334 ：
仕様書無しさん：2007/06/15(金) 08:17:20
>>332 どういう処理のコードがどこに存在するか、というマッピングの全体像。
>>333 最初から完璧目指そうとしないで
まずは何で構成されてるかを考えることからやって
ゆっくりがんがろーぜ
336 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/15(金) 08:52:58
クラス図を提出させれ
そういうのは
>>331 そんぐらい把握出来なければ、プログラマに向いてないと思うんだ…
>>334 そういうことはオブジェクト自身が知ってるだろ。Eclipse使ってりゃ補完して教えてくれる。
どうしても実装が知りたけりゃボタン一発でメソッド定義にジャンプ出来る。
アホでも把握できるだろうが。
と思ったけど、クラス名やメソッド名は謎のアルファベット3文字+連番というルールがあったりとか、
特に理由無くEclipse禁止とか、そもそも職場のマシンでEclipseなんて動かねーよ！
なんていう、かわいそうな人にはこの前提は意味をなさないな。
339 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/15(金) 20:52:28
>>電球
301の図を見たら、ビジネスロジックとビューに処理を分けているように見えるが。
表の意図が分からんな。
>分離したビューではステートモデルが最良にしてほとんど唯一の推奨される構造で、
>他のやり方だとこんなのがある
まず、推奨される唯一の構造なのに、他のやり方を説明してる意味が不明だ。
本当はそれが推奨される唯一の構造ではないと気が付いているのではないか？
それと「分離したビュー」や「MVC」は、OOとは関係ないし、他のやり方の「1、2」は非OOの組み方だから
OOの欠点とは関係ない。
まず全体的に何が言いたいのか分からない。
「OOの欠点」を指摘して、「OOが使い物にならない」と言いたいのか？
しかし電球の組み方はOOとは関係ない非OOの組み方だから、それを例に出されても困る。
それともOOの組み方を知りたいのか？294で説明済みだぞ。しかしプログラム構造より俺の経歴に興味が
あるようだが。
とりあえず、OOを勉強してみたらどうだ？その前にその思い込みを治した方がいいぞ。
もう無理だろ。頭固いし年だし。ひねくれじじぃには理解できない。
341 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/15(金) 21:21:42
おいおい
おじゃばのほうがOO判ってないとさんざん証明してしまったのに まだそんな事いうのかよ。
無学者論に負けずだな
OOの例をひとつも出さないで、是(おじゃば)も非(ココ電)もねえぞ
まともに議論しやがれよ
OOモドキを批判、賛美するスレはここですか？
古の水野薬局
345 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/16(土) 08:28:30
ここまでの議論の経緯
ＵＭＬのステートマシン図について
↓
例としてドキュメントビュー・アーキテクチャのステートモデルを挙げて議論
↓
おじゃばがドキュメントビューなんかOOと関係ないと切れる
自分にはそもそもUMLとOOPに親和性があるからとはいえ
なぜOOを語るときにUMLを持ち出さなくてはならないのかが理解出来ない。
347 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/16(土) 13:57:15
じゃあUMLはOOと関係ないという事で
UMLには状態保持を意味するHマークがあるぞ。
オブジェクト指向っていうとjavaとC++なイメージなんだけど
お前らはどの言語でよくオブジェクト指向を使うの？
OOPつったらRubyだろ
351 ：
仕様書無しさん：2007/06/16(土) 14:37:45
>>349 C++って純粋なオブジェクト指向言語じゃないんじゃないのか。
C#もあるよ。
オブジェクト指向言語としての純粋性にこだわる必要はないとおもうが。
C#だって純粋OOPLではないし
純粋って何よ？
Smalltalk
誰が決めたのよ、多数決か？
Smalltalkにあって、C#にないものって何？
>>356 逆だろ
オブジェクトでないものを言語仕様に持ち込むと純粋でなくなる
Smalltalk処女。C#はヤリマンでＯＫ？
>>357 そういう意味ではJavaも純粋ではないことに？
359だが、なんで俺に聞くんだよｗ
私がSmalltalkと適当に書き込んだらこの有様だ。
365 ：
仕様書無しさん：2007/06/16(土) 19:06:22
うわ・・・言語の話になると、途端にスレが伸びてる・・・キモッ・・
C++はマルチパラダイム言語
ってwikipediaに書いてあった。
スレタイの答えは出ているようだな。
コテハン同士の不毛なやり取りに見て取れるように、お互いがわかっちゃねーで平行線。
なんてことだ、俺たちはとんでもない思い込みをしていたのかもしれない・・・。
つまり、最初からOOなんてなかったんだよ！
OOは確かにある。ただあまりにも当たり前すぎて、空気みたいにその存在を意識しなくなっておるのぢゃ。あぁ人間とはなんと罪深き生き物よ。
369 ：
仕様書無しさん：2007/06/16(土) 19:45:52
>>366 Wikipediaを見なくてもストラウストラップさんのWebに
書いてあったよ。FAQのページにな。
Wikipediaを見るのとストラウストラップさんのWebを見ることの
面倒臭さに一体どれほどの違いがあるというのか。
371 ：
369：2007/06/16(土) 19:49:29
Wikipediaは嘘が書かれていることがよくあるんだよ。
C++は節操無し言語言語
ってjavaに書いてあった
うわ・・・偽装Java坊が沸いてる・・・ﾏｼﾞｷﾓ・・
まるでストラウストラップさんが嘘を書かないような言いっぷり
375 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/16(土) 22:32:05
純粋オブジェクト指向とは、言語や設計などの概念や実態を持ちません。
「俺がOOを一番判っている」
「俺以外はオブジェクト指向を判ってない」
という２つの想念だけが残ったものを指します。
Javaぐらい色々固まってたり、動的コンパイルが無い言語だと
リファクタリングツール作りやすいってのはあるよね。
C++や、Rubyとかだとむずいと思う。
377 ：
仕様書無しさん：2007/06/16(土) 23:05:16
378 ：
仕様書無しさん：2007/06/17(日) 00:03:22
379 ：
仕様書無しさん：2007/06/17(日) 12:54:20
めんどーだから
OOがわかりにくい、混乱する、失敗した、
などの話が出てる理由は一体なぜなんだ？
すばらしいものならここまで負の話は出てこないはずなんだが
すばらしい強力な道具でも使いこなすためにはスキルが必要なものもある
構造化設計やDBの正規化なんかですら、
草の根レベルでは定着したとは言い難い
383 ：
仕様書無しさん：2007/06/17(日) 15:35:11
>>380 ソフトウェア工学は、過去の苦労から生まれたものであり、その意味その価値が分からないものにとっては、やはり無意味なものであり難しいものである。
384 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/17(日) 15:59:11
構造化は登場以来、量が増えてないのに
OOは年々増える一方。
まあ本を売るための詐欺なんだけど、このペースで増えていくと誰も覚えようとはしなくなるし
採算が合わないのが自明になってしまうので将来性は暗いね。
ガンダムOO
たとえば正規化なんていうのは誰がやっても全く同じになる
OOはそういう「誰がやっても同じになる」ような手法を確立すべき
構造化とか正規化とか書いてる連中は複雑系についてもうちょっと学ぶべき
扱う問題が大きくなって単純化していく手法が行き詰まったのが現状
DBの使い方にしても大雑把な設計が氾濫してるぞ。正規化もあやしいし、
むやみに自然キーや複合キーを主キーに設定してたり、外部キー制約や
NOT NULL制約もまともに設定してなかったり。
まともな設計がされないのはOOに限ったことではない。素人さんが多すぎ
るよ、この業界。
免許制じゃ無いからね。
バイトみたいな意識で仕事しやがる人間も居るし・・・
会社がまともな待遇よこさないから
バイト並みのモチベーションでやるお
モチベーコンウマー
せっかくのリレーショナルデータベースをカード型データベースみたいな使いかたしてくれちゃうからな。これぞ宝の持ち腐れ。
>>386 ＞OOはそういう「誰がやっても同じになる」ような手法を確立すべき
それがデザインパターンなんだけどね。
「誰がやっても同じ」が実現されるとｵﾏﾝﾏくいあげです。
正規化はスクリプトまわしても実現できるほど手法が確立されてるんだよ
デザパタと一緒にすんな
構造的な問題が大きいんじゃねーの？
PM、SE、PGって本来は役割の違いなのに序列として扱われてる
その結果技術力の低いPMがいい加減な仕切りを行い、
PGは全然考えずに言われたことしかしない
大体さ、JavaでもC++でもなんでもいいんだけど、
その言語を扱えないPMが言語策定で自分の知らない言語を選んでる時点で
終わってると思うんだわ
で、SEやPGが改善案を出してもPMには知識が無いからそれが理解できない
結局現場で「OOとは」みたいな話をすることになり、
PMは一夜漬けの知識をひけらかし、有識者は別のことを言い、
無知なSE、PGは右往左往する
ってことでOO以前の構造的な問題が大きいってことになりそ
>>397 同意。
PGの地位が低すぎる。
いい年になってまだコード書いてんのかよ？という風潮
誰にでも出来る簡単な職と思われてるが、上と下との技術の差が違いすぎる。
下は、コピペ＝プログラミング、上はちょっとまちな～ で何でも作る。
理想的なのは期日が掛かって良いならSE一人でこなせるだろう仕事を
効率化の為PGに仕事を任せるという感じ。
PMは上記が出来るベテランSEがなるか、せめてPG上がりの奴にさせてほしい。
今は、１００0年あってもやる気の無いSE一人じゃ出来ない仕事を、出来るか出来ないか解らない
PGに全部任せるという感じ。
PMは日経なんちゃら読んだだけの中間管理職。
すれ違いだが、ドカタ業界に優秀な人材を多く求めるのは間違ってる。
われわれはの大多数は、ITドカタであり、職人ではない。ドカタの第一は体力で技術力ではない。
ITドカタなら、なんちゃってOOでまったく問題ない。所詮われわれはITドカタなのだよ。
400 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/18(月) 19:12:15
土方が会社からかきこんでていいのか？
高級言語が登場した時も、「アセンブラの方がいい」という奴はいた。
構造化プログラミングが登場した時も、「goto文の方がいい」という奴はいた。
そいつらはどうなったか…みんな落ちぶれて消えていった。
また同じ事を繰り返してる奴がいる。
402 ：
仕様書無しさん：2007/06/18(月) 19:43:59
アセンブラはしんどらんわ！ぼけっ！
適材適所なのにどれが最強とか もうね
あ、生きた化石がいるw
405 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/18(月) 20:44:36
>>電球
俺は電球と張り合うつもりで言ってる訳ではないぞ。
まあ例えるなら、
台車を横から押して”使えない”と言っているのに、縦から押すんだって言ってるだけだよ。
それを見て笑っている見物人より、ずっと良心的だろう。
406 ：
仕様書無しさん：2007/06/18(月) 20:49:32
>>401 デバイスドライバ屋は消えてはいないが。
>>406 デバドラか職人の世界だな、ドカタは入れない世界だな。
>>405 よくわかってるジャン
つまり、
台車を横から押して”使えない”と言っているおじゃばに、ほかの香具師が縦から押すんだって言ってるだけだ
ということだろ、おまえらYO
408 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/18(月) 22:13:49
その横を俺がフォークリフトで通るんだな。
そしてゴシラが全てを踏み潰していく．．．
結局プログラミング技法や設計手法なんて昔から現場では軽んじられてきたか、
ｺﾝｻﾙのセールストークの中だけの物だったということじゃないか？
低レベル制御の組み込みなんかでは、継承なんか怖くて使えないし、
スタックの無駄遣い、デバッグ困難と良い事無し。
でも人材はオブジ～しか知らない。
昭和の遺物としては、オブ～言語を使って理想の構造化プログラミングをするのが楽しい。
効率の良いモジュール分割をして、データ構造に則ったプログラム構造を作る。
最下位モジュールの簡潔なこと、簡単な事。
できないことのいいわけむなしす
こうやって年寄りはOO出来ない自分を慰めているわけだ。みじめだな。
別に。惨めなんかじゃないよ。
業務遂行に必要ない知識もスキルもいらないね。
将来的に必要になるかも知れないというだけでは勉強もする気もないし、
これは経験から言うことなのだが、勉強だけじゃ実際に必要になったときさえ
実務に大きく役立つようにはならんだろ。
大体、もう管理者を管理する側にまわっているから、もう要素技術を学んでいる暇なんぞないわい。
Googleでは、マネージャクラスでも半分の時間をコード書きに充てるという
爪の垢でも煎じて飲んだらどうだ
415 ：
仕様書無しさん：2007/06/19(火) 01:05:23
>>412 うちは逆で、年寄りがOOとか連呼してるのをみて、
何を夢みたいな事いってんだ？○○の一つ覚えか？と若者が笑ってる。組込み系だけど。
413が勤めているのは人材派遣や偽装派遣で人月いくらで稼いでいる会社というオチだろ？
>>414 Googleじゃ技術部門のマネージャは技術知らないと生きて気無いんじゃないか？
PGでなもなく、さらにOOがわからん管理職様
>>413が、なぜOOスレに来るのか不思議だよ
418 ：
仕様書無しさん：2007/06/19(火) 01:43:40
>>416 なるほど、PG商事なのか、俺らを売買してるからマ板に来てるんだな。
>>415 組み込みでも大規模なものはOO開発されてる部分と聞いたことがある。
ま、ワンチップマイコンで十分な分野を扱う限りはOO不要だろうが
419 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/19(火) 02:41:51
構造化の延長としてクラスを便利に使うだけでいいじゃん
「構造化クラス志向」
これで手を打とう。丸く収まるはず。
ワンチップの一つ一つがオブジェクト
422 ：
仕様書無しさん：2007/06/19(火) 13:15:03
関数型言語が思い浮かんだからダメ
ココ電球志向プログラミングで良いんじゃね
425 ：
仕様書無しさん：2007/06/19(火) 19:22:34
そのATM裏に人入ってねぇか？
428 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/19(火) 20:28:40
ATMは裏に人が入れますよ。
>>421 ソフトウェアの話だよ。
ワンチップマイコンの一つ一つにプログラムが書かれてて、
それをたくさん並べた機械でも、立派なオブジェクト指向さ。
ワンチップマイコン間で通信したら、オブジェクト間通信だしな。
オブジェクト指向を否定するってどんな人
>>429 それはソフトウェアの話じゃなくて、システムの話だと思うの。
ココ電球、おまい、都電のトローリーバスにwktkして乗ってた？
もし、そうなら、わしと同世代だな。
おまいらって、ハードの設計したこと無い？
オブジェクト指向の基本思想ってハード屋じゃ当たり前の考え方なんだぞ。
>>431 ひとつのマシンで完結してる仕事しかした事無いの？
何の話しだ。
オブジェクト指向化されたシステムと単に動けばいいシステムって
作るコストがかなり違うと思う。
俺は前者を求められてるのに後者のスケジュール組まれて死にそうだ。
>>433 431だが、まぁ組み込みにおいてはそうとも言えるかもな。
マシンと言うか「チップ」だが。
もうちょっと大きな機器間でIP通信やらするシステムは作ったことあるけど。
俺のしてる組み込みの仕事では、システム設計の段階で
既にモジュール(チップ)ごとに分割されている仕事しかしたことない。
こんな流れ。
システム設計(各モジュール(チップ)の要件が決定) ：この辺はすごいオブジェクト指向（？）
→モジュール設計(ハードとソフトの分担を決定) ：ここは指向とか良く分からない感じ
→チップに乗るソフトウェアの設計 ：ここは規模と開発環境次第
もしや世間のそういう組み込み開発では、ソフトの設計してから
それ以外をハードウェアにやって貰うようにするのが一般的なのか・・・？
オブジェクト指向というより、単なるインターフェースとブラックボックスでは？
いまどき携帯電話だってマルチCPUだぜ？
( ´ー｀)y-~~
OOで設計する時間があるプロジェクトがどれだけあるのか疑問
多くのデスマプロジェクトは
開始時点から納期・品質・コストに無理が発生するのがわかってるからな
443 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/20(水) 01:42:50
トロリーバスにのった記憶は無いな
路面電車が新宿を走ってたのは記憶にある。
昔の都内は大通りにレールが埋められてて空に電線網が張られてた。
444 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/20(水) 01:52:37
ソフトクリームというものが日本にやってきてデパートの食堂で初めて食ったな。
インスタントラーメンに東京オリンピックにアポロの月着陸に万博
そして秋葉原でコンピューターを売ってるのを発見した（４００４）
どうせ嘘だろうとおもった。
オープンリールの激安テープレコーダーが１０００円で売っててひとつ買ったな。
コンピューターにはまったのはずっと後、IMSAI 、オルテアつう８０８０のかっこいいコンピューターが売られて
３０分５００円でスタートレックやったときだ。
445 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/20(水) 01:55:18
そのころのソフトウエア業界はMISという詐欺で潤っていた。
OOでの一番の恩恵ってなんなん？
あぁ、コテハンには聞いてないからな
問題のモデル化
システム改変の局所化
>>447 それはOOPLの利点でOOの利点とは若干違う気がする
まあ、局所的な意味の違いが連鎖して、システム全体では機能しないなんて事が。
結合の時点でも分からずに、納品までこぎつけちゃうとこかな。
451 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/20(水) 09:32:01
組み込み系でOOを使えなんて言ってないぞ。
規模が小さく変更が少なく、速度を必要とするプログラムにOOを使う意味はない。
あとハードウェアのモジュール化とOOは、似ているが全くの別物だから気をつけた方がいい。
構造化の延長としてクラスを使うのは止めてくれ。電球の言うような多くの問題が発生する。
せっかく知的障害ｺﾃをNG登録してても
いきなり嬉しげにハードウェアの話をし始める間抜けが現れちゃいました。
俺は２個NG登録してるからあぼ～んが増えただけだな
454 ：
仕様書無しさん：2007/06/20(水) 16:18:20
おじゃばさまにしては451だけはマトモなことを書いている。
おっと夕方から大雨になるかな。傘を買いにいかねば。
電球＝おじゃば＝無名
456 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/20(水) 21:29:53
>>452,453
知りたくない奴に無理に教える趣味はない。
意見も反論もないなら、ROMってればいいんじゃね？
457 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/20(水) 21:55:20
俺なんか「仕様書無しさん」をNG登録してるもんね
最初からあぼーんだらけの中で一人で書いているわけなので煽っても無駄。
で？
>>457 ココ電球ーーーーっ
ワロタよ激わらだーーーっ。おまい、お笑いの才能ないか
>>451 おじゃば、
>規模が小さく変更が少なく、速度を必要とするプログラムにOOを使う意味はない。
なんか不明瞭だな。
規模が小さい、変更が少ない、速度を必要とするの論理関係はどうなってるんだよ
全部、&&結合なのか？
461 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/20(水) 22:57:13
おじゃばのスキルはJavaスクリプトなんだ
ajaxなめんな
>>462 そうですか、じゃ、かじりつくのはいい？
OO的なクラス設計を潔しとしない構造化的機能分割主義がOOPLの理解を妨げるんだろうな。
と妄想。
構造化原理主義者は中途半端に見えるクラス設計なる物を受け入れられない。
OOPLって究極的にはステップ数を減らす技法の事なのか？
ＯＯも構造化も場所によって必要だよ。
どんなにＯＯな設計してもライブラリは必要だし。
なんとか”指向”ってネーミングが
やたらと乱発されてるが
普及率がいまひとつなのは名前がイミフだからだな
>>467 それは構造化。
オブジェクト指向ってのはアクターモデルの為の技法だと思ってた。
>>469 違う。アクターモデルは並行プログラミングのためのものだ。
OOは逐次／並行の区別とは独立だ。
アクターモデルを契機としていくつかのOOPLが出来たのは事実だが
OOはアクターモデルに依存しないし、アクターモデルはOOに依存しない。
オブジェクト指向って表現(言葉）誰が使い出したんだ
ひょっとして、アラン・ケイあたりか
FullSpecのバカがあつまるとこんなスレになってしまうのか
哀れだ
473 ：
仕様書無しさん：2007/06/21(木) 14:32:54
なんか、↑の議論見てると
「結局オブジェクト指向って何？」と、言いたくなる。
>>473 結局オブジェクト指向って何？とお前は思っている。
馬鹿にしないから言ってごらん
>>472 はそのバカの一人です
475 ：
仕様書無しさん：2007/06/21(木) 14:43:47
>>473は議論しいる（た）と認識したんじゃね
ま、なにせ、FullSpecのバカがあつまるところだからな
478 ：
仕様書無しさん：2007/06/21(木) 15:20:23
>>476 ただ単に、意見の食い違いを議論と見てしまったというオチでした。
479 ：
仕様書無しさん：2007/06/21(木) 15:52:11
トップダウンでプログラムしやすいから使うだけど、PERLの方がラクかもな～と思うこの頃。
480 ：
仕様書無しさん：2007/06/21(木) 16:28:33
>>477 クレタ人は嘘つきだと言っているクレタ人ですか？
481 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/21(木) 20:32:49
オブジェクト指向とは馬鹿が選民意識を持つための方便なので
定義は馬鹿の数だけあり、どの定義でも「自分が一番理解している」と補足されてます。
で？
483 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/21(木) 20:55:03
オブジェクト指向とは、状態と動作を定義した「クラス」を使用してプログラミングする方式です。
つーかオブジェクト指向は難しくないよ。何が知りたいんだ？
オブジェクト指向自体を現すメタファーって何かないの？
485 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/21(木) 22:20:07
状態のないクラスいっぱいあるけど・・・・
クラスって状態もてるじゃん？
状態もてなかったら引数でわたすしかないじゃん？
オブジェクト指向じゃなかったら引数ばっか増えてかね？
状態ってか情報？
日本語って難しいネ
状態であってるでしょ。
状態でも情報でもどっちでもいいけど、引数はふえるのか？
クラスメソッドを寄せ集めただけのユーティリティクラスは確かに内部状態は不要だな。
>>490 そういうクラスのことをユーティリティクラスって呼ぶんだろ
順番が逆
オブジェクト指向の本は読んだことないけど
自分なりの考えは
・クラスにはできるだけ状態を持たせない
・引数が大量になる場合は１つのデータクラスを作ってそれを渡す。
データクラスの名前が思いつかない（関連性のない情報ばかりなので）場合、
それはそもそもメソッドの役割がおかしい。
この考え方はあってるのだろうか。
いいんじゃね。
クラスなんて構造体にメソッドを入れただけのものだろ！違うのか
・クラスにはできるだけ状態を持たせない
↑なんでよ。
クラス間通信なんて全く無意味な仕組みをなぜ作るんだよ。
某オペレーティングシステム開発者さんよ。
それで誰から誰にメッセージを渡したいのか、本当に分かるとでも思ってる？
シンプルさを出来るだけ保つ。
考え方じゃなくてTIPSかよ
>>496 長く使い続けるようなクラスの場合
前のほうの処理で何されてるかまで気にしないといけないから。
>>500 前でなんの処理やってるとか関係なくすために、状態って形で抽象化するんだよ
おまいら、すまん、今話題になってる状態って何？ stateのことじゃないだろ？
メンバ変数全般じゃね？
くらすってぇのは、状態を維持する為にあるんじゃねえの？
>>505 それだけだったら構造体(レコード)でいいよな。
どうせ関数の引数で持ちまわるんだから最初からくっついてた方が楽じゃん。
509 ：
仕様書無しさん：2007/06/22(金) 00:05:17
>>508 template関数なら、構造体と関数をくっつけることは不便でしかないな。
構造体の悪い所は、構造を持っている所だ。
しかも他人にあっけらかんと見せてしまう所だ。
512 ：
仕様書無しさん：2007/06/22(金) 00:39:22
構造体のメンバ変数が廃止になったり実装が変わった時、
変更が容易とオブ脳はよくいう。
インターフェースと実装の切り分けは別にオブジェクト指向の専売特許じゃないし、
インターフェースクラスの継承とかは、それのオブ脳的解釈にすぎない。
さらに、人間の作ったプログラムなんだから変更箇所は有限個に過ぎない。
必要時に対応してもよいだろうと思う。
あるかないかわからない変更にいちいちビビるオブ脳は臆病。
C++のtemplateはオブジェクト指向と相性いいとはいえないからな。
>>512 変更箇所の問題ではなく、変更の影響が拡散するかしないかが問題
515 ：
仕様書無しさん：2007/06/22(金) 00:58:48
わかった。そこまでいうならオブジェクト指向とやらを認めよう。
もちろん、オブジェクト指向の効果でちゃんと納期は短縮は約束されるんだろうな？
でも、絶対約束しないんだよな。不思議で仕方ない。
>>515 バージョンアップが10回こえるなら、OO開発のほうが100%納期短縮できると約束しよう。
全然不思議じゃない。
ぶっちゃけ多態だけでおｋ
みんな全然わかってねーよ
OOの利点はこれしかねーだろ
TestClass c;
c.
ここでドットを打ったときに子分がずらずらって出てくるのが一番の利点
これはラクだわ～
ん？エディタで書いてるって？知らんよそんなん
アクター
メタファー
逐次/並列
ユーザーに対してもこんな言葉使ってる奴いるんだろーな
塵アクター
おちこぼれ共がぐちを書き込むスレはココですか？
>>515 短縮されるのは納期じゃないぞ。保守も含めた全体工数だ。非OOの場合と比べた場合のな。
OO使えば納期を短縮できるとかほざいてる奴はOOのことを理解してない。納期は適切に設定されるべきものだ。
納期は短縮されたが、規模は広がった。
おかげで中小企業ではかかえきれず、偽装派遣まがいで大手にぶら下がるしかなくなった。
規模が広がったのはＯＯとはまた別の理由だろう
とりあえず、一口に OOP と言っても
実際はいくつかの解釈があることを忘れてないかい？
有名なのはアラン・ケイとびょーんすっぽすっぽだが。
ケイのはメッセージ指向って呼ぶことになった
OOが超有効利用されててプロジェクトが
順調すぎます、ってな人いる？
びょーんすっぽすっぽ？
そんなんは無しで
Cocoaはメッセージ指向？
基底クラスの置き換えとか、乗っ取りとか何でもできるから開発者としては面白い
非OOで順調すぎます、ってな人いる？
536 ：
仕様書無しさん：2007/06/22(金) 22:52:27
>>485 オブジェクト「指向」と言われる所以は、オブジェクト概念だけでは実際の仕様や機能を全てカバーするのが
難しいからだ。そのためオブジェクト概念に合わない物も必要となる。
代表的なのはフォーマット変換のような、変換関数だ。このような物は、static関数にして、状態を持たせず、
Cと同じように使用する。妥協の産物だが、実際に必要なので仕方ない。
>>489 引数は増えないが、getter()、setter()が増える。
>>492 全然違う。それは構造化プログラミングのスタンプ呼び出し方式と言う。
構造化の中でも少し古い部類に入る。今の構造化の主流は、引数が多くなる方式である。
>>495 近いがフィールド変数がオブジェクトの状態を表し、メソッドが動作を表す事が条件になる。
537 ：
仕様書無しさん：2007/06/22(金) 23:23:35
>>503 504の言う通り。
>>508 関数の引数で持ち回るのは構造化。OOの場合は持ち回る情報はクラスのフィールド変数になる。
>>512 OOは変更にびびっている訳ではなく、変更に強い構造なだけ。
確かにIFと実装の分離はOOだけの物ではない。しかし、プログラムの小さいレベル（クラス）から、
大きいレベル（機能）まで、全てを非OOでIF分離できるだろうか？
せいぜい、大きいレベル（機能）の数カ所だ。確かに変更予想が的中すれば、それでも問題ない。
OOの場合は標準で、小さいレベルから大きいレベルまでIF分離と同じ効果になっている。
つまり変更にびびる必要はなく、変更にびびるのは構造化の方だろう。
538 ：
仕様書無しさん：2007/06/22(金) 23:30:25
>>515 516の言う通り。
>>528 オブジェクト指向で出てくる「メッセージ」とは、通信で電文やシグナルを送信する訳ではなく、
ただの「メソッド呼び出し」だから気をつけた方がいい。
あんた、オブジェクト指向と言えばObjectiveCでしょ？
それで使ってるメッセージは完全に電文だよ。
おじゃばに匹敵する教えたがりが来ているのが
今見えたが。
>通信で電文やシグナル
これは実装の話。
542 ：
仕様書無しさん：2007/06/23(土) 04:44:03
543 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 05:42:14
>>522 OOだと保守性も悪くなるけど、誰も評価なんかして無いし
比較方法が無いし、保守するころには責任者が変わっているので問題にされないだけ。
544 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 05:44:16
545 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 05:49:42
状態を持ったモジュールが複数並存する場合
動作検証では状態の組み合わせの数だけ複合状態が存在してしまうので
そのすべてについてチェックしなければならなくなる。
検査の量が指数関数的に増えてしまうので状態を持つのは普通は避ける。
546 ：
あるじゃーのん：2007/06/23(土) 06:12:39
>>545 その状態を管理してくれるテスト環境があればおｋ
その状態って言うのはトトくじみたいな話でしょ。
たいていの場合は外れだけどたまには当たることもある。
だけど項目が多いから当たりをを出すには１億回購入しないといけない。
人間にはテスト不可能だから自動でやらせる。
547 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 06:34:40
学生の寝言か
くだらねー
状態の爆発とOOは関係ない。
構造化プログラミングでも状態変数が増えれば同じことだ。
549 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 07:28:27
べつにOO批判してないもんね
被害妄想ですか？
雑草生えまくりｗｗｗ
議論に介入せず放置して
時々眺めてニンマリするのが大人の姿勢か。
でもホントつまんねぇ奴しか来てねぇな
551 ：
仕様書無しさん：2007/06/23(土) 07:30:31
>>543 一体どんな使い方しているんだ。
普通に使いこなす限りじゃ保守性が悪くなる事はないぞ。
土曜日朝からおまえ暇人だなｗ
ぶっちゃけ、嫌いな人はOOPで書かなければいいって話じゃねーの？
OOPで開発するプロジェクトに投入されないように根回し忘れずにね。
逆にOOで作る人間を構造化プログラミングの世界に投入しないで欲しいとも言える。
OO否定する奴でもOOの成果物はありがたがって使っちゃったりしてるわけだが。
>>545 状態を持つのを避けるって、純粋関数型以外つかえねえじゃん
馬鹿か
>>554 c++に限定したら、便利なOOライブラリがどれだけあるんだろうか？
そのOOライブラリがOOであることで、ユーザーにどんなメリットがあっただろうか？
他の言語は無しで。
557 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 12:54:51
>>545 モジュールの持ってる状態を1箇所に纏めたとしても、
1つのドデカイ状態遷移が出来上がるだけで、テストの数は変わらない。
それでテストの数が減るようなら、
状態遷移を1箇所に纏めたせいで遷移に漏れが出て、品質が落ちてるだけ。
>>558 >>545がいってるのは、状態とその状態の時の処理をわけた方がいいって事をいってるんじゃ？
カプセル化の名の元に、ここをごっちゃにしがちなOO信者がいるから、
わざわざstateパターンってのを作って注意喚起してるんじゃないのかい？
話変わるが、OO信者はOOがうまくいかないのは修行が足りないせいだ、
もっと修行しなけりゃって思うらしいね。
勉強熱心なのは非常にいいと思うけど、
そのパワーをアルゴリズムの研究にでもついやしたほうがいいんじゃないかと思わないでもない。
ま、これは余計なお世話だな。
>>556 STLもBoostも基本はOOでしょ？
ま、何かの状態を管理するのは一カ所で、という話は賛成だ。
きょうび、仕様書振りかざして各機能ごとに状態を判断させたがるが、
仕様変更でもあったら、全員が一斉に変更作業で作業止めないとならんしな。
しかも全部の機能ごとに全部テストし直しだ。
何の為のＯＯだか、わからんような実態は、どこにでもある。
>>561 なんか良く分からんが、1つの状態を複数のモジュールから参照するってこと？
それぞれのモジュールが自分の状態を管理するんじゃなくて、
上位モジュールが全てのモジュールの状態遷移を把握すべき、ってこと？
後者だと、構造化的な考え方に思えるけども。
OOってのは、その状態？とやらを積極的に管理しなくても済む手法かと思ってた。
この状態の時はこのメンバ関数を使い、あの状態のときはあのメンバ関数を使うとかになるんじゃないの？
同じものを呼び出して、呼び出された関数内部で状態を調べるなんて構造化の視点で見ても効率悪いよ。
>>562 OO的発想では、上位に当たるモジュールが下位の状態遷移を把握しなくて良いということなんだろうか。
そこは階層構造にしたほうが上手く行きそうな気がするんだ、上位ですでに決している状態を
下位でいちいち調べるメリットが解らない。
構造化脳だからか？
一番分かりやすい例は、キー状態から画面遷移をするような場合だな。
各クラス内でそれぞれが判断してほかのクラスへ移行させるような作りだと
仕様が先に無いと作れないし、仕様が変更されると全部のクラスが変更を強いられる。
遷移クラスをひとつ作ればそれを変更するだけで済む。
ほかのクラスへ移行させるという概念が構造化脳には新しいW
この辺もOOの理解を妨げて居ると思う。
画面遷移だけで何万ステップにもなっちまうような大規模なシステムだと、
機能ごとに分割管理するしか無いんじゃね？
サブシステムに分割しろよ。人間が一度に管理できる範囲には限界があるぞ。
┌─┴──‐┐ ─◇
│|￣￣￣￣|│ ／
│|（∩Ｔ∀Ｔ）|│ ♪
└────‐┘∧_∧ ～
( ・ω・)＿＿ ＿＿ ＜ネット弁慶が さらに弱いものを叩く～♪
ノ/ ¶/＼＿＼. |[ｌ Ｏ |
ノ￣ゝ＼/＿_/ |┌┐|
|￣￣￣| __ｌｌ__ .|└┘|
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
> キー状態から画面遷移をするような場合だな。
それはシステム(問題解決手段)の表面的な状態遷移であって、
システムが解決しようとしている「本当の問題」に固有の状態遷移とは違うだろ。
そーゆー枝葉の状態遷移は、ライブラリとかフレームワークに外出ししとくべきじゃないかな。
ライブラリ/フレームワーク層が提供すべきもの：
・入力や処理結果、その他条件に応じて、画面遷移を行う仕組み
- 入力に関する抽象化： マウス選択、クリック、キー入力等に対応
- 画面遷移に関する抽象化： Web的なページ遷移、GUI/AJAX的な部分更新への対応
アプリケーション層：
・入力や画面遷移、プロトコル、データ格納手段等に依存しない
本質的な処理の記述に集中すべき (理念として)
システムが解決しなければならないのは、ユーザーからの指示だ。
それ以外は提供機能に過ぎない。
それを忘れて、いまどきの家電製品は、どいつもこいつも愚鈍で専門馬鹿ばっかり。
574 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/23(土) 20:35:27
状態はプロセスに変換できる
例を挙げると「すべてのステートモデルは同じ動作をするプロセスに変換できる」。
状態に相当する情報がプロセス＝プログラムカウンタが保持する事になるわけで、
内部状態が相互に影響するモジュールを組む場合は、プロセスで書いて意図した状態以外の状態にならないように拘束できる。
>システムが解決しなければならないのは、ユーザーからの指示だ。
これは全くちゃうやろｗ
IT業界は常に先にシーズありきで、ニーズは創出するもんだ
ところでアホコテよ
仕様書無しさんをNGにしている設定は？
嘘吐き
ココ電って、何がいいたいのか全然わからない
>>574を、「ＸＸである。なぜならＸＸだからだ。」って形式で書き直してよ。
578 ：
仕様書無しさん：2007/06/23(土) 20:55:56
サラリーマンプログラマはたいてい理解してくれない。
向上心のアル奴らしか使えてない。
プロジェクトは一番レベルの低い奴に足をひっぱられる。
したがって、使えない。
そこで一人プロジェクトですよ
Q.なぜオブジェクト指向は賛否両論なのか？
A.アホコテが沸くから
ココ電って、ν＋のあの痛い人？
>>560 STLはデータ構造とアルゴリズムの分離が基本的な考えで、
データと処理を一つにまとめちゃうOOとは違う概念だと思う。
classキーワードを使えばOOってわけじゃないよね。
iteratorとかBOOSTとかは、言語機能の拡張を指向している感じがする。
やはりOOとはまったくかぶらない。
>>578 たとえオブジェクト指向を理解する人と理解しない人がプロジェクトに混在していても(理論上は)なんとかなるけどな。
>>582 ただ，イテレータ周りのレベルまで操作をデータと一緒にしているからポリモーフィズムが楽しめるわけで，それなりにOOな気がする．
継承しなきゃOOじゃないってわけじゃないよね．
585 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/24(日) 02:52:30
ポリモーフィズムは保守しにくいんで名前にクラス名をつける事
> システムが解決しなければならないのは、ユーザーからの指示だ。
> それ以外は提供機能に過ぎない。
キミは指示方法と、指示内容の区別ができていない。
> システムが解決しなければならないのは、ユーザーからの指示だ。
> それ以外は提供機能に過ぎない。
醒めた目で見ると、↑これって頭おかしい発言だな。
「ユーザからの指示」を「システムが解決」ってなんだそれ？
ユーザからの指示をシステムが解決ｗ
589 ：
仕様書無しさん：2007/06/24(日) 02:59:26
技術というものはその存在を意識させないぐらい自然に使われるようになって
はじめて浸透したといえる。
それなりに勤勉な人達にはだいぶ浸透してきてはいるが、OOがOOであることを
意識させているうちはまだまだなんだと思う。
不真面目な層に浸透させるには、もう少し頭を使わなくても使えるような仕掛け
なり餌なりが必要だ。VBが始めて登場した時のポタペタのようなもうひと工夫が。
ユーザからの指示をシステムが解決ｗ
頭がおかしい人の戯言スレ
ユーザからの指示をシステムが解決ｗ
○ 指示
－－ ───→ システム
｜ 解決ｗ
／＼
ユーザ
戯言、寝言
○ 世迷言 ﾈﾀにﾏｼﾞﾚｽ ○
－－ ────→ 某ちゃんねる ←───── －－
｜ 漁獲 ｜
／＼ ／＼
アホコテ or
名無しアホ
595 ：
仕様書無しさん：2007/06/24(日) 08:29:45
今時OO批判って向いてないんじゃないか？
>>585 造語で名前付けするからじゃねえの？
接頭辞、接尾辞はなるたけウェルノウンなものにするとか
つまり、キー操作のレスポンスの悪い機械作るな！！ って事さ
カーナビとかもう最悪。
>>598 メインの内部処理で遷移状態を判断し、各モジュール内部でもいちいち遷移状態
を取得するって処理を本当にやってるんですか？
設計者の非効率な考えをOO設計と名乗るのは止めてもらいたいね。
それが大多数のOO設計なるものなんだろうか…
>>599 メインの内部処理=モデル
各モジュール内部=コントロール
と読み替えるぞ。
もしモデルのほうで状態を管理しなかったらどうなる？
モデルの本質的な状態っていうのは無くなりはしないんだから、
各コントロールにモデルの状態を管理するための処理が散る。
つまり
モデル状態数=x,コントロール状態数=yのxを0にしようとしたら
モデル状態数=0,コントロール状態数=x*yになる
どっちが効率的なんだろうな？
OOやってるとメソッド名考えるのがめんどい
めんどいっつーか悩む
いやねぇ
レスポンスが遅いのは、マシンスペックがダサイからですよ。
３D表示の描画更新だとPS３並みのエンジン積んでないと無理です。
でも、実際には非力なARMやSHの石積んでるだけですからね。
書くとこちがう
オブジェクト指向とユーザビリティーは直接関係ない。
「オブジェクト指向」
中身がどうこうより、名前がわけわかんねーって思って
敬遠する奴がいても不思議ではない
賛否両論というより、意味わからんからどーでもいい、って奴がいそう
それいったら、構造化設計って名前もいみわかんねーし
ユーザビリティとか言っちゃう奴、マジいるんだよな
「使い勝手」
って言えばいいのに
医療関係と一緒で、利用者から「横文字は意味不明、分かるように喋れ」って
言われないと自覚できない奴はちょっと考えれ
>606
ま、そだな
>>607 JIS用語を使ってるだけですから、あなたが勉強不足なだけです。
>609
同じことを顧客に言えるもんなら大した奴だ
厳密な議論するときは、言葉の定義のあるなしが問題なんだろ。
ユーザビリティには公的な定義があるが、オブジェクト指向には定義がない。
>>610 顧客に「うちはオブジェクト指向ですから、安心です」
と、煙に巻く事は出来るんだろ？
そこまで言って委員会見るか
614 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/24(日) 13:32:52
>>602 ARMは強力だよ
あれで遅いとかいってるのは腕が無い証拠
コンテキストメニューとか、オブジェクト指向的なユーザインタフェースってのはあるか。
一行に横文字が４つ入ってる時点でやばいです
>>610 顧客がエンドユーザーなら言えないが、顧客が大手家電メーカーなら言う。
まああれだ
おまぃらが最近の歌を歌えないのと一緒で
OOはまだブームって言ってる段階なんだわ
619 ：
仕様書無しさん：2007/06/24(日) 16:12:59
>>600 何故一つのデータをわざわざ複数の場所で調べるのか。
昔、OOが出てきたとき盛んに並列動作可能とうたわれていたんだけど、
OSの補助なしで本当に並列動作（時分割でも）できるの？
MS-DOSの時代だったのにスゲーなと思っていた。
>>620 Publicな変数を持たない設計だから、複数同時動作が可能と言う感じじゃね？
でも肝の分割してあげる機構が無いんじゃ、無理だけどね。
622 ：
仕様書無しさん：2007/06/24(日) 16:39:49
>>619をレスした途端に後悔をしてきた俺ｶﾞｲﾙ。
センスを磨け。英語を勉強しろ。
以上。
というか規模が小さいプロジェクト単発だとデータ抽象で止まってオブジェクト指向まで行かない
オブジェクト指向も問題の複雑さに対するひとつの解法（整理法）であって別に問題が複雑でなければいいんじゃないの？
泥臭いコードをもっとスマートに、すっきり記述したいって欲求が出たら使えばよろし。
ただ普段使ってないとどう書けばいいか勘所がわからない、ってのはあるかもな。
なんつうか、オブジェクト指向のスキルを上げるには、
自習 or ちっさな規模のプロジェクトで思い切った試行を繰り返して、
世に流れているオブジェクト指向設計手法の行間を読む経験が重要な気がする。
・可能な限りのクラス分割をやって、クラス数の爆発を経験してみるとか、
・直感の赴くままに共通クラス抽出して、何が共通クラス～フレームワークになり得るかとか、
・クラスの仕様決めの方法について試行錯誤してみるとか、
>>625 うちは規模がでかいのにデータを抽象化しない。
何でもかんでもString型って、アホかと。
629 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/24(日) 19:44:06
>>627 オブジェクト指向は正しいという前提を含んだ悪質なプロパガンダですね。
OOは詐欺の類だという証拠を改めて見せ付けられる思いがします。
630 ：
仕様書無しさん：2007/06/24(日) 19:59:58
＞行間を読む経験が
この時点で工法としてだめじゃん。
631 ：
仕様書無しさん：2007/06/24(日) 20:19:48
オブジェクト指向は正しいだろｗｗｗｗ
コテハンをあぼ～ん指定したらすげー読みやすくなった
633 ：
仕様書無しさん：2007/06/24(日) 20:38:14
>>629 オブジェクト指向は正しくないという前提を含んだ悪質なプロパガンダですね。
OOの本質を理解できない老耄の惨めさを改めて見せ付けられる思いがします。
まあ、間違いなく浸透しないのは明らかだな
言語以外を覚える技術者がどれだけいるものか怪しいもんだ
>>627 つーか、研究者でもないものが、
そういった方法をいちいち研究しないといけないぐらい方法が確立されてないなら、
それはまだ工学として未熟で使いものにならないって事じゃないのか？
今後OOの評価がどう転ぶかわからない現状でそんなものを実戦で使うなんてどうよ？
自己満足といわれてもしかたない状況ですよ。
概念がでてきて何十年もたってるのにこんな状況じゃ、
見込み薄いなと思うのが普通じゃないかと思うが。
現状、OOでもっとも重要な点は、
>>612がいってることじゃないかと思う。
UML書いて設計できたとかいってみたり、デザインパターンで呪文唱えたりとか。
で、よくわかってないやつが、それに釣られてしまってる。
そうだよ、俺たちはOOの研究者じゃないんだから、
極論すれば、OOの成果物であるところのクラスライブラリやデザパタを覚えて使えばよろし。
>>635 > 今後OOの評価がどう転ぶかわからない現状でそんなものを実戦で使うなんてどうよ？
お前は他人の評価で自分による評価を決めるのか？
評価ってのは個人個人がするものであって、「実戦で使う」というというのがつまりは評価だろ。
強制的に使わざるをえない状況にならんと
自主的に学習しないだろ
OOだけが技術でもないし
自主的に学習する人間が稀なプロジェクトだと、
強制的に使わざるを得ない状況になんかならないんだよね～。
そして旧態依然とした体制により悪い伝統をどこまでも引きずってゆく。
640 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/24(日) 23:57:23
たしかC++やJavaはわざとOOじゃなくても組めるように遊びが作ってあったはず。
OOでないと組めない言語採用すればいいじゃん。
やったね。ばっちり解決。 そして死ね
641 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 00:01:02
Smalltalk
SELF
Ruby
Io (iolanguage)
>>ココ電
純粋オブジェクト指向言語≠OOじゃないと組めない言語
OOがプログラミングスタイルの最終形態ならそれでもいいが、言語の寿命って今まではプログラミングスタイルよりは長生きだからなぁ。
644 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 00:06:27
うーむ残念無念
過渡期のスタイルであっても覚えるしかねえだろ
最終形態だけ使いこなせるはずがない
OOじゃないと組めない言語って難しいな、そんな言語作れるのか？
そもそも手続き指向（関数型言語なら関数指向って呼ぶのか？）と
組み合わせて使うものと思うんだが
何故か「OO＝手続き指向を使わない」と勘違いしてる人間が居るから困る
CLOSとか関数型との組み合わせもあるぞ
つまりマルチパラダイム最強ということか
Eiffelとか、流行のNemerleとか
OOP・手続き・関数の全部入りみたいな言語もある。
パラダイムの変遷を見ると、過去の概念をまるっきり捨て去るってことはあんまない。
積み重ねであって、０からの構築ではない。
つまり手続きだってOOだって死にはしない。
651 ：
646：2007/06/25(月) 00:48:56
>647
要はOO単体で使うことはまず無いだろ、って意味。
分かりにくくてごめん。
652 ：
仕様書無しさん：2007/06/25(月) 00:56:29
関数分割もモジュール分割も理解出来たなら、本質の同じオブジェクト指向も覚えられるはず。
OOって「設計」と「コーディング」の両方で利用しないと
理想的？には利用できてないわけじゃん
コーディングだけOOです、なんてのは場合によっては
設計者が書いたものをOOに翻訳してコーディングしてる場合もあるわけで
設計が機能分解で記述して、
コーディングはOOで、ってのはなんか違う
654 ：
仕様書無しさん：2007/06/25(月) 01:05:13
>>653 確かに設計したものがそのまま実装ってのが理想ではあるな
クラス図が無いのにOOで書けって言われても
なんじゃそりゃって話になるわな
>>626 複雑な問題を簡単な問題の集まりにするのが構造化だよ。
問題解決の手法そのものの技術は昔から大して変わってないんじゃないか？
OOでは顧客と意思疎通を取るのが難しい。
というかプログラマ視点の押し付けに過ぎない。
結果、失敗プロジェクトに繋がる。
>>657 まてまてww
それは機能中心設計の問題で、OO開発ではユースケース・セントリックつって
むしろ機能中心設計に対するアンチテーゼだっつの
だが顧客は画面の事しか言わないか、やりたい事しか言わないか、どっちかだ。
新しい技術が出まくりで、
どれを選んでも正しい選択ならいいんだけど
将来性や有効性の当たり外れが激しいと選択肢が増えたというより
混乱要素が増えたと思う奴がいても不思議ではない
OOは資格もなにも、技術を修得したことを保証するものが無いため
それを理由に敬遠されることもあるんだろ
不勉強もよろしくないが、それを責めるだけの根拠が無いのが問題
アンチテーゼってなんだ？
アンチ巨人の親戚か？
辞書ぐらい活用しろよ。
ドイツ語と英語と日本語と、忙しい奴だな
構造化設計は、大きな処理を小さな処理に分解して複雑さを管理するやり方。
オブジェクト指向は、処理で使う「部品」を大きくして大きな処理を小さく「見せかける」やり方。
OOって、様々な部品を同じ概念で扱う事で複雑さを無くそうとする試みじゃないの？
やっぱ免許が必要だな
たとえばプログラマには少なくとも基本情報は持ってないと免許交付しません、
ぐらいの強制的なことせんとアホは排除できん
668 ：
仕様書無しさん：2007/06/25(月) 01:58:28
関数分割もモジュール分割もオブジェクト指向も本質的には同じなんだけどなぁ。
>>667 たとえ基本情報がソフ開でもアホは排除できんだろ
暗記物は無意味
やるならTopCoderで上位入賞とか、そういうのを評価したほうがいい
>>668 ちょっと本質について語ってみてくれ
俺は叩かないから
671 ：
仕様書無しさん：2007/06/25(月) 02:04:02
>>670 全て「機能ごとに分ける」事をしている訳で。
>>669 確かに○暗記クンなどは排除できんが、
無意味とは思わんな
少なくとも学習意欲の無い奴は排除できる
できる奴は「あーめんどくせー」「こんなん意味ねーよ」とか
言いながらも合格するし
機能ってのが何を指すかによってちょっと話が変わるけど、
細分化って意味だよな
確かにここまでは同じなんだけど
関数型とOOはこっから先が違う
>>672 そーかね。
俺は「やる気のあるアホ」をこそ弾きたい
やる気ねーやつばっかなら、俺のやりたいようにできるしw
オブジェクトが表現してるものって、いわゆる「機能」ではないわな。
676 ：
仕様書無しさん：2007/06/25(月) 02:09:20
>>673 そりゃ細かい所は違うさ。
別の物なんだから。
あと、機能＝処理と読み替えてくれてもいい。
>674
やる気があろうが無かろうが、アホはいらん
注意力の無い奴、やるなといわれたことをやる奴、同じミスを繰り返す奴
技術力以前の問題を抱えてる奴は、マジで不要
678 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 08:50:08
やるべきことを「やるな」という問題を理解して無い上司に隠れてやる俺
2chに書き込むのはやるべきことではないぞ
680 ：
仕様書無しさん：2007/06/25(月) 10:05:32
ココ電ってさあ、前に
職歴30年超えてるような事書いてなかったっけ？
50過ぎ？ダメ親父に「それはやるな」と指示出しせにゃならん上司、いとあわれ
>>671 「音声と文字によるコミュニケーション手段という点に於いて
英語も日本語もサンスクリット語も本質は同じ」
くらいおかしな事を言っている。
682 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/25(月) 11:57:14
536-538は俺だ。名前付け忘れた。
オブジェクト指向に限らず、システム開発などの現在ない物を新たに作る場合、最も有用な情報は
試行錯誤によって得られる。基本的にこれを理解していない人が多い。
これは今までの学習方法が身についているせいだろう。テスト勉強では常に答えが用意されていて、
解答は書籍に書かれており、これを調べる事を勉強としている。
答えのある分野ではこれが効率的だ。この手の人はOOと言うと、まず書籍やネットで調べる。
しかし概念的な説明が多いため、やった事がある人には分かっても、やった事のない人には難解だ。
そのため、安易なデザインパターンに当てはめる方法を選んでしまう人も多い。
確かにOOのパターン集であるデザパタに当てはめればOOと言えそうだが、概念を理解していないので、
正しく当てはめることが出来ない。
だからOOの学習には、先に本を読む事をお勧めしない。
まずやってみて、失敗してから本を読む事をお勧めする。
683 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/25(月) 12:05:25
>>545 状態を持ったクラスが相互に干渉し合うような設計自体が間違いだと言っている。
574で言っている意図が不明だが、状態をプロセスに変換出来るなら、状態をクラスにも変換出来るだろう？
そろそろ分かったかな？
結論から言えば、お前のアホ文は不要です、と。
もう来んなよ。
685 ：
仕様書無しさん：2007/06/25(月) 14:49:26
>>685 俺は
>>681のいうことはなんとなくわかったけど
はさみとカッターがある状況で、カッターの有効性について論じてるときに
「はさみもカッターも『何かを切る物である』という点で、本質的に同じ」
とかいわれても、はあ？ってなもんだ
状態ウンヌンは、
例えば、
フローチャートだと、どう移行するのかという変化は分かりやすいが、
「状態」によって、関数やクラスを選択させたい場合、状態をはっきり図示したい場合、
ステートマシンを組めと言ってるんじゃないか。
ただ、これはCOBOL等の順次処理、手続き型においてのみ、しっかり当てはまるのであって、
マルチスレッド、複数SQLについて、待ち・衝突・ブッキング・ACIDの破壊に関してはおざなりだろう。
乱発をしたい、デスマになる、だがやりたい(オンラインをＷＥＢ化するには必要)、
おそらく、このスレの代々続くテーマはおそらくここ。
だが、こういうもの(多並行処理)に対する図示の仕方が出来上がっていない現在(数学的にはあるのかもしれない)、無理がある。
３層アーキテクチャ(プレゼンテーション層(クライアント)、ファンクション層(アプリケーションサーバ、ミドルウェア、ＤＢＭＳ)、データ層(ＤＢ))
という視点で分けると、
クライアントからの受付はマルチスレッドでいいけれど、ファンクション層の本格処理の部分は順次処理にしないとおそらく無理。
例えば、現在CPUのパイプライン処理はＵＶ２段パイプ並行処理なんかがあるけど、
どうしてもやるというなら、多段並行(無限大並行)パイプのＣＰＵ作れと言ってるようなもん。
よくわからんけど、マルチスレッドじゃないAP層など聞いたこともないぞ。EJBコンテナしかり。
他のスレッドと操作するモデルがぶつかるときだけトランザクションで順番に処理されるだろうけど。
>マルチスレッドじゃないAP層など聞いたこともないぞ。EJBコンテナしかり。
難しい分散トランザクション機能をＥＪＢが備えているのを崇めて真に受けるから、デッドロックしたり待ちが多大になったり最悪固まったり落ちたりしてデスマるんじゃないか。
Servletはシングルスレッドモデル使ったり、ＥＪＢはローカルでＪＭＳ使ったりや機能にあるなら連鎖トランザクション(シリアルトランザクション)して、順次処理しないと。
＞他のスレッドと操作するモデルがぶつかるときだけトランザクションで順番に処理されるだろうけど。
こんなスーパーな機能がＪ２ＥＥに組み込まれてるなんて知らないが、ほんとに入ってる？
691 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 19:40:08
OO厨はマルチスレッドを使いこなせない。
それどころか稚拙な「回避」方法で資源を無駄にしておいて自慢する。
692 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 19:41:27
「サーブレットをシングルスレッドで動かしました」
つうのは
技術者の恥
普通は
>>690 別にJ2EEのはなししてるつもりはないよ
たとえば一般的なWebアプリの場合、ユーザAとユーザBの操作によって更新対象となる
モデルインスタンスにはほとんど被りがないようにつくるのでシングルスレッドだろうがマルチスレッド
だろうが基本的に何の問題もないとおもうんだけど。
＞他のスレッドと操作するモデルがぶつかるときだけトランザクションで順番に処理されるだろうけど。
J2EEの機能じゃなくて、DBのトランザクションで。
694 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 19:53:24
ほとんど・・・
は？
クラスという構造だけは知っているが、クラス分けが正しくできないコテハン
OO厨 vs.ココ電厨
698 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/25(月) 21:59:56
OO厨にはスタンドアロンのアプリしか作らせちゃだ駄目だな
ケンチャナヨ精神で恥じる事が無い
ｺｺ電厨
じゃなくて
ｺｺ電(厨)
700 ：
仕様書無しさん：2007/06/25(月) 22:41:16
お馬鹿さんクラスのインスタンスに言われたかないね
>>688 並行処理の図って、ペトリネットじゃあかんの？
OO廚が好きなUMLにはないけどさ。
（そういえば、ER図もないよね。なぜ？変な人形の絵はあるのに…。）
>>664 オブジェクト指向ってのは複雑な問題をそのまま実装するの？
細分化しないなら、人間が管理できないほど複雑で大きな問題を
どうやって管理できるんだろう？
703 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/25(月) 23:07:07
マルチスレッドとOOは、直接関係無い。
OOで組めば状態を持ち回らないので、マルチスレッドにしやすいと言うだけだ。
クラス内での排他処理が必要なのは変わらない。
EJBってのは基本的にはただのクラスだから、使い方を間違えればデットロックも起こるし、
非OO型で組んだ時の弊害も起こる。EJBを使えばOOだと言う訳ではない。
難しい分散処理を行うなら、それ相応の技術が必要な訳で、スキルの低い人でもEJBやサーブレットを使えば、
難しい分散処理が出来る訳ではない。
クラス内で排他処理？
コードとメモリワークは完全に分離してるってのに
どうやって排他するんだろう・・・
おばけさまのおっしゃることはしごくごもっともだが、で？それがどうした？
というかんじだな。
706 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/25(月) 23:23:14
>>702 構造化もOOも細分化は必要。構造化が処理で細分化なのに対して、OOは物（オブジェクト）で細分化する。
>>704 synchronize
>>705 初心者のうちは、EJBやマルチスレッドなど考えなくていいって事。
>>702 SICPの冒頭にこうある。
複雑なものの作り方３ステップ
1.単純なモノをゴウセイしてひとつにする
2.モノとモノを、カンケイでつなぐ
3.つながれたモノとモノをチュウショウで分離する
708 ：
仕様書無しさん：2007/06/25(月) 23:43:59
ココ電球＝妄想屋さん。
世の中は常に離合集散を繰り返す。
分散と集約、そのトレードオフの中で絶妙のバランスでリファクタリング。
System::Send(CLASSID classA, CLASSID ClassB, long MSG);
とかいう意味不明なシステムメッセージがあるんだが、
#define classA (0x12345678)
#define classB (0x22222222)
ptrA0 = (class*)Create(classA);
ptrA1 = (class*)Create(classA);
ptrB0 = (class*)Create(classB);
ptrB1 = (class*)Create(classB);
とあったとき、ptrA0で示すクラスＡのオブジェクトから、ptrB1で示すクラスBのオブジェクトにメッセージを送るにはどうすればいいと思う？
OOなんかマジメにやんなくても仕事はなんとかなるなんて考えてるものぐさな奴らが
大多数を占めるからどうにもこうにも始末に負えない。多勢に無勢。冷め石にお湯。(´Д｀)ﾊｧ…
>>712 でも、同じクラスから生成されたオブジェクトを区別する手が無いんだけど？
this渡せば?
>>714 thisだけで相手が誰だかわかる？
あ、クラスＩＤ見ればアクセス方法が分かるか！？
thisを辿ってメソッドに触れるね。
またスレ違いな話題炸裂
「なぜオブジェクト指向は賛否両論なのか」
どうぞ
717 ：
仕様書無しさん：2007/06/26(火) 05:25:09
竹本 リル (上海帰り)
画数：竹[6] 本[5] リ[2] ル[2]
天画（家柄）11画 大吉 家庭も仕事も順風満帆
地画（個性） 4画 凶 努力も空回りの挫折運
人画（才能） 7画 中吉 わが道を行く
外画（対人） 8画 中吉 強靭な精神力が持ち味
総画（総合）15画 大吉 思慮深く謙虚な性格
評価 : 86.0点
モバイル姓名判断（
http://n1.mogtan.jp/?s13380）
先日、システム間データ連携をグラフィカルに操作できる
アプリを家の会社の社長に見せた時の事です
「お！そこのオブジェクト出来上がったんだねｗ」
オブジェクトの中でsleepしたら、
他のオブジェクトもsleepしちゃう。
プログラムなんてしょせんはプログラムカウンタのリレーなんだから、
そこを無視してオブジェクト指向だとか、他とは独立だとか…。
この業界、オブジェクト指向勉強したら偉いとか思ってるアホがのさばってるんだな。
いやになってきた。
720 ：
仕様書無しさん：2007/06/26(火) 08:55:26
>>719 どんなプログラム書いてんだよｗ
(呼び出し先に)sleepってｗ
あと、何か勘違いしているようだが、オブジェクト指向開発にしようが、
結局呼び出し元のプログラムは単なる関数(サブルーチン)呼び出しと、(自分のモジュールの)データ管理で済むぞ。
721 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/26(火) 09:51:04
>>710 使用目的と状況が分からないので正確には言えないが、ptrA0からptrB1を起動すると言う意味なら設計誤り。
実行順に関する情報は呼び出し元クラスで管理し、呼び出し先クラスでは実行判定メソッドや
実行メソッドを持つ。呼び出し元ではそれらを使用して、実行の制御を行うのが一般的だ。
>>719 オブジェクトの中でスリープしたら、他のオブジェクトもスリープ？
言っている意味が分からない。スレッドやプロセスを使えば止まらないが、そういう意味ではないのかな？
オブジェクト指向に限らず、新しい事を勉強している人は、勉強していない人より偉いんじゃないか？
オブジェクト指向に至っては、知っているのは普通で、知らない人の方が怠慢と言われるレベルだろう。
>>719 >いやになってきた。
とっとと辞めた方がいいと思う。
君、伸びそうにないし。
723 ：
仕様書無しさん：2007/06/26(火) 13:48:44
724 ：
仕様書無しさん：2007/06/26(火) 14:26:37
>>710 スレッド間メッセージじゃ無いならそんなめんどくさい事しないで、
必要に応じて関数(サブルーチン)を呼び出してくれる制御用のプログラムを作れば良いジャマイカ。
>>695 ほとんど･･･
ということは、おそらく既存ＤＢがガンジガラメでポリシー変えられないんだろう、おそらく。
デッドロックしたらタイムアウトを待つしかないみたいな。
＞オブジェクトの中でsleepしたら、
＞他のオブジェクトもsleepしちゃう。
ＡＰサーバ上に、トランザクションのロック中に関する専用ＤＢ作ってみたら？
ＤＢ1｜ＤＢ１のキー名｜ＤＢ2｜ＤＢ２のキー名｜・・・
Ｔ１ Ｋ１ Ｔ２ Ｋ２
常時キャッシュで、終了したら削除、もしくは終了フラグ
その上で、デッドロックを検出したら、特別モード突入みたいな感じで、そいつを待ちキューに入れるとかラウンドロビンさせたり。
ただし、これらはＡＰサーバと非ＡＰサーバとの間のデッドロックの検出は無理だけど。
ＡＰサーバへのリクエストは基本１行更新だよねえ、やっぱ・・、しみじみ思う。
>>725 デッドロックはテーブルのロック順を守れば発生しなくね？
つか更新対象が少々かぶっても(管理者ユーザによるユーザメンテみたいのしょうがなくね？)
楽観排他とかで別に問題なくね？
>>726 オプティミスティック・ペシミスティックというところで、
オプティミスティック使いたい、それが通ればいいけどね。
既存のポリシーでガンジガラメだとそうもいくまい。
それと、まな板サーバみたいなギガキャッシュじゃなくて、メインフレームみたいにキャッシュがテラスゴスみたいな、使う表丸ごと常時キャッシュなところにJAVAサーバ入れられるんなら、
そりゃかなり効率上がると思うよ。
既存でクジラがヒーヒー言いながら動いてるものを、イワシに持ってきたらそりゃミンチになるし。
イワシの大群だといっても、よほど効率よく表が媒体別にパラレルに配置されてないと>ガンジガラメだと難しい
でもいきなりでかいの持ってくるのはコスト的にリスクがあるから。
それと将来イワシが群れなした時、どうにもならなくならないための保険のこのスレのどっか上のほうにあったAPサーバで順序処理だと思うけどね。
>>727 バージョンカラム1つ付けるくらいケチケチすんない
つか、オブジェクト指向なんも関係なくね？
カウンターカラム１個付けるのはいいと思うけど、
既存が分からなきゃ、というか最新を誤るとやばいぞ＞履歴と最新
ということで、カラム追加による既存の修正が必要なんじゃないか
前提としてインクリメントするだけならいいけれど(履歴がないならいいけれど)、
新規用に履歴表を新たに作って(ここにバージョンカラム)既存の表からコピーして(新規側は今までの表と新たな履歴表を両方見て全履歴を判断)、
今までの表はそのまま最新版として既存のやり方で履歴を更新していったほうがいいんじゃないか？
いや考えすぎで蛇足だったらすまんね。
＞つか、オブジェクト指向なんも関係なくね？
まったく関係ないなｗ
731 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/26(火) 23:01:31
>>727 データベースロックの基礎は分かっているのか？
基本的に、トランザクションの途中に入力待ちを入れるのは間違いだし、ロックするのは親となるテーブルの
レコードだぞ。これでほとんどのシステムは問題なく稼働する。
これが使えないのはかなり特殊なシステムだが、そんな特殊なシステムなのか？
>トランザクションの途中に入力待ちを入れるのは間違いだし
もちろんＤＢに対する更新は一発更新だけど、
当然一回のＤＢ更新で複数のレコード追加変更によるデッドロックの懸念や待ち、２フェーズコミット(RPC、J2EEだとRMI/IIOPによる安全終了)のケースもあるからね。
抽出後更新で、既存が楽観排他使ってればいいが、
例えばVTAMなんかオンライン即時更新でクライアントは基本的に１つしか掴まない故に、楽観排他は使って無い可能性もある。
このクライアントのリクエストが別サーバを含める複数レコードロックなんかかましてると。まさかとは思うけどね。
733 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/27(水) 00:33:35
>>729 728は「バージョンを認識出来るカラム（更新日時でも可）を追加して、更新時に最新のレコードと比較して
エラーや警告を出せ」言っているのだろう。履歴と最新？何の事を言っているのか分からないな。
>>730 履歴の処理とロック制御は関係ない話だが、「履歴表を作って既存の表からコピー」？
文面どおりに受け取ると、履歴のためにレコードを別の表にコピーすると聞こえる。
そういう意味なら、DBと言う物が全然分かってないようなので、正規化から勉強し直すように。
>>732 どういう場合を言っているのだ？
トランザクションの途中に入力があって、1つのトランザクションで複数のデータベースを更新する場合か？
それでもロックするテーブルが1つならデットロックしないし、2つでも順番を間違えなければデットロック
しない。1クライアント1ユーザなのに、複数のユーザのレコードをロックするのは設計誤り。
長時間入力があるのにトランザクションの中に入れるのは設計誤り。
問題になるのは、結局はただの設計誤りじゃないか？
734 ：
仕様書無しさん：2007/06/27(水) 01:37:20
意味不明な問題設定して、
それにスラスラ答える変人登場か
あいかわらずアンタの脳内は愉しいワールドだな
自作自演乙
735 ：
仕様書無しさん：2007/06/27(水) 01:39:49
736 ：
仕様書無しさん：2007/06/27(水) 01:43:14
> ＞オブジェクトの中でsleepしたら、
> ＞他のオブジェクトもsleepしちゃう。
>
> ＡＰサーバ上に、トランザクションのロック中に関する専用ＤＢ作ってみたら？
この人の脳内では
sleepとロックが同じカテゴリーの操作と解釈されちゃってるんだろうか？？！
脳内妄想でおかしくなっちゃった人の発言としか解釈できない。
どいつもこいつも
JavaはJavaスレでやれ
DBはDBスレでやれ
738 ：
仕様書無しさん：2007/06/27(水) 02:33:17
要するに異常者が一匹張り付いてるだけ
DBはTDNスレでやれ
740 ：
仕様書無しさん：2007/06/27(水) 06:21:52
俺だったら「そんなスパゲティ、棄てて設計からやり直せ」と、言ってしまいそう。
741 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/27(水) 09:02:22
>>734 俺の自作自演だと思っているなら、明らかに分析能力不足だな。
思い込みだけじゃ預言者と変わらないぞ。
とりあえず、「ﾃﾞｯﾄﾞ」だ
ということだけ言っておく
＞履歴表を作って既存の表からコピー
こういうことじゃないか？実際どうなってるのか知らないが。
既存表履歴 新ＡＰによるコピー新表履歴
Ａ Ａ
Ｂ Ｂ
Ｃ
既存表とコピー表で最新がＣとＢで違う。いわば右はあくまで一時表。
＞とりあえず、「ﾃﾞｯﾄﾞ」だ
ミンチになったか？
デッドロックをかわす一つの方法は、
select---クライアント更新動作--トランザクション開始-再select(←ここでVIEW表作成)-複数レコード更新-commit,rollback
することで、排他ロックする時間のギャップがなくなる。
select for updateで独り占め
>>744 where 付けないのがポイントか。
でもそれ、ヴビ厨の発明だから。
更新ロックは独り占めしたつもりでも独り占めになって無い場合がある。
デッドロックにはよく知られるものにサイクルデッドロック、変換デッドロックがあるけど。
更新ロックどうしならいずれも防げる。
だが、仮に既存が更新ロックを使って無い場合、
要は、更新ロックと共有ロック等では、デッドロックは防げない。
そうなると既存も更新ロックに統一変更する必要がある。
だが、メーカが更新ロック推奨なんだから、将来的な展望含めて、こまめに既存を更新ロックに変更するのが安全な筋だろう。
あぼーん表示の中の人が、何か言い訳しているのを
携帯で偶然見かけて、ﾜﾛﾀ
748 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/27(水) 22:01:44
訳が判らないのは当然です
おじゃばはネットで拾ってきた文章を適当につなげて書いてるだけだから
749 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/27(水) 22:55:06
>>743 DB設計の基礎に正規化と言うのがある。簡単に言うと「重複する情報を持たない」と言う事だ。
正規化の方法と、正しく正規化しなかった時の弊害などは、基本情報処理試験にも出てくるぐらい
一般的な物だから、一度勉強する事をお勧めする。DBは我流ではマスター出来ないぞ。
説明にある排他の方法は、誰かが言っていた、オプティミスティックとか、楽観排他とかと同じ内容だ。
DBの基礎なので勉強した方がいい。
>>746 既存も何もシステムのロックは統一する必要があるから、ロックするテーブルと方式は統一する事。
こまめに変更？無茶苦茶言うなよ。システム止めてでも、一括で全部直すべきだ。
750 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/27(水) 23:06:35
>>748 前にも誰かに言ったが、自作自演なのかは書いた本人は分かるし、コピペなのかも書いた本人が分かるだろ？
だから根拠があって言っているのか、思い込みで言っているのか、書いた本人には分かる訳だ。
俺は他人に自作自演だと思われても、コピペだと思われても全くに構わないが、
電球の思い込みが激しいのを注意してあげたくなる訳だ。
思い込みは正しい理解の妨げになるから注意した方がいいぞ。
いいぞ、いいぞ、もっとやれぇ
＞注意してあげたくなる
親切の押し売りとかってやつ？ｗ
本音は図星突かれたので言い訳してますってことだろ('A`)
コテ共うぜー
753 ：
仕様書無しさん：2007/06/28(木) 00:02:54
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| マスター、ポリモーフィズムは保守しにくいんで名前にクラス名をつけるべきですよね？
┌─┬─┐| ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
│ │ │| ./ . |＼ ＿＿
├─┼─┤|/ │ [| |＼
│ │ │ |＼|＿＿|＼|＼
└─┴─┘ | | ＼目 ＼|＼
＿＿ | [|＿_|＼ [][] ＼|＼＿
＿＿＿＿＿＿/ |.__∧＿∧[][].＼YY ＼| │
∧＿∧ / |...(∩Ｔ∀T)＼△＼ YY | │
（ ´∀）/ .凸 | （ つ[]..＼目 ＼ / │
（ `つ日凵 | | ｜ |＼| .|＼凸 | │
┏（＿_ /.Ｙ | .（＿（_＿） ＼| .|＼ﾉ |
┗┳┳| ￣￣￣￣7 ＼| .| |
┃┃| | ／| ＼| |
／ ￣￣￣￣￣￣￣￣￣￣￣￣
| お客さん、よくわかってますなあ。
＼＿＿＿＿＿＿＿＿＿＿＿
なんにしろ、DBの話はもういいだろ
755 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 00:52:04
あほか
正規化なんかセンスで脳に最初からインプットされてるわ。
わさわざ勉強するやつがおかしい
普通は正規化もOOも脳内プリインストールだろ
DBに必死な奴は一体なんなんだ
マルチスレッドがアミダのトグロくんが
またぞろデッドロック(複数の必要資源を互いにロックしあって処理続行が不可能になる状態)
に悩んでいるのだろう
・・・あわれ
普通はデッドロックは基礎教養だろｗ
やってみるまで判んないって、それ無免許運転に近いんじゃね？
>760
DBスレいけよ
マジで
なんだ、自作自演じゃねぇのかｗ
またバカが一人で戯言書き連ねてるのかと思ったらｗ
はいはい、ﾊﾞﾛｽﾊﾞﾛｽ
764 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 01:56:51
765 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 01:57:41
ここに居るバカどもは
デッドロックといえばDBしか連想できないようだけど、
本来はマルチプロセス/マルチスレッドに共通する
資源競合の問題なんだよね
結局はOOは浸透しない、ってことでOK？
別にアンチじゃないんだけど、
「意味が分からない」「それって何？」「Javaのことでしょ？」
みたいな奴が多すぎて、どーにもならんって印象が強いんだわ
やっぱネーミングは大事だな
売れる商品は第一印象で客を呼べないとダメだわ
「オブジェクト指向で作った会計ソフトです！」
「オブジェクト指向対応！！」（意味不明だがありそう）
「日本中を震撼させているオブジェクト指向によるなんちゃらかんちゃら！」
全然響いてこねー。。。
>>766 おまぃも必死だなあ
スレタイとなんの関係があるんだ？
>>766 バカ相手に講釈乙
教養課程や情報処理でべんきょすべき内容を
関係ないスレで必死に言い訳しつづけるコテ、
スルーするしか能がない
>>767 って
一体どれだけ無教養なんだろう
このスレレベル低過ぎｗ
>760=762=769
粘着乙
771 ：
仕様書無しさん：2007/06/28(木) 02:10:12
今日も異常者が張り付いてるなｗ
いつ来ても即答するコイツ、
よっぽど暇暇なんだろうなｗｗｗｗｗ
773 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 08:36:50
ええええええ
なんでおれが入ってるの
774 ：
仕様書無しさん：2007/06/28(木) 08:41:33
>>767 OOは結局、データと関数(サブルーチン)をまとめた物だし、
インターフェイスだけを公開すれば、別のプログラムがどうなっていても(たとえOO使って無くても)関係無いから…
結論
使いたい人だけ使えばいいよ。(どうぞ御勝手に)
て、ことで。
775 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/28(木) 21:14:28
>>752 ちょっと違うかな。
チャック開いて歩いている人を見つけて、それを見過ごすと罪悪感を抱くので教える。それに近いな。
>>755,756,760
DBもOOもセンスだけじゃどうにもならんぞ。自分の勉強不足を、強がりでカバーしても意味がない。
>>767 「オブジェクト指向」のオブジェクトは「物」としてもいいのだが、実体の無い物もあるので、
やはりオブジェクトが一番いい。指向は、オブジェクトの概念だけでは全ての仕様をカバー出来ないので、
それ以外の概念も入っている事を考えれば、かなり適切な表現だ。
だから「オブジェクト指向」と言うのは、内容をよく表した言葉だと思う。
776 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 21:27:41
虎は訓練などしない。
最初から強い。
あの程度のものちゃっちゃとその場で考つくもの。
ひょっとしてド・モルガンの定理もいちいち暗記してたのか？
普通のセンスの人間は脳にインストールされてるぞ
777 ：
仕様書無しさん：2007/06/28(木) 21:47:31
775 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/28(木) 21:14:28
776 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 21:27:41
誰がどう見ても、このコテ二匹同一人物だよな～（ﾜﾛｽ
778 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/28(木) 21:51:10
>>774 同じシステム内での構造化とOOの混在は良くない。
OOと言うのはモジュール化と違って、最小から最大単位まで抽象化出来る事に意味がある。
だから勝手に使えと言うのは間違い。
プロジェクトでC++やJavaを使うなら、OOをマスターすべきだ。
つーか、C++にCが混じったソースは、見ただけでもやる気がなくなる。
一般的なC++とCのネーミングルールは違うし、ヘッダファイルに分割する単位も違う。
関数かクラスかマクロかテンプレートか分からない物に、どれをインクルードすればいいのか分からない
ヘッダファイル。インラインかライブラリか分からないクラスと、依存性の塊になったライブラリ。
まさに混沌の極致だった。
779 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 22:02:47
ボケが
構造化とOOはほとんど同じ集合だわ
780 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 22:06:42
ラベルか
マシン語時代の記憶から引っ張り出してきたルーチンにはマシン語のラベル
C時代のはCのラベル
Java時代のにはJava式ラベル
たまにBasicのラベル
残りはC++のラベル
を混ぜて書いてる。
とても見やすい。
俺には
781 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 22:13:47
ClearScreen （C++）
crearScreen (java)
clear_screen (C)
CLEARSCREEN (BASIC)
CLS (マシン語 )
782 ：
仕様書無しさん：2007/06/28(木) 22:14:40
>>778 構造化が何を指すのか分からないから教えてくれ。
それとあまり無理するな。
>>781 CLSなんてマシン語が有ったらいいですねぇ・・・
ココ電がマシン語といってるのはたぶんアセンブリ言語の間違いじゃないかと思う。
785 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 23:02:14
SEX
SWAP
００HはBRK
786 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 23:05:53
キャラクターマシン
大昔のマシンでアスキーコードで
A 0x41が ADD
B 0x42が BIT
C 0x43が SEC
みたいにアルファベット一文字がそれに対応したアセンブリ言語になるようにしたマシンがはやった時期があった。
機械語（きかいご）またはマシン語とは、CPUが直接理解し実行できるプログラミング言語であり実体は2値の電気信号の集まりである。
-Wikipediaより抜粋。
788 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/28(木) 23:18:46
まあ、アセンブラでなくマシン語でも組んでいたから間違いではないわな。
慣れると覚えちゃうよ。
「組んでいたから間違いではないわな。」って、お前の個人的な経験なんかどうでもいい。
結局使いこなせて、人が使えるように指導できる奴が少ないからでしょ？
で、OOの話はどこにいった？
クラスが使えて、継承が出来て、仮想関数がつかえて、実行するまで何が呼ばれるか解らないんですよｗ
という何がなんだか解らない解説から進歩しているんだろうか
＞クラスが使えて、継承が出来て、仮想関数がつかえて、実行するまで何が呼ばれるか解らないんですよｗ
少しは学習しろよｗ
794 ：
仕様書無しさん：2007/06/29(金) 08:53:41
オブジェクト指向＝機能をまとめる物。
795 ：
おじゃばさま ◆Fy0HoitUDw ：2007/06/29(金) 08:59:22
>>電球
例えばコボルやっていた人が、C言語を始めて、main()に全てのコードを書いたとする。
それでC言語はソースが複雑になり過ぎるとか文句を言ったとしよう。
そこで、関数を使って分割する、と教えたとする。
そうするとその人は、C言語はこれで正しい、main()に全てを書くのは推奨される唯一の方法だとか言って、
C言語はダメな言語だ、論理はコボルと同じだ、C言語なんて勉強しなくても生まれつき出来る、
とかと言っていたとする。
そういう人にはどう説明すればいい？
>>782 構造化と言っているののは、「構造化プログラミングで書かれたCのソース」。
あと俺は長文だが、あまり考えずに書いているので無理してない。
796 ：
仕様書無しさん：2007/06/29(金) 09:08:55
797 ：
仕様書無しさん：2007/06/29(金) 09:55:42
>>795 ＞構造化プログラミングで書かれたCのソース
つまり、for, whileのたぐいを使うなって意味だな。
>>795 コボラーは大概、構造化プログラミングを理解してるから、
関数作って分割に関しては何にも言わないと思うけど？
1つのプログラム内で、制御部分と処理部分に分けるのは普通にやってる事だし。
799 ：
仕様書無しさん：2007/06/29(金) 10:27:24
800 ：
仕様書無しさん：2007/06/29(金) 10:35:11
>>795 もし本人なら、トリ統一してくれ。
NGから漏れて目障り。
>795
お前キチガイか？
>801
NGName=おじゃばさま,ココ電球
でFA
804 ：
801：2007/06/29(金) 13:42:11
>>803 ってやると、君の書き込みも見えなくなって寂しいじゃないか。
>804
NGWordじゃないぞ？NGNameだぞ？
806 ：
仕様書無しさん：2007/06/29(金) 18:37:38
次スレタイトル
「なぜ構造化を知ったかする奴がOOには大反対するか」
坊やだからさ
「なぜ構造化を知ったかする奴がOOを教えたがるか」
でもアリではないの？
COBOLでも主処理－ＳＥＣに全部書かないだろ
モジュール分割くらいはやる
それ以前に、COBOLにCALL文あったりローカルのWORKING-STORAGE
あるのも知らないでなに言ってるんだ？
最近のＣＯＢＯＬって、他言語とのインターフェース持ってるんだよね？
812 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/29(金) 21:19:05
いやコボルがどうとか言う問題じゃなくて、OOを語る構造化プログラマを、
Cを語るコボラーとして表現したんだよ。
Cプログラマなら、コボラーの指摘がいかに的外れなのか分かると思ってな。
813 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/29(金) 21:28:04
>>797 言いたいことは想像がつくが、餌が腐っているのでスルーさせてもらう。
>>800 いいんだよ、頭のいい人なら頭の悪い文章も容易に理解出来るだろうから。
814 ：
仕様書無しさん：2007/06/29(金) 21:34:52
>>812 そもそもお前が構造化とオブジェクト指向を理解しているのかと。
815 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/29(金) 21:41:16
>>814 理解しているよ。どこか間違っているか？
>>815 理解している人が「同じシステム内で構造化とOOの混在は良くない」なんて言うのか。
もしかして言葉のあやなのか？
…そもそも同一人物なのか？
おじゃばさまは昔、こぼるさま と名乗ってません？
818 ：
おじゃばさま ◆GxjxF3yEw6 ：2007/06/29(金) 21:58:02
>>816 OOもメソッドの中の小さい単位は、構造化と変わらないから問題ないと言いたいのかな？
それはそうだが、構造化の方は関数レベル以上の大きな単位を言っている。
理由も書いたから分かると思うが。
>>817 名乗ってない。
819 ：
仕様書無しさん：2007/06/29(金) 22:14:06
>>818 そんな変な次元の話しに持ち込むなよ。
オブジェクト指向を使わないとしても、わざわざ階層構造を崩す事はしないだろ。
…理由って抽象化の事か？（少し変な物が混じっているが。）
そんな訳無いよな…
ブリッジパタンとか、なんで存在するのかって話かねえ
おじゃばの挙げる前提は超低レベルなんで参考にならん
誰でも知ってる当たり前のことを相変わらず
「オレはよく知ってるだろ」
のノリでだらだら、だらだら、だらだら、だらだら、だらだら、だらだら、だらだら、だらだら、だらだら、
長文を書いてるが、
なんか意味あんのか？
おじゃば、お前あれだろ
全然使いもんにならんから毎年新人教育担当させられてんだろ
そりゃ低レベルだわな
822 ：
仕様書無しさん：2007/06/29(金) 23:18:31
ちょっとした疑問なんですけど。
OOP修得者と非修得者がプロジェクトに混在している事がよくあると思うのですが、
そういう時ってどうプログラムを組んでますか？
良かったら教えて下さい。お願いします。
おじゃばをそう責めるな。
OO言ってる奴なんて、最近じゃそんなもんだ。
わかってないから、OOを擁護するし、できる。そんなのが大多数。
怪しげなOO本が溢れ、どんなバカでもOOを語れるようになった。
COBOLなんて知らんが、構造化の観点で見ればおそらくCと変わらない。
本質的には、メモリに直接アクセスできるかできないかの違い程度だろう。
>>812は、なにをもってコボラーの指摘が的外れなのかさっぱりわからん。
とりあえず、例としてあげたいのだろうが、OOの話とまったく関係ない。
って、やはりおじゃばを責めてしまうことになってしまった…か。
>>822 質問がちょっとおかしい。
OO習得者でもOO嫌いがいるはず。
OO好きとOO嫌いがプロジェクトに混在した場合の質問に変えたほうがいいね。
思うに、ライブラリを完全に利用するだけの場合は、OOライブラリが便利で、
ライブラリを作る側ならOOは面倒なんじゃないだろうか。
ライブラリを完全に利用するだけのつもりだったが、ライブラリが挙動がおかしく、
中を見る必要が出てきた場合もOOだと面倒。
おじゃばは、Java＋DBな人なんだろう。そこには立派なライブラリが溢れており、
完全に利用者になれる。おじゃばはただの糊付け役。
そんな状況ならOO万能って思っちゃうのも無理は無いかもしれない。
ハードウェア屋、OS屋、コンパイラ屋、ライブラリ屋の苦労があって、
おじゃばが「OO勉強している奴偉い」と思える環境ができあがっている。
826 ：
仕様書無しさん：2007/06/29(金) 23:46:36
>>822 何をもってOO習得者と非修得者を判断するのかがわからん
何か、プログラミングができる奴とできない奴が混在してるだけのような
気がする
う～む。
良い文章を思いつかない…
まあ、いいか釣れたし。
釣られてくれてありがとね(^-^)
>>825 おじゃばはC++を使っているのでは？
828 ：
仕様書無しさん：2007/06/29(金) 23:48:36
発注元の大手企業の古参PGが理解できない。それに尽きる。
発注元にPGなんかいないぞ
ああ、UMLすら分からん化石がのさばってるだけ。
今日日みかかですらUMLが標準だぞ
UMLっぽい妙なクラス図？とか、シーケンス図？？とか渡される。
それで「詳細設計から実装までよろしく！」って言われて放置される。
詳細設計と実装は別料金でおk？
>>2が真実。
実際、オブジェクト思考は手間がかかる上に、それに見合うだけの作業効率が得られない時だったある。
ただし、JavaとかC# でプログラム作るんなら、駄々をこねずにオブジェクト思考を取り入れないと。
言語仕様くらいは守ろうぜ。C言語出身の30代PGさん
思考って・・・
言語仕様を守らないとコンパイルが通らないのは当たり前なのに、
なんでキムチに虫が涌いてるんだろう？
まったく意味がわかりません
本当にありがとうございました
838 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/30(土) 04:41:32
OO支持者の層はUFO信じてるやつらと同じ層
ついに意味不明なレッテル貼りしかできなくなりました？
>>834 ほぼ同等のVB.NETはOO無しでも組める。
ならC#だって！
>825
>おじゃばが「OO勉強している奴偉い」と思える環境ができあがっている。
おじゃばって「OO勉強している俺偉い」としか言ってねえよーな。
しかもとんでもなくうわっつらのとこで。
842 ：
ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/30(土) 10:41:01
>>822 モジュール分けして担当を明確に分け、インターフェースだけ決めて中身は好きなように書かせる。
保守に留意するようにあらかじめ言っておく事。
資料を残すこと。
>>842 >モジュール分けして担当を明確に分け、インターフェースだけ決めて中身は好きなように書かせる
これ↑いいと思ってる時点でなんか経験足りてないなぁ・・・って思う
同じ名前の関数で別の動作すんだぞ？
本当にそれはいいことなのか？
例えばバージョンが変わって動作が変わったっていうなら
前の関数はそのまま残しておいて
違う名前の関数にしたほうがいいんじゃないかなーって思う
845 ：
仕様書無しさん：
しかも、ここってオブジェクト指向の本質じゃないよね？
オブジェクト指向ってあくまでもオブジェクト単位でプログラムを組んでくところが味噌じゃね？
ちょっと学者連中の飯の種の影響受け過ぎてて手を広げすぎだと思うんだけど
何が大事なのかさっぱり焦点があってない
あーいえばこーいうみたいな議論になってしまって全然進歩がない
少なくともこんな実装レベルのどーでもいいような内容まで設計の議論に入ってくるもんだろか？
また、そんな風にばたついた概念が果たしていいものだろうか？