【オブジェクト指向】実際どうなの？

漏れは３０過ぎの汎用ＳＥ。
これからはオブジェクト指向と言われ続けてきたけど
実際オブジェクト指向で開発おこなわれているの？
特にＰＧなんてＪａｖａとか言っても
実質殆ど手続き型という話も聞くけど・・・。


やっぱりオブジェクト指向、勉強した方がいいのかなぁ（涙）

オブジェクトチンコ

>>1
そうだよ。漏れもJAVAばっかやってるけど、
コーディングなんざ手続き型と変わらん。
オブジェクト指向だなんだ言っても、
プログラムは結局
演算、分岐、繰り返ししかない。

そりゃクラス設計が終わってコーディングのみだったら
オブジェクト指向も何もないわなぁ

賢い設計者にとっては有効な方法論だけど、
馬鹿なコーダーにとっては豚に真珠。

その意味で、>>1 のこの部分はある意味真実だ：
＞ 特にＰＧなんてＪａｖａとか言っても
＞実質殆ど手続き型という話も聞くけど・・・。

>>1
オブジェクト指向よりもイベントドリグンについては、大丈夫？

>>5
イベントドリグンだったの？
漏れ、ずっとイベントドリブンだと思ってたんだけど・・・

>>６
失礼。そのとおりです。（パンチミス）
イベントドリブン。
イベント駆動

イベントドリブン耳にしたことはありますが
正直解りません。
それもオブジェクト指向を理解する上で
やはり重要なのでしょうか？

>>8
オメエ、イベントドリブンしてるじゃねえか

>>9
なるほど！そういうことなんですね。
解りやすく教えていただきありがとうございます。
チョット実感しました。

>>9,>>10
ﾜﾗﾀ

それにしても、ホントのこと、
オブジェクト指向だから、メンテナンス性がどうのって言われても、
ワシには、とんと判らんわ。

マジ、C+使っても、手続き型だからのう・・・

「オブジェクト狂想曲」を読むとオブジェクト指向がよくわかるよ。

クラス、スーパークラス、サブクラス、継承、インヘリタンス、オーバーライド、ドーバーロード
どの位わかるの？

ttp://www2.ttcn.ne.jp/~javaroad/
で勉強して。

定説になっている有名な論文
ttp://www.geocities.co.jp/HeartLand/6978/object.htm

古い人間がオブジェクト指向にこだわっても遅い
今後の若い人間に期待しよう

　　　∋oノハヽo∈　／￣￣￣￣￣￣￣
　　　　 （　＾▽＾） ＜　新スレおめでとうございま−す♪
　　　= ⊂ 　　）　　 ＼＿＿＿＿＿＿＿
　　　= (__/"(__)　トテテテ

>>1ってオブジェクト指向のどれぐらいまで理解してるのさ？

>>13
extends覚えるだけで左から5個の単語がわかるよ。

>>13
だから、何？（ｗ

ワシらが言いたいのは、オブジェクト指向で生産性が上がるって
神話のことぞよ。

>>18
「だからオブジェクト指向のメリットを理解したかったら、
その内容を勉強してください。」ということだよ。

>>19
だったら、実務的に教えてくれと・・・

>>19
教科書ヴァカ

>>21
あんたは、教科書もわからないヴァカ

>>21
オブジェクト指向はその概要を理解しないとオブジェクト指向開発なんて無理。
オブジェクト指向も理解しないでJAVAのプログラミングやって、なにがうれしいことが
あるんだよ。

ハｱｱｱｱｱ…

>>24
いいたいことがあったら、ちゃんとかけ。

>>24
オブジェクト指向を理解しないで、ＪＡＶＡやＣ＋＋のプログラミングして
なにがうれしいことがあるか？って聞いてるんだよ。
おまえしばくぞ！！！

１です。
私がオブジェクト指向について知っているのは
オブジェクト指向を学ぶ上で使用される基礎用語（？）
くらいです。たとえばそう、クラス、継承やインヘリタンスといった
しかしながら用語は知っているがイメージが湧かないし
とても理解しているとは恥ずかしくいえません。
ＵＭＬでもイメージは多少湧くとしてもコーディングとなると・・・
典型的なＩＦ文おやじです。（苦笑）

＞＞オブジェクト指向を理解しないで、ＪＡＶＡやＣ＋＋のプログラミングして
＞＞なにがうれしいことがあるか？って聞いてるんだよ。
＞＞おまえしばくぞ！！！

ハｱｱｱｱｱ…

>>28
ハｱｱｱｱｱ…

>>27
概要を理解されているなら、オブジェクト指向の言語でプログラムを作られては
どうでしょうか？
私もイメージしかないのですが、プログラム構造化言語の場合、
サブルーチンとか作ってあとで、そのサブルーチンと少ししか違う
サブルーチンを作成する場合、元のサブルールチン
をコピーして、名前を変えて違う部分のみ修正していたのが、
オブジェクト指向言語の場合、クラスを作成し、
そのクラスと少ししか違うクラスを作成する場合、
元のクラスを継承（コピーする必要がなく、簡単に別のクラスを作成可能）
して別のクラスを作成できるということだそうです。

>>28
いつまでも「ハｱｱｱｱｱ… 」言ってろ。

シャブルーチン　(;´Д｀)ﾊｧﾊｧ

>>30
やはり、なんだかんだとそこがオブジェクト指向の実質一番の
メリットっぽいですね。これだけでも現時点では十分に通じそうな
気分になってきました。（気分だけかもしれないですが）

なんか、>>23以降は、自作自演の匂いがするなあ。。。

ま、そんなことは置いといて。。。

漏れみたいに、構造化でやってた人間は
いくらオブジェクト指向の本読んで、開発手法学んで、
ちょっとばかしＪＡＶＡとか勉強しても、
いまいち、ピンとこんのだよ。開発効率という観点で。

コーディングがちょっと効率よくなっても、
結局、時間お手間がかかるのは設計と、テスト。
オブジェクト指向で、効率がよくなるんかいな？

古いが、構造化のモジュールの機能と結合度の観点で
設計することと、大差あるんかね。

また、ドキュメントに関しても、
ＲＵＰみたいに山ほどいろんな設計書書くのは、うんざりだね。

マジで、何がどういいのか、実務的に、教えてチョ。
（長くなったな・・・スマソ）

>>34
自作自演じゃないです。
24には本当に頭に来る。

私もオプジェクト指向型開発は、経験ないけど、
昔いってた、ソフトウェア危機なるものは解消されるような気がします。
（同じような内容のプログラムがたくさん開発されて、保守が大変になるということは
　無くなるような気がします。）

>>35
いや、それじゃあ、理屈になってないよ。
漏れは、オブジェクト指向のどこが生産的で、
開発効率がよくなるのか、聞いてるのに、
結論から＞＞昔いってた、ソフトウェア危機なるものは解消されるような気がします。
と、言われてもねえ。。。

逆にオーヴァーライドできるから、
＞＞同じような内容のプログラムがたくさん開発されて
しまうってことは、ないのかね？

まあ、もういいけどね。

オブジェクト指向は今まで以上に似たような
プログラム（オブジェクト）が生産されてしまうということでしょうか？
経験無いので何ともいえません
構造化とオブジェクト指向、両方の経験があるかたいたら
どなたか教えてください。

＜朝日新聞＞地村さん夫妻取材で１ページの謝罪記事

　北朝鮮による拉致被害者の福井県小浜市の地村保志さん（４７）、富貴恵さん（４７）夫妻に
聞いた話が地村さん側の意向に反して週刊朝日（朝日新聞社発行）に掲載された問題で、同誌は
１月３１日号（２１日発売）に１ページを割いて、地村さん側の主張を全面的に認める鈴木健
編集長名の謝罪記事を掲載した。保志さんの父保さん（７５）は２０日、同市を通じ
「仕方なく了解するが、今後、このようなことが二度とないよう厳重に注意してほしい」
との談話を発表した。

　週刊朝日側は当初「（地村さん側から）取材の承諾を得た」としていたが、謝罪記事では
取材の経緯を明かし「全体のやりとりを踏まえると、承諾していなかったことは明らか」
と主張を覆した。取材した記者が無断で会話をテープに録音していたことも認めた。

　朝日新聞社の内海紀雄・専務広報担当は「取材は基本ルールを逸脱し、信義に反するもので、
ご夫妻らに多大なご迷惑をかけ、心からおわびします。また、読者の信頼を損なう結果になり、
申し訳ありません。関係者を厳しく処分し、再発防止に努めます」などとする談話を出した。

>37
それ当たってると思います。
今のところ、業態や業種レベルで企業をまたいでクラスが
シェアされているなんてことはほとんどありません。
同じ企業の別プロジェクトであってもほとんどない。
汎用性をめざしてフレームワーク(要はクラスライブラリ)の横展開
などをねらっても、使いにくくてしょうがないというのがほんと。
構造化プログラミングの知識は必須。
↑これが無い人のコードはオブジェクト指向どころではありません。

>>39
効果的にフレームワークを作ってゆければ
という気もしますがそれはそれで揺ぎ無い信念と
チームメンバーがついてゆくだけのカリスマを持っていないと
難しそうです。

>>30
>オブジェクト指向言語の場合、クラスを作成し、
>そのクラスと少ししか違うクラスを作成する場合、
>元のクラスを継承（コピーする必要がなく、簡単に別のクラスを作成可能）
>して別のクラスを作成できるということだそうです。

8〜10年前だったら、オブジェクト指向の説明で
そういうことを書いてる本もあるにはあった。
だけど、今となっては大きな間違い。
コードの再利用をしたいならば、包含、委譲を
使うべきであって、継承を使うべきではないんだな。

>>41
オブジェクト指向スペシャリストさんですか？
なにかスンナリ、オブジェクト指向型開発へ入っていく方法はないでしょうか？

41じゃないけど、いきなりすんなりは無理だと思われ。
ひたすら学習と実践の繰り返しあるのみ。
あとは環境。まわりにオブジェクト指向出来る人がいれば習得は早い。
その人の書いたコードを読んで盗む。あと質問しまくり。
一年くらいがんばれば、なんかつかめると思うよ。
俺はそうやって覚えました。

>>34
設計とテストにかかる時間は、オブジェクト指向でやっても
同じですよ。設計なんかはむしろ時間がかかります。
オブジェクト指向やってメリットがあるのはメンテの方です。
うまく作られたオブジェクト指向のプログラムは、
構造化で作られたプログラムに比べると、重複が少なくなるので
修正箇所が少なくて済みます。
あと、オブジェクト指向設計は構造化の高凝集性、低結合の
方針の延長線上にあると思います。
ただ、OOPならはそれをうまくやるための仕組みが言語レベルで
色々提供されているので、少ない労力で達成することができます。

ＵＭＬで設計してＪＢｕｉｌｄｅｒでＪＡＶＡプログラミングされた方、
いらっしゃいますか？
この組み合わせって、幸せになれますか？

>>43
そんな環境が欲し

>>44
解釈は、上流工程でしっかりと熟成されたオブジェクト指向開発は保守が容易
　⇒　つまりシステムのライフサイクルを考えると非常にローコスト
ってことでＯＫ？

>>46
OKです。オブジェクト指向開発には、時間をかけて習得するだけの
メリットは充分あると思いますよ。

イベントドンブリって美味しいの？

>>43
スペシャリストではないけれども。
いわゆる、オブジェクト指向
プログラミングにおけるソフトウェア設計と、
SEが行うシステム設計というものは別モノではでは
ないだろうか？と思うんだが。
UMLを書いて、それからソースを起こすんだったら、
それはプログラマレベルにおけるソフトウェア設計
なので、プログラマが考えたらよい。

それで、その実体はというと、
>>44 のいう、
「構造化の高凝集性、低結合の方針の延長線上」
という一言ことがOOPの本質をあらわしてると
思う。

>>49
オブジェクト指向開発も、ＵＩ設計の作業は、いままでとおりでいいの？
開発範囲をフィックスさせてからクラス設計すればいいの？
教えてください。

オブジェクト指向で開発した基幹業務システムが存在したとして
１０年後には、スパゲッティになっているだろうと思います。
保守性が良いのも、モデルを理解している人がいるうちだけでしょう。
ビジネス環境や業務プロセスが変わって、モデルが原型を留めないほど
変わってしまったら。。。そもそも、設計書が維持されていないのに、
ＵＭＬならちゃんと維持されるという保証は何もありません。

>>51
そうやってオジさんたちは挫折して行くのですね（嘲笑
よくわかりました

>>50
49じゃないけど、UI設計の作業って、
画面の動きやレイアウトや項目を決めることっていうことなら、
今まで通りやってもいいと思うよ。
開発範囲がフィックスしなければ、どんなクラスが必要で、
どうやって設計すればいいのかなんて分からないはずだから。

「UI設計」という構造化分析・設計のキーワードが出てきた所で、質問です。

これまで構造化分析・設計をやってきた方は、
オブジェクト指向分析・設計への移行を図るにあたり、
OOの特徴である、要求分析(ユースケース)や、概念モデル設計、はたまたRDBのスキーマ設計、
をどの工程で実施されるのでしょうか？

オブジェクト指向を極めたい。

>>50
とりあえずＵＩ系とビジネスロジック系を
できる限り切り離すように心がけませう。

その上でＵＩ系は捨てるつもりで軽い奴を作りませう。客の心と秋の空。

商売系はそう簡単に変わる物ではない
（変えられなくてみんな苦労している）ので、しっかり分析しませう。
後にソースに手を入れなくても新規にソースを書くだけで
機能が追加できればしめたものです。

いつも通りの工数を出してガッポリ稼ぎませう。

>>41
包含が使える場面なんてそうそうないとおもうけど・・・・。
集約の特別な種類という意味では、全くの間違いって
わけでないけどね。

Javaで本気で再利用を図ろうとすると、インタフェース＋委譲で
複雑につくりこむしかなくて、工数的なペナルティが厳しい。

個人的にはアスペクト指向が求めてるものに近いので
次のパラダイムになるのではないかと読んでるんだけど
みなさんはどうですか。

>>57
包含云々って部分は、よくイメージがわからないです。
でも,後半ははげどう。

オブジェクト指向とかＪＡＶＡとかいってるけど、
最近ＣＯＢＯＬでの開発が復活しつつあるんでしょ。
トヨタ関係の企業が、せっかくＪＡＶＡでつくったシステムをＣＯＢＯＬで
作り直しているって聞いたよ。
情報求む。

>>59
トヨタがどうかはしらないけど、一部でCOBOLが
復活してるらしいということは、営業から聞きました。
「私にはたいして影響ないかもしれないなぁ。」
と聞き流してましたが。

ふーん、そうなんだ。
ここ数年はずっとJavaの妙なブームが続いていたから
もしかすると反動で向かい風になるかもしれないね。

それでもオブジェクト指向開発は、なくならないんじゃないかな？
ＣＯＢＯＬでクラスは作れないと思うけど。
実際、新規案件で、ＣＯＢＯＬの開発している人いる？

OOCOBOLってのがありますね。
使われてるかどうかはわかりませんが。

つーか、何がOOなんだ？

ＩＩＯＳＳ
http://www.iioss.org/index-j.html
を試してみた方いらっしゃいますでしょうか？
使い勝手等々感想をおきかせください。
よろしく御願い致します。

オブジェクト指向にカプセル化（処理＋データ）ってあるんですが、
ＥＪＢでは、セッションＢｅａｎがビジネスロジックで、エンティティＢｅａｎが
データ。これって、カプセル化ではないでしょ。処理とデータの分離はＤＯＡ。
ＥＪＢは、ＤＯＡってことでしょうか？
データベースを扱う企業業務システムでは、しかたなかったのですね。

>>66
ビジネス・ロジックとデータって分け方が、既にDOA。
つまり、哺乳類の体の構造を、魚の体の構造に関する知識で理解しようとしているのと同じ

>>66
「EJBは、DOA的なフレームワークを含んでいる」って程度じゃないかな？
EJBのコネクターBeanやRMIやJSPは、DOAの何に対応させるつもりなの？

まぁDOAにしろOOにしろ、結局やることはいっしょなんで変に固執しない
方がいいと思うのだが。
DOAだってデータ構造とロジックを完全に分離して考えてるわけじゃないし。
EJBのセッションBeanとエンティティBeanの役割の違いは単に機能の違い
として捉えた方がよい。

>>66
※スレタイから脱線しっぱなしですみません。
エンティティBeanは、単に永続化オブジェクトとしてみればいいのであって、
オブジェクト指向的でないと断言するのはどうでしょうか？
・エンティティBeanにも、Homeインターフェース等にビジネスロジックを
　持たせたりできるので、単純なデータオブジェクトとは言い切れません。
・エンティティBeanはあまりにもORマッピングを意識しすぎているとの
　声もありますが、今後のエンティティBeanの永続化対象は
　リレーショナルDB以外にも、OODB、XMLDB等にも拡大する予定です。
　（正確にはEJB2.2で永続化マネージャとしてJDO等が使われるようになり
　　永続化手段によって永続化マネージャをコネクティビティとして選択
　　できるようになる）

>>70
３〜４年前の情報では、そんな感じだったと思います。
ところで、今使用可能な永続化マネージャって、何があるんでしょうね？
ＯＯＤＢ：　瀕死もしくは消滅
ＸＭＬＤＢ：未熟児もしくは水子
ＲＤＢ：　　ＩＢＭは「ＯＯとＤＯＡの対立」みたいな感じでＯＯに吸収ないし並存させたいと思っているけど、
　　　　　　一向に衰弱する気配がない

EJB使うとカプセル化できない、というわけではないと思うよ。
あるエンティティBeanにアクセスできるSessionBeanを1つに限定すれば
それはそれでちゃんとカプセル化されているわけで。
単に見方の大きさの問題。1つのクラス内だけでカプセル化するのか、
SessionBean+EntityBeanを一つの固まりとして見て
その内部をカプセル化するのか。

>>71
>３〜４年前の情報では、そんな感じだったと思います。
あの...永続化マネージャの対応予定が最終仕様に記載されたのは、
ついこないだ発表されたEJB2.1なんですけど。
それと、３〜４年前は、JDO自体まだ存在してないですよ。
>ところで、今使用可能な永続化マネージャって、何があるんでしょうね？
将来的にはJDO自体も永続化マネージャになるのですが、
既にJDOに対応してフラットファイル、RDB、OODB等に対する
コネクティビリティ製品が米国では販売されてますです。
コネクティビリティ

>>72
禿同。

EntityBeanの下には、手動もしくは自動生成したDAOとか(JDOとか W)置く訳で、
そこらへんひっくるめて Sun BluePrint やらIBMベストプラクティス文書にパターンとして
載ってなかったっけ？(2000年前後)

ぶっちゃけ「DOA的フレームワーク(>>68)」と呼んでしまいたい気がしますが。

>>73
＞あの...永続化マネージャの対応予定が最終仕様に記載されたのは、
＞ついこないだ発表されたEJB2.1なんですけど。
＞それと、３〜４年前は、JDO自体まだ存在してないですよ。
JSRでJDOの議論が始まったのは、2000年前後。
それ以前から、CORBAの永続化サービスとか、
MSのADO DBといった類似技術があったわけでして、
なかなか仕様決めないSUNの仕事っぷりが気になったんで、
2000年前後に、周辺技術とJ2EE仕様の動向調査を行った記憶があります。

J2EE/EJBでJDO採用! とか決まったのは、ここ1〜2年のことだと思いますので
>>71 の書き方は不適切だったかもしれませんね。
×　３〜４年前の情報では、そんな感じだったと思います。
○　３〜４年前から、そっちの方向へ進みそうな気配がありました。

>>73
それは何という製品でしょうか？(CoCoBase？)

あぼーん

>>65
IIOSは使えません。
まだundoも出来ないと思います。
無料でお探しなら、紙と鉛筆のほうがまだいいかと…

>>78
IIOSSをお嫌いですか？
オープン・ソース指向で技術力がある人が、
できる事/できない事を理解して利用する分には構わないと思うけど

そう言う >>78 さんは、何を使ってるの？

カプセル化
継承
多態性
でﾜｯｼｮｲ。

読みやすい、保守しやすいプログラムを書きたいと思ってるPGにとっては
OOPにはメリットが沢山あって、デメリットが無いのは確かだ。

C++全盛期には、信じられない馬鹿に足を引っ張られたものだが・・・JavaやC#には
「教材」になるクラスライブラリが付いてくるからな。常軌を逸するコードは最近見ない。
昔と比べるとイイ時代になったよ。

>>76
JDOのベンダー及び製品はここ見てください。
ttp://jdocentral.com/

「継承」は、２１世紀の「ＧＯＴＯ」とか、「ＵＭＬ」を２１世紀の
「フロチャート」とかいう人がいますけど？
３階層くらい継承して、差分プログラムされたクラスや
めちゃなオーバーライドされたクラスは全体を理解するのに
苦しみます。どうすれば、苦しみから解放されるのでしょう？

>>84
それらは、本当に継承させる理由があるのでしょうか。
実際の設計例を見ると、あまり理由のない継承を良くみかけます。
継承を用いるメリットは、実装の異なる複数のオブジェクトに
対して、抽象クラスの型の操作が可能になること。
しかしながら、委譲（Delegation）を用いても同じ事が実現できます。
（例えばJavaはInterfaceを実装したオブジェクトをInterfaceの型で
　操作できる）
むちゃなオーバーライドが頻繁に見られるようでしたら、継承の
弊害が現れていると言って過言でないと思います。
P.S.
UMLを21世紀のフローチャートと言うのは、あまり意味がわからないです。
もう少し理由を教えていただければうれしいです。

>>83
ありがとうございます。
JDO専用のポータルができているのですね。

>>84
＞３階層くらい継承して、差分プログラムされたクラスや
＞めちゃなオーバーライドされたクラスは全体を理解するのに
＞苦しみます。どうすれば、苦しみから解放されるのでしょう？

新規にソースコードを書くのであれば、
・複雑な実装継承は避けて、
・型継承(Inetrface)や委譲を使え、
という方針をとるべきでしょう。

他の人が書いた、既存のソースコードを
理解して変更するのが目的であれば、
オープン・ソースの開発環境Eclipseや IBMのVisualAge for Java を導入して、
・Type Hierarchyブラウザで、
　上位クラスから継承したメンバーを一括表示して、
　ソース参照上の困難を和らげたり、
・リファクタリング機能を使って、
　実装コードのクラス分割、整理をして、
　複雑な継承を単純化する、
といった方法をとるとよいでしょう。

>>86
洋書では、JDO関連の本もいくつか出ていますよ。
でも、日本では、JDOってあまり話題になりませんね。
昔から、永続化実装に悩んできた方々には、非常に良い
解決手段だと思うのですが。

>>88
>昔から、永続化実装に悩んできた方々には、非常に良い
>解決手段だと思うのですが。

例えばどういった点でしょうか？

＃私は　OODB　やら　Persistent Object に嵌った世代の方の意見を聞き流しながら
＃Stonebraker さんの ORDB の本真似して、J2EEみたいな or-mapping 作ってた世代なんで

>例えばどういった点でしょうか？
おそらく、わかって質問されていますね（W
とりあえず、永続オブジェクトを前提とすると
a.永続オブジェクトに対するクエリ実装
　JDOもEJB(CMP)も、クエリ仕様（EQL等）を
　実装していますが、そのレベルのものを
　自分で実装しようとしたら大変。
b.永続オブジェクトのメモリ上でのライフサイクル
　例えば永続オブジェクト間での参照関係を
　持ち、複数ユーザーからの利用が想定される
　場合、いつ消したらいいのか等ライフサイクル
　管理が大変になります。
　かつてのCOMオブジェクトは、参照数のカウンタを
　持たせてそのオブジェクトを消していいか管理
　していたましたね。
もちろん、ORDB使えば何も永続オブジェクト側で
がんばらなくてもいいのですが、ORDB自体の課題
を話し始めると長くなりそうなので、勘弁して。

>Stonebraker さんの ORDB の本真似して
いい本ですよね。
そういえばC.J.Dateってどうしてるんでしょう？

Javaのクラスライブリとか眺めてれば
なるほどこうするのかって思えてくるんじゃないか？

>>65
IIOSは使えません。問題外です。
シーケンス図、コラボ図など、情報が保存できません。
開発者がOO分析を理解しているので、本にのっている分析図からコントロールと
バウンダリ（ViewとControlerでもよい）をとると、クラスが無くなるのが笑えます。

>>92
開発者がOO分析を理解して *いない*　の間違い。
少し使ってみると、実装ベースの知識で開発していて、上流の分析には使えないのがわかります

>>92
MEF(つうかArgoUMLだね)だけ、フリーのUMLエディタという認識で
使ってるよ。あとはゴミ。

じゃあ、Rose使えばいいじゃん

>>92
前半が意味不明。

RDBへの永続化を、OMTにあるようなやり方でそのままやると、データベースとして
使いにくくなったりしませんか？
前のプロジェクトでそんな感じでやってたのだが、無用なJoinが多すぎ(継承とか･･)
しかもJDBCべたでコーディングしてたので最悪ですた

それにSQL一発で終わるような一覧取得時にも、いちいち

対応するEntityをインスタンス化→関連辿ってデータ取得

というようにやっていたので、無駄なコードが増えるわ、処理は重くなるわ
･･てな幹事でなかなか最悪ですた

結局
・更新系ではORマッピングを使ってもよさそう
・参照系はSQLべた（Viewとか使っても全然OK）
という幹事で自分の中では落ち着いているのですが

>>97
今更何をおっしゃるやら。
スレの流れ的に、JDOとの関連でＯＲマッピングの話題が出てきただけでしょ？

>>95
今時、Roseなんて高いソフト提案できない。
Enterprise Atchitectが10本買える。

じゃぁ、ＥＡ並行輸入するなり、国内発売まで待ちゃーいーだろ。

IIOSはUML書くのには使える無料ﾂｰﾙって
ことでいいわけ？

>>101
まあ、MEF以外はぜんぜん未完成状態みたいだしね。

>>97
J2EEパターンは、まんまそれを薦めてるよ。
最新EJB仕様は、参照系でクソ性能になるのを回避するために、
EQLというSQLもどきを自分で定義している。

いつまでたっても、ORのインピーダンスミスマッチを完全解消
する手段なんか出来ないみたいねー。

つーか、大企業で基幹システムといえばCOBOLなわけだが、
オブジェクト指向？
なにそれ？

>>104
今でもそうなん
そもそも最近大企業の基幹システムをCOBOLで
新規構築なんてきかない

>>105
金融系の現状を知らぬお方らしい

>>106
金融系はCOBOLなんですか？
金融系の仕事ならやっていけそう
業務は激難そうですが

>>103
Fast Laneパターンを知らないの？

http://www.sbpnet.jp/websphere/feature/art.asp?newsid=15
　検索・集計系に、JDBC経由で直接SQLリクエストを発行するサーバ・オブジェクトを使うパターン。
　更新系にはエンティティBeanを使う。

FastLaneみたいな、緊急回避をしないですむように
EJBが拡張されたんだよー。文句たれる前に勉強シロー。

EJB拡張で、ホントにFastLaneの必要がなくなるか？

そうだな
オブジェクト指向覚えるには
パターンは必須だ

>>110
EQLですか？使ってますが何か？
漏れ自身、EJB派ですが、FastLaneは必要だと思う。

FastLaneっていうんだ。げっ。
今後色々とくだらない仕組みにかっちょいい名前をつける
ってのが増えそうでやだなー。
「知らないの？」っていう奴気をつけたほうがいいと思うな。

>>114
概念さえわかってれば、「ちょっと待ってね。しっこしてくる・・・」つって、影でぐぐっとけば即対応可能です。
あと、WebSphere/WebLogic 周りの情報収集は必須かと。

>>109 のリンク先よく見ると、J2EEパターンもろ出しなわけだが。。。

　DTO (Data Transfer Object) と、Value Object って、なんか冗長じゃないかなー。(主旨はわかるけど)
　フレームワーク側で勝手に自動変換してくれる仕組みを提供してもいいんじゃないのか？
　

>>99
今更ですがEA、ホントに安いね。
　http://www.sparxsystems.jp/ea_purchase_en.htm

>>117
性能、結構良いよ。
リバースでもクラスの関連の線が全部引けるのには感動した。
でも、シーケンス図のローソクの長さの自動決定が良くわからん。
英語版では、まだ表示部にバグがある感じ。画面の一部が残る。

日本では本格的に活用されていないオブジェクト指向。
エンジニアとして身に付けておいて損はないスキルだと思うが、
果たしてオブジェクト指向を身に付けたとして
構造化プログラミングのエンジニア以上に年棒が上がるかどうか？
とても疑問だ。

あぼーん

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　 ／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　2/22(土) 16時と21時
　　　　　　　　　　　　　　　　　＼＿／　　 ＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ ﾟ∀ﾟ）＜　梅田マルビルの電光掲示板に…
　『ｷﾀ━（ﾟ∀ﾟ）━!!!!』 ＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　 ￣　　　　 / ／
　　　　　　　　　　　　　　　　　　　￣
詳細はココ→　http://life2.2ch.net/test/read.cgi/offreg/1044221627/l50

もちつけお前ら

age

最近、偉そうなSヨが増えてます。
特にたかがUMLができたくらいで調子にのってるバカです。

プログラミングってのは業務要件を満たす事に
意味があるのにもかかわらず、
クラス設計とUML記述に誇りを持っちゃってるかわいそうな
人達がいます。
数学しかできないバカや理系には業務設計は無理です。
しかしながら、そういう人達がいないと困ります。
スターエンジニアの間では、そのような人達を
使い捨てOO厨と呼ぶのが一般的ですが、
その人達につまらないクラス設計やUML図作成を
安い賃金で任せる事ができるので非常に便利です。
でも、最近は使い捨てOOドカタは中国から輸入する事が
多くなりました。
そういうわけで、うちの会社では
使い捨てOO厨は粗大ゴミとして捨てました。

ちゃんちゃん　

>>124

おなじこと書くな。

ドキュメントもオブジェクト指向で管理できないだろうか

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

あぼーん

あぼーん

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

age
ついでに
ttp://www.geocities.co.jp/HeartLand/6978/object.htm

あぼーん

ゆりかもめ沿線にある、運用が売りの某社みたいなヘタレっぷりだな。
そんなんだから、おまいの会社はいつまでたっても発展しねぇんだよ
IQ低いんじゃねぇの(ぷ

ＯＯ程度の現場発土方技術で、いちいち人材使い捨てにしなきゃ技術移転ができないほど
知的レベルが低い会社はの人が常駐してるスレはここですか？

おまえが使い捨てたんじゃ無くて、
おまえらが見捨てられてるんだよ（ぷ
その証拠に、お前より出来る奴が、なかなか入社して来ないだろう？
井の中の蛙くん（ｗ

ＯＯ程度の現場発土方技術で、いちいち人材使い捨てにしなきゃ技術移転ができないほど
知的レベルが低い会社の人が常駐してるスレはここですか？

おまえが使い捨てたんじゃ無くて、
おまえらが見捨てられてるんだよ（ぷ
その証拠に、お前より出来る奴が、なかなか入社して来ないだろう？
井の中の蛙くん（ｗ

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

age

オブジェクト指向

継承と委譲の分岐点を普遍化出来れば良いのだけど．．．
実際に普遍化したければ一度開発して問題点を導きたし再度見直すサイクルを必要としてしまう。
（異論を持たれる方も多いだろうが神はいない）
そして、現時点での普遍化は成されることとなる。
されど、成されたのは現時点に過ぎず要求項目が増えれば途端に変化する。

概念としての普遍を追いかけても詮無きことと思える現実が存在する。

# 意見お待ちしています。

>>139
「普遍化」「概念としての普遍」が何を指すのか、まったく分かりません。
つまりは意味不明ということです。


同じ問題領域をどうモデリングするかによって、継承を使うか委譲を使うかが決まります。
他にも実装上の要請など(委譲のほうが融通が利く、とか)が決定要因になりえます。

モデリング作業(=分析)とは問題領域の抽象化であり、本質をとらえることです。
「要求項目が増える」ということは、本質としてとらえるべき領域の変化と同義です。
対象が変化したのだから、それに合わせてモデルが変化し、
ひいては継承か委譲かなどという技術的な部分も変化するのは当たり前です。

たとえばデザインパターンという取り組みは、抽象した部分をカタログ化するものです。
決して普遍として存在するものではなく、応用し変化させることを前提に置いています。

いったいぜんたい、誰が「普遍」をめざしているというのでしょうか。
他人を舐めるのもたいがいにしておいたほうがいいと思います

>>140
> モデリング作業(=分析)とは問題領域の抽象化であり、本質をとらえることです。

良く判ってらっしゃる♪
つまり、問題領域が変化すれば現在のモデルは改定せざるえないってことですよね？
そうすると「継承」で構築された場合と「委譲」の場合とで利点は背反することになりますね。
良い面だけを捉えて「応用し変化させることを前提」と言われても説得力なかったりしませんか？

私は結構、醒めた目で眺めています。
オブジェクト指向に何を期待しているのか疑問すらあります。
まぁ、強いて上げれば「継承」と「委譲」の状態管理が可能ってこと位でしょうか？（笑

> そうすると「継承」で構築された場合と「委譲」の場合とで利点は背反することになりますね。
わけわからん。
継承の場合の利点って？
委譲の場合の利点って？

「オブジェクト指向」と呼んで対象にしているものが激しく異なっている気がする。
私にとっては、>>139のレスはどれも見当違いに見えるのだが。

>>142
わからなければレスしなくても良いんじゃないか？
わからぬ人に教える気は全く無いから引っ込んでるほうが良いと思うよ♪

↑おまえ一体何様のつもり（ﾌﾟｹﾞﾗ

委譲じゃなくてコンポジションでしょ、最近は。

継承かコンポジションか、実装はどっちだって構わない。
コンポジションのが対応できる変化の種類が多いってだけだ。

出張はOOを銀の弾丸じゃないといいたいらしいが
そんなの当然じゃん

>>145
そう、銀の弾丸ではないってこと。
つまり「生かすも殺すも貴方次第」であり
「生きてるか死んでるかは解釈により異なる」ってことが言いたい。
そして解釈は価値観により変化するから普遍ではありえない。

あれ？
普遍的な存在理由がなくなってしまった．．．（笑
効率的であることが非効率を生む元になってしまった。
クラス関連図が必須であることが何よりの証明ってか？

>>146
脳が楽できるほうがいいという価値観に基づけば、
オブジェクト指向はbetterだと思う。
よりbetterな手法なりパラダイムが使えるようになったら応用すればいいだけ。

銀の弾丸がないのは当たり前。

> 普遍的な存在理由がなくなってしまった．．．（笑
これは何が対象であるとしても言える言葉だな。
空虚な内容だ(煽りでなくてまじめにそう思う)。

>>147
> 脳が楽できるほうがいいという価値観に基づけば、
> オブジェクト指向はbetterだと思う。
> よりbetterな手法なりパラダイムが使えるようになったら応用すればいいだけ。

あらら、君は経験が浅いのだろうか？（もしかしたら標準的なシステムしか開発されていない？）
経験を積めば積むほどに解釈の多様性に驚き普遍性の無さに辟易するんだけどね。
扱うのが情報であり用途や意図を特定しかねるのが主な原因だ。
勿論、論理的で普遍的な要素もあるがシステムレベルの視野からすれば極小規模なロジックでしかない。

まぁ、多様性に富むからこそ「パッケージの適用率が極端に低い」わけであり
楽をして儲けよう式の企業が如何に頑張っても所詮業界全体に置けるシェア率は非常に小さい。
勿論、お上の定めた用途に基くシステムであれば「普遍性の適用」がほぼ期待通りに働き
パッケージ適用率もグンと上がる。

このように考えるとオブジェクト指向が活躍する場面は限定されているのでは？
と思えたりする。

>>148
抽象的なことばっかいってて、経験に基づかないのが丸わかりだよ。

OOの目的が再利用だとでも思ってるのかなあ。

出張32に継承/委譲/コンポジションを説明して欲しい

>>149
システムを開発する場合に有能者が集まれば「試行錯誤」は少ない。
よって、オブジェクト指向であろうと無かろうと開発工数は殆ど変化しない。

次に、無能者が集まれば「試行錯誤」は非常に多い。
よって、オブジェクト指向だと開発工数は逆に増加する場合が多い。
（但し、金と時間さえかければデコボコでも完成する可能性は大きくなると思われる）

# 結局、ド素人or無能者集団用の開発概念なのかもしれない．．．

>>151
>>143

というか、開発行程の管理をどうすんの?って話も絡むんだけど。
ウォーターフォールモデルで行うか、それともスパイラルフローモデル
で行うかで相当違う。ウォーターフォールモデルで開発するなら
OOPでやろうがモジュール化技法でやろうが工数的にはあんまかわらん。
スパイラルフローモデルを採用する場合、モジュール化技法ではやりきれない
部分が多い。#例えばX window system関連の開発なんか結構たいへんでしょ

手っ取り早くOOPの勉強するならSmalltalkかObjective-Cの方が良い。
本質的な理解ができる。
単にC++やるだけだったったらプログラミング言語C++読んで２ヶ月位
実際に組んでみたら使うだけだったら使えるようになれる。

>>153

うそこけ。ぼけが。

どこら辺が嘘だ?

>>153
OOPてっとり早く勉強するんだったら、デザパタの本読んでみるのが
いいような気がするんだよなぁ。。。

デザパタへの知見なくして何がOOPか

つーかやっぱり世間的にはMFC的な構成・・・継承がまだまだメインの使用方法なの？
んなあほな。

使えねー

知ったかぶりできない話題になった途端姿を消す出張氏

いまさらデザパタ言い出すとは。。。
H部長を思い出す、調子っぱずれな発言だな、こりゃこりゃ

>>153
老人？
X window → gnome, Qt
Smalltalk → Squeak
Objective-C→ MacOSX
だよね、今時。
現場干されて何年でつか？

可哀想な引退老人が、
10年前の付け焼刃の知識で煽りしている
可哀想な板は、ここでつか？

今更Xはねーとは思うがSmalltalkはいいんじゃないのかね。
それに、勉強のためにXのソース読みたいと思うか?

いまやっとくといいのはLispのような気がする。
何でとはいえないが、経験からくる臭いみたいなもの

Lispマンセーな俺だが、オブジェクト指向をやる上での
スタート地点としては、Lispは薦めない。

理由は、Lisp上の多くのOOシステムでは、CLOSに代表されるように、
メソッドがクラスに従属する形式にしないことが多いから。それで、
時にはカプセル化が破れたりもする。この辺はLispの魅力と
表裏一体だから仕方ないよね。

でもみんな、いつかLisp的OOの世界にもおいでよ！寄り道でもいいからさ。

>>164
ここにも老人が・・・。
今は
Aspect指向でMixinでそ。
俺も昔からLisp好きだけど(ちほー

>>162
今更、元ParcPlaceSystemsのVisualWorks無料公開版探して、ソース嫁ってか？
Squeakでええやん、Parc直系Smalltalkの一つだし、今一番活気があるし。
なんでSqueakを無視するのか、リアリティのある説を説明してみろ！

>>164
ここにも老人が・・・。
今は Aspect指向でMixinとか、
CLOSの機能が再認識されてるだろ。
某MJも LispベースのJavaプリプロセッサ研究が起源らしーし。
全く老人が(ｹｯ

ところで漏れもLispﾀﾝが大好きでつ。昔コンパイラ作りますた

ド素人及び未熟者は兎角武器を持ちたがる傾向が顕著で「オブジェクト指向」も手軽に持てる
武器の一つと言える。
だが、残念なことにその武器は全くの「ナマクラ」である。
私が「ナマクラ」である理由を書いたが、それすら読みきれていない御仁の如何に多いことか．．

>167
戻ってきたのは感心だが、皆の武器のどのへんが
ナマクラなのか具体的に言ってみそ。
第一、藻前が指してんのこそ竹光だろ？

>>153
ついでにも一つ突っ込み。
X window systemがオブジェクト指向ではなく、
クラスター指向とでも呼ぶべきものだと思うよ。

MITのLiskov(だっけ？)が "CLU"というクラスターを中心概念に備えた言語を作って、
それの並列処理研究として Argusという並列処理言語＆処理系を作った、
そのWindow Systemとして、Stanford Univ.のW windowを拡張したのが、X window.　
(それがSchriferだっけ、初代X コンソーシアム会長)

国内では投稿大木村研で、Cluの研究やってて、
確かCLU2Cコンパイラーは fj にも流れたはず。(欲しいつったら流してくれた)
Cluの簡単な説明は、bitのバックナンバー探せば載っている。

話は逸れたが、オブジェクト指向のX toolkitとでも呼ぶべきものとして、
Frescoとか呼ばれるクラス・ライブラリが一時期研究されてたが、
結局標準化されずじまい。
ET++あたりに分かれて、デザパタ本のネタになったり、
HTML一般化前にCORBAのプレゼンテーション・レイヤーへの採用が取りざたされたりして、
結局PC Unix業界でBelrinだかFresco98とかいう名前で、余生を送って、
Xwindow標準widgetの地位は Motif/lesstif, gnome, Qtって辺りに譲ったのよねん。

>>167
オブジェクト指向だろうが何だろうがテクニカルな瑣末に過ぎなくて、
実現したいことありきでなければならない。
大事なことはもっと上位のこと。

みたいなことが大意？

試行錯誤の必要すらない、
決まりきった書き方の業務＆制御システムをひたすらしこしこ作ってる、
レガシー職人の溜まり場はここでつか？

いっぱしにOOやってる奴なら、OOが銀の弾丸なんかじゃないことはわかってるって・・・

出張は今ごろ一生懸命ググっている頃と思われ。
昔OOスレに出没していたころも全然OOわかってなかったし、進歩が無いなあ。
わかりもしないで抽象だけ、まあいつものことだが。

>>169
＞話は逸れたが、オブジェクト指向のX toolkitとでも呼ぶべきものとして、
＞Frescoとか呼ばれるクラス・ライブラリが一時期研究されてたが、

Frescoが目指してたのはオブジェクト指向widgetだろがヴォケ

>>172
あなたが「判っている人間」だという証明もありませんが、何か？

　　_, ._
（　ﾟ Дﾟ） 、、、、、、、
2chでそんな保証求められてもねぇ

＞174
おい出張、トリップつけんの忘れてるぞ？
ここは２ちゃんなんだから、しょうがないなあもう。

>>139-163のスレに一括突っ込みをしとく。

>>139要約：「継承と委譲の区別を早期にやらないと、手戻りが多くて駄目だ」
>>145タイポ：あんた、委譲とコンポジションって別扱いしてどうすんのよ
>>150　　　：委譲とコンポジションって、あえて区別する必要あんの？この文脈で。
>>151　　　：「試行錯誤」は無能者がやるものである。
　　　　　　　(従って、継承と委譲の区別は、初期段階に全能者が行わなくてはならない)

けっ。糞ですね。
ふつう、「継承と委譲の区別」とやらの問題を後から手直しできるように、
「分析設計実装テストまで、反復繰り返しやる(Iteration)」つうのが普通の認識でしょ。

自分の勝手な価値観で、設計上の自由度なくして、
分析設計過程に全責任を押し付け、テストで火を噴く、
それが >>139=>>151の生きる道

>>176
むしろ、トリップ付け忘れているのは貴方の方でしょうよ、きっと(ﾆﾔﾘ

>178
なにが(ﾆﾔﾘ なんだか…見苦しいでつね。

うーむ、実のある議論の出来ない椰子は、
言い訳ばっかで見苦しいでつね。

こっちがこれだけネタ提供したんだから、おまいも何か提供しろ！
例えば今モータはどこに居るか？とか

で、出張32は174=177であることは認めるんだな？

確かに、その内容ならトリップを見るまでもなく
明らかではあるんだが。

>>181
　>>177にちゃんとレス付けていない事実からすると、
　お前さんは負け犬だよん(ホレ、裏庭に穴掘れ

この板に常駐しているトリップ無し出張32の正体って、
漏れの元上司 H 部長 である可能性が極めて高い
と確信しますた

で、出張32は174=177=182であることは
認めるんだな？（藁

あと、どうもあからさまに同一人物と思い
たがっているくさいんだが、漏れは
176=178=181ではあるが、その前の議論に
なんか一切書き込んでねぇぞ。
ま、証明不能ではあるけどな。

キチガイと出張は無視って事で、よろしく。
議論は >>177から継続でどうぞ。

あと、OO程度の低脳技術でいちいち人材使い捨てにする、
と称するゆりかもめ沿線H部長の会社に関する議論も、こちらでどうぞ。

>>177
> ふつう、「継承と委譲の区別」とやらの問題を後から手直しできるように、
> 「分析設計実装テストまで、反復繰り返しやる(Iteration)」つうのが普通の認識でしょ。

ふーん、君のとこは極度に生産性の悪いお仕事をされてるのですね？
まぁ、貴方のような認識者が多いから私どもは非常に楽で儲かる商売をさせていただいてます
から感謝せねばね♪

>187
よし、継承と委譲の区別を説明してみなされ

キチガイと出張は、主張が世間とずれてるんで、無視ってことでよろしく。

＃レガシーで後ろ向きな開発しか回ってこない糞会社は、仕事が楽そうでいいなぁー。
＃きっと、誰がやってもすぐできるような、下らない仕事をやってるだけでしょ。
＃こっちは誰もやっていない事をやるのが仕事だから、試行錯誤的な開発が日常茶飯事なんだけどね。

自分がやってることがまるでハイテクであるかのような錯覚 - OO。
そんなのあっちこっちでやってることなのに。
本当はハイテクなんて、一部の基礎研究だけなのに。

君に基礎研究の何がわかるというのか？
君がやったことのある基礎研究を聞くのは可哀想だから、
君が知っている、基礎研究の例をあげてみな。

ハイテク(ぷぷぷ
OOがハイテク(ｹﾞﾗｹﾞﾗ
ソフトウェア開発屋の基礎研究(腹ｲﾃｪｰ

1996年以降にOO始めた初心者は、
OOって昔から確立していると思ってて、
自分が習った概念を思いつかない奴はｱﾌｫ、
とか思ってるのが、なかなか片腹痛い。

おまえねぇー、特に日本はOO後進国だから、極一部例外は除いて、
「そんなのあっちこっちでやってることなのに」なんて大法螺吹けるようになったのは、
ここ数年の事なんよ。それ以前は常に海外主導、海外の成果を紹介するのが大先生
てな時代がずぅーっと続いていたんよ。

本当に哀れな椰子だなぁ。

まぁあれだ、こんな糞スレで虚勢張ってる椰子は、
２０年経ってOOなんてレガシーの極みって時代になっても、
アナパタの解釈がどうしたとか、継承とコンポジションがどうしたとか、
１０年一昔の話題を延々続けて、いっぱしのOO屋を気取って、
今既に始まっている新しい流れに乗れない事だろうと思うよ。
諸先輩の自堕落加減を見てると、ﾏｼﾞそう思う。

「そんなのあっちこっちでやってることなのに」
これも、ゆりかもめ沿線運用会社の御得意の文句だね。

そーゆー事は、5年も10年も経って、
本当に基礎技術が普及した後に言うんじゃなくて、
5年前、10年前にリアルタイムで俺に言えよ。
当時なら、議論の相手になってやるから（ﾜﾗ

お前ら三流大出のなんちゃってSEが屑だから、
こんな土方技術の普及に5年も10年も掛かってるだけだろ。
ふつーの正常な能力の持ち主なら、
今の水準に2〜3年でキャッチアップできてあたりまえ。
それが出来ないから、お前ら屑なんだよ（ぷぷぷ

基礎研究がどうのこうのとかっていうのはどうでもよくて･･･。
つーかある程度枯れた頃に乗っかるのが一番労力が少ないし、業務に導入するのもそれぐらいでまだ間に合う。
ってかさ、世間一般のＳＥっていうのは技術開発をそのものをウリにするわけじゃないんだから、いいんじゃねぇのそれで？

>>1
＞やっぱりオブジェクト指向、勉強した方がいいのかなぁ（涙）

ってか、ＯＯなんて今やもう開発屋の一般常識だって思ってるんだけども違うのか？

なんか滅茶苦茶アフォがいるから指摘しておくけど．．
ＯＯはまだまだ不完全で腐った技術ってことです。（襷に長しってところ）
で、これから先に劇的に進化するかと言えば．．「絶対にムリ！」
結局、理屈を捏ね回したところで綻びが多過ぎて．．．（笑

まぁ、取り敢えず巧いこと使う程度で良しとするってのが有能技術者の考えかたです。
それと、「銀の弾はない」ってことに合意しているようだけど．．．
それは「君等がアフォ」な証拠です。
有能であるのなら「解釈は私が行い決定を下すから私にとっては普遍的であると言える！」
って返答があったかと思うのだけど．．．

# ド素人＆未熟者相手じゃツマランかも．．．

>>196
> 有能であるのなら「解釈は私が行い決定を下すから私にとっては普遍的であると言える！」

そこまで傲慢になれる馬鹿はいないと思うのだが。
出張さんは自分が有能であるとする立場でレスを書いているが、
ご自分は正解を出せる人間だと考えますか？
(そもそも正解は一つじゃないけど)

「自分はこう考える」とは言えても、「俺の考えサイコー、いやっほう」と言い切れるのは馬鹿だけだ。
なんか見てらんない。

>>197
> そこまで傲慢になれる馬鹿はいないと思うのだが。

それがそもそも間違っている。
設計者であり全責任を負う立場であれば、「傲慢と言われても判断を下す」必要がある。
例え間違った判断であっても、揺らぐより遥かにマシなのだからね。
つまり、ＯＯを効率良く使うのならば「割り切りと決め付け」を重視するべきです。
後戻りや不用意な積み込みは問題を生むだけで役に立たないからね。

まぁ、「マスターベーションしてるのだから放置してくだされ！」と言われるのなら
そりゃ見捨てて上げますけどね♪

...このスレ、くだらん。

キチガイと出張は無視でよろしく。
あと、この手の糞スレは出張が痴呆性戯言書き散らすから、
ageずにsage進行でやってね。

しかし2年間出張見てきたけど、ほんとこいつ屑だね。
設計どころかプログラミングもした事ない、ﾀﾀﾞのど素人じゃん、このバカ（ぷ

かつて最も早くコンピュータを導入した銀行業界が，
未だにメインフレームとデータの出し入れが得意なCOBOLの
お守りを一生懸命してるのが笑える。　
澱んだ水溜りのような陳腐化した世界だ。

ブラウン管で席巻したソニーが液晶やPDPで後塵を拝しているみたいなもんだろうか。

皆さんは当たり前のようにソフトウエア工学を勉強してらっしゃるのでしょうか？

>>201 キミの作ったことのあるシステムって、お母さんのための
パソコン上で動く家計簿ソフトくらいなんだろうな。

データの出し入れが得意だから未だにCOBOLを使っているんだし、
ミッションクリティカルな勘定系の高可用性を考えたら、オープン
系よりメインフレームの方がコストパフォーマンスは高いんだけどさ。

知らない世界のことは勉強してから発言する習慣をつけようね。

>>204
先生、質問です！
(1)COBOLが得意な「データの出し入れ」って具体的には何ですか？
(2)
>ミッションクリティカルな勘定系の高可用性を考えたら、オープン
>系よりメインフレームの方がコストパフォーマンスは高いんだけどさ。
コストパフォーマンス、とおっしゃるからには、
勘定系がダウンした場合のコスト（被害額）を見積もってると思うんですが、
それってどうやって計算したんですか？

メインフレームの方がコストパフォーマンス?
ほんとうにわかっているの？
ちなみにどこのHost?i?ｈ？F

ミッションクリティカルってほんとうにわかっているの
hostでどれだけの分散処理できりの

日立ソフトと思われ

ぶー　ｉでーす

モジュールのことだよ。要するに部品。あんた達の事だよ

ｑｑｑｑｑ

ぶー研究者です。。。。。

ああああ

...このスレ、くだらん。

>>204
俺はIBMのメインフレームを一通りやってたよ。
俺が言いたいのは，技術革新から見放された分野だということ。
特に，ソフトウェアの。

まあ，ずっと其処にいると最新の状況が解らなくなるとは思うけどね。
別にメインフレームは要らないとか要ってる訳では無い，
論旨をよく理解して発言して欲しいなあ。

>>202
殆ど一社の独占に近い市場だから競争原理が働かない．．．．。
メーカーに摂っては利益率の高いオイシイセグメント。
ユーザにとってはかなりの重荷．．．
投資と効果のバランスは見合ってないと思う。
例えば，銀行業界は大手の殆どが国から支援を受けて自力で立つことも
できない惨状は御存知のとおり。

音楽でいうとクラシック音楽業界に似てるよね。
オーケストラは国などからの資金援助がないとやってけないし，
作曲レベルでの技術革新とかあんまり期待できない，
演奏者レヴェルではあるのかもしれないけど．．．。

>>216
>殆ど一社の独占に近い市場だから競争原理が働かない．．．．。
>メーカーに摂っては利益率の高いオイシイセグメント。
>ユーザにとってはかなりの重荷．．．
>投資と効果のバランスは見合ってないと思う。

そしてそういう状況をなんとか維持しようというベンダ側の必死の努力が
>>205
>ミッションクリティカルな勘定系の高可用性を考えたら、オープン
>系よりメインフレームの方がコストパフォーマンスは高いんだけどさ。

という「メインフレームの神格化」を意図した間抜けな宣伝に帰着するわけやね。
「システムは絶対にダウンしてはいけない」という思考停止のもと、
リーズナブルなリスク・コスト分析もせず、ただただ「ホストマンセー」を
唱えつづける人々ってのは傍から見ていてまったくおめでたい限り。

漏れはバリバリのOO屋でありメインフレーム屋では
ないんだが、メインフレームには学ぶべき所が
まだまだあると思うんで、217は単純に馬鹿だと思う。

>>217
ここには「ホストマンセー」厨なんていないと思うぞ。
単に、適材適所、っていうことを言葉を変えて言ってる
だけだろ。単純な馬鹿はいるみたいだけど。

オブジェクト指向の権威的な教授ってどこの院の誰？

・ノルウェー某研究所のSimula言語作者(しぼん)
・XEROX PARCでAlto PC〜Smalltalk開発した連中(Alan Key, Goldburg他)
・
・
・

>>218
例えばどこ？

>>221
留学するのは辛いから日本の教授ｷﾎﾞﾝﾇ

>>218
>漏れはバリバリのOO屋でありメインフレーム屋では
>ないんだが、メインフレームには学ぶべき所が
>まだまだあると思うんで、

当たり前だバカ。というか「反面教師」という言葉が存在する以上
「学ぶべき所」がないものなんてこの世にあるわけねえだろハゲ。
あと恥ずかしいから「バリバリのOO屋」なんていう称呼はやめようぜ（ｗ

問題はまさにいみじくも>>204が逝ってる「コストパフォーマンス」なんだが。
まああれだ、所詮人が作ったものは壊れるんだよ。
原子炉だってずっと操業してりゃいつかメルトダウンするだろうし
地理的に分散してるミッションクリティカルシステムだって
同時多発でヒコーキがヒットすりゃあぼーんだ。
「絶対にダウンしないようにがんばる」というのはあくまで過去の遺物的な精神論でしかなく
システムはダウンするもんだという想定のもと、コストと確率を定量化して投資判断を行うのが
理性的なわけだが、どうもそれができてねえ奴が多いんだよなあ。
激しくスレ違いなのでsage。

>>224
スレ違いとか関係なく面白いテーマならみんな乗ってくるからどんどん語ってくれよ。

このスレも，１ヶ月くらい死んでたけど
スレ違いのメインフレームのテーマで復活したんだし．．．。

オブジェクト指向より、シンプルで合理的で正確に動くソースを
書くことに普請してもらいたい。

ああああ

UMLにしても思うのですが　J2eeみたいなObjectの考え方日本でできるとおもうでしょうか？
あたりまえのようにおもうのですが、所詮Javaが出てきて本格的にOBJECT思考の議論ができるよになったのではとおもいます。

いや、日本にクラッシュandビルドができる環境じゃない。企業、国のシステムを
いつCOBOLから脱却できるの。。そうならないと本当のOBJECT思考は学問の世界だけになるのでは

出張の言い方はアレだが、醒めた所からOOを見ていて漏れは同意。
（このスレではOOの限界をシビアに見てる人が多いが、要は世間一般に漂う、
「OOは銀の弾です！マンセー！」的な間違った見識に釘さしたいだけでしょ？）

エンジニアや研究者がいう「有効」と、
営業がいう「有効」と、
経営者がいう「有効」は、
範囲が全く異なってるしね。

>231
まあ指摘がことごとく的外れなのが玉に瑕なんだが。

>231
いまのソフトウェア開発の現状(問題)、OOが出てきた歴史的背景を理解しないと
ただのはやりモノとしてしかみれないよね。

オブジェクト指向開発では、どうやって品質をはかるんだろう。
OO特有のメトリクス手法なんてあるんですか？

ＯＯ以外でも幅広く使えるUnitTestってのが普通

数値計算に使えるオブジェクト指向って
あるかな？　なんか例あったらおしえて。

>237 小学校卒業したらまたおいで

>>231
まぁ、冷静に多角的にみなされと言いたいだけなんだけどね。
良い点があれば、必ず欠点もある。
その中で、賢いチョイスをするには冷静さと多角的視野が必要。

>>233
おまい、「玉に瑕」って言いたかっただけだろう？（笑

XPやagileってやっぱRADみたいなハヤリモノなんでしょうか？

ウォーターフォールも構造化プログラミングもかつてのハヤリモノ

今も昔も多分近未来も変わらないのが「ブレイクスルー」です♪
XPで試行錯誤方式が提案されてるけど所詮は形違いの「ブレイクスルー」です。
手法が如何であれ、「何をどんな目的で開発するのか？」を知らなければ如何しようもない。

それを踏まえた上の制限付きで各手法の特徴を生かして行使して欲しいね。

録音◆Rb.XJ8VXowも新しい攻撃方法を憶えてきたからな。。
最近、録音を攻撃すると
「それじゃ、録音と変わりないなw」とか
「録音なみだな、お前」とかいう反撃は
みんな録音の自演。自分の自演とばれないように
録音自身をバカにしたような論調で
実は録音がむかついたヤツを攻撃してる。
最初は別人かと思ったけど録音がいるところで必ず
同じパターンが続くんでわかってきた。

録音についてはここ
http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html

>>237

なんかちょっといってること違うかもだけど

俺もオブジェクト指向は計算系のアプリに弱そうなのが心配。
金銭関係の計算をするようなとこはデータも計算結果もとにかく
正しい数字が命なのだが、データをちゃんと決めない傾向があるような気がする。

うーん。
数年前に論文書いたけど、
懸賞にはかからんかったよ。。

ヴァカばっかりだな。

学術age

おいこら録音。
オブジェクト指向をなまくらとか言いながらなんで自分は
Cでだされた要求をC++でしか書けねーんだよ。

録音？

>>249
出張32氏の、自作PC板での御芳名です。

>>248
ん？
Ｃで書くのは簡単だ。
Ｃ++で書いたのは単なる意地悪って奴で遊び心だよ♪
まぁ、それで十分に遊べたから楽しかったけどな。

>>251
お前が無能なだけだろ。

>>252
君の書いたコードは全て出鱈目でコンパイルすら通らない紛いものだったばすだよな。
そして、私のコードに対しての疑惑も全て君の錯覚で正常稼動するコードであることが
証明されたはずだ。

それもこれも全ては君が無知だっただけのこと。（私のせいではない。

>>253
ハァ？ T.A.氏やL氏や有志諸氏が手直しして通したんだけど。

>>254
いいや、手直ししなくても通るよ♪

きゃつ等はＣ++であることを理解していなかっただけだぞ。

お前ら他所でやれ。

>>255
Ｃで出題されたのにＣ++で書いたら失格だろ。
お前の仕事振りが目に浮かぶよ無職。

>>257
シツコイやつだなぁ〜（笑
元々超低レベルな連中が超低レベルな設問をしただけのこと、そんなのにマトモに取り合う必要が何処にある？
多少は遊ばして貰わないとな（笑

それにしても面白かったなぁ〜。
無名共用体のこと誰も知らなかったとは・・・・・・
あれだけ大勢いても所詮烏合の衆ってところだろうな。
そしてその中でおいら君は、更に足を引っ張る未熟者ってことだしな。

>>258
遊んで良いとは誰も言ってないけど。
要はプログラムを真面目にしてないって事ね。

OOの本質的な欠陥は、
「難しすぎてほとんどのエンジニアが使えない」
ということです。
その点をわかっていないスーパーエンジニア、スーパーハカーの方々が多すぎる。

> OOの本質的な欠陥は、
> 「難しすぎてほとんどのエンジニアが使えない」

君が難しいと思い込んでるだけだ。
実際は凄く単純で単純が故に使えないってことなのだが・・・・

勿論、複雑でも使えないのは同じ。
論理的であると言う事は、整理されており解り易いと言う事と同義だぞ。
されど切り口がある為に、違う概念を要求されたら崩壊する危険を孕んでいる。
所詮は手法論でしかなくそれ以上でも以下でも無いってことだ。

その為、手順に沿った開発は楽であり部品の再利用率も高いのだが・・・
貧弱な分析で設計すると概念の読み違いで悲惨な状況となるだけのことだ。
目的を違えると何をやってもムダってことなんだよ。

真面目にプログラムしてないヤツに言われてもなぁー

ん？
低脳相手に真面目にプログラムする必要は無いと思うぞ！
（お仕事は別な♪）

仕事なんてしてないくせに。(ﾌﾟｹﾞﾗ

>>260
OO の本質的な問題ではなく、
業界の本質的な問題だろう。

…てか、いい加減出て行くか死ぬかしろ＞おいら＆出張

クソスレ上げ

オブジェ指向などと言ってた香具師の沙羅仕上げ

どうでもいいが、プログラムもろくに掻けず、
無名共用体などという苦し紛れるの言い訳をする
ペテン師出張が、なんでオブジェクト指向スレに粘着してるのか謎。

教養の無い人ほど、コンプレックス対象に粘着するのかなｗ

オブジェクティブ

> 無名共用体などという苦し紛れるの言い訳をする
言い訳ではなく、無名共用体なんだが・・・・（笑

しにたい

age

で、オブジェクト指向は実際どうなのよ

>>273
言語上のオブジェクト指向は複雑差を対処する事で効果を発揮するから、その複雑性の問題を理解せんと話にならんという根本的問題が存在する。

設計上のオブジェクト指向は構造化設計技法の補完でしか成り立たないから、構造化設計技法を先に習わないと話にならんという根本的問題が存在する。

分析上のオブジェクト指向は領域の限定と視点の固定化を大前提としなければ成り立たたず、卵が先か？鶏が先か？が当然の如く存在する現実社会を的確に分析出来る物では無い根本的問題が存在する。

思想上のオブジェクト指向は、現実世界とシステム理論を理解してない認識学派が騒ぎ過ぎる根本的問題が存在する。

って事で納得してくれる？

馬鹿発見。↑↑↑

なんでいまさらそんな子供だましをするかなぁ〜。

むしろ、あんたが言うべきなのは、こーゆ事でしょ。

1. 人間は、その生育歴や職歴に応じて、
　現実世界や仕事に対するメンタルモデルを内部的に持っている。
　このモデルは、言語的なものかもしれないし、数学的なモデルかもしれないし、
　はたまた頭の中でシミュレーションできる、現実と精緻に対応したモデルかもしれない。

2.他方、このメンタルモデルは十人十色で、必ずしも共通性・普遍性はない。

　もちろん、個々人の世界観を形作る基本部分や、あるいは人間の肉体的制約に起因する局所的モデルは、
　なんらかの普遍性を持っており、哲学〜心理学では共時性(シンクロニシティ)とか、(もっと良い呼び名もあったな)
　呼ばれているが、個々人の認識を、言葉などの外部表現を使わずに同じか違うか判定する方法はない。

3. それでは、人と人は、どうやって互いに理解しあうのか？
　サイエンス分野であれば、数学とか物理といった抽象性の高い記述(＋科学的方法論)で、モデルを記述する。
　事務屋さんであれば、モデルは違えども、「規則」や「手続き」を共通化すれば、とりあえず日々の仕事を難なく
　こなせる。(本当は数学屋さんの計算可能性の議論あたりが発端だろうと思うけどｗ)

4.そして、この事務屋さん流の「モデルの手続きによる外部化」が、オブジェクト指向の主要な敵である。

5. ケツ論：事務屋はオブジェクト指向使わなくても結構です
　

　結局、認識論で「俺の見てる赤はお前の見てる赤と同じかどうか分からない」とかいう陳腐なレトリック

　結局おまえさんの議論なんていっつも、
認識論で「俺の見てる赤はお前の見てる赤と同じかどうか分からない」とかいう陳腐なレトリックに終始してて、
議論を成立させるために必要な、客観性を持たせる努力 (例: スペクトルを図れば客観的だ、とか、いや個々人の目の色や視細胞分布で
を測定して補正すべきだ)がケツ落してるんじゃねぇ〜の。

「世の中わからない事ばかりだ」「オブジェクト指向では、決して真実には到達しない」なんて、いまさら(ぷぷぷ

>>276
お前、出張と勘違いしていないか？もし、そうなら相当失礼な行為だぞ！

因みに3番の前半まで同意。3番以降は同意出来ない。

完全事務屋以外はオブジェクト指向を勉強する価値あり。（必要までいわない）
ソフトウェア領域でのオブジェクト指向は特に意見しなくてもいいよね？
問題になるであろう業務領域に関しては、
情報系は実態の無い情報を取扱事だけで始終するから利用する価値あり。
しかし基幹系ではオブジェクト指向は合わない。

よって
>4.そして、この事務屋さん流の「モデルの手続きによる外部化」が、オブジェクト指向の主要な敵である。
の意見は事務屋が取リ扱うシステム業務を理解しているか非常に疑問。

hahaha 香ばしいな。
つまみ食いしてやろう。

＞しかし基幹系ではオブジェクト指向は合わない

基幹系ってナニ？
たしか、例の衛星電話プロジェクトは、世界最初の分散オブジェクト適用例じゃなかったっけｗ

も、もしかして、何億もレンタル料はらって、ﾃﾞｽｸﾄｯﾌﾟPCより性能の低い計算機使ってる事務システムの事？

＞事務屋が取リ扱うシステム業務を理解しているか

事務、つうか、お金計算がメインの金融, 会計, 商品管理なんつう分野は、
歴史が長いだけあって、馬鹿でもヤパン人でも仕事ができるように、
手作業レベルでバリバリに手続き分解が施されている。
そして、それを電算器化するには、やっぱグレースホッパーおばちゃんのCOBOLを使うのがお似合い。

ってな意味で、オブジェクト指向ににじり寄らなくていいよ＞＞事務屋さん

>>276
オブジェクト指向に詳しそうだから、もう一つ質問

業務領域の措いて
単一伝票の申請、照会はオブジェクト指向で対処出来るけど
インタフェースファイル、印刷物、照会一覧系はどう考えてます？

あれもオブジェクト指向で対処する物ですか？
尚、この話はソフトウェア領域の話じゃ無いよ。

マジレス希望。

ホレっ！アンチオブジェクト指向＝COBOLの聖母、バグの命名者でもある
グレース・マリー・ホッパーおねたまのお顔と伝記だよっ。喪前ら崇めろ！

http://www-etsi2.ugr.es/alumnos/mlii/imagenes/Univac%20y%20Grace%20Hopper.jpg
COBOL生誕40周年記念ページ：http://www.cobol.gr.jp/knowledge/report/report001/report001.html
伝記：　http://www.chienowa.co.jp/frame1/ijinden2/Grace_Hopper.html
参考文献：「コンピュータの英雄たち」

清楚なワンピース姿のMurrayおねたま(*´д｀*)ﾊｧﾊｧ

眼鏡っ娘萌え

オブジェクト指向世界を率いる、リチャード・ソゥリィー博士も、
ホッパー嬢の偉大な功績(COBOL)にあやかって
画期的な分散オブジェクト・システム(CORBA)を名付けた、
ともっぱらの噂

ズラ？

もし、Murray嬢が眼鏡をはずしたら、とっても美人だったらどうする？
もし、Murray嬢が水着を着たら、モンローも真っ青なプロポーションだったらどうする？
そして、そんな美人なMurray嬢が、「事務処理・・・楽にするために・・・COBOLって考えたの・・・使って・・・（ﾎﾞｿｯ」
とか、恥ずかしそうに顔真っ赤にして、消え入りそうな声で囁いたらどうする？！





漏れは、、、、





やっぱオブジェクト指向を選ぶな。
オブジェクト指向技術者に生まれてよかった、あーよかった
＃本当はオブジェクト指向大っ嫌いだけどｗ

>>280
＞オブジェクト指向に詳しそうだから、もう一つ質問

お世辞はたくさん。
オブジェクト指向に詳しいっつう香具師は、あんま信用おけない。

＞単一伝票の申請、照会はオブジェクト指向で対処出来るけど
＞インタフェースファイル、印刷物、照会一覧系はどう考えてます？

まず、前者と後者を分けて考える、あなたの観点が理解できない。
照会一覧・・・collectionからの選択でしょ。別にオブジェクト指向でなくても表現できる。
　　　　　　　　つうか、照会一覧も、単一伝票も、同じ観点で扱うべきか、と。
印刷物・・・・・MVC流に、モデルの異なるView表現、とでもしておきますか。
インターフェースファイル・・・事務用語、さぱーりわかりまっすぇん




＞業務領域の措いて

ｗ

× モデルの異なるView表現
○ 同一モデルの、異なるView表現

なんでオブ房は図星な指摘をされると何時も話をはぐらかすの？

ドメイン領域内の話じゃないと整合性が取れないから
ドメイン領域外の話は出来ないんだよ。

＞ドメイン領域内じゃないと整合性取れないから、ドメイン領域外の話はできない


宇宙人と話ししてるみたい。あなたのその考えの根拠はナニ？

>>281

とにふぇぶみたいでかわいい♥

リチャード総理博士のご尊顔

　http://images.google.com/images?q=Richard%20Soley&num=50&hl=ja&lr=lang_ja&sa=N&tab=wi

ｳﾎｯ(ry

そもそも、それほど難しい概念ではないのだが、
日本のPG,SEは文系ばっかで抽象的志向が苦手なアホばっかだからな。
普通は一所懸命語るほどの概念でもない。

大学受験で一応数学やってた国立出身者の中には飲み込み早い人もいるけど、
私立文系の人とか最悪

総理博士は、1990年代前半、百花繚乱状態にあったオブジェクト指向世界で、
忍耐深い努力で一定の方向付けをした、つう意味で尊敬に値する。

オブジェクト指向って、
厳密性に欠けるモデルを、成り行き任せで分析設計する所が、大っ嫌い。

決して到達できない彼岸かもしれないが、
ちゃんと普遍的モデル(共通参照モデル)を導くための戦略とか方法論を考えろ、って漢字。

>>287
それ思いっきりソフトウェア・ドメインの話じゃん（劇藁

揚げ足鶏はいかんな、揚げ足鶏は。

きちんと物事を定義して前向きに議論する事を避けて、
他人の揚げ足を取る事に終始するきみの姿勢は、痛いよ

>>297
やっぱ>>296の中身は出張と同等っぽいね

問題定義をきちんとせず、禅問答を繰り広げる >>280 が悪い。
まず>>280は、何故そのような疑問を持ったのか説明する義務がある。
問題を共有せず、揚げ足鶏をするのは、餓鬼だよ。
(ど〜せ >>296は>>280本人じゃないとか言い出すんだろうが)

そ〜いえば、オブジェクト指向の老舗出身の某自称コンサルも、
蒟蒻問答で煙に巻くのがお得意だったな。

＞ドメイン領域内の話じゃないと整合性が取れないから
＞ドメイン領域外の話は出来ないんだよ。

某オブジェクト指向老舗の偽コンサルなみに、逝ってる事が狭くて痛いな。

ふつ〜、最初に定義したドメイン領域で仕事を進めて、
うまくいかなければ、充分な検討の上でドメイン領域の修正や追加を行なうでしょ。
ドメイン領域を修正・追加する事で、最初のドメインに含まれていない問題を
扱う事ができる。

帰納的な問題解決手法を知ってれば、クリアできるんだけどねぇ〜。
よく意味が分からなければ、例えば科学史を勉強してみる事をお勧めする。

　　　　　　　　　　　　　　　　　　　　　　　　匿名掲示板で訳のわかんない抽象質問をする香具師(>>280)はチキン

インターフェース・ファイルって、もしかして印刷物と並べてる所を見ると、ユーザー・インターフェースの事を指してる？

ロバストネス分析で Boundary-Control-Entity (BCEパターン)に当てはめるなら、Boundary、つまり外部システムや人間とのインターフェースの事だな。
対話的ソフトウェアやサービス提供ソフトウェアの基本要素だから、ソフトウェア・ドメイン的捕らえ方をするのが、基本ちゃー基本。

で、次に、業務領域での解釈をしたいって？！
人手もしくはソフトウェアの絡んだ業務ワークフローがあって、そのタスクの１ステップのI/Oが、画面や印刷物ってだけだろ。どう業務領域の解釈をしたいのか、サパーリだなぁ(藁

>>302
宛なのかどうか分からんが…

現実社会だと、バインダーに閉じたり、文章を書物にしてる。
実はこの手法、既にオブジェクト指向とは少し違った概念。

売上と言う概念を売上明細書と言う抽象化を行ってるんだよね。
だから、オブジェクト指向と業務系は相性が悪いと強烈に感じる人
がいると思う。

売上→（抽象化）→売上明細書→（抽象化）→売上明細ファイル。

一方オブジェクト指向の場合の自然な流れは、
売上→（抽象化）→売上オブジェクト

現実世界で、既にオブジェクト指向によらない抽象化が行われているので、
これを無視出来ないため、売上明細オブジェクトが必要になり…
てなところが業務系でオブジェクト指向を適用するときに混乱する原因なんだと思う。
既に抽象化されてる売上明細書を、オブジェクト指向で最抽象化しなきゃならない
この事に違和感もつ人の方が本物だと思うが、違和感持つだけで、考えないのは
馬鹿だね。

俺って頭いいから、上手くまとめたと思う。

>>303
じゃあ、売上明細オブジェクトを登場させないで、
「売上」を分析してみせてよ。

from >>297 to >>301
朝っぱら連続の自作自演投稿乙！暇だなｗ

>>296で突っ込まれて必死だなｗ自分から吹っ掛けてドツボに嵌っている所がかわいいよね。

でも指摘の仕方を見ると、どっかのサイトに載っている「議論の仕方」は勉強しているみたいだね。

じゃー頑張って勉強してね。ばい、ばーいｗ

↑相変わらず、宇宙人みたいな意味不明の発言(剥藁

>>304
やって出来ないこと無いけど、無駄だよ。
「売上」とは何ぞや、色んな形の取引を見て、検討して、
帰納的に分析して見出され、社会的に合意されてる
「売上」を今更分解するのは、無意味であるよ。

"某オブジェクト指向老舗の偽コンサル"って．．．誰？

>>307
だから〜
そもそも「売上」って概念自体が、コンポジットな
事象をひとつの概念に化体させたものであって、
分解をむきになって否定すること自体ナンセンスじゃん

┌───┐　　　┌─────┐
│Order │◆−−│OrderLine │
└─┬─┘　　　└┬────┘
┌─┴─┐　　　┌┴─┐　　
│Custm │　　　│Item│
└───┘　　　└──┘
　　　　　or
┌───┐　　　　　┌──┐
│Order │−−−−−│Item│
└─┬─┘　　Ｕ　　└──┘
┌─┴─┐　┌┴────┐　　
│Custm │　│OrderLine │
└───┘　└─────┘

私だけ...

オブジェクトって言うのに行為は主観的に感じる。

私だけ...

業務は、表裏一体の世界を扱うのに
なぜかオブジェクト指向の例題で売上の話になった時、債権の話が何時もない。

私だけ...

売上た商品は既にお客様の物なのに、そのオブジェクトが自社システムにはまだ存在している。

> なぜかオブジェクト指向の例題で売上の話になった時、債権の話が何時もない。
売上は商品の引渡しと対価の受領がペアになったコンポジットな事象であるのが基本。
例えば、自動販売機での販売は、即時に取引が完結する。
債権・債務が発生するのは、売買契約に基づいて、商品もしくは対価に
関して発生する。
結局、関心のスコープによって債権も含めるかどうか変わってくる。
在庫に対する引き落しや、受注残の扱いも同様。

JAVAとC#でプログラミングした事あるけど、
オブジェクト指向という概念については、
クラス、インスタンス、継承、インタフェース、ポリモルフィズム、
オーバライド、オーバロード、カプセル化、メッセージパッシング
などの基礎概念しか分からんorz

>>279

278のように
>>「完全事務屋」以外はオブジェクト指向を勉強する価値あり。（必要までいわない）
>>ソフトウェア領域でのオブジェクト指向は特に意見しなくてもいいよね？
>>問題になるであろう「業務」領域に関しては、
>>「情報系」は実態の無い情報を取扱事だけで始終するから利用する価値あり。
と関連情報を出した上で「基幹系」という言葉を使うのは問題ない。

278をけなしつつ、278と同じ
「事務処理にはオブジェクト指向はあわない」
ということを言っている。

物判りの悪い椰子だなぁ。
じゃ、もっと露骨に言うね。

事務処理をシステム化対象とするシステム屋は、
オブジェクト指向ににじり寄らなくていいよ。
似非オブジェクト指向屋が世の中を惑わすだけで、
百害あって一理なし。

事務システム屋にはCOBOLがお似合いｗ

アーキテクトを目指すんでなければ、オブジェクト指向なんてわからんでもいいかもねぇ。
業務屋はそれ以前に業務のことをちゃんと覚えないといかんな

>>309
そのレベルは抽象化の再抽象化ですよ。
売上とは何ぞやと考えたときに、小売店のように商品の授受と
現金の授受が一時に終わるパターンを、様々な商取引形態に
演繹かのうか考え、帰納的に問題ないので、売上と言う概念が
成立してる。

が為に、継続的商取引の場合、売掛金という概念を創設しなければ
ならなかったのだが、その事を無批判に信じてる君の馬鹿さ加減を
見ると馬鹿って幸せだなと何時も思う。

ここまでの分析を踏まえた上で、あえて世間の常識を壊す必要なし、
と会得するのが、本物です。

>>315
それは大間違い、オブジェクト指向程度の事なら使いこなせなきゃね。
アーキテクトじゃなくて、ただの事務屋さんになっちゃう。
人様から高い金貰ってたら、詐欺師だよ。

北に生きた横田さんがいるとする。
返さないのはなぜか？政府のまずい情報を知っているからであろう。
であれば「返さないと経済制裁するぞ」と言っても返さないのは
初めから分かりきっている。
本当に横田さんを取り戻したいなら、国交樹立して、日本人が現地で動くべきだ。
簡単には探させないだろうが、北の政府に任せているよりずっといい。

「そんなことは筋の通らないことだから、北には強硬にすべきだ」という？
「筋」のために横田さんと、横田さんの娘の命が危険にさらされてもいいのか。
それなら拉致被害者のために北に怒っているのではなく、
北に怒るために拉致被害者の件をあてはめているだけだ。
ただただ、「強硬にしたい」だけ。
その果てに必ず来る戦争をなぜそんなに希求する？
感情で動くな。

北をもし武力で制圧できたとして、その後は？
韓国中国はどう動く？日本がまたアジアの国を武力で制圧したという恐怖。
武力で制圧する渦中で日本人も死ぬだろう。
アメリカとアジア諸国を巻き込んだ第三次世界大戦を、そんなに始めたいのか？

感情を捨て北と国交を結んでしまうのだ。
そして武力ではなく経済力で内側からキム政権を倒し、横田さん親子、
その他拉致被害者を助け出せ。

>>311
それはおかしいね.その意見ならばDAOつまり昔からの手法の方が適している.

売上明細は「売上行為」という事象を抽象的に記録した物であり,業務系システムに措いて伝票による事象の記録行為は一つのパターン手法であると考えた方がスマートだ.

例えば,貴方が云うように「売上」だけに焦点を充てて考えるならば,別途,「請求」だけに焦点を充てて分析する必要があるが.この際に現金売上と掛売上が混在する状態を上手く言表わせず,別途事後調整が必要となる.
実務者ならば解るだろうが売上と請求は非常に強い関連を持つ為に最初から分離して扱うのは間違いだ.

それより売上と債権を同時に考え,売上発生時は債権が同時に発生し現金取引の場合は,その債権が即座に相殺する方がパターン化され易くオブジェクト指向だといえるだろう.

また債権を契約によって締めた場合,債権は変更不可の状態になる.この時に対となる売上を変更しようとすると同時変更する必要のある請求が変更できないため,売上自体も変更出来ない制約を受ける.

これが締制約に対する概念,
と考えるのが筋ではないか？ちょっとした状況の違いを大きく取扱うのは如何なモノか.

最後まで説明してはやりたいが, 正直面倒だからココまで.
このつづきを考えるとオブジェクト指向で業務分析するのは事の本質を理解する為に手助けにはなるが,
設計可能な状態に落とし込む場合は, 不十分であり逆にDAOの素晴らしさが理解出来る.

そうだな,一手法だけで分析行為をやろうとする事が間違いだと気付かなければ作業意義を見失っていると言えるだろう.

DAO、DAOって何だお？
コレが噂の出張32流ボケっすか。
つっこむのが面倒そうだなぁ

>>319-320
> 例えば,貴方が云うように「売上」だけに焦点を充てて考えるならば,別途,「請求」だけに焦点を充てて分析する必要があるが.この際に現金売上と掛売上が混在する状態を上手く言表わせず,別途事後調整が必要となる.
>実務者ならば解るだろうが売上と請求は非常に強い関連を持つ為に最初から分離して扱うのは間違いだ.
残念でした。
請求は債権に基づく債務者への履行の「請求」。
従って、売上そのものというよりは、債権から導出される事象。
しかも、売上とは分離された現象として、一部請求など、請求特有の要求も発生する。

貴方は、請求だけにこだわるようだが、こういった難しさは、受注残、納品、返品等においても発生する。
多少、業務経験がありそうだから、説明は不要でしょう。

>それより売上と債権を同時に考え,売上発生時は債権が同時に発生し現金取引の場合は,その債権が即座に相殺する方がパターン化され易くオブジェクト指向だといえるだろう.
物と対価を同時に「交換」せず、信用によって解決するのが「債権」。
売上が発生したからと言って、無理に債権を発生させる必要はないでしょう。

>このつづきを考えるとオブジェクト指向で業務分析するのは事の本質を理解する為に手助けにはなるが,
>設計可能な状態に落とし込む場合は, 不十分であり逆にDAOの素晴らしさが理解出来る.
オブジェクト指向というよりも、単に業務知識として議論しただけだが。

>そうだな,一手法だけで分析行為をやろうとする事が間違いだと気付かなければ作業意義を見失っていると言えるだろう.
そのとおり。
ＤＯＡによってデータ構造やデータ導出によってシンプルに分析する「手法」の素晴らしさ、
一方、オブジェクト指向の手法を用いて動的な分析や責務の配分も検討する「手法」の良さ。
両方、きちんと使い分け、メリットを享受できることが重要でしょう。

「ＤＡＯ」と間違える程度の初心者さんが、ちゃんと実践できているかは不安ですが．．．．

>>322
ごめん.
誤：ＤＡＯ→正：ＤＯＡだ.
後, 初段で突っ込まれている売上「業務」と請求「業務」は,「」が抜けていた.

あなたの仰る意見は理解出来るが,それは議題の掏り変えであり
「業務知識として議論しただけ」と仰っている様にそれではかみ合わない.

逆に業務知識を話ただけ. という事が>>311の文書でこちらが認識出来なかった訳だ.

DAO、DAOって何だお？
コレが噂の出張32流ボケっすか。
つっこむのが面倒そうだなぁ

>>324
DOAで分析してるけど、DAOのバージョン食い違いに苦労してる人なら、
言い間違っても不思議は無いと思うよ。

教科書的に知識蓄えてる人から見ればこの言い間違いは致命的に見えるだろう
けど、実務的に知識得てる人から見れば、「ありがち（ｗ」と感じる。

そのような話者の背景的知識を行間から読める力が付くと、
出張とこの>>319の違いが理解できると思う。

なにもかも密結合させるから話がややこしいのでは。
売上
債権
とかだけいっていると
じゃぁ、有償支給しての外注受入、債務計上どうすんじゃと延々とひろがっていく。

ただでさえ、キーとなるオブジェクトが巨大化して、プロジェクトでの要員山崩しが
面倒なのに。

粒度の適切な使いやすいオブジェクトじゃないとメンテナンスも大変。

>>325
単なる不思議ちゃんじゃん、こやつｗ

>>326
いくら頭悪い事務系業務屋でも、経理・会計上の概念を関連でモデル化し、そこに業務ルールを割り当てていくことくらいできるだろう。
そんなこともできずに、要因が、メンテが、とか言いだすこいつは、
たんなる人材手配師、なんちゃってSEでしかないんだろうなぁ。カワイソ

>>327
SI業界の下層階級には、馬鹿しか居ないからしょうがないよ

>>327
不思議ちゃんとかいうな。ぶー
＞いくら頭悪い事務系業務屋でも、経理・会計上の概念を関連でモデル化し、
＞そこに業務ルールを割り当てていくことくらいできるだろう。

そこを踏まえないでオブジェクト指向なんちゃらと言う本を読むと混乱して
しまうのです。騙されて引っ張られて苦労して無い人を見たことが有りません。

元帳とおり記帳して、数字つくりたいだけだなのに、
端数も縦横合わせられないソフトおおすぎ。
IT的ごたく並べる前に、串刺しでびしっと検証できる会計帳票だせる
かしこなパッケージつくれや。

「これが仕様です」は聞飽きたぞ、おめーら。

業務をパッケージに合わせろ、という前にいいから原価計算の「数字あわせろ」。

>>329
オブジェクト指向に文句言う前に、もうちょっと日本語勉強しなよ。

確かにオブジェクト指向に文句を云うのは間違いだが
教育技術や議論知識の不備は無視出来ない状況にある。

>>332
>教育技術や議論知識の不備は無視出来ない状況にある。
それはＤＯＡやＳＡ／ＳＤのほうが惨いだろう。

オブジェクト指向？
一言で言うなら、こうじゃないか。
例えば、C++の中にミドルウェアがあるようなもの。
ミドルが無きゃぁ、１からカスタマイズするのはタマッタもんじゃないようなものに役立つ。
ただし、ほんとにその関数・コンポーネントを理解しようとするなら、C++の底の部分を知っていかないといけない。
だから、逆に言うと、ある意味変則的なものの場合というか、バッチリその関数・コンポーネントの凡例にはまったものじゃないと使うのは危険で、罠がたくさん仕掛かっていて、使い方を誤ると深みにはまることままあり。
今後も継続するなら、非オブジェクト指向、オブジェクト指向、両面で作っていくのが安定攻法。

>>334
あいかわず不思議なやつだね．．．

自分で説明しながら、混乱していく．．．．

>例えば、C++の中にミドルウェアがあるようなもの。
>ミドルが無きゃぁ、１からカスタマイズするのはタマッタもんじゃないようなものに役立つ。
>ただし、ほんとにその関数・コンポーネントを理解しようとするなら、C++の底の部分を知っていかないといけない。
それは、非オブジェクト指向言語でも一緒でしょ。

>今後も継続するなら、非オブジェクト指向、オブジェクト指向、両面で作っていくのが安定攻法。
一番怖いのは、両方を中途半端に聞きかじって実戦で使うこと。
「生兵法は怪我のもと」

＞３３５
オブジェクト指向は、言語という認識はないな。
自分の認識だと、ほとんど、雛形だよ。
その雛形からはずした使い方すると、非常に怖い。
雛形に乗ってしまえば、楽に行ける。
オブジェクト指向を深く理解しようとする時は、時間が許すなら、
まず凡例の使い方をして、そこから色々変えて見て、特徴を掴むよ自分は。

>336
> オブジェクト指向は、言語という認識はないな。
例えになっていないということさ。

> オブジェクト指向を深く理解しようとする時は、時間が許すなら、
>まず凡例の使い方をして、そこから色々変えて見て、特徴を掴むよ自分は。
だから〜ぁ
その「思い込みの激しさ」が怖いんだってば！

まあ、どっかの他人様だからいいんだけどね。

>>335
＞それは、非オブジェクト指向言語でも一緒でしょ。

例えば、通常のＣの底を考えるのと、ＶＣの底を考えるのとは、訳が違うんじゃないのかと思うよ、自分は。
最単純な話で、ＭＳのウィンドウ初期化・生成関数にしたって、その関数の裏に何があるかなんて、考えたこともないし、おそらく自分じゃ考えても分からない。
ウィンドウをＣでカスタマイズしようなんてしたら、考えただけでも怖いから(まず自分じゃできない)、それだけの複雑なものが裏に流れているだろうし。
だから、雛形として認識している。いくつかレパートリーを持てば、特徴が分かってきて、また、その使い方の範囲を超えないようにする。
それ以上深くを追求するなら、それこそ、WinOSを解剖するって話になってくるんじゃないのかい。

システムなんて動けばいいんだ。
オブジェクト指向なんて考えたことがない。
それでもうまく動いている。
難しい事は考えない。
それが一番。

＞３３９
探究心が旺盛なのも分かる。

＞一番怖いのは、両方を中途半端に聞きかじって実戦で使うこと。
＞「生兵法は怪我のもと」

のとおり、雛形だけの表面上だけ分かって使うのも、非常に危険だってのも分かる。
だから、凡例を超えないように工夫して使う。
逆に使わなかったとしたら･･･､
ＤＡＯの話が出てたけど、表計算にしろＤＢにしろ、セル同士の複雑な関係があるし、それを非オブジェクト指向でカスタマイズなんて、自分じゃまず無理。
だから、ＤＡＯの恩恵に乗る。
嫌っていたらできない。使ってみることが大事だと思う。
そして、君の言うようにできたから、分かったと思わないことだとも思う。
その使い方の外には、断崖絶壁があると思って用心して使うべきだとも思う。

>>338
>例えば、通常のＣの底を考えるのと、ＶＣの底を考えるのとは、訳が違うんじゃないのかと思うよ、自分は。
>最単純な話で、ＭＳのウィンドウ初期化・生成関数にしたって、その関数の裏に何があるかなんて、考えたこともないし、おそらく自分じゃ考えても分からない。
単に、Win32APIをラッピングしているだけなのだが。
そんなに君の妄想のように小難しい話ではない。
#VC++できちんとコーディングした経験があるの？？？？？

>>339
> システムなんて動けばいいんだ。
わかった。
君の言うことは否定しない。
但し、君は技術者ではない。

>>340
頼むから、「データ中心アプローチ」のことを意味しているなら
「ＤＯＡ」とちゃんと書いてくれ。

しつこいようだが、データ中心アプローチをきちんと使っている
人だったら、少なくともそんな間違いはしない筈だ。

で、皆さんは、以下のタイプの中のどれに該当するのか
自己申告してみてください。

１：ＯＯＡ／ＯＯＤとＤＯＡを両方ともきちんとわかっていて
　　実戦で使いこなせる人
２：ＯＯＡ／ＯＯＤもしくはＤＯＡのどちらかをきちんとわか
　　っていて、自分の担当エリア内の仕事を実戦でこなせる人
３：ＯＯＡ／ＯＯＤおよびＤＯＡをどちらも生半可にしか理解
　　していないが、野生の勘で生き残れる人
４：ＯＯＡ／ＯＯＤないしＤＯＡを知識上は理解しているが
　　実戦では通用しない人
５：ＯＯＡ／ＯＯＤもＤＯＡも生半可にしか理解しておらず
　　実戦でも通用しない人

＞３４１
Win32APIラッピング？
wc.とCreatewindowに読み替えて。
なんか、話すのもおこがましいような例出しちゃったけど･･･

>>345
Createwindowにしろ、MFCでのCWnd::Createにしろ、ウィンドウの
生成は環境側でおこなっているだけであって．．．
まさか、VC++の関数内ですべての処理をやっているなんて思って
いるんじゃないでしょね。

＞３４６
まさか。
WC構造体にしろ、Createwindowにしろ値を入れてやってるだけ。
＞３３８の
＞最単純な話で、ＭＳのウィンドウ初期化・生成関数にしたって、その関数の裏に何があるかなんて、考えたこともないし、おそらく自分じゃ考えても分からない。

は、WCやCreatewindowにしろ、その言っている裏での処理がどうなっているかは自分は分からない、という意味。
それこそ、WinOSを解剖する羽目になるんじゃないかなと言う意味。
実際、そこまで考えたことは無い。
だから、書き方は千差万別でも、使い方は外れないように誰でもする。
千差万別といっても、幾つか書き方を変えてみれば、特徴が分かって来るし、注意すべき点も分かって来るし、初歩の初歩の話になってしまったけど。

たぶん、こう言えば良かったんだ･･･｡
APIが実際裏でどんな処理してるか考えるのは、自分にはとてつもなく大変。
だから、雛形として使う。
そして、できるだけ理解する為に、色々書き方を変えて、特徴や注意すべき点を見つける。
こんな初歩的な話で･･･、あぁなんと話をまとめられないとは･･･

>>348
乙．．．．

ただ、画面再表示関連は気をつけないと、
ほとんど、ハングアップしてんじゃないかってくらい、処理がノロくなるからなぁ
ただ、文字を移動させる程度のグラフィックでも

マ板と勘違いしたのは俺だけだろうか．．

しかも、一度脱線するとなかなか元の話に戻らないし．．．

否定論でも、肯定論でもいいから、もう少しまともな議論して欲しいよ。

ふっ。プログラミングしている奴ら。終わってるな。

得意分野がプログラミングでも設計でも良いけれど
せめて日本語だけは不自由なく使って欲しい

ActiveX使わなきゃならなかったりする場合とか、しようがないけど、
オブジェクト指向(特にMFC)は使わなくても良いなら使いたくないな。
それでも充分な場合が結構ある。
使うとツリー構造でがんじがらめで、融通が利かない。

アナリスト、デザイナー、プログラマと
理解するべきレベルが変わってくるもんじゃないか？

データベースの設計がちゃんと出来る人の方が、
OOもしっかり理解できる気がするよ。

言語としてはUMLに従ってくれ。
オブジェクト指向の概念をわりと正確に定義してくれるからさ。

DAOとADOが混ざってるならまだしも、
DOAとDAOを間違えるなんて言語道断だろ。

昔から言葉尻を捉えて優位に立つ様な低レベル手法を好んで用いる奴は、
他の発言自体も程度が低いよな。まぁ子供の意見だからしかたがねぇけど。
子供は大人の話に割り込んだら駄目だと躾をして欲しいモンだね。

>>348
そんなあんたにオープンソース＆Linux
オープンソースの意義は、ＡＰＩの裏を読めないプログラマに、
ＡＰＩの裏側動作を意識させる機会を与える事にあるんだよ。。。

>>355
クラス継承の使い過ぎは、よくない設計になる。
インターフェース継承で、型を継承して、委譲で実装の使いまわしをするのが正解(90年代半ばの常識)

＞クラス継承の使い過ぎは、よくない設計になる。
＞インターフェース継承で、型を継承して、委譲で実装の使いまわしをするのが正解(90年代半ばの常識)
それとこれと（MFC）は別問題。

既に指摘されてる方もいるが、MFCはAPIをラッピングしただけの物なんで、
継承に向かない、売上とかでも述べたように、APIの設計時点で一度構造化とか、
再使用という、文脈での仮想化が行われてる。

入力用グラフィック画面のオブジェクト設計、で考えるならば、
IBM系のライブラリは秀逸なので、JAVA等、IBM系のライブラリに
触れる機会が有れば、それを見てみるといいぞ。

たしか富士通でオブジェクト指向でプロジェクトが成功しているところ
ないと聞いたが２年前今もそうか？

>>360
富士通か。さもありなん。

>入力用グラフィック画面のオブジェクト設計、で考えるならば、
>IBM系のライブラリは秀逸なので、JAVA等、IBM系のライブラリに
>触れる機会が有れば、それを見てみるといいぞ。
SWTは糞ですが．．．

>>360

ん？1997年には、俺がJ2EEの先走りやって、
一応プロジェクト成功させたけど、何か？

現場で土方仕事やってる連中の話は、寡聞にして聴いたこともない。(聴きたくもない

あと、このスレに巣食ってる連中って、
以前フレームワーク・スレに居た連中より更に一段程度の低い、

・未だにGUI画面のオブジェクト指向でヒィヒィいっちゃう様なド素人
・MFCの上にいきなり業務アプリ構築始めちゃうような、フレームワーク素人

が多いように見受けられる。

不毛なんだよな、今更そんな連中にオブジェクト指向の話されてもｗ

>>363
んっ？
Ｆの糞ＯＲＢか？
あんなもの恥ずかしくて「成功した」なんてよく言えるな．．

>>364
なんじゃそりゃ？
AWTやSwingのイベントモデルくらいでヒィヒィいうような
ヤツってそんなにいないんじゃない？
（あなた自身のことですか？）

ちなみに、富士通のオブジェクト指向ってなんであんなに惨いんだろう．．
ComponentAAのコンポーネント部品なんて、オブジェクト指向設計
とは程遠い勘違い設計だったね．．．

あれから進化しているとは思えない

>>322
アナパタに、会計向け分析パターンの章があったけど、
そこでも読んでみてはいかが？

あと、アナパタは国際会計基準(つか米国会計慣習)に則ったモデリングをしてるんで、
なんか違和感あると思うんで、会計周りのデータベースモデリングの本とかも参考になると思う。


ところで最近ちょっと会計分野をおっかけたら、ここ５年ほどの国内会計分野の混乱っぷりを知って、すげぇ笑った。
５年前の国内の会計監査なんて、国際基準で見たら、粉飾決算もいいとこのデタラメ会計だったのね。

あと、ここ20年程の国内の公債と株式市場の平均値も、結構笑える。
国内株式って、国債よりもリスクが高いのに、国債よりも平均利率が低い、
つうゴミくず市場だったのね、ここ20年を平均して見ると。

日本って経済大国とか勘違いしている人多いけど、自由市場経済後進国だったんだよね、実は。

>>365
ん？うちは、富士通本体じゃないから、富士通の糞ミドルは使わなかったよ。
むしろ、国内某研究所のミドルを使ったっけ、最初は。

駄目な奴って、人の駄目な所を見て安心しようとするから、進歩がないんだねぇ。
キミらの見てる、駄目な所って、８年前の基準でも駄目駄目な所だと思うから、
視野に入れないほうがいいんじゃないかなｗ

>>366
能力が屑な人が、自身を安心させるために自己暗示を掛けているのを見ると、
なんだか可愛そうな感じがする。
きみ、小学生か？

>>368
「勘定パターン」か？
だからどうしたっていうんだ。
あくまでも、322での話はトランザクションレベルであって
仕訳以降（エントリーと勘定）には分解していないでしょ。

なんでもいいけど、あいかわらず不思議ちゃんだね．．．

>>369
あっそ！
富士通の下請なわけね

>>367
唯一、話が合いそうなポイントだね。
某Fの生産性向上だかの組織には、
訳もわからずパターン、パターンとか言い出す痛い連中が居て、
通常行うべきまっとうな努力
・ドメイン・オブジェクトの抽出やら、
・リファレンス・モデルの抽出やら
をサボったまま、
なんかありものの業務システムのソースかっさらってきて、
それを体裁整えて「コンポーネント」と称していたような気配がある。

更に論外なのは、その手の痛いコンポーネントを提供するから、
香吸う10％裂く弦しる！つう号令を掛けた所。痛すぎて、もう見てらんないっつの。

>>373
だってあの薮田さんが．．．．

>>372
ん？下請け？
なんか、２０％くらい居る土方部隊の人たちは、下請け仕事してたらしいよ。
漏れとか、上流の人間は、一次受託とか。
つか、研究科にはF推薦なんてなかったし、
ましてや最初っからF系列に来るつもりなんて全然なかったから、
Fの研究所は訪問してないっす。他の研究所はいろいろ回って、適当に辞退しちまったけどｗ

>>371
で、キミは何をしたいの？
「不思議ちゃん」命名者は漏れなわけだが、
人を「不思議ちゃん」呼ばわりすれば、何言ってもいいわけじゃないよ。
人に因縁つけるなら、人を納得させる説明をしたまえ。

>>368

ちょっと先に民営化が予定されている、
貯金残高世界一の某飛脚省庁が、
つい最近まで「企業会計原則」を無視してた、
つう事実も、すげぇ笑える。

腐ってるのは社会保険庁だけじゃない。
政府機関による財政投融資全般について、
「公的利益創出」という観点に基づく会計的評価が不十分である、
というのが専門家の見方らしい。

そこでバランスド・スコア・カードのオブジェクト指向モデリングですよ。。。




ERPは見なかった事にして（爆！)

>>368,376
まあ、おちつけ。
オブジェクト指向の話をしに来たんじゃないのか？？

いまのぉ、オブジェクト指向の流行はぁ、

1. 顧客に、エンタープライズ・アーキテクチャーに基づくIT戦略進めて、

2. システム設計は、SOA(サービス指向アーキテクチャ)使って、

3. 実装アーキテクチャは、MDAでモデルから業務アプリを自動生成

4. あと、ワークフローエンジン(BPEL44WS)と、ルールエンジン(RuleML)の適用も研究中！

とかぁ〜☆

企業システム・オントロジーの実用化研究が、某所で地味ぃ〜に進行する予定もあるﾓﾅｰ

>>379
あっそ

>>380
Lyeeのことか？

>>375
了解、悪かったあやまるよ。

ところで、最近は何をやっているの？

>>379
ついでにぃ、
一階述語論理〜様相論理の応用である某分野で新規ビジネス開拓中！
とか付けると、カッチョイィ〜かもね

>>383
　>>379, >>384 (主に後半メイン)

趣味で形式仕様記述によるハードウェア設計とかﾍﾞﾝｷｮする予定もあるけど
２年位足踏み中。(昨年はLSI製作までいけそうだったんだが)
多分 >>384近辺に合流しちまう予定 (ホントかよｗ)

>>385
がんがってください

オブジェクト指向の問題点は、静的な状態を強く求める事だと思う。

例えば時間的の経過や周囲の状況変化の発生があっても
オブジェクトの外郭を守らねばならん。
これが結果的にオブジェクトがオブジェクトとして存在しえる為に
静的な状態を強く求めてしまう本末転倒な状況に陥る。

って思っている私は、まだまだ未熟ですか？

同じような問題意識を、５年ほど前に持った覚えがある。(圏論やってた新卒社員と顔合わせてた頃の話)

で、(圏論全然関係ないけど)三種類の答えがある、と認識している。

1. Stateパターンで、状態遷移を離散的に表す方法
　例えば、TCP/IPソケットの接続状態 (細かい説明略. man socketとかしてくれ)

2. Decorationパターン(でよかったっけ？)で、
　　時間遷移に伴うデータ構造変化を表現する方法

3. Prototypeベースのオブジェクト指向言語で、
　 オブジェクトの形を序々に変えていき、
　 出世魚みたく、所属クラスを変更していく方法。
　 多分、上記1と2を併用する形になると思う。

つうわけで、ふつーのオブジェクト指向言語でも
「時間変化に伴う動的なオブジェクト変化」を扱えるわけですが、いかがですか。
あと、時間軸を連続的に動かす必要もありますか？(Adobe XMP絡みで、似たことをおっしゃる方が銀座伊方面に居る)
実用的な範囲内では、
1. コンテンツ管理システムや、バージョン管理システムに使われるような、
　 離散的な状態変化
2. マルチメディア(音声や動画)で使われる、ミリ秒オーダの状態変化
3. ネットワーク資源のような、巨大かつ、スナップショットの取得すら難しい資源の、
　 擬似的な把握 (Googleキャッシュ)
みたいな範囲を押さえれば、十分だと思うけど。

SRA先端研究所の教祖様だと、もっとすごい事を考えていそう・・・

SmallTalkのように、型に対して柔軟であれば、そうでもないのでは？

>>389
1.と3.はいい感じ。

2（Decorator）は振る舞いの動的変更と合成であってデータ構造の変化が
目的じゃないれす

>>374
えぇ〜っとぉ、
某所では随分評判悪かったよ。
連中と付き合いたくないから、ウチはJ2EEやらない！って。(爆

>>380
芯で頂いて結構です。

>>391
Factoryとか合わせ技で使うと、
Compositで擬似的なクラス構造ができる罠。

>>390
相撲留遠くの綴りは Smalltalk。なんでTを大文字にすんの？って何回指摘したら気が済むの？
そーゆー物覚えの悪い子には、教祖様のSmalltalk勉強会資料のURLはっつけるぞ。

あと、寡聞にして Smalltalkが「型に対して柔軟」という説を意識した事も聞いたこともございません。
解説して下さい。
・もしかして、Smalltalkはかつてバイトインタープリターで動いてたから、ほぼ動的にクラス定義ができるっつ事？
・あるいは、Prototypeベースオブジェクト指向言語Self (Smalltalk方言)の事とは違うよね？

>>393
まあ、それならすなおにCompositeパターン使えば
いいとおもわれ

>>393
> あと、寡聞にして Smalltalkが「型に対して柔軟」という説を意識した事も聞いたこともございません。
ええ〜Smalltalkってそもそも型がないんじゃなかったの？
#満足してくれた？

うん、オブジェクトの時間的変化っつうのが、振る舞いの変化か、データ構造の変化か、
不明だったからね。(と言い訳)
あと、factoryパターンじゃなく、prototypeパターンでインスタンス生成をする、と訂正。

つ事で、
振る舞いの時間的変化の表現：　 Decorationパターンで振る舞い変更。 (時間軸方向の管理は別途)
データ構造の時間的変化の表現：Compositパターンでデータ構造変更。(時間軸方向の管理は別途)
時間的に変化するオブジェクトを、ファーストクラスのクラスとして扱うための手法：
　　　　　　　　　　　　　　　　　　　　　(1)時間的に変化するオブジェクトのクラスを
　　　　　　　　　　　　　　　　　　　　　　　べき乗パターンの型クラスの導入により、擬似的に表現
　　　　　　　　　　　　　　　　　　　　　(2)その擬似的クラスのインスタンスを作成するには、
　　　　　　　　　　　　　　　　　　　　　　　Prototypeパターンで、原型となるオブジェクトに基づき、作成。

てな漢字かな。

>>395
ｱﾎ。変数に型がないのと、データに型がないのは、ちがう。
(ﾑ板なら、集中砲火浴びて瞬殺でつよ)

>>396 だみだ、酔いが回ってメタメタなぶんしょになってる。明日書き直そう・・・

閑話休題だが。

GUI向けオブジェクト指向フレームワークで、
多くの場合一つしかインスタンスを持たないウィンドウ画面を、
いちいちクラス定義してやる必要がある、というのは、
かなり変態的な設計だと思う(１０年前からの疑問)

あれって、CompositとDecorationあるいはPrototypeで解決すべき問題じゃないかと小一時間(r
最近の画面ビルダーで、そこら辺対応してるのってないの？

↑ちなみに、Windows環境、Java環境限定の話、ね。

　X windowはLiscovおねたま謹製のCLU/Argus由来のクラスター指向で書かれてるから、びゅーちふる♥♥

　最近のフレスコ画とか、キューティとか、ノームは・・・やっぱアレなんだるな。いちいちクラス定義

>>368
それはアメリカ系糞紺猿に毒された意見。WORDで日本語使いづらいのは、
日本人がアメリカドキュメント理解してないからだと言うほど馬鹿げた話。

国内会計基準はそれなりに整合性が取れていた。粉飾を許すと言えば、アメリカだって
似たような物だ。特に日本の場合、直接金融市場が未発達だったので間接金融で重要な
指標に基づいての会計基準が設けられていたのは、実務的にも理念的にも実際的にも
妥当な会計基準だったと思う。

もちろん直接金融へ移行する過程で資本市場も整備された事だしと、会計基準の変更や
新たな会計基準の導入が行われたことも時代の変化と言えば妥当な判断だったと思う。

この過程で制度を悪用した人間は悪党と言うだけの話だ。

少し粒度的には高い話もしてみよう。

>>388-389
昔読ましてもらった論文で、オブジェクト指向には融合と言う操作が欲しいてのが
有った。融合を動的に扱うとなれば、排出が必要になるが、それを扱えれば何か
物凄いことになりそうだと思う。

>>401
お、お詳しそうですね。

確かに、５大国際会計事務所の外圧は、ずいぶんひどかったみたいですね。
(日本の大企業の会計報告に、「国債会計基準に対応していない」と明記させるとか)

間接金融から直接金融への移行により、会計制度の変更が必要だった、との事ですが、
果たして本当に、国内会計基準は、十分なものだったのですか？
会計基準の理念と運用は、常に異なるものだとは存じますが、
そもそも国内では、制度会計と管理会計が極端に乖離していて、
特に管理会計の標準的なフレームワークが未発達だったのではないか、と素人なりに推測したのですが。

>>402
うぅ〜ん、よく例がわかりません。
ダイヤモンド継承と関連した話題でしょうか？

ダイヤモンド継承の問題＝多重継承時の定義衝突の解決方法(自動、手動)

と解釈したのですが。

>>405
ちらっと読んだだけなんで詳しくないんだけど、
そんな感じだった。

ダイヤモンド継承したいやん、でもやりにくいやん。
ダイヤモンド継承って、本当は継承と違うやん。
男と女継承してお釜になるってのもそれはそれで有りやけど
男と女が出会えば夫婦じゃん。
そりゃあ夫婦のメンバーは男と女だけど、そうじゃないやん。
夫婦ってのは、男女が出会って、お互い補い合って幸せになるやん？
てな感じだったと思う。

>>いちいちクラス定義してやる必要がある、というのは、
>>かなり変態的な設計だと思う(１０年前からの疑問)
変態的な設計・・・・
おまえは日立ソフトか

動けばそれでいいんだ。

>>動けばそれでいいんだ。
変態的発想
それがＳＫだ

>>409
お前も変態だな。

オブジェクト指向だの設計だのという世界は自称高級エンジニアのオナニーワールド。
業務SEに一番必要なのはお客様にわかりやすくシステムを語れる能力。
業務システムは例外処理のオンパレードで一番重要なのは千差万別なデータパターン解析。
プログラムなんてのは、一番重要なデータを臨機応変に正確に処理する為の使い捨ての世界。
結局、どんなツールを使おうとも最後には人間がわかりやすい手続き型になるんじゃないの?

優れた理解力を持つ人間の頭の中には、
実世界を適切に抽象化したモデルがあり、
頭の中で十分なシミュレーションを行うことで、
現実には体験していない事柄でも推定を行う事ができる。

不幸にして、そのようなモデルを持っていない人間、
あるいは、モデルを持ってはいるけれど、そのモデルを
他人と共有する能力が欠けている可哀想な人間は、
モデルを扱う代わりに、モデルを操作する手順と、その結果、
といったものを行動やコムにケーションの基本に据える必要がある。

もうおわかりだろう。事務系業務屋、手続至上主義者とは、
所詮、モデルを扱う能力が劣る人間なんだって事が

能書きはいいんだって。
ちゃんと動いてくれればいいんだよ。
「オブジェクト指向で設計しますので、安心です」と豪語していた橋本君。
お前の会社が作ったシステム、バグだらけでどうにもならんぞ。
損害賠償するから覚悟しておけ。

>>413
>「オブジェクト指向で設計しますので、安心です」と豪語していた橋本君。
どこの会社の人？

日立ソフトじゃないの。
IBSとか

モデルだのなんだのという香具師は顧客の現場に対応できず業務に超弱い頭でっかち
で使い物にならんよ。　用は自称高級板前をなのり超一流の包丁セットをもってるけど
野菜や魚が大嫌いという輩が多し。　最後には使い物にならないとレッテルはられて
いつのまにか職場から消えているね。

> 実世界を適切に抽象化したモデルがあり、

机上の思いこみのモデルがズバっと当てはまるケースは皆無。

>といったものを行動やコムにケーションの基本に据える必要がある。

"コムにケーション"ね〜? 最先端のお方の用語には俺はついてゆけんよ。(笑)

>>413
>「オブジェクト指向で設計しますので、安心です」
俺ならこの時点で脳内警報が鳴るんだが。

能書きはいいから、もまえの作ったユースケースとクラス図を
見せやがれ。

てな感じで、ニセモノを見分けられないかな。
あーいった成果物って持ち出せないんだよな・・・

日立ソフトの橋本君？

>事務系業務屋、手続至上主義者
なんていってる時点で脳内ＳＥ決定だな。
理由がわからなければ徹底的に業務をモデリングしてみろ。
例え組込みでも制御でも自社の業務を対象にモデリングは出来るだろ。

だから小僧は無理して話に加わるな。

↑と、事務系業務屋くんがホザいておりますｗ

だからぁ、事務系業務屋はすっこんでろってｗ

業務の重要なロジックは全て現場の生データをもとに作られている。
例えば某コールセンターのユーザコードで

超VIPのマークは下5桁目が"5"である。このユーザコードから電話が入ると
一斉にVIP警報がなり、すぐさま担当営業の電話に担当者はかけ、どんな些細
な情報でも即座対応するシステムになっている。

このように生データ主体の超例外処理が業績に直結しお客にありがたがられる。
現場のシステムの重要ポイントは生データの処理をいかに付加価値がつくように
プログラムを組むかが売り。脳内オブジェクト技術者がモデルだ、クラスだ、インヘリタンスだ
とオナニー用語を並べても顧客に理解されないハリボテモデルは世間に通用しないよ。

↑ビジネスモデルとアーキテクチャモデルの区別が付いていない可哀想な人

そーいやあんた前も、経営コンサルタントと統計ツール・エンジニアの区別ついてなかったっけなｗ

>>422
その話と OO に、まったく接点がないんですが。

>>422
オブジェクト指向が関係ないことないじゃん。
ちゃんとVIPの分析、識別基準、ワークフローが明確化できてる。
オブジェクト指向なアプローチが不適切なようには見えない。

>>421
>>422を見て解った、確かに事務屋は馬鹿が多い。 orz

どうでもいいけど、ちゃんと動くシステムを提供して下さい。
今日もハングしたぞ。しかもＯＳがぶっ飛んだ。
どんな作り方してるんだ？

まあEiffel以外は全部糞。

Smalltalkerって、ここにいるの？

#ところで、このスレ不毛な脳内ＳＥだらけだな。
#誰か、エレガント、且つ、早いオブジェクト指向のシステムを紹介してください。
#この目でみてみたい。
#PL/SQL大好き人だけど、こんどVisualWorksで作れ、といわれた。。。

>>427
OOと関係ないじゃん

事務処理の現場も理解できない脳内技術者の>>426はリストラ一直線。

　　間違いない

>>431
馬鹿も自覚が無いと面白いなｗ

最低限は理解してくれ、
どのOO技法を使っても業務実務者に直接的な恩恵は無い。
だからオメエの云う話は全く関係ないし、
OO技法を用いても君の誇る不細工な仕様は実現出来る。

まず他人の現場より自分の現場を理解しろ、それが先だ。

素朴な疑問。
なんでOO技法とやらは化石のようなCOBOLみたいに業務システム分野に普及
しないの?

素朴な疑問。
そもそも業務実務者って何よ？
顧客ほどの業務知識もないし
できるのは、外部仕様書作成くらいか？

それで、今後も生き残っていけるの？
#ＯＯ以前の問題としてだね

まあ、オブジェクト指向に過大な期待や過信を持つのも問題だが、

オブジェクト指向を目の敵にする連中もどうかと思うぞ。

不毛と思わないか？

＞＞こんどVisualWorksで作れ、といわれた。。。
アホか？
おまえは北大の病院関係者か

だから、ちゃんと動くものを納品しろよ。
今日もアプリがぶっ飛んだぞ。

すんまへん。バグとりの時間なかったもんで。
バグは出てから取れの指示です。

家に着くまでが遠足の様に、システム破棄するまでが検証期間。これ絶対的真理。

おまえらオブジェクト指向のシステムってどんなのを想定してるんだ？
ＯＯＤのシステムか？ＯＯＰだけのシステムか？
ＯＯＰまでならたくさん事例あるぞ

ずぶずぶに低レベル妄想議論を続ける痛いスレ。
情報システム板の常駐者が変な奴だから、しょうがないか

定期age

まあEiffelも使ったことがない奴にオブジェクト指向がどうこう言われたくはないわな。

ん？マイヤーさんちの廻し者か。
ふつ〜、NeXTCUBE/NeXTSTEP買えば、
Eiffelくらいつかうでしょ。
なんでそんなちっぽけな事柄で差別化しようとするの？

むしろ、型理論や純関数型言語の一連の流れも知らずに、
オブジェクト指向が高尚な理論かなんかと勘違いして虚勢を張る勘違い野郎を見ると、
後ろから近寄ってスリッパでﾊﾟｺｫｫｰｰｰﾝとか勢い良く叩いてやりたい気がする。ちょっとだけ

NeXTCUBE
ぷっ！

論点ずらしながら煽るしか能のない無能者プｯ

某社のオブジェクト指向は、なんちゃってオブジェクト。

COBOLerが、
・手続きをクラスの中に押し込んで、
・それをデザパタ風謎解釈で正当化し、
　(オブジェクトが単なる手続きの塊にしかなってないのに、
　 デザパタ引用して正当化してもだめっしょ)
・設計〜実装レベルの改善を、通常のイテレーション・プロセスではなく、
　何故か「実装コードのリファクタリング」で行う、という
　(上流できちんとした設計が成されていないものを、下流でいくらいじくりたおしても、
　工数上がるだけで設計品質は向上しないよ。
　相変わらずオブジェクトは、
　手続き部とデータ部が分離したCOBOLerオブジェクトのままだし)
不思議OO。

経験を積んだまっとうなオブジェクト指向技術者には、
決してお勧めできない。

オブジェクト指向だかアダルトビデオ指向だか知らんが、
ちゃんと動くシステムつくれ！

↑いわゆる負け犬の遠吠え。
　人様に人間扱いして欲しかったら、まずは言葉遣いを直せよ(ﾌﾟﾌﾟﾌﾟ

閑話休題

未だにオブジェクト指向が良く理解できず、
でも新しいアーキテクチャへの欲求が高い
という厄介な顧客を抱えているのであれば、
DOA系の流れで EA/SOAのソリューション提供している所にコンタクトを取ってみたら良いだろう。
もしかすると、あなたの顧客に合うかもしれない。

>>450


> DOA系の流れで EA/SOAのソリューション提供している所にコンタクトを取ってみたら良いだろう。
爆笑

オブジェクト指向は、ＳＶＯ型の言語を母語とする者、
もしくは形而上学的発想の好きな者には心地よいだろうが、
日本人には向かないと思う。

>>451
世間知らずってｶﾜｲｿｗ
迷惑かかるといけないから、ここには書くつもりが無いけど、
その気になって探せばすぐ見つかるよ。

やっぱ２ちゃんに常駐してる奴って、メガトン級のｳﾞｫｹだなｗ

>>447
　

>>452

日本人は、自由経済原理に基づく合理的な金勘定が苦手だから、
金融自由化の流れで外国資本に食い荒らされるだろう、つうのと同じ。成す術のないヘタレはさっさと淘汰されろってこった

3層Webシステムの場合UIなんかはオブジェクト指向でプログラミングしたほうがコスト、品質面で勝るでしょ。
ビジネスロジックについてはオブジェクト指向でキレイに作るのは相当難しい、特にウォーターフォール的な開発体制をとっている場合においては。
俺はビジネスロジックもオブジェクト指向で組めれば組みたいが、規模がでかくて開発者の人数が多いような場合には、オブジェクト指向で作るのはアプリケーションインフラまで。ロジックについてはオブジェクト指向で組んでプロジェクト成功させる自信ない。

>>456
逆のような気もするが、人それぞれってことかな。
UIの方はキレイに作りこむ必要はあまりないと思う。
UIコンポーネントとか入力チェックとか共通化出来る部分はもちろん可能なかぎりやるんだけど。

「ビジネスロジック」というレイヤーの分け方が、
そもそもオブジェクト指向とは別物だと思う。

そして「なんとなくオブジェクト指向っぽい設計」というのを、
充分な考慮もなく、思い込みと思いつきで進めるから、
>>447のような訳のわからない「オブジェクト指向」もどきが出てくるのだと思う。

自分の頭で考えないと、理解できないよ、オブジェクト指向はｗ

オブジェクト指向エバンジェリストみたいな人は、プライドが高いんだかなんだか
知らないが、「正しい知識を身に付ければ、誰でもすぐに役に立つ」みたいな売り込み
方をしながらも「こんな難しい概念を使いこなすオレ」みたいな自意識が隠せなかった
りするのが多い気がする。書籍とかで。
なんかさあ、うさんくさいんだよなあ・・・。
カプセル化とかモジュールの結合度を弱くするとか、構造化プログラミングにちょっと
毛が生えたような部分だけ取り入れて、設計は旧来どおりきっちりやって、ユーザーの
わがままとは徹底的に戦って、極力仕様を変えないようにする、というのがやはり
一番いいんじゃないかな？
リファクタリングなんて、上で出ているような規模の大きなお仕事のシステムでやろうな
んて無理でしょ。

>>460
人の意見なんて絶対聞かない、「馬耳東風の俺様道」を一直線だな。

　　　ど〜でもぃぃでっすよ♪

他の人の足を引っ張らないようにしてねｗ

どうもこうも。
まず第一に、オブジェクト指向という言葉を知っているだけで
２ちゃんねらーのレベルも上がったなぁ、と思います。

第二に、試してみたけど面倒なので、本音を言えばオブジェクト指向では開発したくありません。というか開発自体が嫌いになった。

以上。

ことOracleをびしびし動かすということでは、PL/SQLとPRO*Cが効率的に思える。
DBエンティティをオブジェクト化するとsetとlet操作が煩わしくて。

Oracleなんてローカル技術を基準に分かったようなこと語られてもねえ・・・。

>>460
本音は凡人にオブジェクト指向が使える訳ねぇだろう。と思っているそうだ。
夢を見させなければ、やって行けない商売だからな。

関数の抜出でさえ怪しい奴らが多いのに。
オブジェクトの抜出がまともに出来る奴なんてそうそういない。

また機能を知る事とそれを使いこなす事が別である事くらいは、
厨房でも解る事だし。

結局さ、プロジェクトで理想的に出来る奴ばっかり集めるなんてことは難しいことが多いでしょ。
目の前の仕事を現実的に解決していくのに、オブジェクト指向なんて役に立たないことが多いんじゃ
ないの？　プロジェクトの種類にもよると思うけど。

勉強熱心なのはいいけど、全体最適を考えないで、小賢しいフリされるのが一番迷惑だと思うなあ。

人を便利にするのが、進化したテクノロジーだと思うのだが。

単に、変化できない、では括れない部分が多すぎるのが、Java系のwebUIシステム。
あんなプアなUIで、しかも、プレゼンテーションとロジックとで情報を一元的に管理できない
システムを嬉々としてつくっているのが理解できない。
あれってさ、その昔の端末画面制御言語と端末間通信制御が、多少visualになっただけにしかみえん。
マルチメディア系ならともかく基幹系の数値、文言、あるいは漸進的なコード入力に適用して便利か？

しかも、せっかく使いやすくなったRDBから妙に隔てられる。
なのにRAPIDやらなんかしらんが、一番大事なデータ定義に時間をかけず、
カットオーバまでの短距離走的開発ばかり。

ここ、２、３年でできたシステムって、ほとんど使い捨てなんじゃなかろうか、という疑念もある。

本当に使える技術なのか？

ここにいらっしゃるオブジェクト指向信奉者殿に教えを請いたいものである。












全然、期待してないけど。こむつかしーこといって、煙に巻くだけか、チミタチ。

あぁ、ここぉ。

・・・新しい釣堀って。
　しかし不細工な魚ばっかだなｗ

続きはこっちでどうぞ：
　例の出頭32について
　http://science3.2ch.net/test/read.cgi/infosys/1088029040/l50

>>467
Java系Webシステム＝オブジェクト指向じゃないよ
っていうかほとんどがオブジェクト指向で作られてないのでは

>>457
自分の言うUIっていうのはコントローラーとビューの両方を含むんで。
画面の状態や扱うデータの種類の切り分けをオブジェクト指向で
組んでおくと楽ができるという寸法。
ここらへんは自分の責任でオブジェクト指向で組んでしまっても問題に
ならないからよくやるね。
一方でビジネスロジックの部分をオブジェクト指向で組んでも、
周りの人がそのクラスを再利用していく方向にはならないので
あんまりモチベーションが湧かない。
非パッケージの業務系システムで、複数人で一つのクラスを作っていこうという
雰囲気がなるプロジェクトがあったら参加してみたいよ。

>>463
業務処理は全部ストアドってのは処理効率もいいしロジックの置き場所もしっかり
しているからいいと思う。が、ストアドとJavaに業務ロジックが分散して
ひどいことになったプロジェクトを俺は見たことがある。何事も中途半端はよろしくないね。
ProCの場合は業務ロジックはC言語で書きづらいから大丈夫なのかな。
Javaは便利ゆえ危険。

頭悪そうなスレだなｗ


世の中、およそ二種類の人間が居る。
支配される側と、支配する側。

で、支配される側にも二種類の人間が居て、
ひとつは、自力ではプログラムもデバッグも満足にできないのに、
幼児的万能感をもって「大規模開発」とかによりかかっている屑。
例えば、数十画面の入出力を作るのに、100人月以上、1億円以上のコストを掛けてる人間を見ると
頭にウジでも湧いてるんじゃないか、と思う。

＞複数人で一つのクラスを作っていこうという
＞雰囲気がなるプロジェクトがあったら参加してみたいよ。

アフォ発見。
こーゆー無能者の居る大規模開発とやらを撲滅しない限り、
業界のレベルは下がる一方だなｗ

ついでに、こっちにもレスしとくか。

＞勉強熱心なのはいいけど、全体最適を考えないで、小賢しいフリされるのが一番迷惑だと思うなあ。

それはさぁ、単にキミが不勉強だから、
常識言われて「小賢しいフリ」とかおもっちゃう可哀想な人なんでしょ。

そんなﾚﾍﾞﾙで全体最適化とか言い出すくらいなら、
会社かプロジェクトの入り口に「おばかちんオブジェクト指向もどき実施中！経験者は近寄るべからず」
って大きく書いといて、業界外の未経験者とか、失業者とか、初心者だけプロジェクトに入れとけばええやんｗ

ま、いわゆるデスマーチ・プロジェクト (短期間でできて当たり前の事に、何ヶ月もかける、アホみたいな仕事)
の出来上がりですなｗ

１年目の僕でも475の意見は466の話と噛合っていない事だけは、解りました！

>>475
まあどうでもいいバカって感じだけど。

> そんなﾚﾍﾞﾙで全体最適化とか言い出すくらいなら、
> 会社かプロジェクトの入り口に「おばかちんオブジェクト指向もどき実施中！経験者は近寄るべからず」
> って大きく書いといて、業界外の未経験者とか、失業者とか、初心者だけプロジェクトに入れとけばええやんｗ
こんないかにも頭の悪そうな文章書きながら、自分は優秀でござい、って態度が取れる
ところが、いくら匿名とはいえ、たまらなく恥ずかしいよな。オレだったら自殺しちゃうよ。

どうせお子様プロジェクトの末席に座って、なんだか自分が頭良くなっちゃったような
錯覚にとらわれているだけなんだろうなあ・・・。

いや、オブジェクト指向設計ってさ、こういう勘違い君を作るだけでも充分罪深いよな（ｗ

>>477
「お子様プロジェクト」とは、どういった類のプロジェクトなのでしょうか？
君の方が勘違い君じゃないのかな？
まともな社会人の言うセリフではないですね。



学生アルバイトさんですか？

予想外の漁獲にﾋﾞｸｰﾘ

なんかﾃｷﾄｰ書いたのが図星でムキになってる>>477も居るしｗ

＞お子様プロジェクト

と、お子様会社の社員がムキになっておりますｗ

>>474
おいおい、そういうプロジェクトにしかいたことがないって言うだけで無能とか言われてもね。
「今回はオブジェクト指向で業務ロジックも共通クラス化していきましょう」
と１パートナー、１設計実装要員が音頭をとれとでも言いたいのかな？

>>477
>いや、オブジェクト指向設計ってさ、こういう勘違い君を作るだけでも充分罪深いよな（ｗ
それは言いがかりですね。
「解った気になっている莫迦」が居るのはOOの所為ではなく、そういう人間なのです。

オブジェクト指向ってちょっと貶すともうキ印がわらわら涌いてでてくるから面白いよな。

その意見に同意

オブジェクト指向に変わるものが出てき始めてるよな。
「ダブラッシュミッショナブル」。
これはかなりすごいらしいよ。

↑サンプル登場。
　まあ、最初から人を騙そうとするタイプの人間てのは、
ちょっと見ればすぐわかる。本能的に嫌悪感のシグナルが鳴り響くわけで

>>485
へぇ〜、すごいね。
でも、企業ｼｽﾃﾑ系統の語感しかしないから、全然興味ないです。

オブジェクト指向って、大別すると：

　1.シミュレーション(Simula, サイエンス＆エンジニアリング系)
　2.プログラミング技術系(Smalltalk, OOP, OOD)
　3.計算モデル/並行プロセス系(Plasma/Actor、分散OO)
　4.ビジネス・モデリング系(OOA)

ってな感じに分類できるかと思うけど(てきとー)、
分類4.は、国内じゃ育成する土壌がないんじゃないかな？
○×総研とかそーゆー枠組みの片隅以外では。

ダブラッシュ の検索結果 2 件中 日本語 のページ 1 - 2 件目 (0.59 秒)

EasySeek 生活・インテリア > 家具・インテリア > ...
... ベットの上に掛ける事で、お部屋が明るくなるのでは？ カネボウのベッ
トスプレット（他、マルチカバーとして利用可能）の激安処分です。ダブ...
ラッシュ ワールド 個人, 2,500円, 0 件, 22時間. ...
www.easyseek.net/i_tree.php3?m=i&c_no=111403 - 83k - 補足結果 - キャッシュ - 関連ページ

Soul, R&B
... アウト・オン・ミー ノット・ハッピー クレイジー ラヴィン・ジェスチャー
キープ・オン… 1-800 マイ・ラヴ(ガラージ・ミックス) ユー・エイント・ダ・
イッシュ(クラブ・ダブ) ラッシュ・ミー(インストゥルメンタル). ...
www.motomachi.com/listmania/1RT6DBHV5DSSP.html - 30k - 補足結果 - キャッシュ - 関連ページ

ミッショナブル の検索結果のうち 日本語のページ 約 6 件中 1 - 3 件目 (0.29 秒)

はてなダイアリー - ラックラック
... とかなってて凄いので楽しいので分刻みのスケジュールですよ。しかも今日なんか
日テレの何かに23：55から井川遥さんが出るからそれも見たいからね。インポッシブル
なミッショナブルでともすればファッショナブルです ...
d.hatena.ne.jp/kazking/20040414 - 24k - 補足結果 - キャッシュ - 関連ページ

Ｇ ＧＥＮＥＲＡＴＩＯＮ−Ｆ
... やらなかったなぁ。コンピューター同士の戦闘が長くてうっとおしいんだもん。
（Ｔ Ｔ） シュウ 通常では手に入らないＯＰパーツが手に入るのはよかったん
だけどな。 （￣〜￣ゞ 絆 ミッショナブル・モードもねぇ ...
www.geocities.co.jp/Playtown-Toys/3489/g_f.html - 21k - 補足結果 - キャッシュ - 関連ページ

Ｇ ＧＥＮＥＲＡＴＩＯＮ−Ｆ 追加説明集
... 細胞に感染されたザク�Tや、モビルトレースシステムで動くボー
ルも作れる。 ミッショナブル・モード. 特殊なクリア条件を早く
達成することを競うモード。対コンピューター戦の他 ...
www.geocities.co.jp/Playtown-Toys/3489/g_fp.html - 13k - 補足結果 - キャッシュ - 関連ページ

最も的確な結果を表示するために、上の3件と似たページは除かれています。
検索結果をすべて表示するには、ここから再検索してください。

＞複数人で一つのクラスを作る

大爆笑！！！
まさかAgile手法の、ペアプログラミングとか、ホワイトボードで設計、の事かｗ

アジャイルでおじゃる。

>>490
何がいいたいのかよくわからん。

>>485
それって、今、アメリカで密かに流行り始めているやつでしょ。
小さな企業が考え出した手法で、まだまだ世間的には知られていないけど。

出ました！２ちゃん名物「鮫島伝説」

知能の低いお子茶魔の考えることはなんだかなぁ。

次↓英語の綴りも書けず、情報源も明かせず、
お子茶魔じみた低脳煽りが連発するだけ。
うぜぇよ屑が

昔ドクタードブスジャーナルを読んでいた時期があって、エピス○ーメーとかいう人の連載
がすげえ性格悪そうで嫌だったなあ。
上にもあったけど、「オブジェクト指向のこんな難しい概念が分かる私」みたいな嫌な自意識
が感じられちゃって・・・。ある話のマクラで、電車で見かけたおじさんがコンピュータについて
勉強しているのを馬鹿にしているのがあったんだけど、ひどい内容なんですよ。

昔２ちゃんていうBBSを読んでいた時期があって、そこの>>495とかいう人の書き込み
がすげえ性格悪そうで嫌だったなあ。
上にもあったけど、「オブジェクト指向が理解できる人間は抑圧者だ」みたいな嫌な自意識
が感じられちゃって・・・。ある話のマクラで、電車で見かけたおじさんがコンピュータについて
勉強しているのを馬鹿にしているのがあったんだけど、ひどい内容なんですよ。

>>496
はいはい。

ちなみに本家DDJつうのは、Apple誕生やアンチMS誕生の場になった、
由緒正しいホーム・ブリューアーズ・クラブ文化の一つなんだけど、
国内のDDJつのはMS系出版社が出したイタイ雑誌だったなぁ。
あっという間に廃刊になって、跡継ぎの雑誌(知り合いが連載やってた)なんて名前すら覚えてない

ドクター・ドブスは・・・歯医者の名前


１２へぇ

あっという間というか、何年かは刊行してなかったか？
『憂鬱なプログラマのための・・・』みたいな名著も産んだ。
エピの評価は・・・みんなどうなの？

DDJ(ドクタードブスジャーナル)っていえば、本来は工学社の雑誌「I/O」が提携してたんだよ。
DDJの理念の一つは、ソースコードやノウハウの共有だから、I/Oは路線として当たっている。(ちょっと幼稚な感じもしたが)
MSのゲイツなんてのは、コミュニティの雰囲気壊してでも金を稼ごうとする、異端分子。

で、そのMSが、日本語版DDJ支援してたつうだけで、糞具合がわかるだろ。
SoftBankの禿がやってる、Yahoo!JPやZDNet JP並に胡散臭い、本家から鼻ツマミになってるフェイクっつうこと。
あんな糞雑誌を語るとは、よほど情報源の乏しい、哀しい人だね。

日本では、DDJは『純然たるOOの雑誌』とか誤解してる痛い人も居るみたいだ。
そーゆー奴は、もしかしてざべ(TheBasic)の吉田がOOの導師だと勘違いしてそうだな、上の方にも出てるけど

DDJ/JAPAN INDEX
http://web.archive.org/web/20030127011747/www.shoeisha.com/book/hp/pc/ddjj/contents/contents.html

まあ、クソっていう根拠がＭＳがちょっと関わったから、って書いているだけで大体どういう
奴だか想像がつくな。
そりゃ、そういう狂信者相手にマトモな議論が成り立つわけがない。
イスラム教徒に民主主義の価値を説くようなもの。

>>495からネガティブな話題振ってたｷｼｮｦﾀが、
>>504で見事に釣り上げられてるのを見て、ﾜﾗﾀ

本当、こらえ性ないんだからｗ >>483が正解だなｗ

>>505
本当だな、こいつ(>>504)の場合は、MS狂信者だけどｗ
＞イスラム教徒
(爆笑

Ｍ＄狂信者ってちょっと貶すともうキ印がわらわら涌いてでてくるから面白いよな。

ＭＳ信者だって。ぷ。

MS信者じゃなくて、MS狂信者の間違いだよ。
読めない字を抜かしちゃだめだよ

>>447
そういった開発手法をとる人というのは、
開発プロセスという言葉は知ってても、
実体験として開発プロセスの重要性を
ちゃんと理解できていないのではないか。

独学で勉強している人は、視野狭窄になって、
物事をバランス良く把握できない、という良い例だ

信者とか狂信者とかいう前に、ちゃんと勉強しといたほうがいいよ。学生さん。

大手で生産技術部門がある所はどこも10年以上前から
「開発プロセス」もしくは同等の概念を社内標準化している。
数年前には、自社独自プロセス(構造化〜プロトタイピング等)から
RUPやAgileへの接点とか移行パスを模索しはじめてる。

そして現在、開発ツール製品出してる所は、なんらかの形で
それらプロセスへの対応を主張している。

もちろん、昔ながらの方法でじゃぶじゃぶ金使ってる所もあるけど、
そんなんおは年々減ってきているみたい。

さて次は、各社開発プロセスを横並びで比較していきますか。

ふつう、幼児的万能感持って駄々こねても許されるのって、
せいぜい中学生までよね〜(ｷｬﾊ

社会人で駄々捏ねる男は、初めて見たｗ

誰のこと？

>>504

やれやれ。
お前らオブジェクト指向以前に、ごくごくあたりまえの読解力もないんだな。
あきれたよ。

頭にコンプレックスのある人が、あたかも賢いかのように振舞う、カワイソウなスレ

>>519
コンプレックスなんかないだろう。
本人気付いてないんだから。

意味のあるネタと意味のないネタをふると、必ず意味のないネタにクイックレスポンスのある、痛いスレ

>>510
開発プロセス考えてないわけじゃないだろ。
単に、素人でも入りやすいように、
構造化設計みたいなクラス設計させてるだけだろ。
最初はクラス間相互作用の海で泳がせて、慣れてきたrでざぱたでりふぁくたりんぐ・これ最強。
生命の原初は、海水中のヌクレオチドだったわけだし、いろいろりふぁくたりんぐしてればきっとサルまで成長するって。
ついには、開発プロセスの進行とともにメンバーが成長して、
プロジェクト完了時にはオブジェクトのエキスパートに×××。

つかサルから人なみに進化するっ、と。
まぁ、長い目で見れば、きっと進化するよ。多分。寿命の方が先に来るだろうけど。

>>519,520
そういうことにしたいのですね。

＞ ソフトウェア開発工程を統合管理するソフトウェア製品、開発決定のお知らせ
＞
＞ 株式会社豆蔵（本社：東京都新宿区、社長：荻原 紀男）は平成17 年2 月10 日、豆蔵のソリューショ
＞ ン体系であるenThology の一環としてソフトウェア開発における全工程を統合的に管理するソフトウ
＞ ェア製品の開発及び販売を決定いたしました。本製品は平成17 年2 月中旬より開発を開始し、平成
＞ 18 年1 月より販売を開始する予定です。

やっぱオブジェクト指向コンサルたるもの、
人と組織を動かしてプロジェクト管理をするに当たって、
開発プロセス管理ツールくらいデフォで用意しないと、
この先生きのこれないんだよ。注目あびる優秀なコンサルなら、ね。

【関連スレ】

　■プロジェクト管理　で欲しいツール■ 　(DAT落ち)
　http://mentai.2ch.net/test/read.cgi/infosys/1009417487/

そういうのがほんとにコスト削減に役立っているかどうかは議論の分かれるところ。
ちょうどオブジェクト指向が生産性の向上に役立っているかどうかわからないように。

>>525
実体験で言えばオブジェクト指向で開発するとプロジェクト単位の生産性はあがる。
しかし、一般企業で考えれば投資対処として考えると相当怪しいと思う。
これは投資分の回収は充分に可能だが、別な事に投資した方が良いと言う意味。

みんな投資先（勉強すべき方向）が無い（視野が狭い）から
取敢えずオブジェクト指向とやらに投資をしておけ。
という雰囲気を感じる。

>>526
>>取敢えずオブジェクト指向とやらに投資をしておけ
は正しいと思うぞ。
必ず大きな目を開く。

＞526
＞大手で生産技術部門がある所はどこも10年以上前から
＞「開発プロセス」もしくは同等の概念を社内標準化している。
＞数年前には、自社独自プロセス(構造化〜プロトタイピング等)から
＞RUPやAgileへの接点とか移行パスを模索しはじめてる。
＞
＞そして現在、開発ツール製品出してる所は、なんらかの形で
＞それらプロセスへの対応を主張している。

いや、今更構造化設計に投資したい、ってならそれでもいいけどｗ

あと、ERwinあたりの会社が、なんかＯＯと違う方向性でやってるのが興味深い

＞525

とにかく前レス読んどけや
＞大手で生産技術部門がある所はどこも10年以上前から
＞「開発プロセス」もしくは同等の概念を社内標準化している。
＞数年前には、自社独自プロセス(構造化〜プロトタイピング等)から
＞RUPやAgileへの接点とか移行パスを模索しはじめてる。
＞
＞そして現在、開発ツール製品出してる所は、なんらかの形で
＞それらプロセスへの対応を主張している。

著作権ごと買いたたかれるプロジェクトで、
うんうん唸ってクラスつくってあげると、損だな。
表だって、使い回しできんもん。
使い回しし易いのが、ＯＯの長所だが。

うるさいとこだと、こちとらで開発したベースまで、ずーずーしくもっていこうとする。

で、うちの開発資産だ、というと安くしろと言う。

おらおら、人月買いか、機能買い、なのか、はっきりさせろよ。

といーわけで、うざいとこは、知らんぷりしてファンクション切り。
その方が目先の開発コストがさがる。
どーせ、最近の企業システムだと４年でご臨終だし。

>>530
それもさぁ、あんたの会社の契約次第だよ。
大手ＳＩerでも、強い相手(エンドユーザ企業)と弱い相手(下請け)が居るから、
一応契約で著作権の保有割合はプロジェクト毎に決める事になってるよ。

まぁ、SIerでも格上や元請、メーカ相手の契約では、著作権根こそぎ持って逝かれて、
有効活用もされないまま腐らされちまうのがデフォだけどね。
ちっちゃい所は、自社開発とか、共同開発とかして、開発費用を一部負担するだけの覚悟をしないと、
著作権商売なんて夢のまた夢。

もっとも、共同開発で、著作権の整理までしても、結局全然儲からない・・・つう悲惨な仕事もあったな、前。

ところでここに常駐しているＯＯの人は、
もう数年前から巷では常識になっている、
「既存有名フレームワークに機能追加や強化をして自社フレームワークで安定開発」
とかしてないの？
２ちゃんですら、数年前からそんなスレ立ってるよなｗ
　日本製Java Frameworkの駄目さ加減を語り合うスレ
　http://science3.2ch.net/test/read.cgi/infosys/1002029091/

>>532
あぁ、某UNIXﾏｶﾞｼﾞｿにまるでSI案件みたいなトンでも価格が載っちゃった、
例のｼｽﾃﾑね。SIであの値段とるのは勝手だけど、商品価格としてはいかがなものか、とオモた

× >>532
○ >>531 もっとも、共同開発で、著作権の整理までしても、結局全然儲からない・・・

>>532
Frameworkはオブジェクト指向というよりは、実装寄りの技術だから、
あまり関係ない。

オブジェクト指向技術ってのは、実装言語が異なっても
共通に使える部分を指すのが普通。

すなわち、OOAとOOD。OOPの際言語が違っても共通する技術。
デザインパターン。アーキテクチャパターン。UMLによる図面の統一など。

要求定義やプロジェクト管理、といったところは従来のを流用できる。

要求定義の前の段階もあるけど、これは人に教えるのは難しい。
本人の才能にかなり依存するなぁ。

ああ、開発資産とかいう用語使いからみると、
あなたは某メーカ系の人と同じ考えをもってるっぽいね。

フレームワークは実装よりだから関係ない、とか言い出しちゃうあたり、
なかなか負けず嫌いのハッタリが強いなｗ

こっちは、apache.orgのフレームワークをその誕生以前から見てるから、
その手の負け惜しみもいっぱい見てるんだよｗ

そういえば、国内でも某メーカは、
フレームワークへの取り組みが無茶苦茶弱かったな。

実装フレームワークも、
概念フレームワークもｗ

そして、要求定義前＝インタビュー・企画・提案という営業活動にウェイトを置いて、
あろうことか「本人の才能に依存」とか言い出すあたり、うーん、どうなんだろうねぇ

.>>535　は相変わらず、開発をスタティックな概念(〜パターン、図面)でしか捕らえていないのがミソ。
やっぱ、開発プロセスの重要性理解できてないんじゃないか、と。
こんなレベルで自称コンサルだったら嫌だな。
お豆さんですら、工程管理ツール作るっつってるのに

自分の立ち振る舞いを客観視できない人間が、
開発プロセスなどという大きな視点を持てるわけがなかろうて

え、「本人の才能に依存」ってこの仕事のあらゆるフェーズで、方法論よりもはるかに
大切な一番の真実では？

人を集めるとき、派遣法だろうが、社内の力関係だろうがなんでもかいくぐり、いかに
出来る人間をバイネームで集めるかがプロジェクト初期の管理者の力量の見せ所
かと。

>>539
> .>>535　は相変わらず、開発をスタティックな概念(〜パターン、図面)でしか捕らえていないのがミソ。
そういうとき「ミソ」っていうのは表現としてちょっと変な使い方だな。

みそ 【味噌】

(1)調味料の一。蒸した大豆に食塩と麹(こうじ)を加え、大豆タンパク質を分解させて作ったもの。

(2)カニやエビの甲殻中にある、色が(1)によく似たもの。蟹黄(かいおう)。

(3)工夫をこらして特色となる点。趣向をこらしたところ。
　　→手前味噌

(4)他の語に付いて、さげすんだり、あざけったりする意を表す。
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　「泣き―」「弱―」「―用人」

(5)子供の遊びなどで、一人前にみなされない子供。みそっかす。
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
(6)失敗。しくじり。
　￣￣￣￣￣￣
　　――も糞(くそ)も一緒
　　　善悪・優劣などの区別をせず、何もかもごたまぜに同一視する。
　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　――を上・げる
　　　自慢をする。
　　　「少(ちつ)と―・げるやうだが/社会百面相（魯庵）」

　　――を擂(す)・る
　　　(1)まだ漉(こ)してない味噌を擂り鉢に入れて擂り粉木(こぎ)でする。

　　　(2)へつらう。ごまをする。

　　――をつ・ける
　　　失敗して評判を落とす。面目を失う。
　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

>>540
そうそう、所詮、開発を形而上の問題として分析できない人間が、
いくら「できる奴」つっても、「できる振りしたデタラメ野郎」しか集まらないことは、
歴史が証明してる

大体、できる奴ってのが、なんか別の有名な肩書きで説明しなきゃならないとしたら、それは本人の実力ではないし、
そんなできる奴が匿名掲示板で憂さ晴らしするのは、ほんとに稀にしかないよ。俺自身稀にしかここには来ないし

>>541
なんだ、結局あんたの仕事は多重下請け人材派遣で、
たかだか数十画面のアプリを何百人月もかけて開発するパターンなのか。

そんな仕事でできるもできないもないだろう。
それは、退屈な仕事にしがみつく以外に生きる術を持たない、敗残者の仕事なんだよ。
業界ヒエラルキー的に見て。

>>546
>業界ヒエラルキー
ぷ。
後学のために、ヒエラルキー上部のあなたのお仕事の概要でも教えてくださいませんか？

>>546
うーん、俺的には気になる書き込みだな。
俺は売上高からも平均給与からもSI業界で10番以内に入る企業にいるんだが、
有象無象の派遣プログラマーを使ってぜいぜい言って高品質とは
言えないシステム作っているのがどうも不満。画面は数十ではなく数百だけど。
儲かっているけど釈然とはしない。
こんな俺だが546の言う敗残者ってことになるの？もしそうなら勝者の
集まっている会社を上げてくれ、転職目指してがんばるからさ。

こんな時間に書いてる>>548はまともな
勤め人とは言い難い件について。

SI業界トップ10企業で、派遣プログラマ使って有象無象システム作っているのが
ヒエラルキーの頂点と考えるとは、下請け派遣プログラマの思考って程度低いなｗ

また、そのSI業界トップ10と称するのが、
業界外の人間が見ると聞いた事もないような３Ｋ企業ばっかなわけでｗ

(´-`).｡ｏＯ（>>541 をどう読めば >>546 が出てくるんだろ…？)

>>549
内容に突っ込めないからって、
書き込み時間に難癖つけるのは如何なものか。

SI業界トップ10企業で、派遣プログラマ使って有象無象システム作っているのが
ヒエラルキーの頂点と考えるとは、下請け派遣プログラマの思考って程度低いなｗ

また、そのSI業界トップ10と称するのが、
業界外の人間が見ると聞いた事もないような３Ｋ企業ばっかなわけでｗ

大手ITサービス会社の2003年3月期の連結決算（億円。▲はマイナス）

社名売上高（対前年度増加率）経常利益（対前年度増加率）　2003年度見込経常利益
　　　経常利益率2003年度見込売上高
1. NTTデータ8321.09（3.8％）473.15 　（0.3％） 5.70%8400　530
2. CSK3575.05（▲15.6％）163.61 （202.4％） 4.60%3800　260
3. 大塚商会3242.88（▲1.2％） 77.66 　（1.3％） 2.40%3385　 85.5
4. 伊藤忠テクノサイエンス2909.98（▲15.7％）180.96（▲12.5％） 6.20%2780　161
5. NECフィールディング2401.27（5.7％)151.22　（44.5％） 6.30%2530　165
6. 野村総合研究所2327.43（▲1.6％）276.27（▲16.2％）11.90%2450　283
7. 富士通サポート＆サービス2206.95（▲0.4％） 98.95 　（3.3％） 4.50%2275　102
8. 日立ソフトウェアエンジニアリング
2178.72（5.2％）128.21 （▲3.9％） 5.90%2210　136
9. 富士通ビジネスシステム1707.98（▲10.6％） 19.9　　（2.2％） 1.20%1750　 29
10.TIS1645.84（12.0％）107.2　 （25.2％） 6.50%1680　124

11.日立情報システムズ1639.56（17.2％） 98.53　（20.8％） 6.00%1660　 98.6
12.新日鉄ソリューションズ1530.97（2.8％）120.85 （▲2.7％） 7.90%1500　120
13.富士ソフトABC1330.63（18.0％） 93.11（▲17.6％） 7.00%1387.5　 98.86
14.NECソフト1135.39（21.9％） 94.9　 （15.6％） 8.40%1200　100
15.インテック1080.62（▲1.0％） 47.12　（▲12.8） 4.40%1110　 50
合計　　　　　　 37234.36（0％）　　　　 2131.64　（4.9％） 5.70%38117.52342.96

>>553
> SI業界トップ10企業で、派遣プログラマ使って有象無象システム作っているのが
> ヒエラルキーの頂点と考えるとは、下請け派遣プログラマの思考って程度低いなｗ
まあ別にそれで結構なんだけど、そういうレベルの低い仕事にオブジェクト指向とやらは
役に立たない、という結論でいいのかな？

こういう仕事で、いかにオブジェクト指向を有効に使うか、根付かせるかという議論なら
面白いけど、546みたいなのって結局他人を馬鹿にする（それも具体性なし）ことしか
興味ないみたいだね。

この種の俺様自慢はこの業界では付き物かもしれないけど、オブジェクト指向の信者
に多いというの偏見か？

キミの気のせいだ。
せいぜい仕事に励みたまえ。


　　　　　　　　　期　待　し　て　る　よ　☆ﾐ

なんだ、まともなスレついてないな。人を煽って人の時間を潰すのを
生業にしている輩を相手にしてしまったかな。
俺は自分の仕事環境、それを使って出している自分の成果いずれも
業界のトップレベルだんて思っちゃいない。ただ物差しを給料で
見たら高いってだけの話だ。別に世間で名が売れてなくても３Kでも
気にしていない。
給料業界トップ10の会社は品質、納期、コストの総合得点でいい仕事を
してるところはないだろうと俺は思っている。だからいい仕事をしている
人なり集団なりがいるのなら切実に知りたいと思ってる。

大手ITサービス会社の2003年3月期の連結決算（億円。▲はマイナス）

社名　　　　　　　　　　　　　売上高（対前年度増加率）経常利益（対前年度増加率）　2003年度見込経常利益
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　経常利益率2003年度見込売上高
1. NTTデータ　　　　　　　　　　　　　　 8321.09（3.8％）　　473.15 　（0.3％）　5.70%8400　530
2. CSK　　　　　　　　　　　　　　　　　　 3575.05（▲15.6％）163.61 （202.4％） 4.60%3800　260
3. 大塚商会　　　　　　　　　　　　　　　 3242.88（▲1.2％） 77.66 　（1.3％）　　2.40%3385　 85.5
4. 伊藤忠テクノサイエンス　　　　　　 2909.98（▲15.7％）180.96（▲12.5％） 6.20%2780 161
5. NECフィールディング　　　　　　　　2401.27（5.7％)　　 151.22　（44.5％）　6.30%2530 165
6. 野村総合研究所　　　　　　　　　　　2327.43（▲1.6％） 276.27（▲16.2％）11.90%2450 283
7. 富士通サポート＆サービス　　　　 2206.95（▲0.4％）　98.95 　（3.3％）　　4.50%2275 102
8. 日立ソフトウェアエンジニアリング 2178.72（5.2％）　　128.21 （▲3.9％）　 5.90%2210 136
9. 富士通ビジネスシステム　　　　　　1707.98（▲10.6％） 19.9　　（2.2％）　　1.20%1750　 29
10.TIS　　　　　　　　　　　　　　　　　　　1645.84（12.0％）　107.2　 （25.2％）　　6.50%1680　124

というか、この上位10社の中で画面数を云々するような仕事っつうのは結構下っ端っぽいと思うけどｗ

わざわざOOスレに給料自慢しに来るとは頭が可笑しいんじゃねぇ〜の？

ほっとけよ、それしか自慢がない人なんだからさあ

自称オブジェクト指向、実態COBOLerの危険サイン：

1. システム規模の見積もりが 画面数、LOC、元祖FP法しかない
2. オブジェクト指向経験者だというだけで、大喜びされる
3. 実は実装言語を触った事のある人が、プロジェクトに二名しか居ない
4. その「実装言語を触った事がある」という奴が、
　　実はC言語みたいなクラスレスな設計しかした事がない
5. マネージャは、オブジェクト指向設計をいかに進めるか、ではなく、
　　UMLの図面をひとつ書くのに一ヶ月かかるから、UMLの使用を止めよう、
　　という不毛な議論を何時間も大声で続ける
6. 対外的には、オブジェクト指向の大成功プロジェクトだと大宣伝するが、
　　雑誌に載ったその記事は、とてつもなく恥ずかしい内容

>>559
さすが下っ端プログラマーはものの見方が歪んでるな。
そのうち顔も歪んでくるから注意しろよ。

哀しい人だねぇ〜。
オブジェクト指向スレで罵詈雑言を放つしか、能がないとは。
やっぱ無能な人間とは、お話もしたくないねぇ〜

ほっとけよ、妄想で自慢するしかない人なんだからさあ。
こいつ、２ちゃんにいつも常駐してる人だしｗ

例のコテハンか。
それじゃ、中身のある会話を望む方が無理ってもんだね

画面数の多さが自慢の大規模単純業務システムの担当SEが常駐してるスレは、ここですか？

ソフト会社のコピペしている馬鹿も確かにいるが、ここのところのスレを読む限り、
「画面数の多さが自慢の大規模単純業務システムの担当SE」の方がよっぽどちゃんと
レス返しているじゃん。つまねえあおりばっかりじゃなくてさ、OOの利点を語るとか、２ち
ゃんでのつまんない自慰的な自慢以外のことすればいいのに。

↑などとメタ発言をしつつ、自身ではナニも実践しない奴。
・・・こんなんばっかやね。

まずは自分で実践したらどうよｗ

>>567
あんた偉そうな事言うけど、自分で実践せずに他を貶めるだけで、
無能者のニホヒがプソプソするね。

低能な奴に、あからさまに低能だと言うのもどうかと思って、
低能な奴にも反論可能な形で議論を進めていたけど、
そろそろはっきりさせよう。

>>555
結論：
レベルの低い仕事にオブジェクト指向とやらが役に立たない、とは断言できないが、
それ以前に向上心の無い人間/環境でオブジェクト指向を教え込むのは無理。時間の無駄。

オプソで自己拡張可能なツール(Eclipseとか.NETとか)作り込んで、
便利なフレームワーク(EMFとかRELAXERとか)も作り込んで、
デファクトスタンダードとして無言の圧力で押し付けるしかないでしょ、奴ら低脳には。

それですら、新技術導入に伴う工数拡大の言い訳にしか使わず、
しまいには画面なんてほとんど自動生成するツール用意しても、
　　　　「最低でも一画面一人月は必要」とかほざくんだろうけど

あと、>>557

甘えるな。

自　分　で　さ　が　せ

追伸：

無能者が跳梁跋扈するプロジェクトには、ウンコ臭い奴が多い。
単純な仕事に神経使ってると、
社会人のくせにウンコもらしながら仕事するようになっちゃうんだね。

ウンコはトイレでちゃんとやれよ

>>557
品のないレスは気にすんな。（^o^）v
くだらん反応をしてるのはおそらく1人だ。（たぶん）
10位以内ぐらいだと、一応なんちゃってアーキテクトがいたり、新人さんがSEやったり
だと思うのだけど、結局ハードウェアやアウトソーシングなんかで
金稼ぐ方がメインのはずなんで、実は開発の方はどうでもいいんではないかと思う。
現場のOOは単純にコード減らすための技術と考えた方がいいかもね。

やっぱりなあ。無能だとかウンコだとか根拠も品もない言葉で散々煽るぐらいしか
能がないんだろうね。
真面目に話そうとしているカキコに対してそういう言い方されるんじゃ、こっちも悲
しくなっちゃうなあ。

まともに相手してもらえると思ってます？

>それ以前に向上心の無い人間/環境でオブジェクト指向を教え込むのは無理。時間の無駄。
だからね、あなたが属している向上心のある優秀な人間のプロジェクト、オブジェ
クト指向が生きてつかわれている、っていうプロジェクトがどういうのか教えてくだ
さいな（また自分でさがせ？）。

>低能な奴に、あからさまに低能だと言うのもどうかと思って、
>低能な奴にも反論可能な形で議論を進めていたけど、
>そろそろはっきりさせよう。
なんか力んじゃってるけど、血圧には気をつけてね（ｗ

>>572
あ、読まずに書いちゃいました。

>品のないレスは気にすんな。（^o^）v
ご心配なく、私も充分品が悪いです。まあコンテキストみて品が悪くなったり、良くな
ったりはしますが（上のような人と違って）。


> 金稼ぐ方がメインのはずなんで、実は開発の方はどうでもいいんではないかと思う。
> 現場のOOは単純にコード減らすための技術と考えた方がいいかもね。
そうですね。行き着くところはやはり金になるかどうかですよね。いつまでもプログラム
作りを楽しんでいたい、という気持ちはあれど、やっぱりお金が稼げるかどうか、という
のが重要になってきますよね。
まあ、私の属している会社のレベルが低いのかもしれないけど、既存のクラスライブラ
リを使うとかがやっぱメインで、設計から明確にオブジェクト指向でってわけにはなか
なか行かない部分があります。

自作自演に必死だけど、中身がオブジェクト指向からどんどん離れていく・・・

みんな、ルールに従おうぜ。愚痴吐くなら同僚と酒でものみながらやってくれ。

あとさぁ、自称10位以内というあんたの会社名と部署くらい書けよ

>>573
現場に逝けば判る事なんだけどねぇ〜。
あんたの現場は皆糞詰まりかなｗ

プログラマー比率、害虫比率、高年齢層比率の高い職場ほど、
午後になるとウンコ臭い空気が漂ってきて、
トイレの大は満員状態になる・・・なんて現場に居なけりゃわかんねぇよなｗ

仕事でも遊びでも、
余裕を持って楽しみながら事に当たる余裕のない、
頭悪い奴を見ると、とても哀しくなる。

画面ひとつに一人月かけるような、超スローモーな仕事、
まともな知性を持った人間が相手にすると思ってるのかな、ここの屑どもは

ここにキモイAA貼り付けてるのは、
どーせ出張３２だから、相手にすんな。

相手にすると、基地外が移るぞ

出張が来ると、どの板も下品な荒れ方するねぇ。
自作自演で荒らしてくるから、始末に終えない

荒らすなハゲ
知性の感じられないハッタリ議論は、こちらでどうぞ。

　例のハッタリ野郎について
　http://science3.2ch.net/test/read.cgi/infosys/1088029040/

>>569
結論に対して反論はないけど、付けたし。

あのさ、まずはそこまでやった前提でその先の改善をオブジェクト指向開発で
うまく達成している集団なんてあるのかな？というのが俺の疑問なんだよね。
うちではWebアプリケーションフレームワーク、永続化機構、
画面生成機能を持つ開発環境を使って、こちらで作成した仕様書に
基づいて開発してもらっている。開発は画面（機能ごと）のイメージ。
社内で計測した結果によればフレームワークやジェネレータによる
コードの再利用率は4割弱とのことだ。

単体で機能するサブシステムならこれで問題なく開発できるのだが、
複数のサブシステムが協調するようなでかいシステムで生じる問題について、
「結論」が述べている対策は何もしてくれない。
あなたが言っている部分はアプリケーション開発における土俵を
作る部分であり、それから先の部分については述べていないよね。

OOでドメインモデルを使って開発すればいい、というのが教科書的な
話。だが現実問題それができる要員を20人、30人は集められていない。
自社で達人プログラマを一定数は養成していく必要があるんじゃないかと
思っているが、俺はまだまだ下っ端で今ある環境でがんばっていかなきゃ
いけない。そんな混沌の中で、一つの心の支えみたいなものがほしくて、OOで
いい仕事している実例というのに興味があるわけだ。

だいたい開発ツールを充実させること、コードの再利用率を高めるってのはOO開発
とは関係ないよ。それに開発要員を作業者扱いしているのはちょっと
違うと思う。開発要員が創造的に作業しないと大規模プロジェクトはうまく
いかないんじゃないかな。

別に語り口がお上品でないのは気にしていないんで、俺が直面している
問題に対して成功した経験があるんなら聞かせてくれ。

キミは、話を勝手に仮定して、妄想議論を進める癖がある。
まずは、現実と妄想を区別するところから始めろ。
話はそれからだ。

妄想例：
1. 「複数のサブシステムが協調するようなでかいシステムで生じる問題について、
　　「結論」が述べている対策は何もしてくれない。」

　勝手に妄想してろ

2. 「あなたが言っている部分はアプリケーション開発における土俵を
　　作る部分であり、それから先の部分については述べていないよね。 」

　勝手に妄想してろ

3. 「OOでドメインモデルを使って開発すればいい、というのが教科書的な
　　話。だが現実問題それができる要員を20人、30人は集められていない。」

　20人も30人も集める必要ねぇよ

4. 「だいたい開発ツールを充実させること、コードの再利用率を高めるってのはOO開発
　　とは関係ないよ。」

　誰もそんな事はいっちゃーいねぇよ

>>572
> くだらん反応をしてるのはおそらく1人だ。（たぶん）

俺もそんな気がしてきた。
具体例をあげない妄想議論ってこいつの方じゃないかと。
ポーズだけできる人、っぽいな。

下らん反応をしつこく続けてうざいな

>>585＝やばくなると、人格攻撃に逃げる負け犬

悪いクスリでもやってんのか？

キミは、話を勝手に仮定して、妄想議論を進める癖がある。
まずは、現実と妄想を区別するところから始めろ。
話はそれからだ。

妄想例：
1. 「複数のサブシステムが協調するようなでかいシステムで生じる問題について、
　　「結論」が述べている対策は何もしてくれない。」

　勝手に妄想してろ

2. 「あなたが言っている部分はアプリケーション開発における土俵を
　　作る部分であり、それから先の部分については述べていないよね。 」

　勝手に妄想してろ

3. 「OOでドメインモデルを使って開発すればいい、というのが教科書的な
　　話。だが現実問題それができる要員を20人、30人は集められていない。」

　20人も30人も集める必要ねぇよ

4. 「だいたい開発ツールを充実させること、コードの再利用率を高めるってのはOO開発
　　とは関係ないよ。」

　誰もそんな事はいっちゃーいねぇよ

ここにたむろっている人ってさ、
金を稼げる仕事をできているのか？
ってのが、妙に気になる。

sala shar age

減らず口の足らない御仁だな。
匿名掲示板で尊大な態度で妄想交じりの質問してくる厨が
ゴミ扱いされるのは当たり前。

まっとうな回答というのは、
信頼関係を築いた上で、丁寧に質問して初めて得られるものだ。
社会的訓練が足りねぇんじゃねぇの？

>>591
なら２ｃｈなんぞじゃ絶対無理だね。

だいたいおまえがまっとな回答なんてできるのか？

↑だからお前は馬鹿なんだよ

信頼関係がなければ、いくら深い話をしても通じないというのが事実。

>>592の場合は、信頼関係の構築努力もなしに、他人様に善意を強要する・・・
・・・乞食みたいなもんだな。
乞食が金を稼ぐ仕事などするのは到底無理無理

>>594
話が通じる通じないに、
信頼関係ってそんなに関係あるだろうか？
あったって通じないこともあるし、
無くたって通じることもある。
2chがなりたってるのは後者のケースが結構大きいと思う。

随分高飛車な物乞いだなｗ

おまえらみんな学生？

社会人じゃないよな？

ここおもしろいな。
偉そうな能書きたれてるけど中身ない。

↑ﾎﾝﾄだ、中身が無い

↑おまえ、回りから嫌われてるだろ？

みなさんは２ちゃんねる初心者ですか？SG(セキュリティー・ガード)を知ってますか？
まだSGに登録していないみたいですね。書き込む前にSGに登録しないと大変危険です。
SGに登録せずに書き込んだ場合、あなたのPC（又はケータイ）内の情報が他人に見られる恐れがあります。
勝手にＰＣ（又はケータイ）情報や住所まで公開されてしまったケースも有ります。
初期の頃から2chにいる方達は、殆どSGに登録しています。登録は簡単に出来ます。もちろん無料です。
登録する方法は

１・名前欄に『fusianasan』（半角）と入れる。
２・名前欄隣のＥメール欄に『名前・職業・年齢』を入れる。
３・本文に『SG作動』と入れる。
４・最後に『書き込む』を押す。

以上これだけです。
一度登録すれば、電話番号を変えない限り継続されます。

出張が来ると、どの板も下品な荒れ方するねぇ。
知性の感じられないハッタリ議論は、こちらでどうぞ。

　例のハッタリ野郎について
　http://science3.2ch.net/test/read.cgi/infosys/1088029040/

電話番号ってあたりにダイアルアップ時代の残滓を感じる。

>>2 の時点で、この板のラベルが低いのはわかった。

まあお前らにはレベルが高すぎるだろうが、一応紹介しとく。

なぜArcはとりたててオブジェクト指向でないのか---
ttp://www.shiro.dreamhost.com/scheme/trans/noop-j.html

わははははっ。

OOエキスパートつうのは、20年くらい前に
Lispの処理系やコンパイラーを書いたり、
Lispのオブジェクト指向拡張をやったりした上で、
その経験をオブジェクト指向技術の展開に生かしたりするわけだが、
>>606は未だにCommonLispが最高だと勘違いしてるのか。痛いな。

国内で最初期にCommonLisp処理系を作った人たちのうち少なくとも一人は
後になって「Lisp自体はそれほど好きではない」って言ってるけどｗ

Paul Graham wrote:
＞私が単にばかなのかもしれないし

そう、あなたはばかです。

データベースがリレーショナルモデルで排他制御するからなー。
ORマッピングで破綻しちゃうー。

>>610
意味不明。頭大丈夫か？

>>606
SchemeマニアのWikiか。

>>611

年収400万円でえらそーに。

↑頭がおかしい人
　昼間っから夢見てんじゃね〜の？

ここ読んでると大学でやってることもまんざら無駄ではないんだなと
思いました。

スレ読まずに
■■■■終了■■■■

>>610
俺は言いたい意味は分かるよ。
お前は度量狭すぎ、頭悪すぎ。

>>610
ObjectStoreでも、使ってみる？

インピーダンスマッチングの苦労はないよ。

最近はしらねーけど、昔はWindowsのアプリーケーションメモリ空間に
リニアにマップするので、すぐ飽和してたな。

でもRDBってのは、RDBであることに意味があるのでな。

生で使うよりRDBをObjectにキャッシュしてくれる使い方の方が、受容れられやすい。

>>606
強力な言語を使っていると型の必要性を感じない、という主張は
分かるけど、この人の住んでいる世界が、この人のいう中庸世界とは
違うな、と感じた。
一人ないし数名でコードへの理解度が高い状態なら型は欲しくならない
かもしれない。
だけど人が入れ替わりで20人という開発形態では人の書いたコードを理解する
上で型は有用、さらにいえば静的型のほうが面倒がない。
つか、型あってもいいじゃん。この人が言いたいのは型がないという
理由である言語を十分に強力でないということは間違っている、
てことなのかな。そんなん別に頑張るところじゃないと思うけど〜

あと感じたのは選民思想だね。
LispとかSchemeなんかの関数型言語が強力だってのに異論はないが、
それを使いこなすのに必要な知的バックグラウンドについて
配慮がないと思った。みんなが全員自分と同じだけプログラム技術に
打ち込むのが当然、そうでないの頭のワルいやつというふうに
考えているように見えた。
関数型言語を自在に操るようなお方に、技術的には簡単だが手間はかかる
業務系画面のプログラミングをしていただいて、給料の安さに不満を
言われたら困るんで、フツーの手続き型言語が主流なのは至極
自然状態と思います。

>>610
・分散トランザクション
・コンテナ管理トランザクション
・AOPベース軽量コンテナによるトランザクションアスペクトの分離
程度は理解しておけ。
そして、「既存のコンテナは云々」なんていわずに、
自分でフレームワーク拡張してみれｗ
言語不明瞭なキミには無理だと思うけどｗ

ここ一〜二年は、NTTﾃﾞｰﾀもNRIも、アスペクト指向を基本技術の一つとして扱っているﾓﾅｰ

>>620
610は言語不明瞭は同意だが
お前の場合は「理解」という言葉が軽すぎ。同時アクセスのない環境
（ことによると自分のデスクトップレベル）で動かして喜んでいる
匂いがぷんぷんする。だいたい
・分散トランザクション
・AOPベース軽量コンテナによるトランザクションアスペクトの分離
でどうしてロックインが減るのか説明してみろよ。まったくもって
意味不明。

来ました！必殺！「問題定義明確にせず、勝手に回答ひん曲げ」技！！！

あのさぁ、知性のある人間ってのは、
問題定義を明確にして、次にその問題をいかに解決するか、を語るものだ。
お前の場合>>610
　　　　データベースがリレーショナルモデルで排他制御するからなー。
　　　　ORマッピングで破綻しちゃうー。
禅問答かよ(大笑い

そんなんじゃ、誰も付いていかないよ。残念。

>>623

いや、この人の場合は、
問題定義を明確に語らず、誰も反応しないのを見て、
一人優越感に浸る、という歪んだ行為をずぅーっとやってる可哀想な人だよ。
・・・知識や知性ってのは共有してこそ初めて意味があるのに、
　　その交換を喧嘩腰で相手の気分を害させる形でしかできない人。

まあDB屋ごときに熱くなるなって。

ここはRDB屋の来るスレじゃないよ。
続きの議論はこちらでどうぞ
　DB＠2ch掲示板
　http://pc5.2ch.net/db/

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=RDB+%E3%83%AD%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3&num=50
RDB ロックイン の検索結果のうち 日本語のページ 約 27 件中 1 - 19 件目 (0.35 秒)

もしかして、RDBの排他制御とかデッドロックを語ってる？(ｗ

おれは610にあらず。
お前さんにとっちゃ反対意見言う奴は
全部同じ「敵」って人格なんだろうな。全く活かした
抽象化能力だこと。
なんでもいいけど自分の発言には責任持ってくれよ、
他人のことはいいからさ。

せっかくのオブジェクト指向設計も
負荷テストでデッドロック多発ではたーん。

残念。

結局、概念と単語の結びつき方が特有で、他人には理解のできない単語遣いをしたり、
問題定義をちゃんとせずに、禅問答みたいな説明をしはじめちゃうから
この人の話は他人に通じないわけね。

本人が気づかない限り、一生理解は得られないままなんだろうな。

■■■■終了■■■■

＞お前さんにとっちゃ反対意見言う奴は
＞全部同じ「敵」って人格なんだろうな。全く活かした
＞抽象化能力だこと。
＞なんでもいいけど自分の発言には責任持ってくれよ、
＞他人のことはいいからさ。

すげぇ妄想だなこいつｗ

＞なんでもいいけど自分の発言には責任持ってくれよ、
＞他人のことはいいからさ。

ここん所がすげぇー笑える。
無闇やたらに知的物乞い行為に走るんじゃなくて、
まず問題定義をちゃんとしてから、丁寧な言葉遣いで質問しろってｗ

オブジェクト指向だけしか知らないんじゃなー。

事務屋サン必死だな。
サイエンス畑の話題も、数学的な基礎付けの話も通じないから、
話題の振り方に困るよ、実際

http://www-106.ibm.com/developerworks/library/i-booch/booch_photo.gif

こいつら、役に立つシステム作っているのか？
というのが、このスレ読んでの感想。
張りぼてのモデルルームを彷彿とさせる話ばっか。

その煽りもう秋田。

RationalがIBMに買収されちゃったから
何を言っても説得力に欠けてしまう。

その煽り古杉。

オブジェクト指向開発に移行することを悩んでいる20名弱のソフトハウスの責任者です。
仲間の会社の方にも色々相談したのですが、２社ほど移行に挑戦したところがありまし
た。両者とも、有名どころの研修を受けコンサルをいれたけれども結果としては、オブ
ジェクト指向開発ができているといえるような成果はでておらず、オブジェクト指向を
学んだだけになってしまっているようです。
やるきのある社員の提案であるので、全面的にバックアップし、仕事に対する遣り甲斐
を与えてあげたいと思っているのですが、VB+ORACLEの開発をメインとした受託開発であ
り、しっかりとした設計は行っておらず、現在の所設計に関するスキルやセンスがかな
り不足していると私もその社員も客観的に認識しています。小さな会社でり、ビジネス
なのでお客さんに迷惑をかけることはできません。
ある知り合いの技術者に聞いたところ、受託開発でオブジェクト指向開発をうまくでき
ている所はとても少なく、うまくいっているところは一つの製品を拘りながら作りこん
でいく必要があるパッケージソフト開発をしているところであるということも聞きまし
た。なるほど、一つのものに向かい合うことで、深く学ぶ機会になると思いました。
受託開発だとリスクが高くて身に付けるのに多くの時間が必要であり、根気も続かなく
なるように思いました。
現在の所、オブジェクト指向開発を段階的に導入していこうかとか考えています。
とってくる案件も、オブジェクト指向言語を使う必要があるものにし、その言語になれ
ながらトピック的に色んなテーマを学べるような取り組みを考えています。
ただ、情報不足で踏み出す勇気または止める勇気をもてないでいます。
どうぞ、２ｃｈのみなさん。
わたしのところは、こういう風にしてうまくいったとか、こういう風にしてうまくいか
なかったとか、あきらめたとか、あきらめなくてよかったとかそういったお話を含めて
お話を聞かせていただければと思っています。
どんな情報でも構いませんので、よろしくお願いします。

>>639
オブジェクト指向は取敢えず頭から外して、
旧来から言われる、実装の基本、設計の基本、管理の基本を身につける事。
組織的にオブジェクト指向開発を行うには、それだけの準備が必要。

個人であれば、イキナリオブジェクト指向開発でも
可能（やっているつもりになれる）だが組織レベルでは十中八九無理。
オブジェクト指向開発で持つべき認識は「する事」ではなく「していく事」。
組織は物事を形骸化し易い性質を持つから、そこが可也問題なワケ。

因みに、オブジェクト思考開発に措いてコンサルが、
どの基礎知識や基礎技術を（時間を掛けてでも）身に付けなければいけないか
明示してないようであれば、気をつけろ。

そいつ奴等は、
オブジェクト指向開発とは？を述べる事が出来るが
システム開発とは？という基本的問いに答えれない。
まぁ、こんどお酒にでも誘って、少し試してみろ。

なんちゃってコンサルでも知識は出来るだけ搾り取っておけ、
間違っても、英会話教室に行けば英語が覚えれる様な馬鹿な思考は持つなよ。

あんたが変わらなきゃ何も変わらないんだ。
オブジェクト指向開発が君等を変えるんじゃない。
自分達が望む状態にする為に自分達がする事のサポートとして
オブジェクト指向開発技術を少し利用するんだ。

がんばれ！
by 就職活動中の学生より

とまあ、学生でもコレくらいは言えるんだね。

オブジェクト思考で開発された開発ツールとパッケージ使用するとコーディングとユニットテストの工数は少なくなるから使わないよりは使った方がお得ですよね

>>640
会社起こしてくれ。
んでもって軌道に乗りそうなら雇ってちゃぶ台！

まさに机上の空論や妄想だな。

>>644
コンピュータシステム自体が机上のお話ですが？
問題を切り分けて考えられては如何でしょうか。

コンピュータシステム自体は社会学や組織論の問題かと

>>646
意味がわからんのですが、、、
コンピュータシステム＝社会学 and 組織論
ってコト？

コンピュータシステムじゃなくてシステム開発の仕事って言いたいんだろうな、
きっと。

論点ずらして逃げ回るだけの破綻者か。

■■■■終了■■■■

http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html

衝撃！！！！！(でもなんでもないけど)
年収４5００万プログラマーを自称し、
自作ＰＣ板を中心に活躍する、
人気のコメンテーター「◆Rb.XJ8VXow 」こと、
通称「出張３２」氏は Ｃ言語プログラミングは
おろかSIMD(MMX,SSEなどの処理系)を
SIMMと書き続け、 超超超初級
プログラム問題さえも解けない、
完全なプログラミング素人だった




これは自作板で出張３２氏が立てた、氏の愛するＣＰＵ、
Pentium4の新コアPrescottベタ誉めスレでその出張３２氏のつづる、
ハッタリとおとぼけのストーリーだ

>>640-648
悲惨な書き込みだな。
だいたいその元ネタ、３年前のコピペやん。
頭が悪い人は変な書き込みをして困るでごじゃる。

>>640-648
確かにキチガイだこいつ。

>>648
あ〜納得。解説ありがとう。
そうであれば、>>646の意見は同意。

>>649-652
は何が言いたいの判らん。
ここでの発言は全て出張氏の話にしたいみたいだけど、そうとう粘着君だね。
類友か本人なんだろうね。

コピペっぽいが不快なのは変わらん。
ここまでのアンチ厨を作り出してしまう出張氏って
スゴイ。責任とって相手してくれと言いたいが。

>>653-654＝出張３２

>>653-654のような狂人が住み着くスレ

■■■■終了■■■■

>>443
ホレヨッ。数年前に漏れが書いたレポートだ。糞には理解不可能だろうがコピペしといてやるよ
235 名前： デフォルトの名無しさん [sage] 投稿日： 03/08/19 21:19
　俺にレポートせよとおっしゃる？無理ぽ。
Eiffelは、まぁ、Design by Contract 入れた、普通のOO言語だな、
というのが漏れの印象。
8年前にNEXTSTEP買ったけど、当時も今もまるで興味が沸かない。
あと、質疑応答が結構おもろかった。
いわく、
・Design by Contract は、古典論理で逝けますか。YES
・post condition を分析に役立つ概念としていますが、
　それは(形式仕様による)プログラム定義とは見なせませんか？No
・OOPの今後(の発展)はどーよ？
　1)OO技術自体の洗練がどーたらこたら
　2)数学的概念や形式的手法の導入による、厳密化
　3)ObjectStoreの活用(ODB,ORDB,O-Rmapping等)
・AOPはどーよ？
　Aspect は、えー、(以下10分近く長ーい説明)
　Refactoringによるプログラミングの等価変換すら認めない人がいる。
　アスペクトでも等価変換の概念が必要だ。(脳内妄想要約)
・(主旨のよくわからん質問。Contractのパターン化？)
　最初の簡単な質問に答えた後、延々10分近く長ーい説明。

とにかくパワフルなオヤジで、英語がろくに判らない漏れでも、
口調と単語でおぼろげな意味が理解できてしまう、という
情熱的な教育者＋事業家タイプ、と判定しますた。
Bertland Meyer程の人でも、アカデミックでディープな話題よりも、
自社開発環境の特徴を延々説明してしまうあたりは、
ソフトウェア技術者の佐賀を感じて、なかなか好感が持てますた。

３年前の内容をコピペする人もそれを覚えている人も記憶力いいね。

↑平日昼間っから２ちゃんに入りびたりの廃人

NextStepもObjective-Cも消滅して久しいのに
3年前になぜそんな時代遅れな書きこみをしてるんだろう？

↑今日一日２ちゃんに張り付きっぱなしだった、コンピュータサイエンスも知らない廃人

>>657
昔はEiffelぐらいがサポートしてるだけだったHoare論理
の遠い末裔である制約記述言語OCL2が、
今じゃMDAの主要要素の一つになってる。
時代の流れは速いね。

>>619
> あと感じたのは選民思想だね。
そもそも選民思想を感じた、という意見の表明が有効な批判と思い込んでいる感性が
痛いよな。それこそ悪平等主義な教育に骨の髄まで毒されているというか・・・。
『ハッカーと画家』でも読んで勉強しなおせ。

差別主義者も、被害妄想も、いらない。
きみら、人権板で議論するのがお似合いじゃないか？

>>635
おれもそう思う。ただのお勉強の成果発表してるだけみたい。

>>665

おれもそう思う。こいつら学生なんじゃないの？
実績のないクソ手法ばっかり。

なに？おまえ揚げ足取りばっかの馬鹿じゃん。
死んだほうがいいよ

のっぺらーっとした単調な煽りに、
人間性の卑しさが染み出てるな。

頭悪そうだしｗ

スレがオブジェクト指向からどんどん離れていく・・・

みんな、ルールに従おうぜ。愚痴吐くなら同僚と酒でものみながらやってくれ。

あと、中身のない煽りは、馬鹿に餌を与えるだけだから、完全無視でよろしく。

オブジェクト指向が学生指向になっていく・・・

>>669
中身の無いレスは完全スルー、ね。了解。

そう、スルーね。

>>524
最近の工程管理ツール〜開発プロセス管理ツールの普及状況はどうよ？
国内は大手メーカー〜SIerが、独自の管理ツールを持ってるから、
サードパーティがツール作っても、なかなか商売しにくいと思うけど。
ユーザー企業の情報システム部門にでも売り込むのかな？

C++の悪口言う前にこれぐらいは読んでおいたほうがいいね。
http://www.amazon.co.jp/exec/obidos/ASIN/4797328541/

>>672
いきなり学歴を持ち出す辺り、かなりのコンプレックスがあるようですね。

>>674
なんで C++？唐突ですね。

OOの話題って最近だと何があるかな？
AOPやORMappingとの関係とかかな。
MSがやってるDSLとかはどーなんだろ？

C++はメモリーリークを見つけにくいからな。
それで、デストラクタを書かなくていいJavaが学生向きだ。

>>675
いえいえ、それほどでも。
学歴コンプレックスを感じた事など一度もないけどｗ


>>676
DSLって何ですか？

>>674　は、自分自身の意見を言葉にする努力をするべきだ。

Microsoft Tools for Domain Specific Language (DSL)
マイクロソフトのMDA発展系技術、とでも言うべき物かなぁ〜
http://www.microsoft.com/japan/msdn/vstudio/2005/teamsystem/workshop/DSLTools/walkthrough.aspx

http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2096
マイクロソフト、Visual Studio 2005 Team System用の新しいビジュアル モデリング ツールを発表
〜広範なパートナー企業群の専門技術を背景にした特定領域向けモデル開発を促進〜

つう事で、MSのリサーチ担当重役がACMの会議で
「今後10年に予想されるソフトウェア開発の変革」と題した演説を行って、
そこで Visual Studio 2005 Team Systemをプラットホームにした
visual modeling tool　を発表した、と。

あれまぁ、ドメイン駆動開発 (DDD)がテーマらしいぞ、この技術は。
２ちゃんでDDD本のドラフト版のURL教えてくれたおにいさんが居たっけなぁ。
まだよく読めてないけどｗ

>>677
パッケージ開発〜基盤系では、普通Purify入れてる。

>>681
Dimain-Driven Design
http://www.domaindrivendesign.org/

>>681
Domain-Driven Design
http://www.domaindrivendesign.org/

>>644
お前頭悪そうだな。
実際にオブジェクト指向で開発した経験がろくにないだろ。

>>666
学生様をなめすぎ。
大学院生としてさらに企業でアルバイトしてる俺様に
言わせればおめぇがクズにしかみえねぇな

>>628
> せっかくのオブジェクト指向設計も
> 負荷テストでデッドロック多発ではたーん。
>
> 残念。

そいるはテスト手法をしらずに開発しているために
破綻しただけであってオブジェクト指向設計をしたから
破綻したというわけではないな。
使い方がわからずなんでもかんでもオブジェクト指向を否定する奴は、
PCが企業に浸透しようとした当初、
PCの使い方がわからず破綻して「パソコンなんてないほうがいい」
といってる奴と同レベルだ。

何も知らなければ何もこわくはない。

>>674
最近はVisual＋Model駆動開発が流行ってますね。
そんな中で「ドメイン」を中心に据えたマイクロソフト、さすがという感じがしました。
ところでその「ドメイン固有言語」とやらは、各業界の既存のノーテーションを包括する形なのでしょうか？
それとも、これからマイクロソフトが中心になって各業界と提携して図面の規格を決めていくとか・・・(悪夢だ

大規模開発とやたの現場に顔出すと、もう毎回
「ドメイン分析は(時間的に|能力的に|工程分担的に|ドメイン知識がないから)できない、からやらない」
という情けない話を繰り返し聞かされて、いい加減苛立ったりするわけですが。

大規模開発とやらの現場に顔出すと、もう毎回
「ドメイン分析は(時間的に|能力的に|工程分担的に|ドメイン知識がないから)できない、からやらない」
という情けない話を繰り返し聞かされて、いい加減苛立ったりするわけですが。

Visual Studioだけでしか通用しないゲテモノだな。

>>690,691
つまらないタイプミスの修正だけのために、紛らわしい2重投稿まがいのことをされるのにも
いい加減苛立ったりするのもあるなあ。

>>689
ドメイン固有言語のプラットフォーム中立性が気になるね。
まぁ今時、XMLでデータ交換可能、なんてのは当たり前だと思うけど。

>>681

> ２ちゃんでDDD本のドラフト版のURL教えてくれたおにいさんが居たっけなぁ。
> まだよく読めてないけどｗ
そりゃ、黙ってた方がよさそうだぞ。
恥かくまえに（ｗ

>>694
Domain Specific Language の基礎技術としては
ナニが必要だと思いますか？

・・・オントロジー記述言語、論理フレームワーク、推論規則(￣ー￣)ﾆﾔﾘｯ

>>695
それが不思議と、まだ国内ではほとんど話題になってないんだよねぇ。
もちろん、高卒の学生さんには理解は無理だと思うけど。

>>697
ということにしておきたいのですね。

>>698
中卒のオマエができるんだから頑張ってみるヨ。

>>697
動的なモデル作るには、アクション・セマンティクスは必要でしょ。UML1.5から入ってきてる

スレが所々あぼーん表示になってるんだけど、なんでかな？
まあいいや。気にするまでもないｗ

>>696
実際自分で作るとすると、グラフィック・エディタ周りが一番ややこしそうな気がｗ

>>684
THX!
今まで見落としてた。
今度読んでみるよ

知らない事を恥ずかしい事だと感じ、知らないという事を隠す人＝進歩のない人
知らない事であっても一定の方法で扱って知識を深める事ができる人＝進歩する人

という事でつね。

>>684
その本去年の10月に、某経理プロジェクトに持ち込んだんだけど。
丸っきりチンプンカンプンな顔されたよ。
事務系業務屋って、そのあたりに踏み込めないなんか心理的壁みたいのがあるみたい。
さりとて、戦略提案！！！とかしてくれるわけでもないし。

業務系にそんなプリント持ち込んだら、普通引くよ。
単なるマニュアルや仕様書は読まにゃ仕事がはかどらないから読むけど、
分析手法や方法論は、読んでも即戦力にはならないからねぇ、
現場に持ち込んでも混乱するだけでしょ。

本当にやりたいなら、勉強会とか場を設定しなきゃ

>>705

> その本去年の10月に、某経理プロジェクトに持ち込んだんだけど。
> 丸っきりチンプンカンプンな顔されたよ。
こういうこと得意げに書いているところが、お里が知れるって感じだよなあ。
ようするに俺が持ち込んだ方法論がさっぱり理解されない馬鹿ばっかりです、
って嘆いて見せたいだけだろ？
お前さ、その組織のレベルにあった方法論、開発手法を持ち込んで（あるいは
上手く導入させて）プロジェクト成功させなきゃなんの意味もないじゃない？
チンプンカンプンなのはお前の思考のほうだよ、まったく。

このスレ読んでいる奴ってさ、難しげな開発手法以前にワインバーグやデマ
ルコでも読んでいるのがお似合いじゃないの？

あるいは最近多い「SEのなんちゃら」みたいなゾッキ本か（ｗ

エンドユーザさんが、その辺(ドメインモデリング)や開発プロセスに、すごい自信と関心があるって言うから。

ユーザさんの琴線に触れる提案作るために、少しでも脈のありそうな素材片っ端から集めて、
提案チーム内輪のブレインストーミングに供するのは普通の事だと思うけど。
(提案し取れても受けるかどうか不明(謎)とか、ユーザさんからまだ業務資料見せてもらってない、入り口段階だったし)

>>707
またずいぶんネガティブな考えをする人だな(呆

フリーのオブジェクトDBといえばZODB
ZODBといえばZOPE
ZOPEでここまでできるんだよ
http://secretroom.v37.jp/

>>708
まぁ普通ですな。

>>709
いや、考えはネガティブでもないだろ。少しでも自分の
環境に受け入れられそうな方法を考えて実践していけって
ことでむしろポジティブ。でも書き方はネガティブね、2chだから
しゃーない。
705読んでも自分の組織に受け入れられるように知恵を絞った形跡が
感じられんよ、漏れも。

あ、そう。
なんか元役員の人が、すごい興味を示してくれた。
さりとてそれで、直接関係のある仕事が舞い込んだわけではないけどね。

>>705
自分自身の手で技術なり、プログラムなり、理論の実践なりできない人は、
周りの環境に合わせてやっていくしかない、と思う。

そうでなければ、今はｲﾝﾀｰﾈｯﾄもあるし、
最新製品開発のための基礎研究成果をｵｰﾌﾟﾝｿｰｽで晒してくれる大企業も多いし、
別に、話もろくに通じない仕事環境に拘泥し続ける必要はないんじゃないかな。

まぁ頑張ってくれ

>>713
だから何？
と思わずききたくなるカキコばっかりだな、お前は。

>>714
さりげなく差別発言しているのが、嫌味だな

>>715 お前モナー。
　　　　お前の書き込みってつまらない。砂漠の砂を噛んでいるように、果てしなく退屈だ

今日のNGワード：「お前」

>>715-718　
喪前ﾓﾅｰ

>>696
メタデータ、リレーションシップ、プロパティ、そして継承 (爆

＞720　
その前に、概念 と モデルエディタ・ツールキット

>>714
お里が知れる？いや、
ローカルコンテキスト共有してる相手に
理解できるように書いてるんだが。
コンプレックスだかプライドだかの厚い鎧を着ている人には、
なかなかこちらの善意や理念ってもんが伝わらなくて、困る。

まぁ>>714は御託並べる前に、
前後のレスを100回は読み直せってこった

>>722
　>>707に言えよ

>>722

> ローカルコンテキスト共有してる相手に
> 理解できるように書いてるんだが。
> コンプレックスだかプライドだかの厚い鎧を着ている人には、
> なかなかこちらの善意や理念ってもんが伝わらなくて、困る。
爆笑

これだからﾎﾞｷｬﾌﾞﾗ貧しい厨は・・・

結局、デカイプロジェクトにぶらさがって、
自分では手を動かさずに、人月稼ぐのが目的とちゃうかぁ
>>707の言う「プロジェクトを成功に導く」って

ぶら下がるプロジェクトを探すなら、大手SIerに行った方が近道だぞＷ

>>726
> 結局、デカイプロジェクトにぶらさがって、
> 自分では手を動かさずに、人月稼ぐのが目的とちゃうかぁ
それ、この業界での生き方として正しすぎる。
ラクな方がいいにきまってんじゃん。んで、空いた時間で好きなプログラムを書くと。

（・∀・）

折れは無気力な人と顔合わせるの苦手だからバス。

>空いた時間ででプログラミング
ﾊﾞｸｼｮｳ

うざい馬鹿ガキばっかやのう。

閑話休題


旧:文化オリエント／現:グレープシティに関する都市伝説
(身寄りの無い人間集め、人材派遣＆コンポーネント開発販売した資金で、
誰もが眼にする宗教活動しているとのウワサ)、


アナタはどう考えますか？(ﾏｼﾞ

>>729
バス？

だいたい一流の技術者は中小やフリーにいる。メイカーの関連会社とかなんて、大手と
言っても屑ばっかりだよ。収入だってたいしたことない場合が多い。
で概して前者の方がオブジェクト指向についても造詣が深い。上の書きこみ読んでも、
レベルの高い奴がおおいのは自明だよね。
俺なんか大手のSIerとみなされている会社の奴と仕事したことあるけど、無気力な上に
UMLさえ知らなかった。
もう馬鹿としかいいようがない。

>>733
まあ、上の書き込み見ても、レベル高いとは思えんが....

>>733
大手SIerの内部事情を知らない、外注さんらしい発言に(爆笑
まあ、外注に頼む仕事なんて、人月幾らですめば差額が自動的に利益になる、
屑ぃ仕事ばっかだもんなぁ。

例えば、アスペクトじゃない方のAOPなんて、
大手メーカの有閑知識階級の手遊びとして発展してきたようなもんでしょ、国内は(あそことかあそこ)
サイエンス〜アカデミック分野への分散オブジェクト指向技術適用、なんてのも、
どーでもいい汚れ系プロジェクトは子会社に契約段階から丸投げして、
無茶苦茶出来る香具師が遊んでた気配がする。

おまえの世界狭すぎ。痛い

あと、お前さんには理解もできないんだろうが、
大手メーカの場合はお前が一緒に仕事するような相手の上に、
ソフトウェア「開発技術」専門の部隊があって、
その上にソフトウェア研究部門でしょ、
上下関係はないけど力関係ではハードウェア製造部門がその上にいて、
その上に製品研究開発部門があって、
さらにその上に「基礎研究所」があったりするわけ。

そーゆーヒエラルキーを意識した上で、
「一流の技術者は中小やフリーに居る」なんて戯言いえるか？

>>735-736
おい、>>734を良く見ろ
＞俺なんか大手のSIerとみなされている会社の奴と仕事したことあるけど

おばかちんでつねぇ

プロジェクトを成功に導く、なんて土方じみた仕事イマドキ流行んねぇんだよ。
今の流行は W大でMOTの資格取って、研究のリスクマネージメント。これ最強

>>737
おい、>>734を良く見ろ
もしもし、734ですが、何か？

うざい馬鹿ガキばっかやのう。

研究者、学者が偉いという考えは、ドラえもんに「君は実にバカだな」って言われるぞ。

さ〜てと、ｱﾌｫは放っておいて、
勉強会の講師の準備しなきゃ

スレがオブジェクト指向からどんどん離れていく・・・

みんな、ルールに従おうぜ。愚痴吐くなら飲み会でやっててくれ。

中身のない煽りに反応すると、馬鹿に餌を与えるだけだから、完全無視でよろしく。

本日のNGワード：「俺なんか」「大手のSIerとみなされている会社の奴」「研究者、学者が偉い」

スレタイに沿ったレスをかえすと
・大手の凡庸ＳＩer>役に立たない
・中小の優秀な技術者・大手の優秀な研究者>役に立つ
で終わってしまうので面白くないのだろう。

>>743
お前みたいなのが一番荒れる原因なんだよ。

>>745
スレ違い。

僻み根性丸だしだな

>>744
折れなんか大手とみなされるＳＩｅｒの奴も使ってる、
エラい学者が書いた研究社の辞書持ってる(鬱

研究社の辞書もっているとだめなのか？　リーダース英和とか良く使うけど。

このスレたてた人へ：
オブジェクト指向はあなたが会社に入った頃に流行っていました。
（とうじ従事していた研究所では、unix4.2bsd と oopsがブームだった）
いまや、学校で情報システムの歴史としての話題でしかありません。
いまさらウップスを話題にするなんて、まったくノビタ君だね。

ははは、おじさんだね。
1990年前後から専門課程でML (meta language)使う所が増えてて関数言語ブーム、
1992年前後から趣味で*BSDやPC-UNIX使うPC-UNIXブーム、
1996年前後から実習でJavaをプログラミング使う第二次OOブーム。
インターネットブームは、1984年頃〜1996年頃まで時期にバラツキがあって、お里が知れる指標ブーム
ってところか。

＞（とうじ従事していた研究所では、unix4.2bsd と oopsがブームだった）
＞学校で情報システムの歴史としての話題でしかありません。

そりゃそーだ。OOはどっちかっつうと産業界発の経験知の集積だからね。
MDAやEMF,DSLみたいなのをアカデミックでも研究してるとしたら、それはきっと企業の基礎研究所みたいな所だろ

>>752
　EMF開発したのは、WebsphareStudioの製品開発部隊だよ。

＞unix4.2bsd
ずいぶん古い人だな。
漏れが院で遊びに使ってたのは 4.4BSDだった。
それからしばらくして、例のBSDI vs USLの騒動があって、
ATTソースコードを含まない4.4BSD Lightがリリースされた。。。

学生が唯一書きこめるスレになってきたな

学生はこのスレに居ないよｗ
下請派遣のおさーん頑張れｗ

RUPしてればいいだけでしょ。

過去最大規模で開催：4月26-27日・東京（青山テピア）
　── ビジネスとITの融合が、いま始まる!! ──
-------------------------------------------------------
◇プログラム最新情報はこちらを確認してください↓
　http://www.otij.org/UMLForum2005/

＜UML Forumニュース＞-----------------------------------
★最新情報：スティーブン・メラー来日決定！
組込ソフトウェア技術における工学的手法導入のパイオニアである、
S・メラー氏の来日が決定！1980年代の「メラー法」以来、つねに
モデル駆動開発の先頭にあった同氏が、モデルの変換／実行技術
の現状と展望を明らかにします（27日＝詳細次号）。

★UML vs DSLs (!?)
マイクロソフト社が推進するモデル駆動"Software Factories"が
明らかになるにつれ、MDAとの関係、そしてUMLの位置づけ等に
ついて活発な議論が巻き起こっています。本フォーラムでは、
マイクロソフトの萩原氏、ボーランドのシンディ氏が、両陣営を
代表して競争と協調の現状を語ります。（26日）

★「エクリプス」関係セッション多数準備中
オープンソースJava統合開発環境(IDE)プラットフォームを提供する
エクリプスファウンデーション、マイク・ミリンコビッチ会長による
基調講演をはじめ、欧米で大ブレイク中のエクリプス環境の最新情
報を紹介するセッションを企画中です（26、27日＝詳細次号）。

http://www.umlchina.com/Chat/pics/mellorphoto3.jpg

>>758
>
> ★UML vs DSLs (!?)
> マイクロソフト社が推進するモデル駆動"Software Factories"が
> 明らかになるにつれ、MDAとの関係、そしてUMLの位置づけ等に
> ついて活発な議論が巻き起こっています。本フォーラムでは、
> マイクロソフトの萩原氏、ボーランドのシンディ氏が、両陣営を
> 代表して競争と協調の現状を語ります。（26日）
こういうのって聞きに行く価値あるの？

http://enterprise.watch.impress.co.jp/cda/static/image/2004/10/12/Booch.gif

http://www-306.ibm.com/software/rational/bios/img/rumbaugh.gif

http://www-106.ibm.com/developerworks/rational/library/content/Authors/G-L/jacobson.gif

>>761-763
オチとしてブーチが最後にくるような順番の方が面白いのでは?

メロー：　　　ユルそうだけど、インテリジェンスがあふれる面構え
ブーチ：　　　MITに居室持ってるほうの、教祖様顔
ランボウ：　　名前は「荒野の魂」だが、どっちかっつうとロジシャン顔
ヤコブソン： 「昔はいろいろやりました。で、今度の投資の件だが」顔

※上記は実在の人物の人間性とは一切関係ありません、てばぁ

>>760
討論にM$の彼が入ってる時点で、グダグダな展開になると思うよ。
M$の翻訳ドキュメント (特に重役向けブリーフィング資料)って、
原文も翻訳も非常にくどくて疲れる時期があったけど、あれと同じさ>>M$

競争激しそうなM$でも、どーかとおもう人物が長年エバンジェリストやれる、という事実

MSがなんでも悪いわけではないと思うけど、このスレでまともな議論にはなりそうもないから
そういうことにしとこう。

↑M$のドキュメント(特に重役向けブリーフィング資料)など、原文でも翻訳でも読んだ事の無いヒト

M$って表記する奴ってバイアスかかっている奴多いよね。
まともな議論は望み薄。洗脳されちゃっているからさ。

Martin-Lofの型理論に基づくプログラム合成

形式的に記述された仕様から、その仕様を満たすプログラムを合成することを可能とする理論として、構成的型理論がある。
構成的型理論はCurry-Howardの同型対応により論理体系に対応している。プログラムの仕様を記述するための十分な表現力
を持つ論理体系に対応する型理論では、プログラムの仕様を型を用いて形式的に記述することができる。ある変数がこの仕様
を表す型の要素であるという判定を構成的型理論のもとで成り立つかを証明できれば、証明から具体的なプログラムを抽出でき、
結果的にプログラムを合成する事が可能となる。

>>770
M$リサーチといえば、RDB研究者ベスト10の何割か、
関数型言語のコアな研究者を飼ってるので有名だが、
なぜ論理屋を買占めなかったのだろうか？

>>771
a. 論理は金にならないから
b. ビルゲイツは数理論理が大嫌いだから
c. 論理屋は世界が自分中心に回っていると思っているから、金で飼われるのに耐えられない

>>770
なつかすぃ〜。
林晋せんせーのPXだね。
学生時代には、これが90年代のコンピュータサイエンスだと思ってました(汗
あと漏れは物性屋見習いだったから、DNAコンピューティングちっくな展開も多少期待してた。

皆が夢みてた90年代のコンピュータサイエンスは今どこに？！
ちなみに、↑に名前挙がってるネタは全部 Lisperの仕事だったりするのがいやはや

やっぱりLispか。

ボスキャラは1978佐藤雅彦せんせいなそーな。
・・・やっぱLispというか、文法単純で抽象度高くて一般性高い言語って
Lispしか無かったんだな。
今ならXMLでRELAXERとか、XMI＆OCLでMDAとか、いくらでも展開があるけど。

Dr.Gが常駐してた時代が懐かしいね。
今じゃこの板、廃墟と化している。

某所のイベントに参加。
とってもクリアーな技術説明に非常に共感。どっかの、二言目なは「お前は判ってねえ」が口癖の自称コンサルとはえれぇー違いだ。
相手の共感呼び起こす能力欠いた人物が、いくら仮ｽﾏを事故演出しても、所詮ﾏﾏｺﾞﾄだ、と感じた。

　

>>777
＞どっかの、二言目なは「お前は判ってねえ」が口癖の自称コンサルとはえれぇー違いだ。
これってどこ？

前レスを6.02×10^23回読み直せ

>>676
もうずいぶん前の話題だけど、JDK5.0 Tigerで導入されたメタデータ/Annotationsの技法がなかなか面白いと思った。
M$.NOTでいうと、Attribute でメタデータ指向とか逝ってるあたりのSun/Java流のソリューションね。

遠くHotjava/JDKα版〜JDK1.0の昔には、HORBがJava classファイルを解析して言語情報を取得してたのが、
JDK1.1あたりのRMIで java.lang.reflectのリフレクションAPI経由でアクセスしなさい、とかなって、
そしてJDK5.0のjava.lang.annotatonでは、言語を「宣言的に解釈」して、
ソース作成時/コンパイル時/実行時に独自の解釈や機能追加をできるようにした、とのこと。
この機能があれば、確かにAOPのpointcutの代わりになりそうだ。

「独自の解釈や機能追加」の部分は、各種開発環境やサーバ環境側が提供って事だけど、
もちろんテクがあれば開発者が作成する事もできる。
そして将来的にはAnnotationの仕組み自体をPluggableに置き換え可能にするってｗｗｗ

おら、なんだかワクワクしてきたぞ、と。

参考資料とリファレンスはこれね。

2004丸山先生第四回Annotation入門
　http://www.c-sq.com/servlet/TopPage?COMMAND=VIEW_LINK_PAGE&CAT_ID=maru_2004_no_04_dl&NAVI_TOP=event_seminar&NAVI_SUB=info
　http://www.c-sq.com/data/maru/2004/20050309/annotation_2.pdf

JDK5.0
Annotation (注釈)
　http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/language/annotations.html
Annotation process tool (apt)
　http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/apt/index.html
Mirror API
　http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/apt/mirror/overview-summary.html
JSR 175:
A Metadata Facility for the JavaTM Programming Language
　http://www.jcp.org/en/jsr/detail?id=175

Sun/Java流のソリューションと聞いただけでいかがわしい。

M$流HotJava＝ActiveXの「VolcanoCoffee」
M$流Java＝.NET, CRL, J#/C#
だからしょうがないっしょ。

>>583
　マーチン･ファウラー氏は、PoEAAとアナリシスパターンの第二版のために、
　Domain modelingに関する記述や、Domain MODEL patternを集めてるらしいよ。

　そろそろ「できない」じゃ済まなくなるんじゃないかな

　　http://martinfowler.com/
　　Recent Updates
　　　21 Mar 05: Domain Model patterns added to EaaDev
　　　Over the last few weeks, I've been working on bringing up to date some of my older work on patterns
　　　in domain models (analysis patterns), with the thought of including some of this material in the next
　　　Enterprise Application Architecture book. The main pattern I've added here is Agreement Dispatcher
　　　(a reworking from some of the accounting patterns), although I've also brought in the temporal patterns
　　　and some other accounting patterns into the EAA structure.

Ｃ言語でＯＯＰって出来るかな？

カプセル化以外は
関数ポインタ使えば出来る気がするんだが・・・
誰か挑戦汁

>>786
ナニを今更ｗ
ﾋﾞｬｰﾝｽﾄﾗｳｽのATT C++は、C言語を吐き出すトランスレータとして実装されていただろ。
漏れも５年ほど前に、CPP (C pre processor)でOO構文糖作って、ネットワークアプリを書いた事があるよ。
その前にはLispでSmalltalkのクラス・カーネルを書いた事もあるしｗ

>>787
へぇ〜へぇ〜
Javaで育った世代なんで、知りませんでした。。

関数ポインタの概念がわかればＯＯＰは理解できると思う。
古い人は何故にＯＯＰを理解できないんだ？新たな謎。

>>788
古い人が理解できないのではなく、
新しい事に対応したくはない人なのでは？

関数ポインタでオブジェクト指向を語る、といえばプロの逝ってよしの>>1を思い出すけど、
あなたは関係者ですか？ｗ

>>707
おお、それそれ。学生時代からワインバーグ＆木村泉せんせーの大ファンなんだよね、俺。
つか専門課程の先生が木村研の(後略

仕事始めて、モットーは「エゴレス・プログラミング」＆「今はできなくても、いつかきっとやる」だったんだけど、
己の限界弁えていない人間にはそーゆー志は通用しなくて、萎えまくりのここ？年ｗ

そうだ、ワインバーガーになろう！いつかきっと・・・

そうだ、ダブルバーガー食べよう！あしたきっと・・・

OSのコードはC++で書かないけどどうして？

遅くなるから

じゃOOPは遅くなると言うことだな。

後でそ〜だ水飲もう！！！覚えてたら

エンベデッドシステムってＪＡＶＡで開発されているのですか？

馬鹿ばっか

>>785
Domain Patternは、既にアナパタに載ってるだろ。
それの洗練とアップデートをしたっつうだけ

まあお前らのレベルじゃワインバーグ読むほうがよっぽど今の仕事に役に立つだろうな。
マジで。

まず人の目をみて喋れるようにしろよ。オドオドしすぎだぞ（ｗ

もう秋田。
つか、あんたつまらな過ぎ。

幼児的万能感で物を言い出すけど、裏づけナッシングだから正直対応に困る

コンサルタントの秘密

あぁ、かわいそうだから聞いといてあげるね。
オマエが今読んでる本はナニよ？

スーパーエンジニアへの道

このオヤジはIBMの社員だったんだよな。

ワインバーグに限らず、
木村泉先生の翻訳は心にしみるユーモアたっぷりの名訳が多い。
比べて、最近の木村先生以外のワインバーグ翻訳物は、
「とりたててワインバーグに愛着もないＩＴ翻訳屋が適当にそれっぽく訳しました」
みたいな薄っぺらい感じがする。

ところで「コンサルの秘密」だけど、あれは例外的に感じが悪い本だね。
何十年も前から精神分析医＆コンサルと称する不可思議商売が流行ってる国の、
どうしようもなさが満ち満ちたつまんない本だった。

俺はこれまで、兎に角、場数を踏んだ人生の大先輩
・・・「損弾薬」とか「小紋」と呼ばれる「リアルな方のコンサル」方とよく顔をあわせてきたから、
自称コンサルとか、新入社員３年目で自動コンサルみたいなのは、頭悪い肩書きだと思う。

>>805
へぇ〜、知らなかった。

>>800も>>806も「コンサルの秘密」をいま必死に読んでるﾖｶｰﾝ

>>583
　これでも読んどけ。
　こっちが10年以上悩まされてる、オブジェクト指向業界七不思議の一つを、
　こいつら (Martin Fawler ＆ Eric Evans)はｽﾊﾟｰﾝと言い切ってるんだから、
　まぁこいつらもなかなか見所がある香具師らだと思うｗ

AnemicDomainModel
ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html

ちなみに Eric Evans って、ドメイン駆動開発 (Domain-Driven Development)の主唱者ね。
つか、まーちんのお友達だとは、今日初めて知ったワナ

>>810
オマエ、なかなか見所がある香具師だな(藁

>>809
半分近くまで読んだよ。体力のある大企業のシステム開発では、
変更箇所の局所化ではなく、変更の影響範囲の局所化を重視しやすい
というようなことが書いてあるのを読んで（うちはまさにこの作り方）、
いい本だな、と思った。自分としては規模（複雑性）
がある点を越えると「大企業流」では保守性を確保して
プロジェクトを完了させるのがきわめて難しくなると考えているんだけど、
「ある点」がどこなのか示す根拠がないってのと、
「ある点」を越えたプロジェクトをドメイン駆動で
開発してうまくいった事例を誰も体験してない、って
問題があって、気合のDB中心システム開発が今日も続いている次第です。
ドメイン駆動開発の訳書でも出てベストセラーにならんかなぁ。。。

木村泉のワープロなんとか法、みたいな岩波新書の本はつまんねえ、と思ったけどなあ・・・。

http://www.amazon.co.jp/exec/obidos/ASIN/4569620973/250-1363011-4885857

日米の技術者　夢の大きさに格差
　ttp://techon.nikkeibp.co.jp/article/TOPCOL_LEAF/20050408/103559/

　興奮した。取材で訪れた産業総合技術研究所の増井俊之氏に教えていただいた一冊の本。
　帯に，「10年以内に実現する“真の知能”を持つ機械」とある。
　最初は斜め読み，途中から背筋を伸ばし，最後にはすっかり信じてしまった。根が単純なのだろうか。

　「考える脳 考えるコンピューター」。2004年に米国で出版されたOn Intelligence の訳書である。

　(中略)

　ここで取り上げるのは，本書のもう１つのハイライトである。理論を世に問うまでの，著者の経歴に胸がすく。
1979年に米インテル社に就職した著者は，脳の仕組みを解明するという大志を抱く。
早速，ムーアの法則で知られる会長のゴードン・ムーアに脳の研究グループの設立を直訴する。
しかし，世界初のマイクロプロセサの設計者テッド・ホフに諭されて，あえなく研究を断念。
その後も人工知能の総本山だった米MITに不合格するなどの紆余曲折を経て，
1986年にカリフォルニア大学にてようやく念願の知能の研究に着手する。
程なく，本書の中核を成すアイデアを構築した。

ところが，著者はここで研究生活に一旦別れを告げる。翻訳者のあとがきによれば，
大学院の標準課程を終えなければ，自分の好きな研究ができないことに嫌気がさしたという。
ここからがすごい。「それならば，ビジネスで金をもうけて、自分の研究所をつくって好きなことをすればいい」
（本書p.260）。そして，本当に実行した。2002年，著者は自費を投じてレッドウッド神経科学研究所を設立する。
今や彼は，誰にも妨げられず，思う存分夢を追い求める環境を手に入れた。
ジェフ・ホーキンス -- PDAの代名詞として世界を席巻した「PalmPilot」の生みの親だ。

>>786
X11 Toolkit Intrinsics という格好の実装例が。

何度も書いたけど、あれはＯＯじゃなくて、
LiscovのCLU言語流のクラスター指向。クラスターっつのは
データをひと塊にまとめて、その塊に対して塊の外側で操作を定義する、
というプログラミング・パラダイム。
X11toolkitのＯＯ版と言えばFrescoと言う試みがあったが、

ってこれも木村研ネタやん。何度も何度も同じ話して、飽きない？

>>817
そのFrescoがET++に派生して、
GoF本の第二章の題材になった罠。

・・・あそこに載ってるドキュメント・エディタって、
国内(fj)で一世を風靡したドローイング・エディタ kdraw/idrawの親戚なんだよね。

って何回目のループだろう・・・

InterViews〜Frescoと、ET++は、
開発動機もできるアプリも結構そっくりなんだけど、
開発元が微妙に違うみたいよ。

InterViews：Stanford大
ET++：スイス連邦工科大

ET++：Zurich 大学とスイス・ユニオンの間違いだったよごめん

某所の「オブジェクト指向カルトクイズ」並みに微妙なネタだな。

>>818
どっちも元ネタがMacApp (アップル・マッキントッシュのGUI ツールキット)のオブジェクト指向化
だから、使うデザイン・パターンも被ってる。
つかそこらの連中が集まって本も一冊出してるしｗ

　http://www.browsebooks.com/Lewis2/
　Object Oriented Application Frameworks

　　　　Ted Lewis and friends

　1995, Softbound, 352 pages
　ISBN 0132139847
　Our price: $34.95 [Add to Cart]

>>817
それ、ひろみちゅと久野先生のやりとりの劣化コピーでわ。。。

つか、JHB-1406近辺でそんな漫才やってたとは、
今日初めて気付いたｗ

>>817
クラスタ指向は知らないけれども
各 Widget クラスの behavior はクラス内に閉じ込められていて
かつそれを継承する様は OO と言えるんじゃないかと思って。
(Widget の操作がグローバル関数経由なのは目を瞑って)

>何度も何度も同じ話して、飽きない？
いえ、初めまして。

>>823
あ、それ探して読んでみます。

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=1406+%E6%B5%A9%E5%85%89%20%E4%B9%85%E9%87%8E&num=50

つか。出張相変わらず来てるのな。

まず、コメントマーク "#"つけて独り言言ってるキモイレスは出張。
あと、必ずCでOOできないか？→X11 Toolkit Intrinsics はCでOOしてる良い例だ
つう妄言を繰り返してるのも出張。奴はオブジェクト指向のスレ見つけると、
必ずそれ言い出すからやんなっちゃう。
とにかく、レベルの低い香具師はROMってろってｗ

>>815
PalmPilot持ってた。
アレ作った香具師((Apple/Newton)→US.Robotics→3M→Palm)
が脳科学つう展開にシビれた

脳科学にはとんでもさんが多いから気を付けなきゃな。

きみの発言はいつも後ろ向きだなぁ。
まぁまずは、その妄言のソースを示せって。
それが無理なら、一生ROMってろって。

>>830　出張に脳科学の話題は無理。つか無駄。つか、自分の脳の萎縮でいっぱいいっぱい。