トップページ⇒prog
1001コメント312KB

【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を何故理解できないの？★4

レス数が1000を超えています。これ以上書き込みはできません。
0001仕様書無しさん2007/03/10(土) 21:23:34
【前スレ】

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
http://pc11.2ch.net/test/read.cgi/prog/1171808096/

哲学論で否定、肯定はせずに、まずは参考URLを読んだ上で語りましょう。

【参考ページ】
ドメインモデル貧血症
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

ドメインロジックとSQL
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

データ中心指向とオブジェクト指向
ttp://hp.vector.co.jp/authors/VA020635/system/dataorient.html

さあ、張り切っていきましょう。
0002仕様書無しさん2007/03/10(土) 21:24:58
張り切ったら負けかなと思っている。
0003仕様書無しさん2007/03/10(土) 21:57:56
>>1 乙
0004仕様書無しさん2007/03/10(土) 22:07:20
　　　　　　　　　｢＼ 　　　　__ 　　　__
　 　　　　　　　│ﾄ､l、 ／´,　'｀⌒'´　｀ヽ: : .
　 　 　　　　　　ヾヽ!lV/ /　,／　/　　,'　ﾊ、: .
　 　　　　　,ィニ≧ゝﾚ' /　/　 ,./ 　 /　,　ハ : : .
　　　　　 く<-‐7´ _｣]　l l/_,∠/ 　 /　/ /　い : : .
　 　　　　　￣ﾉ／: :ｆ r'l ｌ /ﾚ'/､_／‐ﾄ'､/ｌ|　li l : : : : .
　　　　　　. : ｛ﾊ　: :|｛(ｌ|y==ﾐ　　　_ﾉ､/ｿﾘ　ll | : : : : :
　 　　　　: : : :ヽヽ: :|､lﾊl､ﾞ 　 　 　⌒ヾｌﾉﾘ　ll l : : : : : :
　 　　　　: : : : : : : : V＼ヽ、 `ｰ 　゛ノﾙんｲﾘﾉ : : : : : :>>1さんｽﾚ立て乙です♪
　 　 　　: : : : : : : : : ,.--､_ﾊ`‐ｒ=ﾆ--､′ノ. : : : : : : :
　 　 　　: : : : : : : : /　　/-ｮﾛ'ヲ´ 　 i　l : : : : : : : : : :
　 　 　　: : : : : : : 〈　　,ﾊﾌ'兀｢ 　 　 !　} : : : : : : : : :
　 　 　　: : : : : : : : ヽ, 　 ト{‐ｌﾊ.　ヽ '　ﾉ : : : : : : : :
　 　 　 　 : : : : : : : 〈 ,　　!｛ｿ 　 ヽl／|､: : : : : : : :　　　,ｒ-､
　　　　　　　: : : : : : ｀ヽ 　V 　 　 j _ノ ,スヘ_ノ7--‐ｲ∧〈
　 　 　 　 　　: : : : : : : {　/ 　 　 ,ﾊ､ 　_//く　〈 ___ r'九〈ﾊ.}
　 　 　 　　　　: : : : : : :ﾚ' 　 　' ,ﾊヘニイヽ_厂　､ノｿト}〈V´
　 　 　 　　　　　　: :_ノ‐- ､' 　{∧　トヘ_｢ 　 　{Y: :仔 之_
　 　 　 　　　　　　〈l￣＞-､_ 丶ﾚ^ヽ厂｀ 　　　上l_:/Z/ｿ‐′
　 　 　 　　r个ｙ'⌒ll_,/‐､;_,､ﾄ､__ﾄ､ 　｀ ｰ/｢＞,､ └トｆ‐′
　　　　　　{_Ｙ＾lヽ､,ど ,　, 　〈__j,ﾊ､)　､_ｲソ´｀ヽﾍ､ﾉ､lフ
　　　　　　ヽ＞ゝﾊ 〈ﾉ{ ｌ! ﾊ_j人lJ　　/ソ: : : . ﾉﾌく_.ｲ
　　　　　　　〉　〈､ｿ´　UU　　　　 ､ノ入 : :__rクｰ＜__〉
　 　　　　∠__, 〈_⊥、′ 　i　　_,ｒくソヽ√ヽﾌ
　 　 　 　　　j__ルく_/Ｔ'┬_ヒｽ⊥ｲ ＼ﾉ
　 　 　　　　　　　　ヽ√ ＼丿 ヽ/
0005仕様書無しさん2007/03/10(土) 23:09:00
>>1のせいで花粉症になった
0006仕様書無しさん2007/03/11(日) 00:24:04
【参考ページ】
はとても偏向しているね
0007仕様書無しさん2007/03/11(日) 08:16:26
新スレもまたJava厨がぞろぞろ沸いてくるんだろうな。
0008仕様書無しさん2007/03/11(日) 08:58:56
オブジェクト指向の話
↓
たとえ話
↓
罵り合い
↓
Java厨の出現

またループを起こすんだろ、もまぃらは
またStrutsの話なんか持ち出すんだろ、もまぃらは
0009仕様書無しさん2007/03/11(日) 09:37:30
フレームワークについてここで語るのはスレ違いだからな。
0010仕様書無しさん2007/03/11(日) 12:16:37
アーキテクトを募集してますよ
http://pc11.2ch.net/test/read.cgi/prog/1173263530/225-241
0011仕様書無しさん2007/03/11(日) 13:27:56
ＯＯ厨 弟w
0012仕様書無しさん2007/03/12(月) 20:56:49
質問だが、一般的に永続エンティティと呼ばれるドメインクラスが
インタフェース持つ場合ってどんな場合がある？

全部のクラスが必ずインタフェース実装するのは馬鹿らしいし。
0013仕様書無しさん2007/03/12(月) 21:03:49
>>12
質問の意図が分からん。説明能力に欠けるお前に設計は無理。あきらめろ。
0014仕様書無しさん2007/03/12(月) 21:15:11
例えばスレッドがあって、レスを1対多でもっている。

この時、「レスを追加する」というメソッドは、

①スレッドクラス自体にベタ書きする

②スレッドインタフェースに書いて、スレッド実装クラスで実装

どっちがいいかって話。
①と②の区別の基準が知りたい。
0015仕様書無しさん2007/03/12(月) 21:23:31
>>14
んなもん、適用するデザインパターンで変わってくる。問題をどう解決したいかが重要。
0016仕様書無しさん2007/03/12(月) 21:39:16
質問内容としてはインタフェースの切り方をどうすればいいかになるのかな。

スレッドという概念が唯一のもので、レスを追加するという振る舞いが今後変更される可能性が低いなら、
上位クラスはスレッドクラスを直接使えばよい。Stringクラスみたいに。

しかし、コテハン禁止スレッド、フシアナさんオンリースレッドなどが存在して、
更にそれらのスレッドに対して一括でレスを追加するならインタフェースで切ることで透過的に扱える。




0017仕様書無しさん2007/03/12(月) 21:46:06
>>12と>>14が同内容とは思えない・・・
説明能力に欠ける奴は、理解能力にも欠ける可能性が高く、
レスしている人たちの労力が徒労に終わる可能性も高い・・・
0018仕様書無しさん2007/03/12(月) 22:06:42
インタフェースを出すんじゃなくて、インタフェースから設計していくわけだが。
あとオブジェクト指向だろうとそうじゃなかろうと、
手抜きの設計すると後で自分が痛い目に合うのはもはや常識。
0019仕様書無しさん2007/03/12(月) 22:08:58
インターフェースだらけかよ
0020仕様書無しさん2007/03/12(月) 23:01:46
ではオブジェクト指向ができないあなた。
なぜ理解できないのでしょうか？
0021仕様書無しさん2007/03/12(月) 23:03:06
　　　　　　 _,..-――-:..、　　　　⌒⌒
　　　　　／.:;;;;;;;;;;;;;;;;;;;;;::.＼　　　　　　^^
　　　　/ .::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::..ヽ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　:::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　　　_,,,......,,__
　　 :::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::／_~　,,...:::＿::;; ~"'ヽ
　　　　 :::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　(,, '"ヾヽ　 i|i　//^''ヽ,,)　　　　どうすれば、この先生きのこれるのか・・・。
　　　　　　::::::::::::::::::::::::::::　　　 　^ :'⌒i　　　 i⌒"
　　　　　　　　::::::::::::　　　　　　　 　 .（|　 ,;;;;;;|
　　　　　　　　　　　　　　　　　　　　　(ﾉ...,;;;;;;|
-―'――ー'''‐'ー'''―‐'―''''―‐'''ー'''.|　 ,;;;;;;|'-''――'｀'
　,,　''''　　｀、　｀´'､､,　　　'''　　　　'''　ヽ ＿ノ　､､,
　　　　,,,　　　''　　,,　　 ''''' 　　　　　''''' U"U 　,,,,
0022仕様書無しさん2007/03/12(月) 23:04:53
ご飯をたべれ
0023仕様書無しさん2007/03/12(月) 23:07:27
ご飯っすかｗ
0024仕様書無しさん2007/03/12(月) 23:13:19
インタフェース中心で考えると、DOA的に抽出したデータの、
○○を取得するみたいなアクセサメソッドまでインタフェースにしなきゃならなくないですか？

私はデータベースに保存する情報を中心にモデルを構築するのですが、
インタフェース中心の方はそれらの情報も全てインタフェースとして見るのですか？
0025仕様書無しさん2007/03/12(月) 23:16:50
ご飯食べてきましたｗ
0026仕様書無しさん2007/03/12(月) 23:21:32
>>24
インタフェースと実装に分けるなら、そうするしかあるまい。
EJB2.xまでのEntity Beanがそうであったように。
0027仕様書無しさん2007/03/12(月) 23:32:21
EJB 使わないんだったら別にいいんじゃね？ そこまで頑なにならなくても。
インタフェースって必要があるから使うんだろ？ インターフェースありき
じゃねえべ。
0028仕様書無しさん2007/03/12(月) 23:37:43
1000 名前：仕様書無しさん[age] 投稿日：2007/03/12(月) 23:33:27
1000ならみんなOOD/Pが理解できるようになる！


前スレ１０００サンクス
0029仕様書無しさん2007/03/12(月) 23:39:23
>>27
元の質問は、インタフェース中心の場合はどうするのか？
じゃないのか？

このスレ、本当に日本語が不自由な奴が多い
0030仕様書無しさん2007/03/12(月) 23:42:25
はぁ？
0031仕様書無しさん2007/03/12(月) 23:44:41
○○中心って、全部○○って意味か。なるほど。
0032仕様書無しさん2007/03/12(月) 23:49:32
アクセサメソッドはクラス内での実装の仕方を隠蔽するためにあるのよ。
っつーかね、会社の連中もそうなんだがなんで一から十まで全部に適用しようとするかね。
頭が固すぎる。有効なところには使えばいいし、面倒なら省いちゃえばいいし、そんなん臨機応変に自分で決められんのかね。
0033仕様書無しさん2007/03/12(月) 23:56:52
臨機応変ができないから未だにOO厨は必死なんだろ
0034仕様書無しさん2007/03/13(火) 00:05:50
あるときはインタフェースにして、あるときはインタフェースにしないなんて、
明確な基準がなければバラバラな設計になっちゃいますよね？

例えば外注に設計依頼する際に臨機応変に、じゃシステム動かないし
そんなの仕事じゃないですよ。

手順や基準を示してきっちりステップ数、バグ数管理しなきゃ品質の高いシステム開発はできないでしょ。
0035仕様書無しさん2007/03/13(火) 00:10:43
そんな明確な基準があるとこなんかねーだろ
0036仕様書無しさん2007/03/13(火) 00:10:50
ステップ数(笑)
0037仕様書無しさん2007/03/13(火) 00:11:20
「ステップ数」で一体何を管理するんだね？
0038仕様書無しさん2007/03/13(火) 00:12:23
>>34からは仕事請けたくねぇな
0039仕様書無しさん2007/03/13(火) 00:18:51
おまいはソフトウェアの品質管理とかやったことない下流ＰＧですか？
ステップ数、バグ数で定量的に品質は分かるんですよ。

Ｊａｖａで実行数これくらい書いたら、過去の数値からこれくらいバグが出るという目安ができ、
それに満たないなら品質が悪いということで試験やり直し。当然でしょｗ
0040仕様書無しさん2007/03/13(火) 00:20:32
バグが出る数の基準があるとかはじめて知ったよ
0041仕様書無しさん2007/03/13(火) 00:23:30
Agitatorとかの結構最近の試験ツールとかも行数カウントとかあったけどなぁ
まぁステップ数の多いクラス、分岐の多いコードほどバグのリスクが高いということだよ。
これはOOだとかJavaだとかに関係なくプログラム全般にいえることでしょ。
0042仕様書無しさん2007/03/13(火) 00:26:15
マ板じゃ生産性や品質評価は荒れるしスレ違いなのでこの辺で。
以後、OOに関する話題をどうぞ。
0043仕様書無しさん2007/03/13(火) 00:28:57
ステップ数があてにならないのは、処理の複雑度、入出力条件、ＰＧの技量、知識、設計
等に左右されるところが大きいからだ。
0044仕様書無しさん2007/03/13(火) 00:36:19
>>43
そんなことは自分だってJavaでプログラム書いてるから１００も承知ですよ。
けどね、対外的に品質報告する際にはやっぱ数字の力はすごいわけで。
日本の企業でプログラム書いてれば分かるでしょ？
そもそも、管理職とかの老人は数字でしか品質を見ない。
Junitのテストケース見せていい品質でしょ？とはいえない。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity
0045仕様書無しさん2007/03/13(火) 00:36:44
>>42
別に構わないんじゃないか？
OOでも荒れるときは荒れるし。
生産性や品質を抜きにして語るのも違う気がするしな。
0046仕様書無しさん2007/03/13(火) 00:54:00
品質を計るのになんでステップ数がいるのかさっぱりわからん。
テスト結果だけじゃだめなのか？　あぁ、さてはテスト仕様書も
テストデータの作成も外だしか？　それで、テスト時のバグ件数
との比率で結果の妥当性を見ようってのか？　そりゃ結局管理し
てないに等しいな。おじゃまもんといっしょじゃねぇか。
0047仕様書無しさん2007/03/13(火) 01:07:21
管理が目的ではなくて報告が目的なのだと思われ
0048仕様書無しさん2007/03/13(火) 01:14:42
>>46
日本語でおk
0049仕様書無しさん2007/03/13(火) 01:16:46
なんか最近偉い人爺さん方が「見えるか～見えるか～」って喚いてるもんな
0050仕様書無しさん2007/03/13(火) 01:34:08
http://pc11.2ch.net/test/read.cgi/prog/1171808096/1000
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3

1000 ：仕様書無しさん ：2007/03/12(月) 23:33:27
1000ならみんなOOD/Pが理解できるようになる！
0051仕様書無しさん2007/03/13(火) 01:37:07
じゃあそろそろオブジェクト指向の話をするんだよな？
0052仕様書無しさん2007/03/13(火) 05:44:10
このバグちょっと見てくれって言われる事よくあるが、ステップ数押さえて細切れ
にしても組み合わせが悪くてバグになってる時とか却って切り分けに一苦労するよな。
他への影響考えると直すに直せなくて結局小さな専用クラスをたくさん作らされる
羽目になったり。
ちゃんと設計して最初から無理な適用は諦めればいいのに。
0053仕様書無しさん2007/03/13(火) 07:19:47
コードも読めない、設計も理解できない層を納得させるには、
前時代的観点での数字が有効なのは間違いない。

こちらもそれをうまく利用していい場面というものが
あるのではないかと思う。
0054仕様書無しさん2007/03/13(火) 08:10:13
まずは数字とオブジェクト指向の関連性を明確にしろよ
それができない限りスレ違い
話はそれからだ
0055仕様書無しさん2007/03/13(火) 08:12:15
>>42
もうちょっと学習しておいで
0056仕様書無しさん2007/03/13(火) 08:13:05
みすった
55は>>45
0057仕様書無しさん2007/03/13(火) 08:16:28
OOPは自己学習でちょっとやってみたことがある程度の、実務未経験者なんだが、
まず初めに思ったのが「クラスって関数と変わらねーんじゃね？」てとこ。
ま、ぶっちゃけクラスと関数じゃ出来ることは多分同じなんだろうけど、
関数を使った従来型のプロシージャ型プログラミングとOOPの違いは以下のようなもんだと勝手に思ってる。


プログラムの中の人が、一人で関数っていうツールを駆使して頑張るのが従来型のプロシージャ型プログラミングで、
OOPは複数のクラスという担当者がいて、それぞれ担当業務が明確に決まっており、要は完全分業。
適切に指示すればクラスがそれぞれやってくれる。

従来型は中の人の出来が悪いと、手順に無駄な繰り返しやらがあったり、
人依存で体系化されてない部分が多く外部から判別不能なこともあったりするが、
中の人が優秀だと仕事の内容も報告も分かり易く、かつ手早く終わったりもする。
対してOOPでは、担当業務が明確なため、誰に頼めばよいか分かり易い。
但し、担当範囲分けがいい加減だったりすると一人の担当者に負荷が集中したり、
無駄な担当者がいたりするし、一人の人がやるよりもレスポンス悪かったりする。
ただ、より大規模に仕事するには出来に体系化・分業化されたOOPの方がグダグダになりにくい。


こんな理解でおk？
0058仕様書無しさん2007/03/13(火) 09:04:15
変わるところ（仕様変更／機能追加がありそうなところ）と、変わらない
ところを切り分け、その間のやりとり(I/F)を決める。

変わらないところは、気合いが入った濃い人が構築して、変わるところに
ついては人海戦術なり何なりでふくらませていく。

基本的にはI/Fを死守（生育）していかなければいけないけど、最初の切り分けが
まずかったり、うまく戦略が全体に伝達できてなかったり、濃い人の言うことが
意味不明に感じたりする人が出てきてチーム間の仲が悪くなったりと、
ぐだぐだになって「おまえら何やってるんだ？」なんてことになるのだが、どう？

0059仕様書無しさん2007/03/13(火) 09:09:28
クラスメソッドを関数とみるなら逝ってよし。
クラスをその分野に関して機能提供する処理担当とみるなら正解。
0060仕様書無しさん2007/03/13(火) 09:18:08
>>14
おそれすだけど。
掲示板をどこまでサポートするかによる。

2ちゃんとしたらば、スラドにmixi、どれも「スレッドを追加」という概念はあるだろうけど、（テーマ別にあるような）単独掲示板にはそういった概念はない。

なので、どういった範囲を対象として、どういう機能を提供したいかに依存する。

0061仕様書無しさん2007/03/13(火) 12:36:08
なんでOOPを含めちゃうかな？
前の設計話のほうが馬鹿入ってこなくて良かったのに。
ミクロな話ばっかりだとつまらん。
0062仕様書無しさん2007/03/13(火) 12:56:26
純粋なOO設計だけって話題はあり得るのか？
設計は実装のためにあるんだろ。実装にシームレスに繋がらないクラス設計されてもな。

しかも、クラスやメソッドという単語はむしろOO一般の設計の話で、言語の話ではないと思うぞ。
0063仕様書無しさん2007/03/13(火) 13:08:12
>>61はプログラム組めないなんちゃってSE君だろw
0064仕様書無しさん2007/03/13(火) 14:09:12
プログラムなら中国人でもインドの山奥の人でも組める。
0065仕様書無しさん2007/03/13(火) 15:02:31
つまりそんなスキルすら>>61はもってないと
0066仕様書無しさん2007/03/13(火) 15:03:22
1オブジェクト指向プログラミング言語もできない奴がOO設計など到底無理。
0067仕様書無しさん2007/03/13(火) 15:06:41
>>63
で、また設計と製造は別物議論が繰り返すと。

まあ、せっかく勉強したJAVAなり何なりと、なんちゃってオブジェクト指向が高尚だと思いたいのは、自己陶酔だと思うけど。
0068仕様書無しさん2007/03/13(火) 15:13:10
Strutsはくそ
0069仕様書無しさん2007/03/13(火) 15:14:22
別にStrutsはOOPでも何でも無いし。
だからPを含めるのは嫌なんだよ。馬鹿避けできないから。
0070仕様書無しさん2007/03/13(火) 15:23:30
DIはくそ
0071仕様書無しさん2007/03/13(火) 15:41:53
Springは糞だな。
0072仕様書無しさん2007/03/13(火) 16:02:43
>>68 >>70-71
…あー、なんとなく >>69 の気持ちが理解できたような気がする。
0073仕様書無しさん2007/03/13(火) 16:08:05
自演乙
0074仕様書無しさん2007/03/13(火) 16:59:25
>>73
莫迦の定番乙。
0075仕様書無しさん2007/03/13(火) 17:10:31
お前ら喧嘩すんな、まじめにやれよ
0076仕様書無しさん2007/03/13(火) 18:40:19
インスタンス、クラス、オブジェクトの違い。
0077仕様書無しさん2007/03/13(火) 18:45:35
インスタンスはメモリ上のオブジェクト
クラスはインスタンスの型
オブジェクトは物だ！
0078仕様書無しさん2007/03/13(火) 18:49:39
Strutsは意味ない
0079仕様書無しさん2007/03/13(火) 18:50:52
たしか支柱っ意味じゃなかったっけ？
0080仕様書無しさん2007/03/13(火) 19:14:06
strutsはリクエストと処理をコマンドパターンで統一的に扱えるようにし、
コマンドでフォワード先画面を決められるようにしたフレームワークだ。
内部はOOで作られているようだが所詮はシステムの画面遷移の担い手に過ぎんよ。

ラピュタで言えば半球の外の城に過ぎんよ。
技術の粋は内部に集約されているのだよ。
見たいかね？新のOOを、かつてのDOAではバズワードとして恐れられたOOの力を！！

0081仕様書無しさん2007/03/13(火) 19:23:31
OOの力↓

public class うんこ{

private String 排泄物;

public void 爆発する(){
排泄分.大爆発()

}

}



(ﾟдﾟ)
0082仕様書無しさん2007/03/13(火) 19:24:54
別に
0083仕様書無しさん2007/03/13(火) 19:27:54
なんでstringが爆発するんだ
0084仕様書無しさん2007/03/13(火) 19:58:24
アホだから
0085仕様書無しさん2007/03/13(火) 20:32:24
しかも排泄物はヌルポだろーに
0086仕様書無しさん2007/03/13(火) 20:35:56
そもそも、うんこをモデリングしなきゃならんドメインがわからない。
0087仕様書無しさん2007/03/13(火) 20:54:28
たぶん、、、OO理解できないﾔｼって、同じこと何回も書いて、「ステップ数＆工数」の水増ししてる。

例えば、ISAM的なdbのアクセスなんて、その都度SQL発行しなくてもできると思いまつ。
　　①コンストラクタで、アクセスするテーブルIDと（読み込みに使う）キーフィールドIDを渡す。
　　　　この時、アクセスするテーブルの全フィールドの型が文字列・数値・日付・etc…なのかを覚える。
　　②読み込みメソッドでは、①の情報を元にSQLを組み立てる。
　　　　ここでは、キーの値を引数でもらう。
　　　　VBで言うと、ParamArrayだし、Cでいうとva_argだっけ(...のこと)？
　　③上記②で読み込んだ結果を、Getterで公開（引数はフィールドID）。
　　　　②で空振りしたときは、ゼロやスペース等、適当な値を返す。
　　④上記②が空振りしたかどうかを、Getterで公開。
　　　　STATUSね。COBOLみたいｗ
こうすると、後処理（Close...ハンドルの解放）忘れないし、SQLを何回も投げなくて済みまつ。

まぁ、所詮COBOLerの考えることなので、あんまりツッコまないでねｗ
0088仕様書無しさん2007/03/13(火) 21:00:00
何を言いたいのかさっぱりわからんが、DAOパターンの方がよっぽどまし。
0089仕様書無しさん2007/03/13(火) 22:00:19
ま、素人はER図からやってみたほうが良いよ
あれは純粋にデータだけを扱えばいいし、
最近はER図からテーブル作ってくれるツールもある

プログラムの場合はデータの他に操作も考える必要がある

0090仕様書無しさん2007/03/13(火) 22:39:16
SpringやらStrutsやらの話がしたい奴は
別スレ立ててそっちでやれ
0091仕様書無しさん2007/03/13(火) 22:42:25
>>90は度量の小さい奴だなぁ
0092仕様書無しさん2007/03/13(火) 22:48:02
>>91
おまぃは業務分割できない奴だなぁ
0093仕様書無しさん2007/03/13(火) 22:59:35
>>87

それはテーブルモジュールというやつじゃないか？
テーブルと１対１になっているクラスの静的メソッドにCRUD機能を持たせるって奴。

あと、関連も一度に読み込むならリソースの無駄だからそこはレイジーロードで
必要に応じてフィールドがnullなら読み込むとかにしとけばOKかね。
0094仕様書無しさん2007/03/13(火) 23:29:17
このスレみて今日試しにオブジェクト指向設計してみたんだが
やっぱり最初は扱うドメイン領域の概念やデータをクラスとして抽出じゃね？

で、次にその抽出したクラスが単なるアクセサメソッドしか持たない値クラスなのか、
操作（といってもほとんど検索と登録ばっかだが）を持ちえるIFなのかって判断になると思う。

で、さらに詳細に属性、メソッドの戻り値とパラメータを決めてクラス図を描く。
ただ、この方法だとデザインパターンを適用したくなったり、IF使ってポリモフィズムとかやりたくなるのが難点だな。
後々こいつらをDBに入れること考えちまうとあんまり継承とか使いたくないし。
0095仕様書無しさん2007/03/13(火) 23:39:10
>>1のテンプレが頭悪そうでたまらない
0096仕様書無しさん2007/03/13(火) 23:40:17
俺はそうは思わない
0097仕様書無しさん2007/03/13(火) 23:40:47
C++だと聞いてクラス図を記述していた俺。
Cでやると聞いてへこんだ俺。
いいよ、確定申告のときのおねーさんが超かわいかったから。
0098仕様書無しさん2007/03/13(火) 23:44:52
>>96
スレの最初から居る古代人ですか
0099仕様書無しさん2007/03/13(火) 23:46:21
ちがいます
0100仕様書無しさん2007/03/13(火) 23:46:55
別にどうでもいいです
0101872007/03/14(水) 20:37:39
>>93
σ（・_・）、COBOLerだから、難しい言葉は理解できません＾＾；；；
でもでも、間違っても>>87の③の公開は、静的にしませぬ。
VB.Netなら
------------------------------------------------------------------------------------------
Default Public ReadOnly Property Fields(ByVal FieldName As String) As Object
------------------------------------------------------------------------------------------
のような実装ね。

あと、書き忘れたけど、コンストラクタの引数は
　　・ｄｂのコネクション
　　・テーブルID
　　・読み込みに使うキーのFieldID（VBならParamArray、Cなら...)

こうすれば、
　　Dim 管理マスタ As New TableReader(dbCnn, "管理マスタ")
　　Dim 顧客マスタ As New TableReader(dbCnn, "顧客マスタ", "顧客コード")
　　Dim 月次顧客マスタ As New TableReader(dbCnn, "月次顧客マスタ", "年月", "顧客コード")
　　管理マスタ.Read()
　　顧客マスタ.Read(txt_顧客コード.Text)
　　月次顧客マスタ.Read(管理マスタ("処理年月"), txt_顧客コード.Text)
　　...
みたいな、記述ができるんでつ。

>>93ﾀｿが言う「テーブルモジュール」ってこうゆうこと？？？
0102仕様書無しさん2007/03/14(水) 22:18:00
>>101 外部参照テーブルの読み込みはどうすんだよ
0103仕様書無しさん2007/03/14(水) 22:22:29
viewにすればいいんじゃね？
あくまでgetterの話だから

setterになるとcommitやら排他制御やら
色々ややこしいことになるけどな
0104仕様書無しさん2007/03/14(水) 22:48:54
1対多とか多対多とか破綻しないか？
0105仕様書無しさん2007/03/14(水) 22:52:54
>>104
別に。
0106仕様書無しさん2007/03/14(水) 23:12:50
いっぺんに沢山のレコード読むときどーすんだ、各オブシェクトが格納された
List型で返すのか？そのList型のプロパティーはどれが持つんだ？
Daoパターンの方がきれいじゃね？
0107仕様書無しさん2007/03/14(水) 23:27:54
>>106
勉強して出直せ。それ以上のレスは恥を晒すだけだ。
0108仕様書無しさん2007/03/14(水) 23:53:10
↑なんだよ、こいつ。そんなヒステリーおこさずに説明してくれよ。
0109仕様書無しさん2007/03/14(水) 23:54:42
力量不足な連中が集まるスレはここですか？
0110仕様書無しさん2007/03/14(水) 23:59:19
ここじゃないです。
0111仕様書無しさん2007/03/15(木) 00:58:47
ここだと聞いてやってきたのですが間違いないようですね
0112仕様書無しさん2007/03/15(木) 02:05:55
「不勉強ですが勉強したくないのでピンポイントで教えてください」
なんて質問には親切を装ったウソの回答がふさわしいので
筆の立つウソツキの登場を強く望むものである
0113仕様書無しさん2007/03/15(木) 09:00:01
抽象で語れず、すぐ具象な話になってしまう。

0114仕様書無しさん2007/03/15(木) 09:53:20
2chシステムをOOで設計すると、俺らは「名無しさん」で抽象化される。
0115仕様書無しさん2007/03/15(木) 10:53:48
>>113 抽象で語ってみれ。できるもんなら。
0116仕様書無しさん2007/03/15(木) 12:44:03
ああ、あれをそれしといて。
0117おじゃばさま2007/03/15(木) 12:59:50
メソッドは天使のように優しく設計してくれ。
0118仕様書無しさん2007/03/15(木) 13:01:11
抽象論で語る奴ばかりが集まると全然物事が進まないねぇ。
話かみ合わないし。
0119仕様書無しさん2007/03/15(木) 13:02:43
名前は属性に過ぎない
0120仕様書無しさん2007/03/15(木) 13:11:39
遺憾ながらこの世では属性といえども名前をもっておる
01211132007/03/15(木) 21:26:39
>>115
一口にOOといっても、流儀がいろいろあるけど、主流はやはりUP派閥かねぃ。

組み込みではDOORSが調子いいと聞くけど。

・・・こんな感じ？ なあんてw

冗談はさておき、実際はどうなんでしょうか？
やっぱりUP？

0122仕様書無しさん2007/03/15(木) 21:45:55
ググれ
0123仕様書無しさん2007/03/15(木) 22:01:27
>>121
UPって何? Unified Process? つか日本語でおk
0124仕様書無しさん2007/03/15(木) 22:05:19
開発方法論の話がしたい奴は
別スレ立ててそっちでやれ
012587=1012007/03/15(木) 22:45:20
>>104
「１対多とか多対多」は、普通にDataTableとかRecordsetで処理すればいいでしょ？
設計思想とか顧客の要求によって、それぞれだと思うけど、少なくとも入力系PGなら
「１：１」のアクセスが圧倒的に多いと思いまつ。
例えば、顧客マスタの登録画面で、担当者コードを入力してHitしたらその担当者名を表示、
未登録ならエラーを表示して再入力させるとか…。

まぁ、最近の設計は、コンボボックスから選択っていうのが一般的なのかなぁ？？？
それなら、こんなｼｮﾎﾞいクラスｲﾗﾈなんだけどねｗ
0126仕様書無しさん2007/03/15(木) 22:46:01
>>121 評判聞くのがお前の抽象論かよwww
0127仕様書無しさん2007/03/15(木) 22:50:20
>>125って・・・
0128仕様書無しさん2007/03/15(木) 23:15:00
もまぃらはオブジェクト指向の何が理解できないんだ？
具体的に言ってみろ
0129仕様書無しさん2007/03/15(木) 23:15:48
いやだ
01301132007/03/15(木) 23:29:15
>>126
同じOOと呼ばれていてもプロテスタントとカトリック、モルモン教ぐらい違うものがある、という認識ない？

立ち位置によって、捉え方が微妙にずれている、人によって"OO"が違うから混乱が生じる。
それじゃまずいってので、UMLで言葉をあわせましょう、ということになったけど、
もとの教義が違うのでUMLは最大公約数的なものになっているのが現状かな、と。

だから、話がかみあわないのではないのかなあ、と。

0131仕様書無しさん2007/03/15(木) 23:41:39
>>130
それUPとかアジャイル関係ねーじゃん。
0132仕様書無しさん2007/03/15(木) 23:45:36
>>131 キリンさんが好きれす。でも、ぞうさんのほうがもっと好きれすｗ
0133仕様書無しさん2007/03/15(木) 23:52:43
>130
なんか分かったような分からんような話だが、多分その通りなんだろう。
さすが抽象論だ。で、どうすればいいんだ? 立ち位置と教養を合わせろっ
てことか？
0134仕様書無しさん2007/03/16(金) 00:09:22
Java厨の自己陶酔なレスを排除すればおｋ
0135仕様書無しさん2007/03/16(金) 00:22:42
アホか、そんなわがまま通るか、何様だよ。
開発方法論の話がしたけりゃ別スレ立てろ。
0136仕様書無しさん2007/03/16(金) 00:37:17
OOを特別なものと考えると
うまく行かないだろうな。
所詮は人間様が使う道具なんだから
それを忘れなければうまくいくだろう。
0137おじゃばさま2007/03/16(金) 09:12:06
オブジェクト指向は詳細設計の技術である。
機能設計にオブジェクト指向は使えない。
機能設計の画面設計に必要なのは、作法とセンスである。DB設計に必要なのは正規化と経験である。
開発手法にオブジェクト指向は使えない。
プロジェクト運営で必要なのは、経験と分析と実行力と、優秀な営業である。
0138仕様書無しさん2007/03/16(金) 09:17:09
>>137 画面設計は外部設計ですが？　UMLはオブジェクト使わないのか？
01391132007/03/16(金) 09:40:50
>>133
OOといって違う概念の違う話をしているから、人によって理解している／
理解していないの基準が違う。

混乱するので、例えば“正統派”smalltalkのOOか、“新興の”Javaか、それとも設計論の一派か
わかるようにしないとずっとgdgdのままだろいなあと感じる。
（というか、自分の「神様」は誰か知らないままやってるのが大半だろうなあ、と思う。）
邪教みたいなのも、いっぱいあるし。

教養とまではいわないが、せめて話をするときに意識できるようになっていてほしいとは思う。
（無邪気なのがいちばんタチが悪い）

ささやかな望みとしては「布教活動」する関係者には、そのへんを意識してほしいなあ、と。

>>135
方法論だけではないって。
開発言語、デザパタ、フレームワーク、どれでもあてはまる。

0140おじゃばさま2007/03/16(金) 09:42:55
UMLは一部を除き詳細設計のための資料である。
ユースケース図とシーケンス図は機能仕様の部類に入る場合もあるが、オブジェクト指向とは関係ない。
ちなみに「UML＝オブジェクト指向」ではない。
0141仕様書無しさん2007/03/16(金) 10:12:08
アホか当たり前だろ、UMLはモデリング言語で、OOは考え方だ。
0142仕様書無しさん2007/03/16(金) 10:18:03
>>139 smalltalkのOOとJavaのOOは考え方違うのか？
それは知らんかった。つかそれ結局具象の話じゃね？
えらそうに、お前が布教しろよ。
0143仕様書無しさん2007/03/16(金) 11:43:09
>>139,142
smalltalkのOOかC++(Java)のOOかというよりは、
アラン・ケイのOOか、ビヨーン・ストラウストラップのOOか、の違いじゃないでしょうか。
「メッセージング（動的性や流動性）」重視か、
「ユーザー定義型（カプセル化や型安全性）」重視かの差、ですね。

それと、smalltalkやJavaに限ったことではないですが、
考え方を特定の言語にくくりつけないほうがよいと思います。

たとえばC++(Java)だってケイのOOっぽいメッセージをイメージしたコードは組めるし（善し悪しは別）、
smalltalkだってストラウストラップのOOっぽく型を意識したことをライブラリでばしばしやっています。
0144仕様書無しさん2007/03/16(金) 12:53:03
>考え方を特定の言語にくくりつけないほうがよいと思います。
無理。そんなことしたら特定の言語についてしか話せない人間が発言できなくなって寂れる。
個人的にはそのほうが望ましいけど。
01451132007/03/16(金) 12:59:39
>>142
だから、「例えば」の話。

主旨は、「OO(と呼ばれるもの)には種類があるけど、区別されていない(ことが多い)から、
理解できているのか、できていないのか混乱しているのが現状では？」です。

>>143
確かに。

0146仕様書無しさん2007/03/16(金) 13:18:47
　　　　　　　　　　　　（( ⌒ )）
　　　　　　　 　　　　｜・　 ・｜
　　　　　　　 　　　　｜　◎ ｜＜びょ～ん・すとらうすとらっぷ
　　　　　　　　　　└｜ 　　 ｜┘
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜＿＿｜
　　　　　　　　　　　　∪　　∪
0147おじゃばさま2007/03/16(金) 19:50:04
つーか、何が分からないって？
0148仕様書無しさん2007/03/16(金) 20:08:21
ユースケース図は要件の洗い出しに使うし、アクティビティ図は業務分析に
使うよなぁ。おじゃばのいうUMLはこれらは含まないのか？都合のいいUMLだな。
0149仕様書無しさん2007/03/16(金) 20:35:14
C++やJavaでsmalltalkみたいなメッセージなんて出きるわけねーだろ。
やれるってんなら例を見せてみろ。
0150仕様書無しさん2007/03/16(金) 20:52:50
つ interpreterパターン
0151仕様書無しさん2007/03/16(金) 21:13:53
>>149
C++でsmalltalkのエミュレータを作ればいいだろ
0152仕様書無しさん2007/03/16(金) 23:07:30
クラス指向とメッセージ指向で呼びわけすりゃいいんじゃね？
0153仕様書無しさん2007/03/16(金) 23:45:33
>>151
C++で書かれたSmalltalk VM＝Squeak
Squeakのコードをコンパイルすると
裏でC++コンパイラが走る。

C系言語でﾒｯｾｰｼﾞをﾊﾟｯﾂﾝﾊﾟｯﾂﾝしたいなら
・ MacOS X上でObjective C
・ MPI
あたりがｵﾇﾇﾒ

0154仕様書無しさん2007/03/17(土) 00:03:53
結局はアセンブラに回帰する
ifとgotoさえあれば問題ない

頭が悪いから一々問題領域を分割しないと駄目なんだよ
天才ならばどんなに読みにくいコードでも把握できる
馬鹿はある意味他人の責任にすることの天才なので
理解できないのはオブジェクト指向で無いからということで
本当のオブジェクト指向だったら理解できると自分自身を欺く

本当のオブジェクト指向は自分自身も知らないことも欺こうとする
だから何時まで経っても馬鹿のままでいい気になれる
まず自分自身で最高の実装だと自負できるコードを見せろ
話はそれからだ

取りあえず例としてオセロゲームにしてみようか？
#include <stdio.h>

int p,t,a,d,c,v,i,m[90]={0},s,r[]={-10,-9,-8,-1,1,8,9,10};void k(){if(m[p]==0)

for(i=0;i<8;i++){for(c=0,v=p+r[i];m[v]==3-t;v+=r[i])c++;if(c&&m[v]==t){a+=c;v=

p;if(d)do m[v]=t,v+=r[i];while(m[v]!=t);}}}char*h="・○●\n";int main(){for(i=

1,m[41]=m[49]=2;i<10;m[i++*9]=3)m[40]=m[50]=t=s=1;for(;;a=d=0){for(p=9;p<82;++

p)k(),printf("%.2s",&h[m[p]*2]);if(a)for(d=a=s=p=8;a==8;k())t-2?(scanf("%d %d"

,&p,&i),p+=i*9):++p;else if(s)s=0,printf("pass");else break;t=3-t;}return 0;}


これをオブジェクト指向とやらでもっと保守性と再利用性をやらを高めてみろよ
0155仕様書無しさん2007/03/17(土) 00:31:49
学習量の違いなのか、
それとも学習過程の違いなのか、
なんにせよおまえら見てると
オブジェクト指向の統一見解が無いってのがはっきりわかる。
誰か本出さないか？
「あなたが思っているそれはオブジェクト指向ではない！」
って感じの、オブジェクト指向の切り分け本。
ちったあ売れるかも。

要求定義と一緒だ。
何をする、だけじゃなくて、
何をしない、ってのを明確にできてないから混乱するんだよ。
0156仕様書無しさん2007/03/17(土) 00:34:53
さて、脱線もこのくらいにして、そろそろオブジェクト指向の話に戻らないか、もまいら。
0157仕様書無しさん2007/03/17(土) 00:43:25
うわ・・
0158仕様書無しさん2007/03/17(土) 00:44:09
本を読めばその内容は分かる。
でも実装の方法がよく分からん。
ってのが実際のところじゃまいか？
0159仕様書無しさん2007/03/17(土) 00:49:16
>>154 ｶﾜｲｿｽ
0160仕様書無しさん2007/03/17(土) 01:28:52
>>154
ﾜﾛｽw

問題を分けられないのも
責任を他のせいにしてるのも
全部、お前だろw

お前は一人でPCのOSでもアセンブラで組んでろよ。
もちろん、全国を一件ずつまわるんだぞ。
わかったなw

じゃあ、逝っていいよ。
ついでに業界からも逝ってくれ。
害がありすぎだから
0161仕様書無しさん2007/03/17(土) 01:38:30
>>159と>>160が見事に釣れたわけだが
下魚だったな
0162仕様書無しさん2007/03/17(土) 02:24:38
>>158は絶対わかってない
0163仕様書無しさん2007/03/17(土) 02:37:22
あんまり役に立たないんだよな。
面倒が増えるばかりでコストパフォーマンス寺ワロス。
0164仕様書無しさん2007/03/17(土) 03:04:04
最初が面倒だからな

でもそれを怠るとあとで混沌となる
0165仕様書無しさん2007/03/17(土) 05:35:43
if と gotoだけじゃダメだべ。
分岐だけで演算なかったら。
全てのアセンブラの命令は分岐と引き算だけで置き換えられる事を
偉い人が証明したって学校で習ったけど、詳細は覚えとらんわ。
0166仕様書無しさん2007/03/17(土) 08:33:11
次々に現場が変わる偽装請負の連中が９割いる業界で、
再利用性を重視・実施できてるプロジェクトが
どれだけあるのか怪しいもんだ。
結局なんちゃってOOの残骸をバグだらけのまま
使いまわしてプロジェクトの都度同じバグを修正してるところばかりだろ
0167仕様書無しさん2007/03/17(土) 09:46:55
>>154
アセンブラにifとgotoは無い訳だが。。
0168仕様書無しさん2007/03/17(土) 09:56:12
あるだろ。。。。。
0169仕様書無しさん2007/03/17(土) 10:29:58
雑魚しか釣れないね
0170仕様書無しさん2007/03/17(土) 13:10:20
>>169
あるのはcompareとjumpだが。。
0171仕様書無しさん2007/03/17(土) 13:42:31
「オブジェクト指向を何故理解できなの？」って質問は、結局、
「何故泳げないの？」とか、「何故楽器を弾けないの？」って質問
と同じで、本人は理解できてるつもりでも、はたから見ると全然
ダメってことなんだよな。程度の差の問題っていうのは、どの領
域でもありうる話で、表面をさらうだけならだれでもわかるが、
実際、それをプロの技として使いこなせるかどうかという話にな
ると、本人の努力とか素質とかセンスに負う所が大きいわけで、
これはいくら言い聞かせも、本人にその気がなければ徒労に終わる。
0172仕様書無しさん2007/03/17(土) 15:59:26
なんでもそうだけど、信者かアンチの２極化するのをどうにかしてくれ。
0173仕様書無しさん2007/03/17(土) 16:12:08
>>171
それを言うなら
「何故、平泳ぎで北島のタイムを出せないの？」
だろ。
OOは万能ではそもそもない。

たとえば、OSを全部OOでつくるのは設計レベルでも無理だしな。
基本的にはOOは人の為の考え方であって
ハード的には必ずしも扱いやすい考え方ではない。

OOに限らないけど
やり方の向き不向きを考えないと
本末転倒な結果になる。
OO信者は特に気をつけたほうがいいな。
0174仕様書無しさん2007/03/17(土) 16:21:03
個人レベルでは使いたくなったら使うでも間に合うんだけどね。
プロトタイプはOO意識せずに作ってみて、まとめた方が楽に扱えそうな
部分だけOOで作り直せばいい。
でも大規模PRJでこれやると予算も納期も破綻するからな。
01751732007/03/17(土) 16:21:08
ちなみに、OSの話は
強引な処理しないでって意味だから。
ここでわざわざ説明する必要はないとは思うけど。
0176仕様書無しさん2007/03/17(土) 16:28:16
えあ？実装の詳細を気にしないでよいプロトこそOOで作ったほうがよくね？
0177仕様書無しさん2007/03/17(土) 16:54:57
>>176
たしかに、使い捨てコードを
OOPで書き捨てるのは楽でいいよな。
そのまま使われると、後で地獄見そうだけどw
0178仕様書無しさん2007/03/17(土) 16:56:22
>>171のオブジェクト指向理解＝C++でインベーダゲーム作るレベル

Javaの大規模開発でぼろくそにされて逃げ出して
巣の穴の中でﾌﾟﾙﾌﾟﾙしながら強がりを言ってるだけ。

頭は弱いけど、元は優しい子なんです。許してやってもらえませんか？
0179仕様書無しさん2007/03/17(土) 17:12:46
ああ、例のOODもろくにできないコンサルか。
設計中からデザパタデザパタ喚いて
OODの勘所をはずしまくって、しまいには
全部リファクタリングで改善するとか世迷言を言い出して
蹴り出されたコンサルね。

納得したわ
0180仕様書無しさん2007/03/17(土) 17:16:55
>>176
過去の資産があるなら楽かもしれんけど、何も無い状態で何ちゃってOOで
プロト作って>>177の言うように「工数短縮のためプロト流用してね」と
言われると元も子も無いよｗ
0181仕様書無しさん2007/03/17(土) 17:24:07
どんな状況だか、まだ話が見えねー。
もちっと具体的にたのむわｗ
0182仕様書無しさん2007/03/17(土) 17:28:12
毎回違う外注使って自社でノウハウ貯めない企業が多い時点で
流行る流行らない以前の問題
0183仕様書無しさん2007/03/17(土) 17:42:45
自演の多いスレだな
0184仕様書無しさん2007/03/17(土) 17:43:39
すずきたかひろスレｗ
0185仕様書無しさん2007/03/17(土) 18:09:52
あいでぃびゅーわーは使うなとあれほど、
0186仕様書無しさん2007/03/17(土) 18:18:27
あいぴーびゅーわーだけど、何か？
0187ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/17(土) 18:26:17
OO信者による歪曲ですな。
OOなんて簡単。
馬鹿でも理解できるから、背伸びして実力以上に見せたがるやつが好んで使う。
0188ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/17(土) 18:28:33
「おれ平仮名読めるんだぜ」

と吹聴して回るOO信者
0189仕様書無しさん2007/03/17(土) 18:31:09
・・・と吹聴して回るココ電球（∩T∀T)y-~~~~
0190ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/17(土) 18:31:45
ローマ字の方が例えとしては良いかな？

「俺ローマ字読めるんだぜ」と吹聴して回ってる馬鹿が　全部ローマ字で書いた文章作ってきて
「読みにくい」と言われると　「俺だけがローマ字を理解している」　などと有頂天になる。
始末に困るな。こういう輩は
0191ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/17(土) 18:32:43
postgres MLスレ消えちゃったね　困るね
0192仕様書無しさん2007/03/17(土) 18:33:53
あぼ～んって便利だな
0193仕様書無しさん2007/03/17(土) 18:42:28
普通はリソースプールとか弄るんだよ、アホか。
しかし、負荷テスト好きだな、このおっさん。
そんな大規模サイトやってるようには見えんが。
0194仕様書無しさん2007/03/17(土) 18:43:32
ガーン、まちがったorz...
0195仕様書無しさん2007/03/17(土) 18:53:05
支離滅裂なレスばかりだな
0196仕様書無しさん2007/03/17(土) 19:07:23
もう、すっかり春だな。
0197仕様書無しさん2007/03/17(土) 19:11:57
そか、春だったからか
0198仕様書無しさん2007/03/17(土) 19:23:04
春厨、湧きすぎｗ
0199仕様書無しさん2007/03/17(土) 20:02:45
>>171もずいぶん必死で煙幕張るんだなぁ。
　>>172-184 に、そんなにマズイ内容が書かれてるのか？
0200仕様書無しさん2007/03/17(土) 21:36:31
で、なんなんよ
このキメェコテは
0201仕様書無しさん2007/03/17(土) 21:37:15
>>200
春っぽい奴がまた発生か
0202仕様書無しさん2007/03/17(土) 21:52:12
53 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/02/24(土) 23:28:49
しかしライブラリ全部覚えとくのって大変


54 ：仕様書無しさん ：2007/02/24(土) 23:35:24
失せろ糞コテ


55 ：仕様書無しさん ：2007/02/25(日) 04:17:17
>>53

それと、OOとは、まったく関係ない。
0203仕様書無しさん2007/03/17(土) 22:10:58
本当にOO開発を分かりたいなら、ファウラーのPoEAAとエバンズのDDDを読め。
英語だが技術者なら読めるだろ。
0204仕様書無しさん2007/03/17(土) 22:12:18
読めるけど理解できません
0205仕様書無しさん2007/03/17(土) 22:13:22
PofEAAは和訳あるぞ
0206仕様書無しさん2007/03/17(土) 22:20:52
もし経営者が本当に開発効率を上げたいのなら、
こんなスレにいるアホな連中を雇ってる金で最高のハッカーを一人雇った方がいいってのはもはや常識
0207仕様書無しさん2007/03/17(土) 22:28:27
会社立ち上げては逃げ、どっかの会社に潜り込んでは逃げ
会社立ち上げては逃げ、どっかの会社に潜り込んでは逃げ
を繰り返してる経営者には無理だと思いまーす
0208仕様書無しさん2007/03/17(土) 22:28:59
そんな現実的でない可決策出す時点でお前使えんといわれるだけ
0209仕様書無しさん2007/03/17(土) 22:29:03
>>203
DDDの概要を1000文字程度 (書き込み制限)で述べよ
0210仕様書無しさん2007/03/17(土) 23:17:13
Diabolical Daemon Director
0211仕様書無しさん2007/03/17(土) 23:20:12
複雑なドメインモデル構築時のエバンズの頭の中を順を追って説明していく書物だな。
読む側も考え方や指針が掴めるから理解がしやすい。
あとジョークなんかが織り混ぜられてて、フランクな口調で書かれてるから親しみやすい。
日本語訳が待ち望まれるな。
0212仕様書無しさん2007/03/17(土) 23:25:06
とりあえずdomain-driven design quicklyとかいうのが無料なので落としてみた
これ読んで良かったら買ってみる
0213仕様書無しさん2007/03/17(土) 23:52:59
>>211
ｗｗｗｗおいｗｗｗｗちょっとｗｗｗｗそれ単なる読書感想文じゃんｗｗｗｗ
ｗｗ仮にも技術系板でｗｗｗｗそれは低レベル過ぎるぞｗ
0214仕様書無しさん2007/03/17(土) 23:56:16
>>211
なんとも言いがたい違和感を感じる文章だな
0215仕様書無しさん2007/03/18(日) 00:23:27
ん
ぽ
ぽ
ん
ま
つ
り
で
す
か
？
0216仕様書無しさん2007/03/18(日) 00:26:38
215よ、おまぃも春っぽいな
0217仕様書無しさん2007/03/18(日) 17:22:36
>>154
何これ
これが基準なら、どうやったって保守性再利用性高くなるだろ。
0218仕様書無しさん2007/03/18(日) 18:25:44
>>217
そっとしといてやれ・・・。
0219仕様書無しさん2007/03/18(日) 20:37:57
釣れるのは雑魚ばかりか
0220仕様書無しさん2007/03/18(日) 20:44:22
餌が腐ってやがる。
0221仕様書無しさん2007/03/19(月) 01:29:56
オブジェクト指向って、
結局はクラスとか継承とかが理解できてりゃそれでおｋ
0222仕様書無しさん2007/03/19(月) 01:39:41
ポリモーフィズムが理解できていればOKだとは思う。
インタフェースも継承も抽象クラスもそれで使い分けられる。
0223仕様書無しさん2007/03/19(月) 08:58:32
クラスが部品であることを理解してるかどうかだと思ふ
0224仕様書無しさん2007/03/19(月) 09:16:33
だから、ＯＯＰは除外すればよかったのに、設計とかの話なら馬鹿混入しないんだから。
0225仕様書無しさん2007/03/19(月) 11:20:24
↑OOで大規模開発すると言い出して破綻させたバカ
0226仕様書無しさん2007/03/19(月) 11:21:10
たかひろスレ
0227仕様書無しさん2007/03/19(月) 11:31:25
たかひろ君が自慢気に出してくるネタは
たいてい情報システム板でたかひろに流し込んだネタだから
馬鹿馬鹿しくなる。
お前はいままで引用時にネタ元に敬意を示した事があるのか？
0228仕様書無しさん2007/03/19(月) 12:51:12
ここはマ板だからな。設計の話に限定しろという方が馬鹿。
まわりの状況がみえてない。なんでも自分の思い通りにしたがる
どっかの総書記と同じ。
0229仕様書無しさん2007/03/19(月) 13:05:05
だから、前スレのように分けてあれば良かったといってるの。
排除なんてしないよ、分離。
0230仕様書無しさん2007/03/19(月) 13:09:02
そもそもたかひろは設計などろくにできない。

たかひろの設計方法論というのは
・インベーダゲームで実証済みの設計手順
・クラス設計では、GoFデザパタ23パターンとJ2EEパターンを絶対視する
・設計の不備は全て、コーディング後にリファクタリングで改善する
・ORマッピングよりObjectStoreの優劣検討
程度の話でしかない。

設計できない人間が、話を設計に限定しようというのだから
いつも話が破綻するのは当然のこと。
0231仕様書無しさん2007/03/19(月) 13:11:52
× ORマッピングよりObjectStoreの優劣検討
○ ORマッピングとObjectStoreの優劣の比較検討
0232仕様書無しさん2007/03/19(月) 13:15:24
たかひろって誰よ？
設計話できない電波なら、設計分離すればそっちは平和になるじゃん。
Pの話で勝手に春厨呼び込んでくれよ。
0233仕様書無しさん2007/03/19(月) 13:20:47
文句ばっか言ってないでお前がスレ立てろよ。過疎らなきゃいいがな。
0234仕様書無しさん2007/03/19(月) 13:21:09
↑意味不明な春デムパ
0235仕様書無しさん2007/03/19(月) 13:23:04
>>232
> たかひろって誰よ？

>1のテンプレ書いた人。
0236仕様書無しさん2007/03/19(月) 13:26:41
設計の話で生産性も品質も度外視したいという妄想は
凄いと思った


42 名前： 仕様書無しさん [sage] 投稿日： 2007/03/13(火) 00:26:15
マ板じゃ生産性や品質評価は荒れるしスレ違いなのでこの辺で。
以後、OOに関する話題をどうぞ。

45 名前： 仕様書無しさん [sage] 投稿日： 2007/03/13(火) 00:36:44
>>42
別に構わないんじゃないか？
OOでも荒れるときは荒れるし。
生産性や品質を抜きにして語るのも違う気がするしな。

55 名前： 仕様書無しさん [sage] 投稿日： 2007/03/13(火) 08:12:15
>>45
もうちょっと学習しておいで
0237仕様書無しさん2007/03/19(月) 13:49:43
前スレの認証話の混迷具合もすげぇな

パスワード照合をユーザ・オブジェクトでやるかシステム・オブジェクトでやるか
とかｗ

正解は
http://pc11.2ch.net/test/read.cgi/prog/1171808096/151 の後半。
151も呆れ返っているように、この種の常識のない奴は逝ってヨシ

更に、この種の課題は
http://pc11.2ch.net/test/read.cgi/prog/1171808096/111
として一般化できる
02382372007/03/19(月) 13:54:41
いや、既存の利用可能な認証システムに依存しない
空理空論の分析モデルの話か。

例があまりに不適切過ぎる。
どうでもいい話だ。
0239仕様書無しさん2007/03/19(月) 15:53:36
http://pc11.2ch.net/test/read.cgi/prog/1171808096/222
名言。某OOコンサル会社元社長の現場がそれ。

http://pc11.2ch.net/test/read.cgi/prog/1171808096/298
これも名言。

http://pc11.2ch.net/test/read.cgi/prog/1171808096/498
正解。
http://pc11.2ch.net/test/read.cgi/prog/1171808096/513
分析クラスと設計クラスを同じものとしか見れないとは、
実装感覚が欠落した話だな。

http://pc11.2ch.net/test/read.cgi/prog/1171808096/583
http://pc11.2ch.net/test/read.cgi/prog/1171808096/593
ﾜﾛﾀ
0240仕様書無しさん2007/03/19(月) 16:06:17
http://pc11.2ch.net/test/read.cgi/prog/1171808096/737-738
とある数百人月規模のOO開発現場の基本設計で
とんでもない継承/関連ツリーを見た事がある。
・数百ある画面を、全て別々の画面サブクラスとして定義し、
・データクラス、ビジネスロジック・クラスを
　画面と密結合した形で画面毎に個別定義
つー設計。クラス図書くとこんな感じ

　　　　　画面abstract
　　　　　　　　△　
　　　　　　　　 ：implements
　　┌………┼………┐
　 画面1 　　画面2　　画面N
　　 ◇　　　　◇　　　　 ◇
　　 │　　　 (略)　　　 (略)
　画面1専用
　ｺﾝﾃｷｽﾄ
　　 ◇
　┌┴────┬───┐
　画面1専用　画面1専用　画面1専用
　入力ﾃﾞｰﾀ　　ｴﾝﾃｨﾃｨ　　 出力ﾃﾞｰﾀ
　(DTO)　　　　(POJO)　　 (ValueObject)
　↑　　　　　　　 ↑　　　　 ↑
　│参照　 参照│代入　 │代入
　└─────┼───┘
　　　　　　　　　　 ： n
　　　　　　　　画面1専用
　　　　　　　　ﾋﾞｼﾞﾈｽﾛｼﾞｯｸ
02412402007/03/19(月) 16:15:54
おっと、出力データもDTOだな
0242仕様書無しさん2007/03/19(月) 18:45:43
>>240
いいか悪いか別として、ありがちな設計だな。
0243仕様書無しさん2007/03/19(月) 19:50:15
基本設計なのにクラスのことを考えてるってのが古い組織を感じさせるな
まぁ今俺がおるところがそういう感じなんだがorz
0244仕様書無しさん2007/03/19(月) 19:51:13
あいたたたた、お腹痛い、ちょっとウンコしてくる。
0245仕様書無しさん2007/03/19(月) 19:51:16
>>240
トンでもない設計だな。

数百ある画面で、画面個別に
　・入出力データクラス
　・エンティティクラス
　・ビジネスロジッククラス
を作っちまったら、問題が多すぎるよ。

第一に、互いに互換のないクラスが爆発的に増えて、
作成～テスト～メンテの手間の増大、
ひいては品質低下につながる。
「後でリファクタリングで整理するから大丈夫」
なんて言えるレベルじゃない。

第二に、各画面間でロジックやデータ、エンティティ
の型互換性が低下しやすくて、
「後からリファクタリングで共通メソッド/クラスを抽出」
が著しく困難になる。

問題は、ロジックが特定画面の特定データ、特定エンティティと
密結合しちまっていて、切り離しが面倒ってこと。

こんな基本設計押し付けてくる奴が居たら
俺は即座に理由を説明してダメ出しするだろうな。
0246仕様書無しさん2007/03/19(月) 19:56:58
また自演かよ
0247仕様書無しさん2007/03/19(月) 19:58:37
>>243
> 基本設計なのにクラスのことを考えてるってのが古い組織を感じさせるな

いちいちつまんない事でつっかかるなよ。
普通に言えば「アーキテクチャ設計」だよ。

0248仕様書無しさん2007/03/19(月) 19:58:41
ビジネスロジックってたいへんなんでねえ。
0249仕様書無しさん2007/03/19(月) 20:05:43
まぁこの手のシステムでは
MartinFawler言うところの「ドメイン・スクリプト」のパターンに陥りがちなんだよな。
あと、数百ある画面自体は、開発ﾂｰﾙでﾎｲﾎｲ作成できるっつうのに、
そこに付帯する味噌っかすみたいなドメインスクリプトを
何百人月とかけて設計、コーディング、テストしてるっつうのが
バカバカしいんだよな。

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ
02502492007/03/19(月) 20:06:53
×ドメイン・スクリプト
○トランザクション・スクリプト
orz

まぁこの手のシステムでは MartinFawler言うところの
トランザクション・スクリプト・パターンに陥りがちなんだよな。
あと、数百ある画面自体は、開発ﾂｰﾙでﾎｲﾎｲ作成できるっつうのに、
そこに付帯する味噌っかすみたいなドメインスクリプトを
何百人月とかけて設計、コーディング、テストしてるっつうのが
バカバカしいんだよな。

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ
0251仕様書無しさん2007/03/19(月) 20:07:58
×ドメイン・スクリプト
○トランザクション・スクリプト
orz orz orz

まぁこの手のシステムでは MartinFawler言うところの
トランザクション・スクリプト・パターンに陥りがちなんだよな。
あと、数百ある画面自体は、開発ﾂｰﾙでﾎｲﾎｲ作成できるっつうのに、
そこに付帯する味噌っかすみたいなトランザクション・スクリプトを
何百人月とかけて設計、コーディング、テストしてるっつうのが
バカバカしいんだよな。

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ
0252仕様書無しさん2007/03/19(月) 20:14:30
実際COBOLやってた組織のシステム作るときは>240みたいな設計を押し付けられることが多い。
しかも基本設計という名の下に。
なぜか要件定義段階からStruts拡張自前フレームワークを使用するという前提までつけられる。

本来であればサービスの1メソッド程度のものを、個別のビジネスロジッククラスとして定義させられたりしてな。
0253仕様書無しさん2007/03/19(月) 20:18:30
要するに、メインフレーム系COBOL等の
オープンシステムへのミグレーションね。

そして、そんな設計押し付けてくる奴には
ダメ出ししなきゃね。
0254仕様書無しさん2007/03/19(月) 20:22:55
ユーザ企業本体の情報システム部門～関連子会社の下請けに入る限りは、
そこらへんに変な条件が付帯するのはしょうがないよな。
0255仕様書無しさん2007/03/19(月) 20:25:07
うひょー。綴り考えながら書いたら、ミスってるし。

× ミグレーション
○ マイグレーション
0256仕様書無しさん2007/03/19(月) 20:25:32
今時、画面とB/Lの分離もできないっていうのが、致命的なんだよな。
>>240の設計は実装を分離しただけの代物だろ。
0257仕様書無しさん2007/03/19(月) 20:39:57
>>255
ググった俺の人生を返せ
0258仕様書無しさん2007/03/19(月) 20:41:46
>>251
開発ﾂｰﾙを使ってｻｸｻｸの部分が失敗して
完全なﾃﾞｽﾏｰﾁ化する事も多いからなぁ…

そうなったときの責任の所在も
曖昧になる事が多いのがなんともね…w
0259仕様書無しさん2007/03/19(月) 20:56:08
http://science6.2ch.net/test/read.cgi/infosys/1103757092/

これの件は、まぁ俺の責任じゃーねぇな。
より上位から判断できる人間２人には問題点を指摘したし、
その問題を無視して突っ走ったバカの責任だろ。
0260仕様書無しさん2007/03/19(月) 21:11:01
ネタにされてますよ
0261仕様書無しさん2007/03/19(月) 21:21:31
>>258
　>>259は、開発ﾂｰﾙが提供している複数のｿﾘｭｰｼｮﾝを
理解できないSEが、選択をﾐｽって暴走しただけの話だろ。

>>251の「開発ﾂｰﾙでﾎｲﾎｲ」は意味が違う。
・いくらﾏｲｸﾞﾚｰｼｮﾝ部隊と言えども、Webだったらこんな設計はしない。
　Webｱﾌﾟﾘｹｰｼｮﾝの設計作法などｺﾓﾃﾞｨﾃｨ化しているから、
　設計の初期段階で誰かが気付いてさっさと方向修正できていたはずだ。
・問題は、ﾌｧｯﾄｸﾗｲｱﾝﾄの作法で画面中心の設計をしちゃった事。
　ﾌｧｯﾄｸﾗｲｱﾝﾄの作法は未だに、ﾗｲﾌﾞﾗﾘの提供する部品を継承して
　Compositで組み合わせて、一画面一画面別々の画面クラス～処理クラス作り
　という手法が標準の地位を占めている。
　例のCLU～X WindowやObjectPascal～MacApp時代の名残だ。
・>>240の問題は、ﾌｧｯﾄｸﾗｲｱﾝﾄ流の１画面１クラスを頂点に、
　COBOL流ﾌﾟﾛｼｰｼﾞｬ＝ｸﾗｽとする処理クラスと、
　構造体＝ValueObject or DTO とするデータクラスを追加して、
　それを継承や(略 でガンジガラメにしちゃった、って点にあると思う。ｗ
　
02622612007/03/19(月) 21:38:47
あうあう。ちょっと説明が跳んだなｗ
書き直し。

>>258
　>>259は、開発ﾂｰﾙが提供している複数のｿﾘｭｰｼｮﾝを
理解できないSEが、選択をﾐｽって暴走しただけの話だろ。


>>251の「開発ﾂｰﾙでﾎｲﾎｲ」は意味が違う。
要するに、あれはﾌｧｯﾄｸﾗｲｱﾝﾄ流の設計＋αだ。
ﾌｧｯﾄｸﾗｲｱﾝﾄの画面なら、IDEの画面ﾂｰﾙでｻｸｻｸ作れる。
その手のﾂｰﾙは大抵、１画面１クラスみたいなｺｰﾄﾞを吐き出す。
そしてその画面ｸﾗｽにﾐﾄﾞﾙｳｪｱ使ってﾘﾓｰﾄｲﾝﾀﾌｪｰｽ付けりゃ
画面部は完了だろ。
　(そのあたりはかなり枯れている)

問題はその後、＋αの部分だ。
個々の画面に密結合する形で、
画面専用のデータクラス、画面専用のロジッククラス
などというものの設計を許しちゃうから、
クラス数の爆発して、ﾃﾞｽﾏｰﾁ化する、って事。
0263仕様書無しさん2007/03/19(月) 21:39:35
>>260
ｋｗｓｋ
0264仕様書無しさん2007/03/19(月) 21:45:55
http://pc11.2ch.net/test/read.cgi/prog/1174154285/
02652612007/03/19(月) 21:53:58

問題はもう一つある。(>>261後半部分)

１画面１クラスを頂点に、 画面単位で
COBOLﾌﾟﾛｼｰｼﾞｬ＝１ｸﾗｽとするﾋﾞｼﾞﾈｽﾛｼﾞｯｸ (Coplienのfunctorパターン)と、
構造体＝1ｸﾗｽとするﾃﾞｰﾀｸﾗｽ(J2EEﾊﾟﾀｰﾝのValueObject or DTO)を追加して、
なおかつそれを継承/関連でガンジガラメに密結合しちゃってる事。
これではﾋﾞｼﾞﾈｽﾛｼﾞｯｸもﾃﾞｰﾀｸﾗｽも再利用できない。


これらの問題の解決方法はただ一つ。
ﾋﾞｼﾞﾈｽﾛｼﾞｯｸやﾃﾞｰﾀｸﾗｽを、できるだけ画面に依存しない形(疎結合)にしろって事。
そのためには、設計に充分時間をかけて、判りやすい疎結合の手法を決めておけ
って事。
よく、「設計に時間をかける程品質が上がる」ってのは、
その類の問題を事前に検出して、その問題に対するｿﾘｭｰｼｮﾝを検討しておく
って事なんだ。
0266仕様書無しさん2007/03/19(月) 22:08:30
ぉーぃ酔っ払い

話がﾙｰﾌﾟしてるZO!
0267仕様書無しさん2007/03/19(月) 22:10:35
148 名前：仕様書無しさん[] 投稿日：2007/03/19(月) 22:08:24
ビジネスロジックに対する正しい対処法：

そういうところに関わらない仕事で食っていく。
ドカタ仕事はドカタに投げる。ドカタはそれが技術と思って喜んで作っては捨て作っては捨てを
繰り返す。無限にデスマを続けながら、俺は先端技術者だぜｲｪｰｲと喜ばせておく。

やっすい単金で。
0268仕様書無しさん2007/03/19(月) 22:15:14
>>261
俺が話しているのも
その＋αの部分の話なんだけど
ｿｰｽｼﾞｪﾈﾚｰﾀみたいなﾂｰﾙ開発して解決する前提が
うまく行かず、ﾃﾞｽﾏｰﾁ化が
酷い事になってた時があった。

設計とある程度並行に
実装が進む開発の場合は
ありがちな問題かと思った。
0269仕様書無しさん2007/03/19(月) 22:29:22
>>261
たしかに、そのときもｿｰｽｼﾞｪﾈﾚｰﾀ周りを
きちんと設計出来てから
開発を進めれば問題なかったかもしれない。

しかし、複数の会社が絡んでいたり
担当者が掛け持ちで仕事して
そっちも忙しかったりで
無理だったと思うけどw
0270仕様書無しさん2007/03/19(月) 22:35:03
その件に関して、キミを責めたりはしていない。

ってどこのキミかよくわかんないけどｗ
最近耳ぶたが閉じっぱなしで勘が狂いっぱなし・・・花粉のせいか
0271仕様書無しさん2007/03/19(月) 22:36:48
むしろ基本設計部隊だよなぁ、問題あるのは
0272仕様書無しさん2007/03/19(月) 23:51:42
　 ε　⌒ﾍ⌒ヽﾌ
　（ 　　( 　・ω・）　基本設計ブタ？
　　しー し─Ｊ
0273仕様書無しさん2007/03/19(月) 23:58:06
引用しまくってる春厨がいるな
0274仕様書無しさん2007/03/20(火) 02:35:23
はぁ？引用じゃなく、単に書きなおしてるだけじゃねぇの？
0275仕様書無しさん2007/03/20(火) 08:07:55
2時か。
春厨確定だな
0276仕様書無しさん2007/03/20(火) 08:50:30
相変わらず逃げまくりだねぇ、あんたの人生
0277仕様書無しさん2007/03/20(火) 10:54:01
ﾄｺﾛﾃﾞ ﾅｾﾞ ﾊﾝｶｸ ｶﾅｶﾞ ｵｵｲﾝﾀﾞﾛ
0278仕様書無しさん2007/03/20(火) 13:43:40
理解でないのではなく使い方、メリットがわからんのだろ
かつての構造化プログラミングが提唱されたときと同じ
自分の作業に疑問をもってないやつは気がつかないのさ
0279仕様書無しさん2007/03/20(火) 14:33:01
If message contains many English words, fools can't read.
If message contains many zenkaku katakana words (i.e., imported idea),
fools miss understanding.
To have plain discussion with fools,
>>261 wrote message with hankaku katakana.

そこまで言われんでも自分で理解しときぃやー。ぼけぇー。
0280仕様書無しさん2007/03/20(火) 14:35:23
あうあう
0281仕様書無しさん2007/03/20(火) 16:30:41
ドメインモデル設計と実装は切り離すのではなく一緒に考えるんだ。
SEは良い設計ができるだけでなくバリバリ実装もできるんだ。

ってDDDにかいてあったよ。
0282仕様書無しさん2007/03/20(火) 17:18:33
議論の文脈との関連を説明せずに
引用のみ書いても意味がない。
0283仕様書無しさん2007/03/20(火) 17:28:21
相手とかみ合った会話ができないのが
たかひろ の特徴
0284仕様書無しさん2007/03/21(水) 00:28:51
なんだなんだ？この春厨の多さは！？
0285仕様書無しさん2007/03/21(水) 00:45:11
お前は泣きながらｵﾅｰﾆしてろ
0286仕様書無しさん2007/03/21(水) 00:58:30
また>>285という春が釣れたわけだが雑魚すぎて泣けてくる
0287仕様書無しさん2007/03/21(水) 01:23:37
またお前か。
一般論を隠れ蓑にした
知り合い同士の内輪話だから
お前は顔突っ込むな
0288仕様書無しさん2007/03/21(水) 01:25:37
また釣れた　雑魚だが
0289仕様書無しさん2007/03/21(水) 01:27:46
キチガイ警報発令！！！
0290仕様書無しさん2007/03/21(水) 01:32:45
>>289
お前さっきからウザイぞ
自分のブログに逝け
0291仕様書無しさん2007/03/21(水) 01:33:31
キチガイ警報発令中！！！
0292仕様書無しさん2007/03/21(水) 01:37:00
オブジェクト指向を理解してる人って
技術者の何％ぐらいなんやろ？
0293仕様書無しさん2007/03/21(水) 01:45:40
現場の技術者って何％ぐらいなんやろ？
0294仕様書無しさん2007/03/21(水) 07:23:55
　　　　　　　　　　　　
0295仕様書無しさん2007/03/21(水) 07:38:23
キチガイ警報解除
0296仕様書無しさん2007/03/21(水) 07:58:02
議論の土俵を用意してやっても
一向に議論展開できない ﾍﾀﾚ>>1
0297仕様書無しさん2007/03/21(水) 08:58:48
５％もいるかな？
オブジェクト指向を掲げる現場は多いけど、
要員集めは言語で集めるしね
0298仕様書無しさん2007/03/21(水) 10:10:02
言語で集めてるならまだマシだけどな
0299仕様書無しさん2007/03/21(水) 10:27:59
ﾍﾀﾚ
0300仕様書無しさん2007/03/21(水) 10:51:00
釣堀かｗ
0301仕様書無しさん2007/03/21(水) 13:31:28
現場の80%は作業員
0302仕様書無しさん2007/03/21(水) 13:39:28
議論の土俵を用意されても
一向に議論展開できない ﾍﾀﾚ>>1
0303仕様書無しさん2007/03/21(水) 14:46:28
>>302
コピペ春厨は消えうせろ
0304仕様書無しさん2007/03/21(水) 16:22:16
スレ天婦羅に議論展開とは恐れ入ったｗ
0305仕様書無しさん2007/03/21(水) 19:01:22
なんだ>>1のテンプレは飾りかよ

Martin Fowlerを元ネタに
技術話のネタも書けねぇとは
とんだ池沼だな
0306仕様書無しさん2007/03/21(水) 19:08:59
おまえが書けボケナス
0307仕様書無しさん2007/03/21(水) 19:15:14
議論の土俵を用意されても
一向に議論展開できない ﾍﾀﾚ>>1
0308仕様書無しさん2007/03/21(水) 19:15:47
議論の土俵を用意されても
一向に議論展開できない 池沼>>1
0309仕様書無しさん2007/03/21(水) 19:22:19
なんで、Martin Fowlerを元ネタにせなあかんねん。一人でオナってろ。
0310仕様書無しさん2007/03/21(水) 20:00:03
頭悪すぎ
0311仕様書無しさん2007/03/21(水) 20:03:04
>>309
この高名な先生に逆にMartin Fowlerについて質問してみたらいかがですか？
0312仕様書無しさん2007/03/21(水) 20:03:50
たぶん>>1の発言待ちにおちつく事が予想されてしまいますが。
0313仕様書無しさん2007/03/21(水) 20:07:09
この先生はかつてはオープンソースの大家と言われてました。
ただmake installはいつも失敗していたようですが。
0314仕様書無しさん2007/03/21(水) 20:52:58
議論の土俵を用意されても
一向に議論展開できない 池沼>>1
0315仕様書無しさん2007/03/21(水) 20:58:27
>>314
では、先生。先生の議論展開をお願いします。
0316仕様書無しさん2007/03/21(水) 21:37:54
たまに、スレタイに則ったまともな話になっても、
理解できない香具師が暴れるっつーのがこのスレの流れとして定着してきた感があるな。
0317ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/21(水) 21:42:50
>>292
>>297
ＯＯを批判してる人は１００％理解している。
ＯＯを支持してる人は２０％くらい
0318仕様書無しさん2007/03/21(水) 21:47:35
うそつけ。具体的な批判など一度も出てきて無いぞ。
0319仕様書無しさん2007/03/21(水) 21:50:26
おっさんスレに基地外が住み着いたようなのだが、出所はここか。
0320仕様書無しさん2007/03/21(水) 21:55:22
おっさんスレのんぽぽんが居るじゃないか
よう、んぽぽん！
0321仕様書無しさん2007/03/21(水) 21:56:16
>>319
違いますね。
彼は２ちゃんにしか居所のないﾋｷｰ。
２ちゃんのスレをさすらうのが彼の人生。
0322仕様書無しさん2007/03/21(水) 21:57:23
議論の土俵を用意されても
一向に議論展開できない 奇知guy>>1
0323仕様書無しさん2007/03/21(水) 21:57:28
どこが違うんだよｗ
0324仕様書無しさん2007/03/21(水) 22:01:18
>>321
さすが、んぽぽんだけあって、んぽぽんが解ってるな
次はこのスレでんぽぽんするのか
0325仕様書無しさん2007/03/21(水) 22:13:51
322のような春厨が多発しているスレはここですか？
0326仕様書無しさん2007/03/21(水) 22:53:52
漏れ思うんだけどさぁ、別に全ての状況で無理にＯＯを意識する必要ないべ？
例えばＰＧ組む時でも、複数のインスタンスを生成した方が便利そうな場合は、
ＯＯ使えばいいし、そうでなければ、普通の構造化だけでいいんじゃね？
つまり、1対多、多対多の関係をもつエンティティを扱う場合はOOがいいし、
単一或いは、1対1の関係しかないエンティティだけの場合は、ＯＯいらないと。
しかし、言語の構造がもはやＯＯを前提にしちゃってるから、まぁ、カプセル化
ぐらいは使うか、とか、場合によっちゃ、継承やポリモも使っちゃうかぐらいの
感覚でいいんじゃねぇかと。 OOやるぞぉって身構えちゃう必要ないよな。
0327仕様書無しさん2007/03/21(水) 22:55:21
そそ。
0328仕様書無しさん2007/03/21(水) 22:56:32
そういうときはシングルトンパターンを使え。
0329仕様書無しさん2007/03/21(水) 23:03:16
シングルトンパターンがどうこう、ってのはオブジェクト指向に含まれるのか？
それって派生した奴の話じゃないの？
少なくとも、今まで読んだ本の中にシングルトンの話は出てないんで
必要性がさっぱりわからん。
0330仕様書無しさん2007/03/21(水) 23:04:51
実行中にnewすると処理時間を食われる。
複数インスタンス必要なものならいざしらず、単一インスタンスしか必要なく、
実行中に存在してればＯＫなものはシングルトンがむいている。
0331仕様書無しさん2007/03/21(水) 23:09:05
System.out.println("Hello World!");を実行するためにSystemをnewするような
バカな真似をしたくない。
0332仕様書無しさん2007/03/21(水) 23:10:30
複数インスタンス必要の場合は何パターンがお勧め？
0333仕様書無しさん2007/03/21(水) 23:10:56
>>326
そうなんだけど、多分そのやり方じゃうまくはいかないべ
OO覚えてしばらくは厨のように、全てにOO適用デザパタ適用するんだ。
そのうちOO/デザパタを「あえて省略できる」ようになってくる
0334仕様書無しさん2007/03/21(水) 23:13:16
全部おじゃばに見えてきたw
やべえな
0335仕様書無しさん2007/03/21(水) 23:15:38
>>332
シングルトン＊Nパターン
0336仕様書無しさん2007/03/21(水) 23:17:21
インスタンス化する必要のないものまでインスタンス化するのは無駄。
モジュールでＯＫ。
0337仕様書無しさん2007/03/21(水) 23:20:05
>>335
あまりにも常識過ぎるレスに、逆にワロタヨ
0338仕様書無しさん2007/03/21(水) 23:23:20
シングルトンってなんだ？
OOでは普通に使うのか？
0339仕様書無しさん2007/03/21(水) 23:24:43
自分ではなんの答えも出していないのに笑うだけかよ。
0340仕様書無しさん2007/03/21(水) 23:26:00
素のシングルトンってのはもう流行らんぞ。テストもしにくいし。
0341仕様書無しさん2007/03/21(水) 23:26:08
シングルトンもマネージャクラスみたいなものには必要かもしれないど、
クラスメソッドで十分な場合も多い。特に単一スレッドの場合は。
0342仕様書無しさん2007/03/21(水) 23:26:13
http://www.nulab.co.jp/designPatterns/designPatterns2/designPatterns2-1.html
このページを読んでみたが、
梅酒で酔っ払った俺には理解できねーｗ
0343仕様書無しさん2007/03/21(水) 23:28:58
>>341
そういうの向けにmonostateパターンっていうのがあるぞ
0344仕様書無しさん2007/03/21(水) 23:30:34
>>343 それっと、ものすげぇの？
0345仕様書無しさん2007/03/21(水) 23:33:41
誰か梅酒な俺に教えてくれ。
なんとかパターンってのは覚えてないと
オブジェクト指向を理解した、とはみなされないのか？
なんとかパターンって定石みたいなんもんなんだろ？
0346仕様書無しさん2007/03/21(水) 23:36:22
キチガイが糞質問中
0347仕様書無しさん2007/03/21(水) 23:38:40
>>346
はいはい、ﾊﾞﾛｽﾊﾞﾛｽ
0348仕様書無しさん2007/03/21(水) 23:43:26
すぐ、どうでも良いミクロな枝葉な話になる。
厨房の春、にっぽんの春。
0349仕様書無しさん2007/03/21(水) 23:45:24
>>345
ググればすぐ出てくるものだから覚える必要なんかないよ。

クラスをつかったパズルみたいなもので、頭かたいやつは名前と何の役にたつか
知っとけって感じ

ただし、我流OOPをある程度やった後じゃないと理解できん可能性があるかな。
0350仕様書無しさん2007/03/21(水) 23:46:23
>>348
>>281
0351仕様書無しさん2007/03/21(水) 23:48:44
>>349
サンクス。まあそんな感じだとは思った。
結論は、オブジェクト指向の根幹に関係ねーってことね。
明日シラフになったら調べてみるわ
0352仕様書無しさん2007/03/21(水) 23:49:07
キチガイがループ中
0353仕様書無しさん2007/03/21(水) 23:55:40
352の主治医です。
この度、このようなレスを352が行うに至ったことは、
主治医として、大変残念な事であり、また、治療の効果が
まだまだ現れていないことを証明しているため、そろそろ
最終的な決断を下す必要があるようです。
みなさんお聞きになったことがあるかもしれませんが、
必ずしも心の病は、特殊な病気ではなく、誰もがそうなる
可能性があります。しかし、だからといって、これ以上、
352を放置することは、例えば何の関係もない人を傷つけたり、
逆に352自身の将来にとり、名から図示も良いことではありません。
そこで、私は、352の両親、臨床心理士などとも相談して、
352をしばらくの間、ネットの出来る環境から離して、
濃密な人間関係の中で治療をすることにしました。
352にとっては、納得がいかないことかもしれませんが、私も、
医師免許をかけて、352を徹底して直すことに致しました。
どうかみなさん！352が戻ってきましたら、このような人を悲しませる
スレではなく、みんなに感動を届ける以上の人間になっていると思いますので、
暖かく見守ってやってください。
0354仕様書無しさん2007/03/21(水) 23:58:23
名から図示も
0355仕様書無しさん2007/03/22(木) 00:01:24
>>351
覚えていると会話容量を減らせて楽だぞ。
反面、このパターンがどうのこうのとシッタカな厨が釣れてしまうが。
0356仕様書無しさん2007/03/22(木) 00:01:34
オブジェクト指向を理解してる奴が何％ぐらいいれば、
システム開発はラクになるんだ？
0357仕様書無しさん2007/03/22(木) 00:02:32
>>353の出現によりスレに基地外スレ警報でました
速やかにスレより非難してください
0358仕様書無しさん2007/03/22(木) 00:07:04
荒らしは軽やかにスルーしましょう
0359仕様書無しさん2007/03/22(木) 00:17:08
>>356
設計・実装に関わる人間については100%
一人で設計・実装をやるのが現実的かな
0360仕様書無しさん2007/03/22(木) 00:19:27
一応マジレスすると

>>352-353

「日本初の基幹系大規模OO開発を成功させる」
とか大言壮語したなんちゃってコンサルが、
国内のマイグレーション現場の現実を事前に知らずに、
そのまま現場のグダグダに巻き込まれてしまうのは
失笑に値する。

・・・そういう現実を皆知ってるから、
基幹系とか大規模開発には関わらないようにしてるんだってｗ
0361仕様書無しさん2007/03/22(木) 00:23:04
まあ基幹系でも、まともな業種もあるけどな。
金融～証券の基幹はほぼドキュソの世界。
03623602007/03/22(木) 00:24:23
リンクミス
>>252-253
0363仕様書無しさん2007/03/22(木) 00:31:25
>>360
基幹系って「十分すぎる程枯れたモノ」を使うところだろうにね。
0364仕様書無しさん2007/03/22(木) 00:32:42
ハードがそろそろ壊れるとか、処理速度が遅いとか、
金が余ってるとか、なんとなくとか、
いろいろ理由があるんだろ
0365仕様書無しさん2007/03/22(木) 00:48:50
うまくいかないプロジェクトってのは、単に人を入れすぎなんでしょ。
0366仕様書無しさん2007/03/22(木) 00:53:46
言語でしか人選しねーからなあ
OO経験なんて確認する現場なんて聞いたことねー
0367仕様書無しさん2007/03/22(木) 01:01:07
>>366
OO以前の問題。
人集めは自分でやるんだよ。
0368仕様書無しさん2007/03/22(木) 01:05:44
なんかドラクエみたいだな
0369仕様書無しさん2007/03/22(木) 01:10:27
人買いから十把一絡げで人員調達してうまくいくプロジェクトなんてないからな。
人集めする権限を自分で持つか、権限を持った人物と知り合いになるかすればよくて
それはそんなに難しくないだろ。
0370ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:16:15
んなもんモジュールごとに担当分けしてＯＯやりたいやつだけ勝手に中でやればいいだろ。
なぜ全体を支配しようとする？
いざとなったら逃げるか放置の癖に
0371仕様書無しさん2007/03/22(木) 01:17:06
まだ生きてたのか
この糞コテ
0372ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:17:19
ＯＯ厨はモジュールの中に隔離して他に感染しないようにするべき。
0373ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:20:23
もう５年前かなあ
この板でオセロでＯＯ勝負したけどＯＯ厨みんな逃げたね
0374仕様書無しさん2007/03/22(木) 01:20:49
OOアンチにはモジュラリティなんて概念ごと無いくせに良く言うわ
0375仕様書無しさん2007/03/22(木) 01:21:41
>>373
勝負ってどうやって？
0376仕様書無しさん2007/03/22(木) 01:23:21
>>373
日本語でおｋ
0377仕様書無しさん2007/03/22(木) 01:23:52
>>373
何の勝負か知らんが、俺が受けてやったっていいぜ？ん？
0378仕様書無しさん2007/03/22(木) 01:26:04
全角英数使ってるようなアホコテの言い出す勝負ってどんなんかwktk
0379仕様書無しさん2007/03/22(木) 01:28:10
この5年OOアンチでいたことは、技術者として致命的だったな。
0380ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:31:21
この板で「オセロ作って勝負しよう」といって
開発時間とソース公開やったの。
ＯＯの生産性は構造化の1/10くらいだった
0381ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:32:04
いまファイル残ってるの見つけたが
Ｊ２ＳＤＫ１．４だべ
0382仕様書無しさん2007/03/22(木) 01:32:57
電球の主張がよく分からん
0383仕様書無しさん2007/03/22(木) 01:33:41
おれも
0384ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:34:58
サンのダウンロードページ行ったら　トップがｃ、ｃ＋＋　ＦＯＲＴＲＡＮじゃん
Ｊａｖａどこいった？
0385仕様書無しさん2007/03/22(木) 01:35:38
>>380
いろいろあるがまず、構造化とOOがなんで対立する概念みたいなってんのよ。
0386ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:37:08
ＪＡＶＡのＳＤＫのダウンロードページねえですよ？
0387仕様書無しさん2007/03/22(木) 01:37:44
COBOLとsmalltalkでどっちが速くオセロつくれるかってこと？
0388ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:37:54
構造化だけ
と書いておこう
0389仕様書無しさん2007/03/22(木) 01:37:54
OOは一からの生産性が高いとはあまり聞かないな。
修正が効き易いという話は聞くが。

っつーわけで開発時間を単純に比較しても仕方ない罠。
0390ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:38:27
java構造化　ＶＳ　ＯＯ何でもいい
0391ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:40:27
修正しにくいかしやすいかはコード書いた人によるところが大きい。
ＯＯ関係ない。
0392仕様書無しさん2007/03/22(木) 01:40:44
電球は、まず何を言いたいのかはっきりしろ
酔っ払ってんのか？
0393仕様書無しさん2007/03/22(木) 01:43:02
>392
薬物じゃね
0394ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:44:15
この板はＩＤついてないのでね
質問の一部だけ書かれても意味が判らない。
全文書くか、ハンドルつけるように。
0395仕様書無しさん2007/03/22(木) 01:45:31
＞電球
全体的に支離滅裂で主張が分からん
0396仕様書無しさん2007/03/22(木) 01:46:45
>>395
同意
0397ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:47:06
ＯＯは実験の結果とっくに生産性低いと結論が出ている。
５年前もＯＯ厨は「保守性は高い」と逃げたけど、証拠を提示できなかった。
さらに最初は「ＯＯは生産性高い」と触れ込んでたのに、あっさり撤回してたその厚顔さにあきれたもんだ。
0398仕様書無しさん2007/03/22(木) 01:48:55
>>397
お前の身近で起こったことは宇宙の真理なのか？ん？
0399仕様書無しさん2007/03/22(木) 01:49:02
だから・・・
実験の詳細を示せ
この程度の内容でまともな文章を書けないとか
お前の程度の低さを証明して終わりでいいのか糞コテ
0400ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:49:05
理論は実証によって裏付けられるべきで
実証に反する理論を掲げ続けるのは空理空論という。
0401仕様書無しさん2007/03/22(木) 01:49:51
なぜかエイとかウツボの画像が思い浮かんだ。
0402ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:50:12
時間を計っただけだよ。
0403ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:52:37
ＪＡＶＡオセロは三日くらいでできたよ　仕事終わって家でやった。
対してＯＯ側は誰も提出せず、逃げ回ってた
一ヶ月と少し経って、やっとＯＯオセロが提出されたけど、完成度は構造化のみのより低かった。
0404仕様書無しさん2007/03/22(木) 01:52:43
OOの生産性は高いはずだったのが実は低いという結果が出たんだな。
で、その生産性って奴が構造化10に対してOOが１ってことを主張したいんだよな？

そのソースを出してみれ。
３丁目のおじさんが言ってたよ、なんて話は役に立たんだろ。
0405仕様書無しさん2007/03/22(木) 01:52:53
糞ｺﾃ降臨で議論妨害か。
懐かしいパターンだな
0406仕様書無しさん2007/03/22(木) 01:53:28
＞空理空論

お前の言ってる実証って
他人に内容を伝えられない程度の妄想なんだね
OKOK　帰っていいよ
0407仕様書無しさん2007/03/22(木) 01:53:37
あほらし。
こんな話に付き合ってた俺がどうかしてたわ
0408ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:54:03
ぷ
切れてやんのｗｗ
0409仕様書無しさん2007/03/22(木) 01:54:47
たかひろ乙
0410仕様書無しさん2007/03/22(木) 01:54:54
流石に糞コテが哀れ
よくその頭で厚顔無恥なレス繰り返せるもんだ
オレにはできん
0411仕様書無しさん2007/03/22(木) 01:55:20
荒らしは華麗にスルーしましょう
0412仕様書無しさん2007/03/22(木) 01:55:37
>408
なぁ、まさか、それ煽ったつもりなの？
0413ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 01:55:42
ここか
やっとみつかった
http://java.sun.com/javase/ja/6/download.html
0414仕様書無しさん2007/03/22(木) 01:56:36
電球よ、春休みの課題ちゃんとやっとけよ
0415仕様書無しさん2007/03/22(木) 01:56:44
たかくんおっきしたお。
0416仕様書無しさん2007/03/22(木) 01:59:35
オセロって、UI以外では石と盤とロジックぐらいしかクラス対象ねぇじゃん。
ほとんどロジックの実装だっつうの。こんなんで優劣比べようなんて、どうか
してる。オセロ作るんだったら、そりゃ構造化だけでも全然OKだわな。なんで
もOOって考える方が柔軟性なさすぎ。もちっと頭柔らかくしような。
どうせゲームなら、種族や職業が100種類以上あるようなRPGで勝負すっか？
0417仕様書無しさん2007/03/22(木) 02:01:52
電球が宿題スレと勘違いしているのはここですか？
0418仕様書無しさん2007/03/22(木) 02:02:50
>>408
いい大人が、愚にもつかないレス垂れ流してみっともないだろ。

プログラムの生産性や拡張性なんざ作り手に拠るなんてことは
だれでも知ってるし、ならオセロつくる競争なんてやったってOOが
いいか悪いかなんて判断しようがないだろ。

なんでもいいから議論するに足る意見を書きこんでみろや。
0419仕様書無しさん2007/03/22(木) 02:03:32
勝負終わったら結果教えてくれ
じゃーな
0420仕様書無しさん2007/03/22(木) 02:04:40
>416
そこはシムシティで行こうぜ
0421仕様書無しさん2007/03/22(木) 02:11:57
具体的にこういうところはOO使わないほうが良いとか事例あげて主張するとか
出来ないものかねえ。
0422仕様書無しさん2007/03/22(木) 02:12:19
だいたい気取って煙草ふかしてるような奴にろくな奴はいない
0423ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 02:14:52
１．６にコンパイルしなおしてるところだ
0424仕様書無しさん2007/03/22(木) 02:16:54
勉強スレに行っておいで
0425仕様書無しさん2007/03/22(木) 02:17:30
そもそも名乗ってるコテ自体にセンスねーんだが・・・
そこは不問にしてあげたほうがいいのか？
0426仕様書無しさん2007/03/22(木) 02:19:03
春嵐はスルーで
0427仕様書無しさん2007/03/22(木) 02:19:13
とりあえず泥縄やってる時点で
生産性とか保守性とか語れるレベルじゃねーと思う
0428仕様書無しさん2007/03/22(木) 02:38:53
え？これで終わり？
尻切れ蜻蛉だな・・・
流石と言うべきか
0429仕様書無しさん2007/03/22(木) 02:54:16
爺は巣に帰れよ。
0430仕様書無しさん2007/03/22(木) 03:14:09
つーかこの糞コテなんだったん？
0431仕様書無しさん2007/03/22(木) 03:14:22
やっと基本設計書き終わった；；
期限めちゃくちゃやし・・・
明日バックレ宣言してやる！！！マジで！
こんなPJしったことか
0432仕様書無しさん2007/03/22(木) 09:19:58
>>416
違う、OO的オセロは自軍の石がそれぞれ独立した個を持っており、その協調で戦略が完成するんだよ。ｗ
0433仕様書無しさん2007/03/22(木) 09:30:36
>>432 よし、お前が電球と勝負してやれ。
0434仕様書無しさん2007/03/22(木) 09:34:16
戦略を与えるのはプレイヤーであって駒ではない。
駒は位置属性と色しか持たず、複数の駒を決められたルールで管理するのはボード。
0435仕様書無しさん2007/03/22(木) 09:50:32
だから、オセロなんか無理やりOOにしない方がいいっつうの。
0436仕様書無しさん2007/03/22(木) 10:40:46
オセロはシンプルだからOOの勉強には丁度良い
あとMVCも
0437仕様書無しさん2007/03/22(木) 10:46:29
>434
隣の駒への参照ぐらいは持ってても良いかもね。
0438仕様書無しさん2007/03/22(木) 11:00:07
1 名前： 仕様書無しさん 投稿日： 2007/03/10(土) 21:23:34
　哲学論で否定、肯定はせずに、まずは参考URLを読んだ上で語りましょう。
　【参考ページ】
　ドメインモデル貧血症
　ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
　ドメインロジックとSQL
　ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
　データ中心指向とオブジェクト指向
　ttp://hp.vector.co.jp/authors/VA020635/system/dataorient.html
　さあ、張り切っていきましょう。

403 名前： ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 投稿日： 2007/03/22(木) 01:52:37
　ＪＡＶＡオセロは三日くらいでできたよ　仕事終わって家でやった。
　対してＯＯ側は誰も提出せず、逃げ回ってた
　一ヶ月と少し経って、やっとＯＯオセロが提出されたけど、完成度は構造化のみのより低かった。

竜頭蛇尾だな。
やっぱバカか
0439仕様書無しさん2007/03/22(木) 11:01:45
オセロのコードなら4,5日前にこのスレでみたような気
がする。気のせいか・・・
0440仕様書無しさん2007/03/22(木) 11:04:33
オセロキチガイ乙
0441仕様書無しさん2007/03/22(木) 12:41:18
OO的オセロは、各石が独自の判断で他の石と連携して戦略を盤面に伝えるんだろ？
0442仕様書無しさん2007/03/22(木) 12:53:34
オセロみたいに思考スピードが要求されるドメインで
OOなんか使ってちんたらやってられっかよ。
データは配列で十分だ。
0443仕様書無しさん2007/03/22(木) 13:31:28
なにいってんの
0444仕様書無しさん2007/03/22(木) 13:50:54
結論： ﾆｰﾄにOOは不要。
　　　　OOにﾆｰﾄは不要。

終了
0445仕様書無しさん2007/03/22(木) 16:38:54
開発によってはOO的な手法が害になるという点と
単純な意味での生産性ではOO的な手法が従来的な手法より劣るという点では
電球の意見も理に適っている。

ただし、実際にはコードの再利用性や保守性が上がる効果が
OOにはあるので単純な比較は難しいけどな。
0446仕様書無しさん2007/03/22(木) 17:27:17
抽象論ですらない、実に中身のないご意見ですね。
0447仕様書無しさん2007/03/22(木) 17:51:51
物質指向とは梵が唱えし如来の十号における応供を声聞の成仏たるべしと解了するが如きなるものかな。
0448仕様書無しさん2007/03/22(木) 18:02:39
設計する上でセマンティック結合は避けた方がいいな、一般に凝集度
は強い方がいいとはされているが、これも場合によりけりである。
ルーチンレベルでの凝集度について検討することがヒューリスティクス
の観点から効果的であることには異論は無い。なかなか現場では実践さ
れないのが残念だが。
0449仕様書無しさん2007/03/22(木) 18:12:51
>>447
オブジェクト指向は部品指向であって物質指向ではないぞ
0450仕様書無しさん2007/03/22(木) 18:31:54
テストのし易さを常に念頭において設計することは良いプラクティスだ。
0451仕様書無しさん2007/03/22(木) 18:50:11
>>449
確かにオブジェクト指向より部品指向と言ったほうが解り易いな。

-早くPGを辞めて、新しい人生を歩くことは良いことだ
0452仕様書無しさん2007/03/22(木) 19:35:33
PGのスキルを武器に他業種に潜り込むのは良いライフハッキングだ
0453ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 20:17:18
そのときのオセロＵＰ
Ｊａｖａなんで環境整えないと動かない。

http://vipup.sakura.ne.jp/512kb/src/512kb_8346.lzh

環境は　C:\Program Files\Java\jdk1.6.0\　だ。
0454ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 20:18:18
アップ失敗したくさい
フィルターかかってんのか？
0455仕様書無しさん2007/03/22(木) 20:22:09
コマクラスのsetter/getterで白黒いれかえるの？
0456仕様書無しさん2007/03/22(木) 20:28:11
Othello.java　Othello2.java src
ってなんだよ。readmeぐらい入れとけや、ヴぉけ！
0457ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 20:30:51
http://vipup.sakura.ne.jp/512kb/src/512kb_8358.lzh
今度は成功
0458仕様書無しさん2007/03/22(木) 20:41:58
理解できるのかよ
羨ますぃー
0459仕様書無しさん2007/03/22(木) 20:56:03
糞コテが糞ソースを公開してスルーされるスレｗ
0460仕様書無しさん2007/03/22(木) 21:02:25
結論： 糞ｺﾃにOOは不要。
　　　　OOに糞ｺﾃは不要。

終了
0461仕様書無しさん2007/03/22(木) 21:17:25
手続き型と言いながら中途半端にOO使ってるし。つっても継承と
UI廻りだけか。どうせなら、全部クラス変数とクラスメソッドにしろよ。
public だらけじゃん。意味ねぇ～
0462仕様書無しさん2007/03/22(木) 21:28:20
>>461
そういうキミは、どんなクラスを抽出できたのかな？
0463仕様書無しさん2007/03/22(木) 21:32:04
ん～と、今んとこ、電子クラスと陽子クラスと中性子クラスの３つ。
0464仕様書無しさん2007/03/22(木) 21:33:54
結論：
　　　　池沼にOOは不要。
　　　　OOに池沼は不要。

池沼の方は巣 ( http://etc6.2ch.net/denpa/ ) にお引取り下さい。

終了
0465仕様書無しさん2007/03/22(木) 21:39:11
今やBDUFは流行らない。最近の流行はLDUF若しくはENUFだ。
そういう意味では、>>457はプロトタイプとしてはまぁまぁ
の出来だと言えるのではないか。
0466仕様書無しさん2007/03/22(木) 21:42:24
>>462
View部
　　　　　　(略)
Model部
Game　　１回戦分のゲーム
Score　　対戦記録 (コマンドパターンで譜の再現等)
Step　　　一手 (Commandパターン)
Board　　盤面の管理
Player　　プレイヤ (人間およびコンピュータ)
Strategy コンピュータ側思考 (Strategyパターン)
0467仕様書無しさん2007/03/22(木) 21:48:04
BDUF： Big Design Up Front
LDUF： Little Design Up Front
ENUF： ENough design Up Front
0468仕様書無しさん2007/03/22(木) 21:49:05
終了
0469仕様書無しさん2007/03/22(木) 21:52:44
>>466
あと、審判(指し手交代、パス回数、得点の管理)とか、
ルール(StrategyパターンでOthello/Reversi/源平碁等のルール切替)
があっても良いかもな。
0470仕様書無しさん2007/03/22(木) 21:58:12
この程度の屑ソースのうpに半日以上かかるアホコテが
保守性だのなんだのって馬鹿も休み休み言えってカンジだな
0471仕様書無しさん2007/03/22(木) 21:59:10
結論：
　　　　ソースも読めない池沼にOOは不要。

池沼の方は巣 ( http://etc6.2ch.net/denpa/ ) にお引取り下さい。

終了
0472仕様書無しさん2007/03/22(木) 21:59:29
>>448のような横文字は嫌だな
独りよがりで敬遠されそうだ
0473仕様書無しさん2007/03/22(木) 22:08:37
独りよがり、ってなんかエロくね？ひとりーよがり。
0474仕様書無しさん2007/03/22(木) 22:09:11
電球ソース見たけどpublic好きなのもほどほどにしとけよ
privateが一個もねーし
全然Javaが分かってねーだろ
0475ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:10:34
ＯＯで組んでないっつうの
0476仕様書無しさん2007/03/22(木) 22:10:55
どうせどっかのアフォが書いたデタラメだと思うけどｗ

「設計する上でセマンティック結合は避けた方がいいな、」
＝設計時には疎結合を心掛けよ。
　画面中心設計で画面に密着したクラス設計をすると、
　変更の自由度や再利用性が失われる。

「一般に凝集度 は強い方がいいとはされているが、これも場合によりけりである。 」
＝一般に、関連するデータと処理は
　一まとめにした方がいい (＝クラス化、ひとまとまりのクラス)
　と言われるが、これによって前述の密結合が発生するのは論外である。

「ルーチンレベルでの凝集度について検討することが
ヒューリスティクス の観点から効果的であることには異論は無い。」
＝むしろ、関連するデータと処理は、手続き(処理)レベルで
　 一まとまりにした方がいい、ってCOBOL現場のおっちゃんが言ってたから
　 それがいーと思いまーす。トランザクション・スクリプト、マンセー
　 漏れはOOコンサルやめて、手続き型プログラミング・コンサルに堕ちまーす。

「なかなか現場では実践さ れないのが残念だが。 」
＝COBOL現場の常識を、OO屋は理解していない。
　 COBOLの常識を取り入れた俺様こそ日本一のコンサルでーす。
0477仕様書無しさん2007/03/22(木) 22:12:58
>>475
OOは関係ないぐらいひどいぞ。
言語を理解していないだけだろ。
0478仕様書無しさん2007/03/22(木) 22:14:18
>>475

で、ココ壱番。
おまいは何をしたいの？
妄想上の仮想的に向かって必死に非難を浴びせたいわけ？
0479ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:14:26
煽り坊しかのこらねーのかよ
0480仕様書無しさん2007/03/22(木) 22:14:51
>475
OO以前の問題だろ
真性のアホか？
0481ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:15:21
吼えてないで手本をＵＰしる
0482仕様書無しさん2007/03/22(木) 22:15:29
「よがり」のイメージ検索結果 約 1,820 件中 1 - 20 件目
http://images.google.com/images?hl=ja&lr=&q=%E3%82%88%E3%81%8C%E3%82%8A
0483仕様書無しさん2007/03/22(木) 22:15:34
>>479
敗北宣言ッスかぁ？
0484ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:15:59
で、逃げて終わると。
毎回同じだね。
0485仕様書無しさん2007/03/22(木) 22:16:19
終了、終了言ってる奴、見に来なきゃいいのに。知恵遅れか？
0486仕様書無しさん2007/03/22(木) 22:16:25
>>479
Eclipseで組んでるんだったら
リファクタリング機能あるから学習しとけ
インデントがたがたなのはみっともない
0487仕様書無しさん2007/03/22(木) 22:17:06
>>481

で、ココ壱番。 おまいは何をしたいの？
お前が糞ソースをUPしたからといって、
俺達がそれに付き合う義務はない。
上に思いつきで書いたクラス分割を参考に、
OO化したソースを書けばいいんじゃねぇの？
0488仕様書無しさん2007/03/22(木) 22:17:28
>>481
相手にしてやろうと思えるぐらいのまともな作品用意してくれ
ぶっちゃけ話にならん
0489仕様書無しさん2007/03/22(木) 22:17:42
>>486
タブサイズ＝２で見れ(わらい
0490仕様書無しさん2007/03/22(木) 22:18:30
>>488
威勢がいいなぁ。
おじさん、威勢がいい子は好きだぞ。
次はおまいがUPしる
0491仕様書無しさん2007/03/22(木) 22:18:38
つーかコテハン自体がキモいのはどうにかならんのか
0492仕様書無しさん2007/03/22(木) 22:20:14
もしかしてココ電球って、
５年前にパクったソースうｐしただけじゃねぇの？

これは、ソース内容説明できるかどうか
テストする必要があるなｗ
0493仕様書無しさん2007/03/22(木) 22:20:44
お前らコードにはコードで対抗しろよ。説得力ないぞ。
0494仕様書無しさん2007/03/22(木) 22:23:58
はい、ココ電球にテスト質問。

問１： 思考ルーチンのアルゴリズムを説明せよ。
問２： 思考ルーチンの評価ポイントの根拠を説明せよ。

まずはこれからだな。
これを簡単に説明できないようなら、パクリ決定
0495ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:24:31
５年前、「オブジェクト指向逝ってよし」というスレをたてた。
そこでハンドルを「逝って良しの１」とした。

0496仕様書無しさん2007/03/22(木) 22:25:28
>>495
　>>494の解答をどうぞ
0497仕様書無しさん2007/03/22(木) 22:26:10
こんな保守性の無いソースは久しぶりにみたな
できる奴は遊びソースでも必要にあわせて定数はちゃんと定義するし

なんだこりゃ？定数と変数の違いぐらい勉強しとけよ・・・
↓ソース引用
/**ゲームボードのウィンドウ上の水平表示位置*/
public int DESIGN_BOARD_X = 0; //盤

/**ゲームボードのウィンドウ上の垂直表示位置*/
public int DESIGN_BOARD_Y = 24;

/**ゲームボードの幅*/
public int DESIGN_BOARD_W = 400;
0498仕様書無しさん2007/03/22(木) 22:26:33
ﾁｸ ﾀｸ ﾁｸ ﾀｸ ﾁｸ ﾀｸ ・・・
0499仕様書無しさん2007/03/22(木) 22:27:19
>>497
　キミが>>494に解答してもいいんだぞｗ
0500ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:27:58
すべての配置可能ポイントにおいた場合の評価を評価関数をもっておこない、
数手先まで見るときは相手側もそれに対して最大の評価を得られる手を打ってくるとみなして
再帰評価しているのだ。

評価ポイントは裏返せる数＋隅っこのボーナス。
辺および四隅は評価が高い。
0501仕様書無しさん2007/03/22(木) 22:28:57
>>499
まずは言語の勉強からだろ
finalも知らん奴にアルゴリズムもへったくれもねーし
0502仕様書無しさん2007/03/22(木) 22:29:02
はい、ココ電球にテスト質問。

問３： 評価関数のアルゴリズムを説明せよ。

次はこれだな。
これを説明できないようなら、ソース作成者と認められない
0503ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:29:37
定数と変数をあえて分ける論理的必要性を見出せない。
0504ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:30:25
さっき書いたじゃん
0505仕様書無しさん2007/03/22(木) 22:30:35
>>503
偽者の相手をしても時間の無駄だよ。
さっさと問3に答えたほうが、観衆の受けがいいよｗ
0506仕様書無しさん2007/03/22(木) 22:31:17
おまえら、電球はCOBOLERで、一生懸命Javaを勉強したんだ
そんな年寄りをあまりいじめるなよ。
そりゃ、お舞らに比べればはるかに実力が低いの電球だって骨の髄まで解ってよ
0507仕様書無しさん2007/03/22(木) 22:31:39
いいぞ、電球。がんばれ
0508仕様書無しさん2007/03/22(木) 22:32:34
ヒント： 712行目
　　　　score += 200;
0509仕様書無しさん2007/03/22(木) 22:33:51
>>503
あのな、まじめに答えてやるけどさ、
マジでプログラマーとしてやっていくつもりなら、
ちゃんと勉強した方がいいぞ
必要性を見出せないんじゃなくて、わかんねーんだろ
虚勢を張っても分かってる奴が見れば、冷笑もんのソースなんだよ

うまいプログラマーってのは、下手に作ろうと思っても作れないの
お前のソースは下手な奴が作ってるから、下手なソースなんだよ
0510仕様書無しさん2007/03/22(木) 22:34:07
電球はあれを3日でつくったんだゾ。しかも会社から帰ってから。
少しぐらいソースが汚くたって、俺は尊敬するな。お前らにでき
んのかよ。
0511ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:35:56
その２００はコンピューター側が　相手が置けないように追い詰める評価値なわけだ。
elseじゃないほうはとられる
0512仕様書無しさん2007/03/22(木) 22:36:33
むしろ、字面にばかり突っ込んで、
内容に一切突っ込めない >>509が
偽者のヨカーン。

あと、問1, 問2はソース読みゃ誰でも判るけど、
問3 は作成者じゃないと説明しにくい。
説明を出ししぶるココ電球はパクリ魔のヨカーン。
0513仕様書無しさん2007/03/22(木) 22:36:36
ちゃんとアルゴリズムを考えられるところは偉いと思う
でもfinal知らない（使わない？）のは不勉強過ぎるんでわ
0514仕様書無しさん2007/03/22(木) 22:36:42
３日もかけんなよ・・・
0515仕様書無しさん2007/03/22(木) 22:37:24
結論： ココ電球＝プログラムできる人
　　　　final厨房＝しったか
0516仕様書無しさん2007/03/22(木) 22:37:45
だから、コードにはコードで対抗しないと、全然説得力無いって。
虚勢張ってる厨房にしか見えない。
0517仕様書無しさん2007/03/22(木) 22:38:14
本物と偽者の判別ができたところで、
ココ電球よ、おまいは何を望んでいるんだい。
0518仕様書無しさん2007/03/22(木) 22:40:19
>>final厨

ヒント：ウィンドウサイズ変更への対応
0519ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:40:37
真実
0520仕様書無しさん2007/03/22(木) 22:42:10
>>519
何の真実？
あとちっぽけな存在に過ぎない「人間」という種族は、
なかなか真実など語れるものではないよ。
0521仕様書無しさん2007/03/22(木) 22:43:31
おまえは、電球は"んぽぽん"と思うか？
0522ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/22(木) 22:43:49
ほっほっほっほ
0523仕様書無しさん2007/03/22(木) 22:45:37
どこかにきっと「真実がある」
そう信じて５年間も彷徨い続けたココ電球。
しかし「真実などどこにもない」という老師の言葉に
ただただ唖然とするばかりであった。

0524仕様書無しさん2007/03/22(木) 22:47:02
電球はこれよんどけ
「なぜ、あなたはJavaでオブジェクト指向開発ができないのか」
0525仕様書無しさん2007/03/22(木) 22:48:18
５年もプログラマーやってあのソースなのかよ・・・
どの現場からもお荷物扱いされてるんだろうな
ちょっと同情するわ
0526仕様書無しさん2007/03/22(木) 22:48:31
要するに、オセロはこのスレとは全然関係ない話だったという事で
>>373-523は削除。

>>1は、議論の土俵を用意されても
一向に議論展開できない池沼だったと言う事で
このスレ

　　　　　　　　　　　　　　　　　　　終了



＃part1, part2はまともだったんだけどね
0527仕様書無しさん2007/03/22(木) 22:51:52
テンプレにつっこんでどうするｗｗｗ
0528仕様書無しさん2007/03/22(木) 22:52:56
池沼にOOは必要なし
0529仕様書無しさん2007/03/22(木) 22:53:00
結局パクっただけのソースで勝利宣言ってオチか
糞コテらしい
0530仕様書無しさん2007/03/22(木) 22:53:32
>>1は、議論の土俵を用意されても
一向に議論展開できない池沼
0531仕様書無しさん2007/03/22(木) 22:54:42
荒らしはスルーで。
0532仕様書無しさん2007/03/22(木) 22:55:17
オセロの部分、荒しとして削除依頼出しときました。
0533仕様書無しさん2007/03/22(木) 22:57:15
ループが続いてるな・・・・・
ユースケースってどうよ？
0534仕様書無しさん2007/03/22(木) 22:58:14
498 名前： 仕様書無しさん [sage] 投稿日： 2007/03/04(日) 10:15:48
ユースケース分析って、機能中心のシステム分析に対するアンチテーゼだろ。
0535仕様書無しさん2007/03/22(木) 23:00:00
いや、むしろユースケース・シナリオは
システムが提供すべき機能を洗い出す分析手法だろｗ
0536仕様書無しさん2007/03/22(木) 23:00:14
アンチテーゼってのをいちいちググるのがめんどい
0537仕様書無しさん2007/03/22(木) 23:00:30
以下無限ループ
0538仕様書無しさん2007/03/22(木) 23:02:12
>>1は、議論の土俵を用意されても
一向に議論展開できない池沼
0539仕様書無しさん2007/03/22(木) 23:03:04
現場がオブジェクト指向じゃない奴ってどのぐらいいるの？
0540仕様書無しさん2007/03/22(木) 23:03:23
以下無限ループ
0541仕様書無しさん2007/03/22(木) 23:03:55
>>1は、議論の土俵を用意されても
一向に議論展開できない池沼
0542仕様書無しさん2007/03/22(木) 23:07:48
春だな～
0543仕様書無しさん2007/03/22(木) 23:10:21
負け犬乙
0544仕様書無しさん2007/03/22(木) 23:13:02
オブジェクト指向ってなんで敬遠されるんだろうな
やっぱり用語の乱立も理由の１つなんだろうな
0545仕様書無しさん2007/03/22(木) 23:13:43
以下無限ループ
0546仕様書無しさん2007/03/22(木) 23:15:46
荒らしはスルーで
0547仕様書無しさん2007/03/22(木) 23:16:25
ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ
0548仕様書無しさん2007/03/22(木) 23:20:55
OOは一朝一夕で身につくものではない。イパーイ本読んで、
イパーイ実践して、イパーイ失敗して、そうやって感覚的に
身に着けていくものだ。イパーイ、ｲﾊﾟ－ｲ、ｲﾊﾟ-ｨ...
0549仕様書無しさん2007/03/22(木) 23:23:18
覚えることが多いんだよな～
なんつーか、何が正解なのかがはっきり言えないところがな～
0550仕様書無しさん2007/03/22(木) 23:26:54
議論の一つもまともにできずに常駐してるのが
荒らし本人。

推奨されるまでもなくデフォで無視。
0551仕様書無しさん2007/03/22(木) 23:30:07
はいはい、ﾊﾞﾛｽﾊﾞﾛｽ
0552仕様書無しさん2007/03/22(木) 23:35:50
>>548
ゆとり教育世代乙。

リアルな世界には正解を示してくれる先生などという
絶対的存在など居なくて、
ただ「(ある面から見て)より良い(と思われる)方法」があるだけなのだよｗ
0553仕様書無しさん2007/03/22(木) 23:40:58
本読んでるとさ、詳しくは別のこの本を参照してくれみたいなこと書いて
あるじゃん。んで、わざわさその本取り寄せて、読むとその本にも、詳し
くはこの本読めとか書いてあるわけよ。もうきりが無くてさ、何処まで勉
強したらええねんと。モチベーションもガクーンと下がるわけさ。そして
気づいたら、アレ？ 俺、なんで、開発設計の本じゃなくて、建築デザイン
の本とか読んでんだっけとかなるわけよ。まったくこいつらつるんでると
しか思えねぇ。市ね。
0554仕様書無しさん2007/03/22(木) 23:44:46
>>553
幸せになる壷買わないように気を付けてね^^
0555仕様書無しさん2007/03/22(木) 23:49:06
>>553
もっと具体的に説明しる
具体性の無い愚痴は、トイレの便器にでも叫んで、
水に流しちゃえ
0556仕様書無しさん2007/03/22(木) 23:51:09
単に自学自習スキルのない厨房だと思った
0557仕様書無しさん2007/03/22(木) 23:52:45
>>548
われらが69式オサンはちがうぞ

ｵﾊﾟｰｲ、ｵﾊﾟｰｲ、ｵﾊﾟｰｲが人生の全てさ
0558仕様書無しさん2007/03/22(木) 23:52:58
厨房にＯＯは必要なし
0559仕様書無しさん2007/03/22(木) 23:53:49
例のちゃぱつか
0560仕様書無しさん2007/03/23(金) 00:25:03
実業務ではどれをインターフェースにすればいいか、
なんてことで悩んだりすることが当然出てくる。
こういうことを繰り返していかないとOOは身につかない

偽装請負で作業場所がコロコロ変わるようなこの業界で、
オブジェクト指向の要員なんか探す方が難しい
0561仕様書無しさん2007/03/23(金) 00:30:19
ソースの良し悪しはともかく、ただの批判しかしない奴よりは断然マシだな。
がんばれ。

俺もStrutsSpringHibernateでオセロ作ってみるわ。
誰かOOまとめWiki作らね？あればそこにうぷするわ。
0562仕様書無しさん2007/03/23(金) 00:40:24
あのな、犬小屋を作るのと高層ビルを作るのはわけがちがうんだ。
高層建築に適した設計論で犬小屋を作るのは無駄でしかない。
犬小屋には強度計算も必要なければ、資材調達計画も
必要ない。いいか？このスレのオセロの例はそれだ。犬小屋を作って見せて
無駄だと言っている。お前ら、リアルで厨房だろう？春休みで暇なのはわかるが、
留年しないように頑張れよ。
0563仕様書無しさん2007/03/23(金) 00:43:13
それはいいアイデアだな。
そういう荒唐無稽なプログラムは
学生時代じゃないと決して組むチャンスは無いから
まあ頑張れ。

完成したら教えてくれ。じゃ
0564仕様書無しさん2007/03/23(金) 00:49:16
じゃあ俺は普通にJavaでオセロ作ってみるか
その前にオセロのマスっていくつだったっけ？
0565仕様書無しさん2007/03/23(金) 00:51:51
>>564　11個
0566仕様書無しさん2007/03/23(金) 00:53:10
サンクス
おまぃ　いい奴だな
0567仕様書無しさん2007/03/23(金) 01:03:08
つまりOOは高層建築のための設計手法であって犬小屋を作るためのものではない。
0568仕様書無しさん2007/03/23(金) 01:05:21
犬小屋には犬小屋のデザインパターンがあるようにも思う。
0569仕様書無しさん2007/03/23(金) 01:11:14
犬小屋と高層マンションも入居者が出入りするインターフェースは同じ
0570仕様書無しさん2007/03/23(金) 01:12:54
犬小屋はPerlでどうぞ。
0571仕様書無しさん2007/03/23(金) 01:13:25
そのOO高層建築の進捗管理(建築での積算)がステップ数であった場合、
Pjを辞めた渡しは正解ですか?
0572仕様書無しさん2007/03/23(金) 01:14:38
日本語でおｋ
0573仕様書無しさん2007/03/23(金) 01:15:24
輪切りの私～♪
0574仕様書無しさん2007/03/23(金) 01:23:37
犬をバカにすんな
0575仕様書無しさん2007/03/23(金) 01:26:45
ちがうだろ、オセロは8x8だっチュウの
0576仕様書無しさん2007/03/23(金) 01:29:40
お前のネタは実に単調だな。

0577仕様書無しさん2007/03/23(金) 01:42:39
お前はやり過ぎたんだ。
お前は暇つぶしのために７年間に渡って
２ちゃんのスレを荒し続けた。
その結果、もう誰も２ちゃんになど来なくなった。
お前の残りの人生は、誰も居ない２ちゃんで
ただひたすら独り言を書き続けることになる
・・・命ある限り、永遠に
0578仕様書無しさん2007/03/23(金) 04:01:49
結局ＶＢが一番ってことだろ。
その次エクセルマクロ。
あとは必要ないよな。
改良もされてくるだろうし。
0579仕様書無しさん2007/03/23(金) 04:04:08
違うの、C#が一番なの
0580仕様書無しさん2007/03/23(金) 08:37:22
javaとc#の両方を使ってると
混乱してくる
0581仕様書無しさん2007/03/23(金) 10:25:32
そんなときはJ#でつよ
0582おじゃばさま2007/03/23(金) 10:27:34
石は白と黒しかないのでboolで十分。石を置いたり裏返したりはゲーム盤クラスに実装すべき。

#define BORD_SIZE_X (10)
#define BORD_SIZE_Y (10)
class Board{
public:
　　// コンストラクタ（初期配置を行う））
　　Board(){}
　　~Board(){}
　　// 石を置く
　　bool put(int x, int y, bool c){
　　　　bool ret = false;
　　　　if(canPut(x, y, c)){
　　　　　　put(x, y, c);
　　　　　　ret = true;
　　　　}
　　　　return ret;
　　}
　　// 終了判定
　　bool isEnd(){}
　　// 結果出力
　　bool total(){}
private:
　　// 石が置けるか判定する
　　bool canPut(int x, int y, bool c){}
　　// 石を置き、囲まれた範囲を裏返す
　　void put(int x, int y, bool c){}
　　// ボード情報
　　bool tbl[10][10];
};
0583おじゃばさま2007/03/23(金) 10:29:36
class Game{
public:
　　void play(){
　　　　for(int cnt=0; bd.isEnd(); cnt++){
　　　　　　int x, y;cin >> x;cin >> y;
　　　　　　bd.put(x, y, (cnt%2)==0));
　　　　}
　　　　bd.total();
　　}
private:
　　Board bd;
};

int main(int argc, char argc[]){
　　int ret = 0;
Game gm;
gm.play();
　　return ret;
}

0584おじゃばさま2007/03/23(金) 10:30:51
今回はJavaじゃなくて、C++で書いてみた。
0585仕様書無しさん2007/03/23(金) 10:33:53
どこがオブジェクト指向なんだ？
クラスを使った構造化なだけ
ここのスレに書くならば
・無駄な処理と分かっても無理やりOO的に書く
・時間が1000倍かかっても無理やりOO的に書く
・見通しがかえって悪くなったとしても無理やりOO的に書く
これがこのスレの掟
0586仕様書無しさん2007/03/23(金) 10:37:48
>>582
石の操作クラスは別に儲けるべきだと思うが
0587仕様書無しさん2007/03/23(金) 11:29:50
設計の話もダメ、実装させてみてもダメか。
何の役にたつんだこの糞ｺﾃ。
0588仕様書無しさん2007/03/23(金) 11:36:01
>>582-583
これだと結局、石を交互に置くというルールしか表現されてないわけだが。
オセロっつったらコンピュータの思考ロジックが一番の肝だろうが、ヴぉけ
0589仕様書無しさん2007/03/23(金) 11:43:33
これが糞コテクオリティ
次々と自爆荒らししていくんじゃねぇっつーの
0590仕様書無しさん2007/03/23(金) 11:45:01
Strategyパターンの検討材料としてはよい題材かもな。
0591おじゃばさま2007/03/23(金) 12:04:28
>588
ゲーム盤には石を置く機能と、終了判定機能、結果表示機能を持たせるべきだ。
思考ロジックはゲーム盤に入れる機能ではなく、プレイヤークラスを作りそっちに入れるべきだ。
って事だよ。分かった？
0592仕様書無しさん2007/03/23(金) 12:12:56
御託はいいから実装しれ
0593仕様書無しさん2007/03/23(金) 12:23:34
おじゃばはこのスレだとスキルが一番高くなれそうだな。
0594仕様書無しさん2007/03/23(金) 12:36:20
>>591
>そっちに入れるべきだ。
その「べき」の理由を説明したりすると
このｽﾚが有意義なものになるかも知れませんね。
0595おじゃばさま2007/03/23(金) 12:43:38
>594
なぜならボードクラスはボードゲームを抽象化したもので、石を置き、終了判定をして、結果を表示するのは、
他のボードゲーム（将棋、囲碁など）にも共通するからだ。これならば、ゲームの内容が変わっても
構造を変更する必要がない。

そしてプレイヤークラスに思考ロジックを実装するのは、プレイヤーを抽象化する事になる。
例えばプレイヤーにはオセロを知っていてやる人ばかりでなく、もしかしたら占いで打ったり、
勘で打ったりする人もいるかもしれない。それをボードには実装するのは明らかに変だ。
0596仕様書無しさん2007/03/23(金) 12:46:00
>>591 誰もゲーム盤に思考ロジック入れろとは書いてねぇだろ、ヴぉけ
思考ロジックを含めてことコンピュータオセロゲームだっつってんの。
0597仕様書無しさん2007/03/23(金) 12:46:33
> 石は白と黒しかないのでboolで十分。

おいおい、お前のオセロ盤は
初期配置から盤面が石で埋まっているのか、と。

0598仕様書無しさん2007/03/23(金) 12:46:44
ゲーム盤クラスとゲームクラスと終了判定インターフェイスと表示クラスまで分離
プレイヤークラスを継承して人間・COM
COMをさらに継承し思考パターン毎にクラスを
0599仕様書無しさん2007/03/23(金) 12:49:13
御託はいいからその肝心な部分を実装しろ。
06005982007/03/23(金) 12:49:52
で、ゲームクラスはゲーム盤クラスのインスタンスやログを持ち
再ゲームはゲームクラスのインスタンスを再生成して行う
06014662007/03/23(金) 12:51:47
View部
　　　　　　(略)
Model部
　Game　　１回戦分のゲーム
　Score　　対戦記録 (コマンドパターンで譜の再現等)
　Step　　　一手 (Commandパターン)
　Board　　盤面の管理
　Player　　プレイヤ (人間およびコンピュータ)
　Strategy コンピュータ側思考 (Strategyパターン)
あと、審判(指し手交代、パス判定、パス回数、終了判定、得点の管理)とか、
ルール(StrategyパターンでOthello/Reversi/源平碁等のルール切替)
があっても良いかもな。
0602仕様書無しさん2007/03/23(金) 12:51:54
>>597 が改心の一撃を放った。
0603仕様書無しさん2007/03/23(金) 12:54:03
オセロの審判は Judge でいいのか？
0604仕様書無しさん2007/03/23(金) 12:56:40
>601
プレイヤーとCOMプレイヤーは親クラスかインターフェース作って
内部からは同じインターフェースで呼べるようにしたほうが
COMvsCOMやプレイヤーvsプレイヤーにするとき楽では？
06056042007/03/23(金) 12:57:18
ごめん俺なにか読み違ってたｗスマソ
0606仕様書無しさん2007/03/23(金) 13:04:49
ルールを切り替え可能にするのは良いが、
ルールに従ってJudge, Player, Strategy, (あと場合によっては Board)
の挙動を変えるのは結構めんどい。
単に別途用意したクラスと切り替えるだけなら楽だが。
0607仕様書無しさん2007/03/23(金) 13:05:28
PS3でFolding＠homeが利用可能になりました！
タンパク質解析プロジェクトFolding＠homeで病気で苦しむ人達を救えるかも。

PS3でFolding＠homeしようぜ(Team 2ch)
http://ex22.2ch.net/test/read.cgi/ghard/1174030817/

チーム番号：162
チーム名：Team 2ch
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=162

☆PS3での参加方法
PS3からFolding@homeを起動し、チーム番号162に入力すればOK。
ユーザ名は何でも良いが、http://folding.stanford.edu/japanese/download.html
にて、名前が既に使われているかどうか確認する事を推奨。
参加の確認としては、「オプション（△）」→「関連サイト」→「チーム処理統計量」と開き、
「Team 2ch」（上記URLのページ）が表示されればちゃんと参加できている。
☆Folding@homeについて
http://folding.stanford.edu/japanese/
0608仕様書無しさん2007/03/23(金) 13:08:17
ルールは大規模な変更じゃなくて、ローカルルールの変更ぐらいに留めた方が良くない？
別のボードゲームだったら、それこそPlayerもJudgeもBoardやStrategyも
そのボードゲーム用に新調した方が良いんでないかと。
0609おじゃばさま2007/03/23(金) 13:09:32
>596
この課題の場合、初心者が陥りやすいのは思考ロジックをボード入れようとする事だ。
そのために敢えて思考ロジックを除外してある。って事だよ、分かった？

>597
その通りでした。intにします。
いやむしろ、enumにしよう。
enum STONE{
　　WHITE, BLACK, NONE
};

>599
肝心な設計部分はあれで完了だ。
細かい実装はここにいる人間なら、出来て当然なレベルだろう？
そんなの俺にやらせるのか？
0610604=6082007/03/23(金) 13:10:13
ってそのローカルルール変更が問題なのか。スマソ
俺全然ダメだな。
0611仕様書無しさん2007/03/23(金) 13:29:47
>>609 あんなものをオセロのテンプレートにしろと言うのか？
せいぜい使えても、いくらか改造して、しりとりゲームぐらいだろ。
0612おじゃばさま2007/03/23(金) 13:34:45
>611
オブジェクト指向モジュール分割の参考にしろって事だよ。
オセロ作ってもしょうがないだろう。
0613仕様書無しさん2007/03/23(金) 13:43:30
まあ、春厨には閉鎖空間であるオセロ程度が丁度いいね。
0614仕様書無しさん2007/03/23(金) 14:03:40
>>612
>参考にしろって事だよ。
○　参考になった
○　参考にならなかった
●　使えねー奴だとわかった

>閉鎖空間
俺用語なのか単なるｦﾀなのか知らんが
どっちみち思考ルーチンに関しては触れないんだろうから
有限確定の二人零和完全情報ゲームだろうと何だろうと関係ないっしょ。
0615仕様書無しさん2007/03/23(金) 14:08:43
まあローカルルールのぶれは、・用語、見た目
・先行後攻、初期配置
・ボード形状
　(リバーシは8x8以外あり
　　ニップは円形で線の交点に駒を置く)
・終了判定
位。

ルール・クラスの記述方法を工夫して
・どのローカルルールも記述可能な汎用の枠組み(スキーマ)を作っておいて、
・ローカルルールはその枠組みの中で記述し、
・あと、ルールの影響を受けるクラス(Judge,Player,Board,Strategy)
　への変更点をStrategyパターンかなんかで提供
とかすれば、一見うまくいきそうだけど・・・

実際は、コンピュータの思考部分(ComStrategyクラス)も入れ替え対象だから、
上の三番目・のように、Ruleクラスと密結合した設計はあまりおすすめできない。
0616仕様書無しさん2007/03/23(金) 14:23:41
なあんか段ポール箱ひっくり返した机の上が世界の全てな
オブジェクト指向を語っているみたいだな。。。
0617仕様書無しさん2007/03/23(金) 14:27:29
自己分析乙
0618仕様書無しさん2007/03/23(金) 14:53:02
反論する時に代替案も出せないようなバカはスルーで。
0619仕様書無しさん2007/03/23(金) 15:17:46
つか、ここでコードレビューしてどうするんのよｗ
>>1のやりたい事と全くちがうだろう。反論とかそういう問題以前の話。
そういう大きいくくりもコントロールできない>>617 >>618
は設計を語る以前の状態。
0620仕様書無しさん2007/03/23(金) 15:25:41
散々書いているが、ここは設計限定してないだろ？
だから最初にそれを言ったのに、コードしか語れない馬鹿PGがそれを否定したわけで。
0621仕様書無しさん2007/03/23(金) 15:27:37
いみふめ



またバカのグダグタ展開か
0622仕様書無しさん2007/03/23(金) 15:38:04
>>615
実際はルールに依存するような思考ルーチンは多いだろうから
関係はどうしても密になってしまうだろうなあ
0623仕様書無しさん2007/03/23(金) 16:26:11
思考ルーチンの最適化や学習を考慮すると、
ルール毎に思考ルーチンを作った方がいい。

つまり、思考ルーチンはあらかじめルールを知りつくしている前提で次の一手を出し、
審判はその手がルールに従っている事のみチェックする。

すると、ルールクラスと思考クラスは密に結合する必要はなくなる。
(思考クラスが内部的に別のルールクラスを持っていて、
思考クラスの出力が偶然、外側のルールにも従っている、というイメージ)
0624仕様書無しさん2007/03/23(金) 16:28:02
反応するのも馬鹿らしいが、
開発プロセスの中で、要求は策定ではなく想定される可能性があり、
アーキテクチャはうやむやにされる可能性があり、テストは短縮さ
れたり省略される可能性がある。だがコードは必ず書かれる。
コードの改善ほど実り多い領域はないとエロい人もいってるぞ。
062512007/03/23(金) 16:31:38
スレッドを立てたものです。

このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
なので設計だけ、実装だけといった縛りは特にありません。
設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。

いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。

なお、私的な意見ですが、厳密に自分の意図を伝えるために実装サンプルと合わせて説明することは良いプラクティスだと思います。
書き込みを読む方も、自分の考え方と違う考え方だからといって否定するのではなく、
改善策や自分の考え方を書いてみましょう。
0626仕様書無しさん2007/03/23(金) 16:41:15
ちうことで、>>619は的外れの煽り止めるか別スレ立ててやれ。
0627仕様書無しさん2007/03/23(金) 17:06:50
>>623は、分析クラスで抽出された関連※１は
　※１ 思考がルールに直接依存
実装を考慮した設計クラスでは別の形※２になり得る、
という話。

※２ 思考は内部ルールにのみ従う。
　思考から得られた「手」は
　プレーヤが盤面上に打って初めて、
　審判チェックという形で外部ルールと関連する。
0628仕様書無しさん2007/03/23(金) 17:18:54
おれ、C++あんまよく知らないんだけど
石を置けるかどうかの判定が全く機能してないんでは。
置けないとこに入力しても白黒番かわっちゃうんじゃないの？
0629仕様書無しさん2007/03/23(金) 17:23:22
こちらへどうぞ。
>ttp://pc11.2ch.net/test/read.cgi/prog/1152383007/
0630仕様書無しさん2007/03/23(金) 17:36:31
>>628
　>>582は単なる天婦羅またはｳﾞｧﾁｬｰﾙだろ。
　要するに天婦羅の中身は他の奴が書けっつう。
0631仕様書無しさん2007/03/23(金) 17:37:16
あと、>>601=>>466-468ではワザとネグっといたんだけど、
オセロの石(Piece)は分析クラスにも設計クラスにも入れといた方が良さそうだな。

分析上の理由：
・現実世界に石は存在する。
・ある種のローカルルールでは、プレーヤの持ち石の数が制限されている。
　(リバーシ・ルール。いずれかの持ち石が無くなったら終了)

設計上の理由：
・実装Othello2でリバース・アニメーションをやっている関係上、
　石クラスがあり、そのViewクラスでアニメーションを表示する、
　というクラス分割が自然に見える。

実装上の注意点：
・思考ルーチン内では通常、
　盤面をbitmap配列として保持し、石はbit列として表現される。
　ここに石クラスを持ち込むのは、ナンセンスである。
・もし、bitmap配列とボードクラス、石クラスを関連付ける必要があるのであれば、
　Flyweightパターンの適用を検討するとよい。
0632仕様書無しさん2007/03/23(金) 18:04:30
オセロって実際作ろうとおもったら、UI周りもめんどいんだよな。
特にアニメーション。そういう意味では電球は馬鹿なりによく作ってる。
電球の場合は、駒反転のアニメーションの状態もintの配列で兼用させて
たみたいだけど、bit列だと表現できないな。つか、ON/OFFだとおじゃば
と同じで駒無しの状態が表現できなくね？　ま、OOとは直接関係ないが。
0633仕様書無しさん2007/03/23(金) 18:06:56
実際はクラス設計なんてしたこと無いんだろ、お舞ら！！！
ま、クラス設計はPG(コーダー）じゃなくSEの仕事だからな
クラス設計を夢見るCoder諸君、非常加油
0634仕様書無しさん2007/03/23(金) 18:11:07
擦れ欲嫁
0635仕様書無しさん2007/03/23(金) 18:12:35
クラス設計ときれいなコードを書くのとどっちがスキルいるかと
言われれば、当然後者だわな。
06366152007/03/23(金) 18:14:00
// ルール記述用仮想クラス
class Rule {
public:
　// 用語のカスタマイズ
　virtual char *getTerm(char *termID);
　// 見た目、ボード形状等のカスタマイズ
　virtual int getColor(int colorID);　　　　 // 配色
　virtual bool isCellSurroundedByLine(); // 線の引き方
　　　　// (セル外周 or セル並び四方向)
　virtual Size *getBoardSize();　　　　　　// ボードサイズ
　virtual BoardState getBoardShape();　// ボード形状

　// 初期配置
　virtual BoardState getInitialPlacement();
　// 先攻後攻
　virtual Side getFirst();
　　　　/* TODO: 先攻後攻決め処理(ジャンケン等)の提供 */

　// 判定ルール
　virtual bool canPut(BoardState b, Step s);　// 石の置き場所チェック
　virtual bool isPass(BoardState b, Side s);　　// パス判定
　virtual bool isEnd(BoardState b, Score *s, Player ps[]); // 終了判定
　　　　// (置き場所なし、手詰まり、プレーヤの持ち石なし、等)
　/* TODO: その他ルールがあれば追加。(時間制限等) */

　/* TODO: ゲームに参加するオブジェクトが、ルールに準拠している事を監査/保証する仕組み */
};
06376152007/03/23(金) 18:14:32
// プレーヤ識別子 (二人限定版)
typedef enum { WHITE, BLACK } Side;

// ゲーム盤上のセル状態 (ボード形状や初期配置の記述に使用)
typedef enum { _WHITE=WHITE, _BLACK=BLACK, NONE, OUTSIDE } CellState;

// ゲーム盤の状態 (Ruleクラス記述用簡易版)
typedef struct {
　int w, h;　　　　// 幅、高
} Size;
typedef struct {
　Size size;　　　// ゲーム盤の幅、高 （＝二次元配列の幅、高)
　CellState **b;// セル状態の二次元配列
} BoardState;

// 手クラス
class Step {　/* 略 */ };
// 譜クラス
class Score {/* 略 */ };
// プレーヤクラス
class Player {/* 略 */ };

0638仕様書無しさん2007/03/23(金) 18:19:55
> bit列だと表現できないな

{黒, 白, 無し} の３状態＝約1.5bitを表現すれば充分。
2bitあれば表現できる。
0639仕様書無しさん2007/03/23(金) 18:24:09
>>636 爺、全体のクラス設計して、それを晒せよ
0640仕様書無しさん2007/03/23(金) 18:25:50
>>638
　　　　A1セルに石があるか無いか
　　　　 ↓
　　　■■□□■■□□■■□□■■□□
　　　↑
A1セルの石が白か黒か

>>639
自分でヤレ
0641仕様書無しさん2007/03/23(金) 18:30:09
>>633
コードは最も詳細なクラス図であり相互作用図だぞ。

>>638
bit列を使うメリットって何？ 早いの？ こんぐらい
のサイズを気にするご時勢じゃないよなぁ。
0642仕様書無しさん2007/03/23(金) 18:39:25
>>641
おまいら最強のリバーシプログラムしてみろよ
http://pc10.2ch.net/test/read.cgi/tech/1166749119/
おまいら最強のリバーシプログラムしてみろよ part2
http://pc11.2ch.net/test/read.cgi/tech/1169413998/
おまいら最強のリバーシプログラムしてみろよ part3
http://pc11.2ch.net/test/read.cgi/tech/1173784074/
0643仕様書無しさん2007/03/23(金) 18:43:43
要するに、思考ルーチン内部でたかだか数倍程度のせこい高速化をしたり、
膨大な対戦譜(数百万試合)の学習結果を要約して持っておく時に使われる手法。
高度な思考ルーチンを要求しなければ、関係ない話だ。
0644仕様書無しさん2007/03/23(金) 18:44:45
敢えてArrayList<Boolean>で表現してみようぜ
0645仕様書無しさん2007/03/23(金) 18:51:23
{黒, 白, 無し} の３状態＝約1.5bitないと表現できない。
1bitでは表現できない。
0646仕様書無しさん2007/03/23(金) 18:52:15
またグダグダ展開か
0647ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 19:26:19
>>632
なに偉そうにゴタク並べてるんだよ
0648ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 19:29:30
まあ、Ｊａｖａのインストールだけでこのスレの半数は脱落だろ
それからパス通せなくてさらに半数脱落だな。
Ｊａｖａは不便だな。
0649ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 19:30:42
囲碁や将棋と違ってオセロは簡単に最強クラスのプログラムが組めるよ
そんな難しく考える事は無い。
0650仕様書無しさん2007/03/23(金) 19:46:18
パタンが単純だからな。強くしようと思ったら総当りで最終手まで
シミュレーションさせればいい。あとはスピードとの兼ね合いか。
0651仕様書無しさん2007/03/23(金) 19:55:22
>>645
これならどうだッ！？

Boolean(true)
Boolean(false)
null
0652仕様書無しさん2007/03/23(金) 19:59:50
32bit CPUのアドレス長は32 bit >> 1bit
0653仕様書無しさん2007/03/23(金) 20:04:21
交互に石を打つ、置けないところはだめ、もっかい入れな、っつ
盤としての最低仕様も満たさないんじゃテンプレにもならん。
いまさらオセロなんか出してきて、C++だってんじゃ
おじゃばさまの名前ってなんなのよｗ
0654仕様書無しさん2007/03/23(金) 20:05:11
オブジェクト指向を無視した電球ソースをこのスレで語る理由がない
ってのは誰がつっこむんだ？
0655仕様書無しさん2007/03/23(金) 20:09:27
>654
理由が何もないからつっこまないのでは。
0656仕様書無しさん2007/03/23(金) 20:42:13
スレタイに、オブジェクト指向を何故理解できないの？、ってあるけど、
オブジェクト指向を理解した、ってのはどうやって判定すんの？
0657ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 20:45:20
コンピューターレベルは０，１，２だけど
５にしてＣＯＭ同士の対戦にしたら５分くらい考え込む。
学習能力付加して高速化できるな。
0658仕様書無しさん2007/03/23(金) 20:47:44
>>656
それは非常に簡単。ジャワやってます==理解している
0659仕様書無しさん2007/03/23(金) 20:48:01
電球、おまぃはスレ違いだ
0660仕様書無しさん2007/03/23(金) 20:48:08
で一体ココ電球は、ここで何をしたいの？
最強リバーシ対決なら、あっちでヤレ

おまいら最強のリバーシプログラムしてみろよ
http://pc10.2ch.net/test/read.cgi/tech/1166749119/
おまいら最強のリバーシプログラムしてみろよ part2
http://pc11.2ch.net/test/read.cgi/tech/1169413998/
おまいら最強のリバーシプログラムしてみろよ part3
http://pc11.2ch.net/test/read.cgi/tech/1173784074/
0661仕様書無しさん2007/03/23(金) 20:48:43
>>658
んなわけないだろｗ
0662仕様書無しさん2007/03/23(金) 20:51:22
>>658
このスレの存在理由問う衝撃発言
0663仕様書無しさん2007/03/23(金) 20:52:05
ぷぷ。底辺の連中って、煽り合いでしか盛り上がらないんだな。
まるでCOBOL現場みたいｗ
06646562007/03/23(金) 20:56:22
いくら本を読んで内容を理解できても、
なぜか「分かった気になってる」ように感じるんだよ。
実務に活かせるスキルになってないことを自覚しててな。
こっから脱却したいんだけど、どうすりゃいいもんやら。
0665仕様書無しさん2007/03/23(金) 20:58:45
実戦あるのみかと
0666仕様書無しさん2007/03/23(金) 21:01:03
理解してるかどうかは実はどうでもいい。
一緒に働く奴と、同じ考えだなと実感できれば
それが役に立つ技術というものだと。
構造化だろうがオブジェクト指向だろうが、
しょせん意思疎通の手段だろ。
0667仕様書無しさん2007/03/23(金) 21:02:09
結局のところ、設計を語りたいなら
>>240　なり >>601を出発点にすりゃえーんじゃねぇの？

>>601を出発点にするなら、
>>601を分析クラス (ドメイン・モデル)として、
その責務は何か、データは何を持つか、
どんな振る舞いをするか、ってなあたりを
シーケンス図かなんか使って詰めてけば
いいじゃないか。

もし、ドメイン・モデル以外の部分も問題にしたいなら、
バウンダリ/コントロール/エンティティ抽出してロバストネス図作って、
エンティティがドメインモデルに対応している事を確認して、
最後に、MVCなりDocumentViewに対応させればいいじゃないか。

ってUMLヲタが言ってたｗ
0668おじゃばさま2007/03/23(金) 21:03:44
601は難しく設計しているようだが、OOで設計するコツが少しある。
まず、そんなに後々の拡張や例外を考慮する必要はない。
これは優秀な構造化プログラマーが陥りやすい罠である。
構造化では最初の設計で見越した拡張性が後々の変更に大きく関わる。
そのためローカルルールやゲーム自体の変更を意識して設計するが、OOでは使用する部分としない部分の
選択の自由度が比較的高いため、それほど意識する必要はない。
オセロ作るならシンプルなオセロだけ考えれば良い。
そうなると、最初は継承やインタフェースは出て来ないだろう。

それと機能分割する考え方が異なる。
構想化プログラマーは無意識のうちに「機能」を抜き出してそれを分類しようとする。
すると601のようにオブジェクトと機能の区別が曖昧になる。
OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

そして重要なのは修正だ。
単純なオブジェクトに対して、ルールや値を追加して、どこに機能を持たせるか考える。
多くの場合は、設計の誤りに気が付くだろう。しかし最適な場所がある。
ここで継承やインタフェースも出て来るだろう。
この修正を繰り返すたびに、モジュールの結合が緩くなり、完成度が増すのがOOだ。
是非ともこの感覚を味わってもらいたい。まあ、普通の人は1年半後かな？
0669仕様書無しさん2007/03/23(金) 21:04:58
そもそも、くそ2chの掲示板で図が書けないのが問題なんだよ。
せっかくの俺様のビューチフルなコラボレーション図を藻前ら
に示せないのが残念だ。なんとかしろよ、糞ゆき。
0670仕様書無しさん2007/03/23(金) 21:05:24
おじゃばはこっちにいたのか。
おっさんスレに帰れよ。
みんな待っているよ。
0671仕様書無しさん2007/03/23(金) 21:05:32
長文は動揺。
0672仕様書無しさん2007/03/23(金) 21:07:14
まってねえよ
0673仕様書無しさん2007/03/23(金) 21:07:19
シンプルでも碁盤と区別がつかないんじゃ困るだろう。
06746672007/03/23(金) 21:08:34
俺だったら、問題を把握したら
その>>667みたいなのはパッと思い浮かんじゃうけどｗ

問題(あるいはそこで認められている問題解決方法)を把握できないまま、
OO分析/設計するっつうのは不安だよなぁ。目隠しして歩けって言われるようなもんでｗ
分析/設計の重要な目標ってのが、
問題の正確な把握、解決策の仮定/検証、そして解決策の実現方法の明確化
にあるとすれば、それを実行するためにうまくOOを使えばいいだけの話じゃないか。
OO使うとうまくいかない～と言うなら、OOはあきらめればいいだけの話。
0675仕様書無しさん2007/03/23(金) 21:08:50
>>668
学校で先生に関数は短くって習わなかったのか？
0676仕様書無しさん2007/03/23(金) 21:09:07
あんな糞ソース晒しといて、よく言うよこのおっさん。
06776562007/03/23(金) 21:10:01
なんで>>601のようなことになるのか、
さっぱり理解できん
0678仕様書無しさん2007/03/23(金) 21:10:15
傷つきました。仕様書無し潜伏します。
0679仕様書無しさん2007/03/23(金) 21:10:29
>>668
たかひろ乙。

そして、YAGNAI原則は重要。
ただオツムと問題を比較した時に、
問題の難易度が低い場合、
俺なら >>601から出発するね。
0680仕様書無しさん2007/03/23(金) 21:11:40
>>677
良い問題提起だ。
限られた時間の中で、解答してあげよう。
質問はないかな？
0681仕様書無しさん2007/03/23(金) 21:14:14
トップダウンもボトムアップも程よく折衷するのがよろし。
0682仕様書無しさん2007/03/23(金) 21:15:22
>>670
javaを叩くだけのオッサンスレよりこっちの方がはるかに良いだろうに。
オッサンスレはjavaを叩きすぎて、いまや焦土なっちまったからな。
>>670、老兵の待ってるオッサンスレに帰れ
0683656=6772007/03/23(金) 21:15:53
>>680
いや、>>601で書いてあることは分かる。
けど、実際自分がやれ、って言われると視点というか着眼点が分からない。
どうやればそういう発想を持てるんだろか。
0684仕様書無しさん2007/03/23(金) 21:16:22
また仕様書無しに潜伏したな。
0685仕様書無しさん2007/03/23(金) 21:17:09
いる奴は同じような気がしないでもない。
06866792007/03/23(金) 21:19:16
> ただオツムと問題を比較した時に、
> 問題の難易度が低い場合、

なんちゃってｗ
誠実に言い直す事にしよう。
オセロゲームという問題領域は、
これまで何度かカジった事がある。
今回は >>154を見て内容を思い出し、
次に >>457を見て、この仮想プロジェクトの現状を知り、
そして >>601の形で次の設計の端緒を示したつもりだ。

もう、一からオブジェクトを抽出するなんて段階ではない。
実装に基づいて、分析モデルを洗練し、設計モデルを洗練する、
というイテレーション・プロセスのど真ん中に現在は位置する。

だから >>601が今回のベースラインなんだ。
0687仕様書無しさん2007/03/23(金) 21:25:01
>>683
OOがへたれな漏れ思うに
やっぱ、OO分析できないと、>>601のようなモデリング出来ないんじゃね
ま、クラス設計の問題だよな
06886802007/03/23(金) 21:29:39
>>683
> いや、>>601で書いてあることは分かる。
> けど、実際自分がやれ、って言われると視点というか着眼点が分からない。
> どうやればそういう発想を持てるんだろか。

基本は、>>681の通りだ。

トップダウンで言うと、
まずドメインモデルの抽出手法ってのがある。
シナリオの品詞に着目して
ドメイン・オブジェクトの候補を洗い出す、ってな手法だ。
この手法では、名詞＝静的データ構造、動詞＝動的振る舞い
ってな解釈でオブジェクトができる。
しかしこの手法には大きな問題点があって、
それは明確に概念化されていない対象、見えない対象、実装方法等は
抽出の落ちや、不適切な抽出が発生しやすい。

0689仕様書無しさん2007/03/23(金) 21:29:42
しかし、OOでオセロゲーム作るとえらいのんびりしたものが
できあがりそうだな。これじゃぁ、機能要求は満たせても、
非機能要求は満たせまい。
0690仕様書無しさん2007/03/23(金) 21:30:42
>>686
たかひろ様に光臨願ったほうがいいじゃない
06916802007/03/23(金) 21:31:09
(>>688の続き)

次にボトムアップで言うと、
「コードやデータの凝集度」といった言葉で表される、
「これとこれ、わけて、あっちでまとめたら、判りやすくねぇ？」
というコード感覚、モジュール感覚、アスペクト感覚がある。
上でじゃばらーが「構造化設計」感覚とかほざいているが、
そんな低レベルなものではなく、コードと日々戦い続けて
研ぎ澄まされた感覚だ。

ボトムアップのモジュール感覚、アスペクト感覚を、
トップダウンの分析モデルと擦り合せたものが、
設計モデルだ。もちろん、詳細化していく中で、
最初の設計モデルの見込みが間違ってたり、
あるいは詳細化能力の低いのが仕事にタッチしてきて、
設計モデルが崩れる事もあるけれど。

こんなところでいかがかな>>683
0692６８６2007/03/23(金) 21:32:19
>>690
いみふめ
0693仕様書無しさん2007/03/23(金) 21:32:33
とにかく犬を飼うんだったら先に犬小屋を用意しろと。
0694仕様書無しさん2007/03/23(金) 21:34:48
>>689
> 非機能要求は満たせまい。

はいはい煽り乙。
それでは、本件に関する「非機能的要求」として
何が想定できるか、言ってみてくれ。

ヒント：
速度かなぁ～？
それとも問題領域とOO手法のインピーダンスマッチングかなぁ～ｗ
0695仕様書無しさん2007/03/23(金) 21:36:37
コードサイズ。
0696仕様書無しさん2007/03/23(金) 21:37:25
速度にしとく。快適かつ歯ごたえのある奴がいい。
0697仕様書無しさん2007/03/23(金) 21:38:10
オセロで2M bytes
0698仕様書無しさん2007/03/23(金) 21:38:24
いくら言葉を重ねても、ソースが糞ならしかたがない。
この商売はそういうものだ。
0699仕様書無しさん2007/03/23(金) 21:39:23
imodeのゲームは殆どが糞ソースだが、要件は満たしている。
0700仕様書無しさん2007/03/23(金) 21:39:59
電球の奴は弱すぎた。あれの十倍ぐらい強くなきゃな。
もちろんレスポンスも大事。
0701仕様書無しさん2007/03/23(金) 21:41:44
んだ、動いてしまえばこっちのもん。
コンパイルもしないうちにダメだと見切られてちゃねぇ。
0702仕様書無しさん2007/03/23(金) 21:42:39
>>695
>>696
それは
> 問題領域とOO手法のインピーダンスマッチング
に起因する問題だ。

俺の知り合いでIPAに出入りしてた奴が居て、
J2EEクラスタリングの話をしたら
「科学技術研究支援(数値計算バリバリ)に使えないかなぁ～」
とわけのわからない事を逝ってきた奴がいる。
しかし、J2EEは数値計算には向かない。Javaも然り。
可視化やWebサイトといった部分でしか関与しない。
C++も、並列クラスターを使いこなせるとは言いがたい。
結局数値計算には、ベクター化Fortran、並列化Fortran を使う。
それが適所適材ってもんだ。
0703仕様書無しさん2007/03/23(金) 21:45:20
＞ベクター化Fortran、並列化Fortran
このふたつはどう違うの？

違うよ。全然違うよ。
0704仕様書無しさん2007/03/23(金) 21:46:09
そして現在。

Fortranの作者 John Backusは亡くなり、
数々の並列化言語とJavaを仕様化したGLSは、
「C++に対するJava」に相当する「Fortranに対するFortress」
を提案している。
結局、Javaで数値計算～数値処理なんて・・・GLSも本気にしていない戯言なんだ。
0705仕様書無しさん2007/03/23(金) 21:47:19
>>703
自問自答の練習かな？

じゃあ、自分で回答を調べて、
ここでレポートするように。
0706仕様書無しさん2007/03/23(金) 21:48:26
Strategyで思考ロジックを分離して、そこだけCとかアセンブラで組めば
いいんじゃね？
0707仕様書無しさん2007/03/23(金) 21:48:40
わぁい、先生に宿題もらっちゃった～
たのしみだな、答え合わせ。
0708仕様書無しさん2007/03/23(金) 21:53:55
ところで、C++はだめでFortranならいいのはわかったけど
Cじゃだめなの？並列化ライブラリCとインラインasmで書いてあるんだけど。
0709仕様書無しさん2007/03/23(金) 21:56:31
>>668
あと、詳細にマジレスしておこう。

> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。
>
> そして重要なのは修正だ。
> 単純なオブジェクトに対して、ルールや値を追加して、どこに機能を持たせるか考える。
> 多くの場合は、設計の誤りに気が付くだろう。しかし最適な場所がある。

オセロのルールはどの「物」に付与しますか？
まさかゲーム盤や石がルールを持って協調作業する、
なんて奇妙な設計を、わざわざ苦労してするつもりですか？

ゲームの進行はどうやって書きますか？
まさかプレイヤーとプレイヤーの協調作業だなんて、
不確実なものを、わざわざ苦労して設計しますか？

目には見えないけれど、ルールは存在する。
そして、きっちりとゲームをする時は、
審判を置いて、ゲーム進行とルール遵守を確認する。
そういった突き詰めた思考こそが、分析・設計には重要かと存じます。

0710仕様書無しさん2007/03/23(金) 21:57:02
このJavolutionとかJscienceとかはIPA的にはどうなんですか？
http://javolution.org/
http://www.jscience.org/
0711仕様書無しさん2007/03/23(金) 21:59:55
>>710
IPAは見通しの良くない無駄な研究テーマに
無駄な研究費を配る慈善団体に過ぎない。
IPAの判断と、I,N,H,F,SGI/Cray,Sunの判断、
どちらが適切かなんて言わずもがなだ。
それでも疑問があるなら、IPAに直接言え。
0712仕様書無しさん2007/03/23(金) 22:01:21
いくらネタ板とはいえ、体を張って本職のいるとこへ叩かれに来る
おじゃばさまってすごい。もっとがんばれ。超がんばれ。
0713仕様書無しさん2007/03/23(金) 22:02:16
kusowarota
0714仕様書無しさん2007/03/23(金) 22:05:57
>>708
一応訂正しといてやると、
Othelloの思考ルーチンならC++で充分なんじゃないかな。
別に数値計算業界みたく、C++を今更始めるのも億劫だし、
アセンブラレベルの最適化まで面倒みたくない、ってな
専門家が居る業界ではないのだから。

0715仕様書無しさん2007/03/23(金) 22:07:29
>>710
> GLSは、 「C++に対するJava」に相当する「Fortranに対するFortress」 を提案している。
> 結局、Javaで数値計算～数値処理なんて・・・GLSも本気にしていない戯言なんだ。
0716仕様書無しさん2007/03/23(金) 22:12:02
>714
いつオセロにもどったんでしょうか？
オセロの思考ルーチンもFortranがいいの？
混乱してるの、先生？仕様書なしさんは一人じゃないんだよ。
インスタンスはたくさんｗ
0717仕様書無しさん2007/03/23(金) 22:13:45
>>716
> >>708
> 一応（>>708の決め付けを）訂正しといてやると、
> Othelloの思考ルーチンならC++で充分なんじゃないかな。
0718ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 22:18:00
あふぉか
オセロはどうやってもＯＯにしたら見通し悪いだろうが
0719仕様書無しさん2007/03/23(金) 22:20:11
>>718
> > 問題領域とOO手法のインピーダンスマッチング
> に起因する問題だ。
0720仕様書無しさん2007/03/23(金) 22:20:57
ふうん、fortranの話でC++じゃ数値演算はだめ、って流れだったんじゃないんだ。
ごめんね。オセロの思考ルーチンのお話じゃまして。
0721仕様書無しさん2007/03/23(金) 22:22:44
オセロネタが予想外に伸びて内心うれしい>>718
0722仕様書無しさん2007/03/23(金) 22:25:36
「俺の知り合いで」話する時点で説得力なかろ。
0723仕様書無しさん2007/03/23(金) 22:27:58
> 709
> オセロのルールはどの「物」に付与しますか？
> まさかゲーム盤や石がルールを持って協調作業する、
> なんて奇妙な設計を、わざわざ苦労してするつもりですか？
　：
> 目には見えないけれど、ルールは存在する。

「オセロのルール」は、
オセロゲームのシナリオの中の「ミニ・シナリオ」みたいなものだ。
両者(シナリオとルール)の境界は極めて曖昧だ。
だから、シナリオからオブジェクトを抽出すると、
必然的に石やボードがルールを持つようになる。

問題は、そのようなモデルは、
人間の持つ擬人化能力にはよくマッチするが、
既に計算機向けに形式化され構築された思考モデルとは
極めて相性が悪い、という事なんだ。
OO化したモデルと、計算機向けに形式化されたモデル、
どちらが求められるかは、言うまでもないだろう。
0724仕様書無しさん2007/03/23(金) 22:29:10
> 「俺の知り合いで」話する時点で説得力なかろ。

はぁ？なんで？
アフォな説に主語を付けただけだが。
0725723訂正2007/03/23(金) 22:33:17
△ OO化したモデルと、
　　計算機向けに形式化されたモデル、

◎ 人間向けに擬人化したモデル(OO)と、
　　計算機向けに形式化され最適化されたモデル、
0726仕様書無しさん2007/03/23(金) 22:35:21
>>723
じゃあ、何なら相性がいいの？
COBOLで作ってた、ビジネスロジックｗの世界かな？
たしかにいまそう使ってるけど、それこそ
「インピーダンスマッチング」が問題なんでしょ。
07277252007/03/23(金) 22:37:17
そして、もし誠実なOO研究者というものがこの世の中に存在するなら、
前者を後者に対応させるコンパイラ の開発に全力をそそぐだろう。

人間が扱いやすい数式を、浮動小数点演算装置への命令列に
自動翻訳するソフト(Fortran)を開発したJohn Backusのように。

＃まぁ、OOの場合は、そんな努力は実らないと思うが。

0728仕様書無しさん2007/03/23(金) 22:40:24
つまんね議論だな、机上でやっとけよ。
0729仕様書無しさん2007/03/23(金) 22:46:56
>>726
話が通じなかったかな？
オセロのように研究しつくされている領域では、
既存の成果の利用/流用を通じた、より強い思考ルーチンの構築
こそが課題だ。だから、少なくとも思考ルーチンの内部表現としては
> 　計算機向けに形式化され最適化されたモデル、
を使用するのが適切。

業務システム(COBOL)の場合はもっと話がややこしくて、
・人間による手作業に最適化された処理手順 (必ずしも電算機化には向かないｗ)
・COBOL向けに最適化されたロジック 　　　　　(冗長で構築しにくいｗ)
・OO屋が判り易く構築し易いと信じ込んでいる擬人化モデル (やれやれｗ)
の三つの階層が存在する。
まぁ勝手に戦ってくださいってな感想しか持ち合わせていないがｗ
ああ、ネットビジネスとか、ERPとかとの絡みで改善されてくる部分もあるかもなぁ
0730仕様書無しさん2007/03/23(金) 22:50:12
>>727
> 前者を後者に対応させるコンパイラ

無理。
つか、わざわざ回りくどい「擬人化モデル」でアプリを記述するのは地獄だろｗ
効果が確認されてる仕様記述言語すらろくすっぽ使われて現状でｗ
0731仕様書無しさん2007/03/23(金) 22:52:02
結局、 >>601のモデルはさほど間違ってないって結論でおｋ？
0732仕様書無しさん2007/03/23(金) 22:53:52
>729
うん、OOが役立たずなのがよくわかったよぉ。
ありがとー先生。
0733仕様書無しさん2007/03/23(金) 22:55:55
ちょいと待たれい、そこの町人

こちなるポストオブジェクト壷は神妙なる効果を持っておってだな、
おい、聞けよあｓｆｈんｇｓｆｊｈｍんｂｂ
0734ポストオブジェクト壷売り2007/03/23(金) 23:03:51
ここで視聴者のみなさんに素敵なお知らせがあります。

ただいま、この大安成就のポストオブジェクト壷、
通常価格￥１０、０００，０００，０００の所を
先着５名様になーんと
　　　　　　￥１０、０００，０００
という特別価格で提供しちゃいます。

しかも！
通常なら別売りの
・XMLアダプター　・・・タンス裏のホコリを取るのに便利ですね！
・高枝切バサミ・アダプター　・・・コウルサい上司を簡単に切れますよ。便利ですねぇ！
・収納バッグ ・・・使わなくなった壷をスマートに格納できますよ。いいですね！
の三点セットで、なんと
　　　　　　　￥１０，０００，０００
いまなら送料無料です。ご注文は画面下側のURLまでどうぞー
0735仕様書無しさん2007/03/23(金) 23:06:47
まぁ内実を話すとだな、
世界最強！大安成就のポストオブジェクト壷にも大きな弱点があって、
この壷はオブジェクト壷被害者しか買わないって事なんだ。
つまり、オブジェクト壷の被害者が増えれば増えるほど・・・
逆に、オブジェクト壷が全然売れないと・・・
ってことで、オブジェクト壷売りのみなさん、頑張って下さいｗ
0736仕様書無しさん2007/03/23(金) 23:12:56
OO言語なんてそれこそ大量にあるだろう。

頭の中のイメージを人に分かる形で伝えられ、素直にクラス図を理解させることができ、
なおかつ動くプログラムを実装できればOOの答えは無限大だ。
「やりかたいろいろ」というように。

ただこのスレでは他人のOO設計時の頭の中の考え方の理解、擦り合わせと、
それに対する改善策や別解に関して議論することが重要なんだと思うし、それによって良スレになるかもしれない。

煽りは何も生まないぞ。
0737仕様書無しさん2007/03/23(金) 23:19:26
そうそう、OO壷はいいぞぉぅ

そして、OO壷を限界を感じる所まで使い込んだら、
次は是非、ポストOO壷をご購入下さいﾈ。（ぺこり
0738仕様書無しさん2007/03/23(金) 23:21:34
素敵索敵
0739仕様書無しさん2007/03/23(金) 23:23:00
>>736
ご発言、どうぞ。
0740ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/23(金) 23:24:15
高枝切り鋏を思い出した。
0741仕様書無しさん2007/03/23(金) 23:26:26
あと>>668、
　>>679
　>>686
　>>709
　どうよ？
0742仕様書無しさん2007/03/23(金) 23:26:43
おさんスレのゾンビが這い出してきたようだな。
0743仕様書無しさん2007/03/23(金) 23:30:00
>>686よ
　↓も関連レスだな
　>>723
　>>725
　>>727
　>>729
　どうよ？
0744仕様書無しさん2007/03/23(金) 23:34:48
ポストオブジェクト指向壷　しーくぁーさ

なんか、売れそうな名前じゃね？
0745仕様書無しさん2007/03/23(金) 23:38:53
ポストオブジェクト指向壷方法論　くっすん

ﾃﾞｽﾏで泣いてる彼女もｲﾁｺﾛさ
0746仕様書無しさん2007/03/23(金) 23:39:53
ポストオブジェクト指向壷BBS　おさんねる
0747仕様書無しさん2007/03/24(土) 00:08:40
おさん、寝た？
0748仕様書無しさん2007/03/24(土) 00:14:13
俺の隣で寝てるよ
0749仕様書無しさん2007/03/24(土) 00:19:33
古くさいＯＯ壷方法論のフィンガーテクニックで逝かしたのか。やるな
0750仕様書無しさん2007/03/24(土) 04:28:10
ここまで流し読み

アホコテのあまりのレベルの低さに驚いた
Javaのインストール如きで苦しむなよ
どんだけレベル低いんだよ >648
ぶっちゃけPGに向いてないとか以前に
死んだほうがいいんじゃね
0751仕様書無しさん2007/03/24(土) 09:10:01
「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。
これって、括弧の奴をクラスにすればいいの？
教えてエロぃ人
0752ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 09:19:48
金はクラスにしなくていいな
0753仕様書無しさん2007/03/24(土) 09:20:43
>>668
> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

プアーなイメージで書いたコラボレーション図の例


+---------------+ 手を打つ　+---------------+
| プレーヤ　　　　　 |────→| プレーヤ　　　　　 |
+---------------+2　　　　　 1+---------------+
| 石の色※1　　　　 |　　　　　　　 | 石配置　　　　　　 |
+---------------+ (パス)　　　+---------------+
| 次の手を考える　|────→.| 初期配置　　　　　|
|　　　　　　　　　　　 |2　　　　　　1| はさまれた石を　 |
|　　　　　　　　　　　 |　　　　　　　 | 　ひっくり返す　　 |
|　　　　　　　　　　　 |　　　　　　　 | 終了判定　　　　　|
|　　　　　　　　　　　 |　　　　　　　 | 得点集計　　　　　|
+---------------+　　　　　　　+---------------+

※1 石の色は、黒を先手、白を後手とする。
0754ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 09:21:31
金じゃなくて「支払い」ならクラスにするかな。
現金　クレジットカード　商品券　つけ　
0755仕様書無しさん2007/03/24(土) 09:29:39
>>751
> 「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。

　　金を払う　
[客]　→　[店]
　 ＼
　　　 →　[商品]
　　手にとる
0756仕様書無しさん2007/03/24(土) 09:33:23
>>754
> 金じゃなくて「支払い」ならクラスにするかな。

　　　選ぶ
　┌　→ [商品]
　｜
　｜ 支払う
[客]　→　[店]
　　　　：
　　　[支払]
0757仕様書無しさん2007/03/24(土) 09:36:03
[客]　→　[店]
　　　　：
　　　 ：
　　[購入]
　　↓　 ↓
[商品]　[支払い]
0758仕様書無しさん2007/03/24(土) 09:47:08
>>756の点線部
　「客」と「店」の関連「支払う」を、
　関連クラス「支払い」として抽出

>757の点線部
「支払い」では一般に
店から客に何らかの「商品 (物品やサービス)」を提供し、
その対価として客が「支払い」をする。
つまり客が店から「購入」するという関係を抽出した
0759仕様書無しさん2007/03/24(土) 10:00:42
「客」が「店」から「商品」を「購入」し、対価の「支払い」をする。
「支払い」方法： 現金、カード、商品券

「ツケ」は債権の発生だから、「支払い」とは別扱いにした方が・・・
0760仕様書無しさん2007/03/24(土) 10:02:24
>>753
それ激しく手続き型だと思うんだが。。
0761仕様書無しさん2007/03/24(土) 10:03:15
うちは特例としてサービス金券を出していて
月3万以上お買い上げしたお客様には
10万以上の品は10%引き
それ以下は5.8%引きのサービスを行うを追加してください
0762753訂正2007/03/24(土) 10:03:37
>>668
> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

プアーなイメージで書いたコラボレーション図の例


+---------------+ 手を打つ　+---------------+
| プレーヤ　　　　　 |────→| ゲーム盤　　　　 |
+---------------+2　　　　　 1+---------------+
| 石の色※1　　　　 |　　　　　　　 | 石配置　　　　　　 |
+---------------+ (パス)　　　+---------------+
| 次の手を考える　|────→.| 初期配置　　　　　|
|　　　　　　　　　　　 |2　　　　　　1| はさまれた石を　 |
|　　　　　　　　　　　 |　　　　　　　 | 　ひっくり返す　　 |
|　　　　　　　　　　　 |　　　　　　　 | 終了判定　　　　　|
|　　　　　　　　　　　 |　　　　　　　 | 得点集計　　　　　|
+---------------+　　　　　　　+---------------+

※1 石の色は、黒を先手、白を後手とする。
0763仕様書無しさん2007/03/24(土) 10:05:07
>>760
はい？
0764仕様書無しさん2007/03/24(土) 10:17:16
public 店{
public:
　void 購入(客 customer, 商品 comm)
　{
　　if(customer->getMoney >= comm->getPrice()){
　　　customer->setMoney(customer->getMoney() - comm->getPrice());
　　}
　}
}
0765仕様書無しさん2007/03/24(土) 10:25:53
>>761
[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　　：　　 [商品　　　　 ]
[残高　　　　 ]　　　：　　 [　　　　　　　 ]
[債務　　　　 ]　　　：　　 [債権　　　　 ]
[クーポン　　]　　　：　　 [割引ルール]
[購入履歴 　]　　　：　　-----------
-----------　　　：
[商品を選ぶ]　　　：
　　　　　　　　　　 ：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↓　
[商品　　　　]　[請求　　　　]　[支払い　　]
-----------　----------　----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------　[クーポン　　]
　　　　　　　　　[割引適用　]
0766仕様書無しさん2007/03/24(土) 10:28:27
>>765
別の店を相手にする場合は購入履歴はどうなる？
0767仕様書無しさん2007/03/24(土) 10:34:06
>>767
[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　　：　　 [商品　　　　 ]
[残高　　　　 ]　　　：　　 [　　　　　　　 ]
[債務　　　　 ]　　　：　　 [債権　　　　 ]
[クーポン　　]　　　：　　 [割引ルール]
[　　　　　　　 ]　　　：　　 [顧客情報　 ]
-----------　　　：
[商品を選ぶ]　　　：
　　　　　　　　　　 ：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↑
[商品　　　　]　[請求書　　 ]　[支払い　　　]
-----------　----------　-----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------　[クーポン　　]
　　　　　　　　　[割引適用　]
0768仕様書無しさん2007/03/24(土) 10:38:07
基本的に返品はうけつけてないんですけど
クレーマーな客の無理やり返品・返金にも対応してください
0769ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 10:40:49
支払いは例外が多いんだよねえどこの会社も。
只とか相殺とか贈与とか割引、お釣りが無かったのでまけた、などなど
0770仕様書無しさん2007/03/24(土) 10:41:15
在庫との連動がないと、そのクラスは使い物になりませんね
0771仕様書無しさん2007/03/24(土) 10:42:21
在庫の引きあてトランザクション処理も追加してください
0772ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 10:43:26
それはＤＢのだろ　ＯＯじゃなくてＤＢ設計だな。
ちなみにＤＢとＯＯはものすごく相性が悪い。
0773仕様書無しさん2007/03/24(土) 10:44:54
>>772
DB側であろうがなかろうが、クラスと連携して業務が完結します。
それともこのクラスは業務で使わないのが前提ですか？
DBを使わないのならDBをシミュレートするクラスが必要になります。
0774仕様書無しさん2007/03/24(土) 10:47:54
そのクラスが直販をしているメーカ本社であったとすると
代理店が複数あった場合はどうなりますか？
0775ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 10:47:54
おまいはトランザクション処理をクライアント側の中で勝手にやる気なのかよ
0776仕様書無しさん2007/03/24(土) 10:48:40
>>775
シミュレートってんだろうが、このんぽぽん！
0777仕様書無しさん2007/03/24(土) 10:49:56
直販の仕入れ価格と、代理店の仕切り価格がばらばらだと
その管理も考慮しなくてはなりませんね。
0778仕様書無しさん2007/03/24(土) 10:51:41
一次代理店と取次ぎ店と二次代理店があった場合は
もっと複雑になってきますね。どーしましょうか？
0779仕様書無しさん2007/03/24(土) 10:59:21
おまいら本当にバカだな。
適当だから抜けあるかもだが、こんな感じでいいんじゃね？

こいつらは目印用interfaceな。
石って名前はいまいちだが、汎用的な名前思いつかなかた(´・ω・`)
位置interface：
石interface：
ルール情報interface：

こっちは処理系interface
盤interface：
put石(石interface);
get石リスト();
get終了判定();　
プレーヤーinterface：
put石(位置interface);
get終了判定();　
ルールinterface：
checkルール(ルール情報interface);
戦術interface：
get駒位置();
全体制御interface：
exec();

続く。。。
07807792007/03/24(土) 11:00:54
続き。。

んで、オセロとか将棋とかの独自実装をする。

位置クラス：
位置interfaceをimplementして作成。
位置情報を保持する。
ゲームによって保持する情報が変更される。

石クラス：
石インターフェースをimplementして作成。
位置・状態(裏表)等を保持。
ゲームによって保持する情報が変更される。

ルール情報クラス：
ルール情報インターフェースをimplementして作成。
ルールを判断するのに必要な情報を保持。
ゲームによって保持する情報が変更される。

盤クラス：
singleton指定
盤interfaceをimplementして作成。
ルールクラスをinjection。
石instanceを保持。
ルールクラスのメソッドを参照し石が置けるか判断。
置けたら他の石インスタンスの状態を変更。

さらに続く。。
07817792007/03/24(土) 11:01:55
続き。。

プレーヤークラス：
プレーヤーinterfaceをimplementして作成。
盤クラスをinjection
プレーヤー情報を保持。盤に石を置く。

ルールクラス：
プレーヤーinterfaceをimplementして作成。
渡されたルール情報instanceを参照しルールに従っているか判断。

戦術クラス：
戦術interfaceをimplementして作成。
盤クラス・ルールクラスをinjection。
それぞれのクラスを参照し石を置く位置を決定。

全体制御クラス
全体制御interfaceをimplementして作成。
main処理。ゲーム・プレーヤークラス・AI(戦術クラス)の管理を行う。

めんどくさくなた。。後は意見出して発展させてくれ。

ちなみに終了判定は、
全体制御クラス→プレーヤークラスのget終了判定()→盤クラスのget終了判定()で呼ばれる。そうする事によってどのプレーヤーが終了したかが分かる。
でも、全体制御クラス→盤クラスでもいいかも。プレーヤーinterfaceにget終了判定持つのはちょっと違和感あるし。
0782仕様書無しさん2007/03/24(土) 11:02:27
オセロはもう終了しれ
07837792007/03/24(土) 11:06:06
>>782
(´；ω；｀)
0784仕様書無しさん2007/03/24(土) 11:12:44
複雑になってきたらビジネスロジック設計はスルーされました
07856012007/03/24(土) 11:16:19
>>779
　　　　　　　　　　[Othelloゲーム]
　　　　　　　　　　　◇　　　　　△
　　　　　　　　　　　｜　　　　　 ：
　　　　　　　　　[ルール]　　　[試合]
　　　　　　　　　　　│　　　　　◇
　　　　　　　　　　　↓　　　　　↓

　　　　　　　　　　通知ｗ
[進行係　　　　 ]←──[審判　　　　　 ]　　[記録係　　　　　]
-------------　　　　 -------------　　　　│
-------------　　　　 -------------　　　　│
[先攻後攻決定]　　　　[お手つき判定 ]　　　　│
[開始指示　　　]　　　　[パス判定　　　]　　　　│
[打ち順指示.　 ]　　　　[終了判定　　　]　　　 .│
[終了指示　　　]　　　　[得点集計　　　]　　　 .│
　　　│　　　　　　　　　　　　　│チェック　　　 │記録
指示↓　　　　　　　　打つ.　　└───┐　　 │
[プレーヤ　 ]─────────→[ゲーム盤　]
----------　2　　　　　：　　　　　 1　----------
[石の色　 　]　　　　[手　　　　]　　　　[石の配置 ]
----------　　　　 ---------　　　　----------
[手を考える]　　　　[石の色　]　　　　[初期配置　]
　　　　｜　2◇　　　[位置　　 ]　　　　[ひっくり返す]
考える｜　　│1..64◇　　　　◇
　　　　↓　　└──┤1　　　│
[戦術　　　　]　　[石　　　　]　[位置　　　]
　　　　　　　　　　---------
　　　　　　　　　　[石の色　]
　　　　　　　　　　---------
　　　　　　　　　　[リバース ]
07867792007/03/24(土) 11:25:53
>>785
それだと、人がプレーヤーになれなくないか？
0787仕様書無しさん2007/03/24(土) 11:33:19
>>786
はい？
>>601に書いたように、
　プレーヤ　∋　人、コンピュータ

　　　[プレーヤ]
　　　△　　　△
　　[人]　　[コンピュータ]
　　　　　　　↓考える
　　　　　　[戦術]

誰か(>>668)が「継承」や「インターフェース」はまだ書くな
とか世迷言を言ってたから、省略しただけ。
07887792007/03/24(土) 11:37:07
>>785
戦術interfaceをimplementした「戦術クラス」と「人が操作クラス」作って
それぞれを別のプレーヤークラスにinjectionすればいけるか。
そうすると戦術interfaceって名前がいまいちだな。
07897792007/03/24(土) 11:40:52
>>787
　プレーヤ　∋　人、コンピュータ

　　　[プレーヤ]
　　　△　　　△
　　[人]　　[コンピュータ]
　　　　　　　↓考える
　　　　　　[戦術]

それは分かるんだが、プレーヤーに手を考えるメソッドがあって、
戦術クラスに直繋がりだったから、どうやって人に操作渡すのかと思った。
自己完結したからおk。
07906012007/03/24(土) 11:42:23
　　　　　　[Othelloゲーム]
　　　　　　△　　　　　　◇
　　　　　　 ：　　　　　　 │
　　　　　[試合]　　　[ルール]
　　　　　　◇　　　　　　│
　　　　　　↓　　　　　　↓

　　　　　　　　　 通知(ｗ
[進行係　　　　 ]←─[審判　　　　　 ]　　　　[記録係　　　　]
-------------　　　 -------------　　　　　 ↑
-------------　　　 -------------　　　　　 │記録
[先攻後攻決定]　　　[お手つき判定 ]　　　　　 │
[開始指示　　　]　　　[パス判定　　　]　　　　　 │
[打ち順指示.　 ]　　　[終了判定　　　]　　　　　.│
[終了指示　　　]　　　[得点集計　　　]　　　　　.│
　　　│　　　　　　　　　　　　　│チェック　　　　.│
指示│　　　　　　　　　　　.　　└─────┐│
　　　↓　　　　　　　　打つ　　　　　　　　　　　↓│
[プレーヤ　 ]────────────→[ゲーム盤　]
----------　2　　　　　　　　　：　　　　　　 1 ----------
[石の色　 　]　　　　　　　[手　　　　]　　　　　[石の配置 ]
----------　　　　　　　 ---------　　　　　----------
[手を考える]　　　　　　　[石の色　]　　　　　[初期配置　]
　　　　△　　　　　　　　.　[位置　　 ]　　　　　[ひっくり返す]
　┌─┴──┐　　　　　.◇　　　 ◇
[人　　　]　　[ｺﾝﾋﾟｭｰﾀ]　 │　　　└┐
-------　　　↓　　　　　[石　　]　[ 位置 ]
-------　　[戦略]　　　 .------
[手入力]　　　　　　　　　 [色　　]
　　　　　　　　　　　　　　　------
　　　　　　　　　　　　　　 .[ﾘﾊﾞｰｽ]
0791仕様書無しさん2007/03/24(土) 11:50:52
支払いは例外が多いか。ならば

interface 支払い方法｛
　　支払い（客，店）；
｝
class 現金一括（支払い方法）｛
　　private　金額；

　　コンストラクタ（金額）｛
　　　　this．金額　＝　金額；
　　｝
　　支払い（客，店）｛
　　　　客．手持ち現金　－　金額；
　　　　店．現金　＋　金額；
　　｝
｝

かな？相当例外的な支払いは最悪その場でローカルインナークラス生成とか。
0792仕様書無しさん2007/03/24(土) 11:55:24
>>オセロ
「その場でユーザ入力してもらう」って戦術を作れば
何も人間プレーヤーとコンピュータ分ける必要ないんじゃ。
0793仕様書無しさん2007/03/24(土) 12:02:04
>>768
[客　　　　　　] ────→ [店　　　　　　]
-----------　　　：　　　　　-----------
[返品商品　 ]　　　：　　　　 [商品　　　　　]
[口座　　　　 ]　　　：　　　　 [返品ルール. ]
[債務　　　　 ]　　　：　　　　 [債権　　　　 ]
[　　　　　　　 ]　　　：　　　　 [顧客情報　 ]
　　　　　　　　　　　：
　　　　　　　　　[　返品　　 　]
　　　　　　　　　-----------
　　　　　　　　　-----------
　　　　　　　　　[ルール判定]
　　　　　　　 ／　　　│　　　　 ＼
　　　　　　 ↑　　　　↓応じる 　↓応じない
[返品商品 　]　[返金　　　　] 　[リジェクト　 ]
-----------　----------- 　-----------
[購入価格 　]　[返金方法　] 　-----------
[返品送料 　]　[返金金額　]　 [客に通知　 ]
　　　　　　　　　　　　　　　　　　 [商品再返送]
0794仕様書無しさん2007/03/24(土) 12:05:46
返品は例外で返すべきでは
07957792007/03/24(土) 12:09:53
>>790
石instanceは盤クラスが管理してるから、
記録係は盤がやってもいいんじゃね？
記録方法の変更は石管理のやり方換えればいい訳だし。

ルールと審判は結局同じ物だから１つのinterfaceに実装した方がいいかな。
その方が戦略クラスからルールクラスの参照する際に便利だし。
審判から進行係に「通知」は変だろw
それから、戦略クラスからルールinterfaceへの参照が抜けてるな。

あと得点集計は別クラスがいい希ガス
07967792007/03/24(土) 12:18:22
>>791
ちょっとまてそれはおかしくね？

interface 支払い方法｛
　　支払い（金額）；
｝
class 現金一括（支払い方法）｛
　　private　お金管理interface　払う人；
　　private　お金管理interface　貰う人；

　　支払い（金額）｛
　　　　払う人.現金払う(金額)；
　　　　貰う人.現金貰う(金額)；
　　｝
　　
　　払う人のsetterとgetter
　　貰う人のsetterとgetter
｝

だろ？
0797仕様書無しさん2007/03/24(土) 12:19:24
>>769
[支払い　　 ]
-----------
[支払方法[]]
[合計金額　]
-----------
[確認　　　　]
　　　　◇
　　　　｜
[支払方法]
---------
[金額　　　]
[確度　　　]
---------
[確度ﾁｪｯｸ]
　　　　 △
┌──┼──┬─────┬─────┬─────┐
現金　　　　　金券　　　　　クレジット　　　　債権相殺　　　クーポン/割引/オマケ/贈与
--------　　--------　　--------　　　　
入金済　　　 有効性　　　 信用　　　　　　　
--------　　--------　　--------
入金確認　　使用可？　　与信処理
0798仕様書無しさん2007/03/24(土) 12:22:11
>>797
支払いについてはそんな感じになるかなあ
0799仕様書無しさん2007/03/24(土) 12:39:19
>>795
1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。
　現実の対戦記録は、プレイヤーの打ち手の系列だったりする。
　だから、プレイヤー→盤→記録係　という流れが自然。

2-1.ルールと審判は違う。
　 ルールは静的なデータ構造、審判は試合にルールを適用する係。

2-2.戦略クラスは、一般的なオセロ・ルールに基づくヒューリスティックを持った上で、
　 その試合固有のルールにも参照を持つ、という意味なら同意。

2-3.審判から進行係への通知は省略して書いた。
　　例えば、お手付き判定、パス判定、終了判定は、
　　進行係からプレイヤへの指示に影響を与える。
　
3. いみふめ
　 審判の責務は、試合がルールを遵守し、結果を出す事にある。
　 試合の結果は終了判定と得点なのだから、得点集計は審判の責務。

　ただ、似たような曖昧さもある。例えば時間制限ルール。
　現実には時間制限は進行係がやる。理由は下っ端だから？
0800799訂正2007/03/24(土) 12:40:35
× 1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。

◎ 1. 「盤」の状態変化の記録を、記録係に委譲する、と考えればおｋ。
08017792007/03/24(土) 12:41:35
客店商品の設計してる人達って要件も定義しないで
どうして設計出来るのかと。。
レス読むと仕変が入りまくってぐちゃぐちゃになってきてる訳だが。。
デスマ直行プロジェクトだなww
0802799書き直し2007/03/24(土) 12:43:49
>>795
1. 「盤」の状態変化の記録を、記録係に委譲する、と考えればおｋ。
　現実の対戦記録は、プレイヤーの打ち手の系列だったりする。
　だから、プレイヤー→盤→記録係　という流れが自然。

2-1.ルールと審判は違う。
　 ルールは静的なデータ構造、審判は試合にルールを適用する係。

2-2.戦略クラスは、一般的なオセロ・ルールに基づくヒューリスティックを持った上で、
　 その試合固有のルールにも参照を持つ、という意味なら同意。

2-3.審判から進行係への通知は省略して書いた。
　　例えば、お手付き判定、パス判定、終了判定は、
　　進行係からプレイヤへの指示に影響を与える。
　
3. いみふめ
　 審判の責務は、試合のルール遵守を管理し、試合の判定結果に責任を持つ事である。
　 試合の判定結果とは、つきつめれば終了判定と得点なのだから、得点集計は審判の責務。

　ただ、似たような曖昧さもある。例えば時間制限ルール。
　試合へのルール適用という意味では審判の責務なのだが、
　現実には進行係に委譲されるｗ　理由は下っ端だからかｗｗｗ
0803仕様書無しさん2007/03/24(土) 12:45:59
>>801
それがジャワポンSEオブジェクト指向宗教家の標準仕様です
0804仕様書無しさん2007/03/24(土) 12:45:59
> 客店商品の設計してる人達って要件も定義しないで
> どうして設計出来るのかと。。
> レス読むと仕変が入りまくってぐちゃぐちゃになってきてる訳だが。。
> デスマ直行プロジェクトだなww

上に出ているような「仕変」は、
実はよくある一般的な「仕様」の詳細部に過ぎない。
つまり、経験と常識があれば考慮済な話。
0805仕様書無しさん2007/03/24(土) 12:47:04
>>801
どこまで仕様変更に耐えられるかを通じて
OOPが出来ているかを試してるんだろうが
0806仕様書無しさん2007/03/24(土) 12:50:49
>>771
> 在庫の引きあてトランザクション処理も追加してください

ｋｗｓｋ

>>774
> そのクラスが直販をしているメーカ本社であったとすると
> 代理店が複数あった場合はどうなりますか？

直販しているなら問題なっしんぐ。
直販していないなら代理店紹介して終了。
0807仕様書無しさん2007/03/24(土) 12:53:38
直販&&一次代理店&&取次店&&二次代理店&&紹介手数料支払いルール&&
大量業務販売卸
0808仕様書無しさん2007/03/24(土) 12:54:15
同一商品の仕入先は多数でその時の相場で変動する
0809仕様書無しさん2007/03/24(土) 12:54:51
在庫をストックする場所は複数で、在庫連動をマネージする仕組みも必要
0810仕様書無しさん2007/03/24(土) 12:56:21
輸入品のため、予約注文はインボイス日時の予想をするシミュレータが必要
0811仕様書無しさん2007/03/24(土) 12:57:29
>>808
それは価格付けルールに関する問題かと。
つまり、商品仕入れ時に個別の値段付けをするか、
あるいは注文と商品の対応付けの際に、値段を付け直すかｗ
08127792007/03/24(土) 12:57:50
>>799
>1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。

了解

>2-1.ルールと審判は違う。
>　 ルールは静的なデータ構造、審判は試合にルールを適用する係。
　ルールは必ずしも静的にはならないとおも。ロジックが確実に入るんじゃね？
　結局チェックロジックが入るなら、どっちにしろ同じかと。
　但し、ルールが確実に静的になるという確証があるのであれば同意。

>2-2.戦略クラスは、一般的なオセロ・ルールに基づくヒューリスティックを持った上で、
>　 その試合固有のルールにも参照を持つ、という意味なら同意。
　盤が参照するルールと、戦略が参照するルールで違いがあったらやばくね？って事。

>2-3.審判から進行係への通知は省略して書いた。
>　　例えば、お手付き判定、パス判定、終了判定は、
>　　進行係からプレイヤへの指示に影響を与える。
お手付き判定・パス判定は石を置いた時点、終了判定のタイミングは盤によって石instanceの状態が変わった後であるから、これらの判断は盤クラスへ石を置いた時に実行するべきかと。　終了判定は、進行係でもいいかな。

>3. いみふめ
>　 審判の責務は、試合がルールを遵守し、結果を出す事にある。
>　 試合の結果は終了判定と得点なのだから、得点集計は審判の責務。
確かに審判が得点集計を行ってくれと指示を出す。
ただし集計の責務は審判には無い。
通常のスポーツでも審判は判断するだけで、集計は別物だろ？
0813仕様書無しさん2007/03/24(土) 12:57:51
個人のお客でもある一定ロット数以上の注文ならば
業務販売卸価格を適用できる
この場合は個人客の監査を行い、問題が無ければ顧客リストに登録できる仕様
0814仕様書無しさん2007/03/24(土) 12:58:49
>>809
既に問題領域の外側に発散した感があるな。

>>810
配送日時はモデルの対象外になってるよね？
08157792007/03/24(土) 13:00:09
>>805
おまいのプロジェクトはデスマ確定だなww
要件確定しないと仕様は無限に増えるぞ？
0816仕様書無しさん2007/03/24(土) 13:02:25
>>814
>>815
対象範囲を超えているのは理解済み。あえて、クラス疎結合学習のための
例題として出している。
0817仕様書無しさん2007/03/24(土) 13:02:31
>>815
要件を確定することは重要だがそれはまた別の話だろ
ここはオブジェクト指向スレだぞ？
0818仕様書無しさん2007/03/24(土) 13:05:26
>>815
「ビジネスロジック設計」スレたてろ　んぽぽん！
0819仕様書無しさん2007/03/24(土) 13:06:04
さあさあ、んぽってきました。
08207792007/03/24(土) 13:09:33
>>817
ちょ。。おまえら。。
要件確定→クラス図作りました→仕変がありました→どうしましょう？
っていう流れだったらOOのプラクティスとしても意味がある。
だが、今のままじゃぐちゃぐちゃになって終わるだけだぞ。
実際すでにDBの領域にまで突入しようとしてるじゃないか？
0821ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 13:10:22
オセロだと都合が悪いからなＯＯには
店の売り上げ管理でもＯＯだと都合が悪いから話を中断させようと必死だ。
08227792007/03/24(土) 13:11:29
>>821
お前はカエレ
0823ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 13:12:11
実用的なのでなんでもいいから具体例だしてみ＞ＯＯ厨

「具体的に考えるとＯＯが適当とされる事例が思い浮かばない」

が真実かな？
0824仕様書無しさん2007/03/24(土) 13:13:27
>>823
書き捨てのシステム以外全部
0825仕様書無しさん2007/03/24(土) 13:14:10
>>812
はいはい。
一部の意見は参照に値するが、
別の一部の意見は主観的ブレの範囲なので
ご自由にどうぞ、という感じ。

2-1. ルールには、盤面や石の色や形状が含まれるので、
　　　審判と同一視するのは不自然。
　　　ルールが静的データ構造かどうかは、実は本質ではない。
　　　単に「ルールは固有のアプリに強く依存した形で表現すべきではない」
　　　というだけの設計上の気持ちに過ぎない。
　　　どうしても静的データ構造にしたいなら、
　　　ルールエンジンなり宣言的な補助言語(スクリプト・インタープリタとか)
　　　を導入すれば、実現できる。

2-2. これは前にも書いた話だが、
　　　戦略が(Strategy切替ミス、バグ、勘違いその他の理由で)
　　　試合ルールに従おうが従わないだろうが、
　　　審判が手を判定して、手が試合ルールに従っていると判断すればそれでおｋ。
　　　仮に試合ルールを勘違いして、とんでもない戦略ミスをしたとしても、
　　　プレーヤが損をするだけの話。

　　　話は逆になるが、初心者に可能な打ち手を示す、というサービスを考えると、
　　　助言者クラスの追加が必要かもしれない。

とりあえず長々文章書くよりも、>>793の図を修正したらどうか、と。
図の編集には、2chツールのAAエディタがｵﾇﾇﾒ。
　　http://aaesp.at.infoseek.co.jp/
0826ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 13:15:03
「再利用というものがＯＯではじめて可能になった」
というのは完全な捏造だ。
0827仕様書無しさん2007/03/24(土) 13:16:36
OOを否定する人間はOOも構造化も
独立性を高め依存度を低くするための手段に過ぎず
本質的に同じものだと言う事を理解していない。
0828仕様書無しさん2007/03/24(土) 13:18:25
だから上の例で疎結合学習しようぜ
0829仕様書無しさん2007/03/24(土) 13:26:04
疎結合なら絶対良い、というのであれば、
単純で汎用性の高いXMLファイルをやり取りするようなインタフェースで、
各モジュールをWebサービス化ｂｷればいい。

　　　　　　　　　Webサービス呼出
　　プレーヤ←─────→ボード
　　　　　　　　　XMLファイル

問題は、空理空論の疎結合ではなく、
現実に密結合でどうしようもなくﾃﾞｽﾏｰﾁ化したシステム(例えば>>240)
をどうしたら良いか、そのためにはどんな疎結合の手法を使えばいいか、
って事。

話を現実から出発しないと、空理空論に終わる。
0830仕様書無しさん2007/03/24(土) 13:43:08
ルール　　　＝監査基準
審判　　　　 ＝監査役(経営, 品質, 環境, etc)
試合進行係＝社長
プレーヤ　　＝社員

と考えれば、
・実行役が監査したり、
・監査基準と監査役が同一物だったり
したらおかしいのはすぐ判るだろｗ

上の方に余分にあるクラス (ルール、審判、進行係) は
要するに「監査パターン」っつこったｗ
0831仕様書無しさん2007/03/24(土) 13:55:36
ソース書きながら考えようぜ
0832仕様書無しさん2007/03/24(土) 13:56:22
【分析モデル】
　　　　ルールに従う
試合───────→ルール
　　　　　　　　：
　　　　　　　審判


【設計モデル】
　　ルール準拠を　ルール準拠を
　　監査する　　　　保証する
試合←──審判──→ルール
　↑
　│ルール準拠で
　│実行する
進行係

0833仕様書無しさん2007/03/24(土) 13:59:54
【設計モデル２】

　　　　監査　　　　保証
試合←──審判──→ルール
　↑　　　　　 │
　│進行　　 │アドバイス（ｗ
　│　　　　　 │
進行係 ←─┘
0834仕様書無しさん2007/03/24(土) 15:13:20
んじゃ、まずはXMLの定義からはじめないと
0835仕様書無しさん2007/03/24(土) 15:34:52
きましたねＸＭＬ
ＷＥＢの本には必ずといっていいほど出てくるＳＯＡＰ,ＵＤＤＩ,ＷＳＤＬ
だが、いまだ日の目を見てない、実物みたことない、抽象論。
JavaScriptや鯖サイＪＡＶＡ,ＣＧＩ(Cがネイティブで使えるし)があるんだからいいじゃん！
ＸＭＬ？平文ネットに流すのか？＞ならSSLにすりゃどーよ
と言う声も。
じゃあ、SOAPの利点＞広域分散処理に関しては？
＞お前やれよｗ
以下ループｗ
0836仕様書無しさん2007/03/24(土) 15:38:11
AJAX全盛期にしては
突っ込みの古臭さに唖然とした。
0837仕様書無しさん2007/03/24(土) 15:39:23
REST、とかも良く聞くよな。
0838仕様書無しさん2007/03/24(土) 15:43:21
>>826
お前詭弁ばっかだな
全く論拠がねぇ
まともな議論ができるようになってから出直しな
0839仕様書無しさん2007/03/24(土) 15:49:59
　　　　　　　　[Othelloゲーム]
　　　　　　　　△　　　　　　◇
　　　　　　[ 試合 ]◇─[ルール]
　　　　　　　　◇　　　　　　↑従う
{ ルール, プレーヤ,　　　{ 審判, ゲーム盤,
　　　記録, 進行係, }　　　石, (進行係)...}
　　　＿＿＿＿＿＿__　　　　　　　　 ＿＿＿＿＿＿＿
　　　[進行係　　　　 ]　　　　　　　　 [審判　　　　　　 ]
　　　=============　　　　　　　　　==============
　　　[先攻後攻決め]　　　　　　　　 .[　　　　　　　　　 ]
　　　[開始指示　　　]　　　　　　　　 .[お手付き判定　]
　　　[打ち順指示.　 ]←─────[パス判定　　　 ]
　　　[終了指示　　　]←─────[終了判定　　　 ]
　　　￣￣￣|￣|￣￣　　　　　　　　　 ￣￣￣￣￣￣|
　　　　　　　│.│開始/終了/　　　　　　　　　　　　 .│
　　　　　　　│.│手戻り/譜の再現　　　　　　　　　 │ﾁｪｯｸ
　　　　　　　│.└────────────┐　│
　.＿＿＿＿↓　　　　　　　　　打つ　　　　　　　.↓__.↓＿＿　　記録
　[プレーヤ　 ] ───────────→ [ゲーム盤　]────→┐
　----------　2　　　　　 ＿＿：＿＿　　　　1 -----------　　　　　 [記録係]
　[石の色　 　]　　　　　　　[手　　　　]　　　　　[石の配置　]←────┘
　----------　　　　　　　 ---------　　　　　-----------　譜の再現、手戻り等
　[手を考える]　　　　　　　[石の色　]　　　　　.[初期配置　]
　￣￣△￣￣　　　　　.　　[位置　　 ]　　　　　.[ﾘﾊﾞｰｽ　　　]
. .┌─┴──┐ 　　　.　　 ￣◇￣◇　　　　　 [集計　　　　]
＿|＿＿_　　＿|＿＿＿　　 ＿│＿└─┐＿　 ￣￣￣￣￣
[人　　　]　　[ｺﾝﾋﾟｭｰﾀ]　　.[石　　]　　[ 位置 ]　
=======　　 ￣￣ |￣　　　------　　￣￣￣
[手入力]　考える↓＿　　 .[色　　]
￣￣￣　　　[　戦略　 ]　　 ------
　　　　　　　 ￣￣￣￣　　 .[ﾘﾊﾞｰｽ]
　　　　　　　　　　　　　　　　￣￣￣
0840ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 16:15:35
ＯＯなんて詐欺商売からは足を洗ってまっとうに生きろ。
0841仕様書無しさん2007/03/24(土) 16:24:16
>>840　電球
世のため、早く氏ね
0842仕様書無しさん2007/03/24(土) 16:35:44
OO壷売りの皆様、お疲れです。

OO壷の被害者が増えれば増えるほど、
ウチのお客様が増えるって仕組みになってますので、
皆さん頑張って下さいネ。

あと、OO壷売りに騙されたと感じたら、
すぐご連絡下さいネ。
即座にポストOO壷の説明にあがりますのでｗ
0843仕様書無しさん2007/03/24(土) 16:42:31
オブジェクト指向ってさ、理解は誰でもできるんだよね
使いこなしが出来ないだけでさ
0844仕様書無しさん2007/03/24(土) 16:44:52
すげえ延びてんなこのスレ。。

>>839
こんなに大きな設計になる前に、一度コードに落とすべきだな。
0845仕様書無しさん2007/03/24(土) 18:17:40
>>843
使いこなすといっても
目的もいろいろだしな。
たとえば、保守性を上げたいのか
拡張性を上げたいのかの違いだけでも
使いこなす方法が変わってくるだろうしな…
08467792007/03/24(土) 18:23:27
>>825
せっかくまともに会話出来る相手がいたとおもたのに【残念です。】

>>2-1. ルールには、盤面や石の色や形状が含まれるので、
要点が全然違う方向にいってるのわかってる？
前回の発言と矛盾してるよ。

>>2-2. これは前にも書いた話だが、
だから戦略ルーチンでルールの判断必要だろって事をいっている。
それに盤クラスの石置きメソッドでルールクラスのcheckルール()を実行すれば事足りる。
ようは、ルールを提供するクラスがあればいいのであって、審判クラスいらなくね？って事。
08477792007/03/24(土) 18:26:17
>>839
うんうん。それかなりイメージと合ってる。

ただ、やっぱり審判クラスいらないな。
お手つき判定はルールクラスで、
パスと終了判定は進行係クラスで事足りそう。

ルールクラスで統合的にルールのチェックを行う。
08487792007/03/24(土) 18:35:45
>>826
再利用なんて激しく昔からあるし。
標準ライブラリって名のつく物なんてみんな再利用の為に作られてる。

OOだと再利用出来る(やりやすい)なんて誰が言い出したんだ？アホかと。。
OOなんて大きな事象を細分化する考え方なだけで、
再利用出来るかどうかは設計の内容によるもの。
0849仕様書無しさん2007/03/24(土) 18:44:49
荒らしはスルーしれ
0850仕様書無しさん2007/03/24(土) 18:45:38
>>846
はいはい。

2-1.ルールと審判は違う
> 要点が全然違う方向にいってるのわかってる？
> 前回の発言と矛盾してるよ。

　>>799
　2-1.ルールと審判は違う。
　　 ルールは静的なデータ構造、審判は試合にルールを適用する係。
　
　>>812
　ルールは必ずしも静的にはならないとおも。ロジックが確実に入るんじゃね？
　結局チェックロジックが入るなら、どっちにしろ同じかと。
　但し、ルールが確実に静的になるという確証があるのであれば同意。

　>>825
　2-1. ルールには、盤面や石の色や形状が含まれるので、
　　　審判と同一視するのは不自然。
　　　【注：>>799　「審判は試合にルールを適用する係」】

　　　ルールが静的データ構造かどうかは、実は本質ではない。
　　　～～～～～～～～～～～～～～～～～～～～～～～～
　　　単に「ルールは固有のアプリに強く依存した形で表現すべきではない」
　　　～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
　　　というだけの設計上の気持ちに過ぎない。
　　　どうしても静的データ構造にしたいなら、
　　　ルールエンジンなり宣言的な補助言語(スクリプト・インタープリタとか)
　　　～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
　　　を導入すれば、実現できる。

で、どこが矛盾してるって？
0851仕様書無しさん2007/03/24(土) 18:50:14
とりあえず二人とも茶でものんでもちつけ
0852仕様書無しさん2007/03/24(土) 18:57:18
>>846
　はいはい。

　■2-2. 戦略とルールの関連
　>>846 これは前にも書いた話だが、
　>>846 だから戦略ルーチンでルールの判断必要だろって事をいっている。

　【回答】>>802参照
　> 2-2.戦略クラスは、一般的なオセロ・ルールに基づくヒューリスティックを持った上で、
　> その試合固有のルールにも参照を持つ、という意味なら同意。


　■2-2'. 審判クラスいらなくね？　
　>>846 ようは、ルールを提供するクラスがあればいいのであって、審判クラスいらなくね？って事。

　【回答】
　「2-1.ルールと審判」の件と同様。
　>>825 主観的ブレの範囲なのでご自由にどうぞ、という感じ。

　>>825 ルールは、（略）　審判と同一視するのは不自然。
　>>830 　
　> ルール　　　＝監査基準
　> 審判　　　　 ＝監査役(経営, 品質, 環境, etc)
　> 試合進行係＝社長
　> プレーヤ　　＝社員
　>
　> と考えれば、
　> ・実行役が監査したり、
　> ・監査基準と監査役が同一物だったり
　> したらおかしいのはすぐ判るだろｗ
　>>850 「ルールは 【注：審判のように】 固有のアプリに強く依存した形で表現すべきではない」というだけの設計上の気持ち
0853仕様書無しさん2007/03/24(土) 19:02:00
なんだかお互いのこだわりを主張しあってるにしか見えんな
08547792007/03/24(土) 19:03:44
>>850
>で、どこが矛盾してるって？

最初は、
> ルールは静的なデータ構造
って発言してるのに
>ルールは必ずしも静的にはならないとおも
と突っ込んだ途端に
>ルールが静的データ構造かどうかは、実は本質ではない
って発言が翻ってるところかな。
あ。。矛盾じゃなくって誤りを認めてないだけかw

とりあえず、>>839の構成を元にinterface抽出してみるよ。
興味ある人は気長に待ってみて。

>>851
分かった。飲んどくww
08557792007/03/24(土) 19:04:25
>>853
確かにそうだなw
実際の現場でもよくある事ww
0856仕様書無しさん2007/03/24(土) 19:08:36
何故、明らかに別物のクラスを
一つにマージしようとするのか、
その意図が理解できない。

>>240の例みたく、
画面１クラス～画面１０００クラス、
画面１専用のロジック１クラス～ロジック１０クラス
・・・
なんて訳わかんないことやってるわけじゃないしｗ
0857仕様書無しさん2007/03/24(土) 19:09:10
>>854
あ、わかった。君は粘着質だ。
0858仕様書無しさん2007/03/24(土) 19:09:38
苦心惨憺で設計したことが、コードに落とすとあっさり実現できてしまったり
その逆もあったりする。
ので、とにかくコードを書いた上で議論したほうがいいとおもう。
0859仕様書無しさん2007/03/24(土) 19:09:44
>>853
　>>825 主観的ブレの範囲なのでご自由にどうぞ、という感じ。
0860仕様書無しさん2007/03/24(土) 19:15:15
非常に下らない言い争いを始めた厨房が出てきたんで、
この件へのレスはこれで最後にしておく。後はスルーする。

>>854
> >>850
> >で、どこが矛盾してるって？
>
> 最初は、
> > ルールは静的なデータ構造
> って発言してるのに
> >ルールは必ずしも静的にはならないとおも
> と突っ込んだ途端に
> >ルールが静的データ構造かどうかは、実は本質ではない
> って発言が翻ってるところかな。
> あ。。矛盾じゃなくって誤りを認めてないだけかw

あーチミチミ、チミは気付かんかったのだろうが、

>>825 にちゃんと書いたよ。

１．静的データ構造にしたいなら、
　　ルールエンジンなり宣言的な補助言語(スクリプト・インタープリタとか)
　　を導入すれば、実現できる。

２．(しかし)ルールが静的データ構造かどうかは、実は本質ではない。
　　単に「ルールは固有のアプリに強く依存した形で表現すべきではない」
　　というだけの設計上の気持ちに過ぎない。

２の後半部＝「ルールをアプリと密結合すべきではない」
これが、このｽﾚ >>240 以降の一貫したテーマ。
0861仕様書無しさん2007/03/24(土) 19:16:15
>>829
>現実に密結合でどうしようもなくﾃﾞｽﾏｰﾁ化したシステム(例えば>>240) 
>をどうしたら良いか

そんな政治や営業上の問題を、
技術で解決しようとするなよ・・・
08627792007/03/24(土) 19:19:34
>>857
粘着はしない。面倒だから(´・ω・`)
納得がいくまで議論したがり質かな？
でも、端から見ると粘着か。。。ORZ

亀田の相手のパンチなんかへろへろだよね。
0863仕様書無しさん2007/03/24(土) 19:21:05
あー。そー考えちゃうかー。

んー。どうでもいい。

客やﾃﾞｽﾏｰﾁ開発屋の立場からすると、
「これまで手数と人員をかけてきた旧型大規模システムが、
　PCサーバ数台上に簡単に再構築されちゃーたまらん」
って、考える人も居るかもなぁー。俺はどーでもいい。
0864仕様書無しさん2007/03/24(土) 19:27:49
>>240の密結合ってのは、要するに、
画面設計の下に、ビジネスロジックをぶらさげちゃったのが原因なんだよね。

画面は画面、ビジネスロジックはビジネスロジックで
ある程度分けて分析するべきなんだけど、

マイグレーション商売では
　・COBOLから業務フロー抽出
　・業務フローからJavaコード作成
なんつーのがメーカ標準だったりするから、
画面とロジックを分離するっつー肝心な事を
一切努力しない。
バカそのもの。いや判っててそうしてるんだよな。
でも、判っててそんなアフォな選択するのはやっぱアフォ。
0865仕様書無しさん2007/03/24(土) 19:34:05
> 静的データ構造にしたいなら、
> ルールエンジンなり宣言的な補助言語(スクリプト・インタープリタとか)
>　を導入すれば、実現できる。

SQL文なら、Java/C++上に「静的データ構造」の形で
各種ルールを書けますぜ、ダンナ。
StoredProcedureにしとけば、処理はDBサーバで行われるから処理負荷の分散もおｋ、
しかもSQLは、れっきとした宣言型言語ですぜ、ダンナ。

とか夜道で誘われて堕ちていく人も多そうな予感
0866仕様書無しさん2007/03/24(土) 19:37:09
>>864
>画面とロジックを分離するっつー肝心な事を 
>一切努力しない。

だって、そんなことすると、
「この設計書、全然意味ワカンネ」って言われて
没になってしまうんだもん・・・
0867仕様書無しさん2007/03/24(土) 19:40:21
なんか最近スレに勢いがあるな・・・
春だから？
0868仕様書無しさん2007/03/24(土) 19:42:46
今年度いっぱいで契約を切られたドカタが暴れていると聞いてとんできました。
0869仕様書無しさん2007/03/24(土) 19:45:27
画面とロジックがベッタリって、
例えばマイクロソフトあたりが好きなんだよなぁ。

Model/ViewをControlで分離するMVCの代わりに
Document-View アーキテクチャとか、
VisualStudioやVBAで、画面にちょこちょこコールバック書いて
サブルーチン数本作って、業務ツールいっちょあがり、とかｗ
0870仕様書無しさん2007/03/24(土) 19:46:01
>>868
低学歴乙
0871仕様書無しさん2007/03/24(土) 19:47:55
図星でしたか・・・。ごめんね。
0872仕様書無しさん2007/03/24(土) 19:49:50
いや、つか頭悪い奴が沸いてるなぁーって思っただけ。
ごめん、キミを侮辱するつもりはないんだ。
0873仕様書無しさん2007/03/24(土) 19:51:37
いえいえ侮辱されたつもりはありませんでしたが、四月からどうするんですか？
0874仕様書無しさん2007/03/24(土) 19:55:02
>>868
そういう奴って、
契約を切られて暇なものだから、
ついつい、皆が自分と同じように
２ｃｈに即レスするもんだと
勘違いしてしまうんだよね・・・
0875仕様書無しさん2007/03/24(土) 19:55:48
マイグレーションの対象になるような、COBOLとかの開発環境って
いったい今時どんなになってるんだろうね？
もう10年以上前に遠目に見た時は、なんか今のJ2EEと同じ雰囲気で
画面とロジックはそう密接には見えなかったけどｗ
10年位前になると、なんかVisualStudioもどきのGUIとか、CGIまで書ける環境ｗ
になっちゃってたんだよね。でもそんな時代のアプリなら、マイグレーションしないでしょう。

すると、すげぇ厨臭いCOBOL開発者の開発方法論ってのが
「画面指向設計」だったりするのかな？よくわかんね。
0876仕様書無しさん2007/03/24(土) 19:57:18
おまいら、今日は土曜日ですよ？
0877ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:28:32
オブジェクト指向分析/設計概論オブジェクト指向の大きなメリットの一つはその再利用性の高さにあります。
オブジェクト指向では以下のテクニックを用いて再 ...
(2)はオブジェクト指向による再利用。最下層の部分が再利用できるのは(1)の場合と同じですが、それに加えてプログラムの ...
0878ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:30:29
現在世間に蔓延しているオブジェクト指向の説明では、 むしろ納得しない方がまともだとさえ思えます。
「オブジェクト指向を使えば、生産性が飛躍的に上がり、 プログラムの見通しがよくなり、再利用性も高まる」と聞かされて、
「ホントかあ? ...
0879ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:31:07
Amazon.co.jp： オブジェクト指向における再利用のためのデザイン ...Amazon.co.jp：
オブジェクト指向における再利用のためのデザインパターン: 本:
エリック ガンマ,ラルフ ジョンソン,リチャード ヘルム,ジョン ブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,
本位田 真一,吉田 和樹 by エリック ...
0880仕様書無しさん2007/03/24(土) 21:31:17
お前、心の病気だろ。
0881ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:31:50
オブジェクト指向の現実ソフトウェアの開発を繰り返していくたびに、再利用できる部品がどんどん揃って、開発は楽になっていき
、開発コストも小さくなっていく、というのが、オブジェクト指向を薦める際の謳い文句であった。
だが現実には、ソフトウェアを部品として再利用 ...
0882ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:32:27
オブジェクト指向技術の基本概念オブジェクト指向では、今の比喩でいう仕事の実行主体のことをオブジェクトと呼んでいます。 ...
こうのように、継承の概念は、ソフトウェアの再利用性を確保する役目を果たし、生産性の向上に役立ちます。
標準的なクラス群を部品として用意しておき、 ...

0883ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 21:33:23
「オブジェクト指向　再利用」でぐぐるといっぱい出てくる
0884仕様書無しさん2007/03/24(土) 21:35:34
大丈夫か？
0885仕様書無しさん2007/03/24(土) 21:38:25
スレが伸びてると思ってみたら
キ○ガイ>>779が勝手なOO論で暴れてるだけwww
ここはいつから厨の隔離スレになったんだ。激ワロスwww

別スレ立ててそこでやれよ。
0886仕様書無しさん2007/03/24(土) 21:41:10
ココ電頭ダイジョブ？
0887仕様書無しさん2007/03/24(土) 21:43:32
>>電球
OOが再利用性に有効なのは明らかだから、別に暴れなくていい。
0888仕様書無しさん2007/03/24(土) 21:55:31
基地外は自分の頭が異常だとはわからない。だろ、ココ電
0889仕様書無しさん2007/03/24(土) 21:59:32
OO分かる奴、OOと相性いい奴はOOやれ、
OO分かんない奴、OOの有効性に懐疑的な奴は、OOやめとけ
でいいと思うんだけど、ことプロジェクトとなるとそういうわけにも
いかないんだよなぁ。全員が同じ手法でやってもらわなきゃめちゃく
ちゃになっちまう。なぁ、蛍光灯さん。
0890仕様書無しさん2007/03/24(土) 22:01:55
|　釣れますか？　　　　　　 　　　　　　　　 ,
＼　　　　　　　　　　　　 　 　 　 　 　 　 ,／ヽ
　 ￣∨￣￣￣￣￣￣￣ 　 　 　 　 ,／　　　ヽ
　　 ∧＿∧　 　 　 　 　 ∧∧　　,／ 　 　 　 　 ヽ
　　（　´∀｀） 　 　 　 　 (ﾟДﾟ,,),／　　　 　 　 　 　 ヽ
　　（　　　　）　　　　　　(|電　つ@　　 　 　 　 　 　 　 ヽ
　　｜ ｜　| 　 ＿＿_ ～|球　|　　　　　　　　　　　　　 　 ヽ
　　（_＿）＿）　|――|. 　∪∪　　　　 　 　 　 　 　 　 　 　 ヽ
　　￣￣￣￣￣￣￣￣￣￣￣￣|　　　　　　　　　　 　 　 　 ヽ
　　／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ　゜~ ~。゜　~ ~　~ ~~　~ ~~　~ ~~　~~　~~
　　⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡　～　～～　～～　～～　～　～
0891とりあえずこれまで出た未着手の設計寝た。あんまり興味は湧かないが2007/03/24(土) 22:01:59
>>768 基本的に返品はうけつけてないんですけどクレーマーな客の無理やり返品・返金にも対応してください
→爺曰く、「ビジネス例外」処理サーバで処理との事。ｗｗｗ

>>771 在庫の引きあてトランザクション処理も追加してください
>>809 在庫をストックする場所は複数で、在庫連動をマネージする仕組みも必要
→まず、現在の在庫管理システムの仕様を調査して、受注時に在庫引当処理しるｗ

>>774 そのクラスが直販をしているメーカ本社であったとすると 代理店が複数あった場合はどうなりますか？
→いみふめ
>>807 直販&&一次代理店&&取次店&&二次代理店&&紹介手数料支払いルール&&大量業務販売卸
→日本語でおｋ
>>777 直販の仕入れ価格と、代理店の仕切り価格がばらばらだとその管理も考慮しなくてはなりませんね。
>>778 一次代理店と取次ぎ店と二次代理店があった場合はもっと複雑になってきますね。どーしましょうか？
>>808 同一商品の仕入先は多数でその時の相場で変動する
→価格付けルールの問題かと。

>>810 輸入品のため、予約注文はインボイス日時の予想をするシミュレータが必要
→で、一体何を設計して欲しいんだ？シミュ？それともインボイス日時を含めた受注処理？

>>813 個人のお客でもある一定ロット数以上の注文ならば業務販売卸価格を適用できる
　　　　 この場合は個人客の監査を行い、問題が無ければ顧客リストに登録できる仕様
→価格付けルール＋顧客管理システムへ丸投げだろｗ
0892仕様書無しさん2007/03/24(土) 22:06:09
過去の資産を再利用するためには、
資産管理が重要です
まともな設計書が書かれていないデスマーチPJの資産を
再利用するなんてとてもとても
何を再利用したらいいか分かんないんだからね
0893仕様書無しさん2007/03/24(土) 22:07:25
こぴぺすりゃいいんじゃない
0894仕様書無しさん2007/03/24(土) 22:07:46
そこでだな、RDF資産管理という壷を薦めてもだな・・・・・・
0895仕様書無しさん2007/03/24(土) 22:09:20
芸がないな。以前のJavaスレのようなこみ上げてくるようなおかしさがないね。
0896仕様書無しさん2007/03/24(土) 22:14:09
こみあげる嘔吐感。
0897仕様書無しさん2007/03/24(土) 22:14:35
まぁコード感覚が研ぎ澄まされた理系サイエンティストの俺に言わせればだな、
「再利用」っつうのは
・古いアプリのコードを再利用する (例：COBOLのビジネスロジックを取り出す)
っつうしょうもない例ばっかじゃなくて、
・コピペで埋め尽くされたダメコードを書かなくても済むようにする
っつう差分プログラミング的側面が大きいんじゃないか、と。
そして、少しだけ新しい世代の差分プログラミングとして、
・アスペクト指向
・メタクラス・プログラミング
みたいなのをもっと広めてもいいんじゃないか、と。
0898仕様書無しさん2007/03/24(土) 22:15:26
>>889
全てを一つの手法に統一する必要はないだろ？
お前のPJでも全てがOOに統一とか、まずなってないよ。

たとえば、デバイスドライバやOSのAPIはどうよ？
結局、うまく切り分けて設計してるだけで
それに気づいてないのはお前の視野が狭いから。
0899仕様書無しさん2007/03/24(土) 22:15:26
>>895
お前はいつもの薬飲んで早く寝ろ。
眠れなかったらおさんスレで遊んでろ。
0900仕様書無しさん2007/03/24(土) 22:16:23
アスペクトがなぜ流行らないか疑問。
あの便利さは異常
09018972007/03/24(土) 22:16:39
あと、コンピュータ・サイエンス出身の若手に頑張ってもらうネタとして
・純関数型プログラミング
・ルールベース・エンジン
なんて笛や太鼓も活用したらえーじゃないか、と。
0902仕様書無しさん2007/03/24(土) 22:20:55
たかひろが、「一階述語論理」「一階述語論理」騒いで閉口した事があったけど、
要するに Haskellのように型推論を備えた純関数型言語を、
今で言うSOAのルール・エンジンみたいな形で使いたい、
ってそういう話だろ。な、たかひろ？
0903仕様書無しさん2007/03/24(土) 22:21:43
・純関数型プログラミング
・ルールベース・エンジン

これ使う層は被らなそうだな。。
だがビジネスロジックはオブジェクト指向より
関数型プログラミングの方が適合しそうな気もする。
0904仕様書無しさん2007/03/24(土) 22:21:45
日本語でおｋ
0905仕様書無しさん2007/03/24(土) 22:24:12
> だがビジネスロジックはオブジェクト指向より
> 関数型プログラミングの方が適合しそうな気もする。

CommonLispでアプリサーバ書いてる某苫※地氏の所へ
生贄お一人様ご案内～
0906仕様書無しさん2007/03/24(土) 22:25:12
> だがビジネスロジックはオブジェクト指向より
> 関数型プログラミングの方が適合しそうな気もする。

恵比寿のO社へ一名様ご案内～ｗ
0907仕様書無しさん2007/03/24(土) 22:30:56
あ、やっぱ誰でも思い付くのか。。
0908仕様書無しさん2007/03/24(土) 22:32:21
個人的にOOPLの一番の恩恵はスコープがもう一段増えた事だったり
0909仕様書無しさん2007/03/24(土) 22:37:23
２段じゃないの？
0910仕様書無しさん2007/03/24(土) 23:04:49
オブジェクト指向で、構造体が必要に感じるようではまだまだｗ
0911仕様書無しさん2007/03/24(土) 23:07:56
>>909 クラスとネームスペース/パッケージ？
0912仕様書無しさん2007/03/24(土) 23:08:51
言語によっちゃ、内部クラスってのもあるな
0913仕様書無しさん2007/03/24(土) 23:10:18
あ、あー、そこのチミチミ
チミが埋め立てにかかっているのは百も承知だが
新しいスレにはこのスレのネタをふりまきまくる予定だ
って事もお忘れなくｗ
0914仕様書無しさん2007/03/24(土) 23:10:49
オブジェクト＝＝インスタンスではまだまだぜんぜんｗ
0915仕様書無しさん2007/03/24(土) 23:11:47







　　　　　　　　　　　　注意：池沼が会話にならない自作自演を続行中です






0916仕様書無しさん2007/03/24(土) 23:14:15
凝集度は強い方がいい。結合度は弱い方がいい。糞レスは無視しした方がいい。
0917仕様書無しさん2007/03/24(土) 23:15:45
関数＝＝メソッドではほど遠いｗ
0918ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:21:48
某企業の基幹システムの保守をやってますが
メンテナンス性が一番悪いのがＯＯちゅが書いたやつだけど
どうしてくれる？
古参の主任もお手上げだ。
なぜなら全部書き直さないとまともにならないからあきらめてる。
とにかく可読性が悪い。
俺だから読めるけど、前任者と前々任者はお手上げだった。
ノイローゼになってやめたようだ。
0919仕様書無しさん2007/03/24(土) 23:24:02
推奨ワード：◆tIS/.aX84
0920仕様書無しさん2007/03/24(土) 23:25:11
>>918
あんたこの前メンテナンス性の良し悪しはコード書いた奴に拠るっていってたじゃないの。
OOに責任転嫁するなよ。
0921仕様書無しさん2007/03/24(土) 23:26:40
そもそもが自己愛性人格障害の典型的症状に近いので、
プライドは高いために自分の無能さに目を向けることができずに、
他者を批判することでフラストレーションを解消しようとしている
だけと思われ。
まとまった業績のひとつも上げれば頭も冷えるのだが、
焦りがあるので長期的な取組みができず、目先の目新しそうなもの
（で、ちょっとよさげなもの）につい飛びついてしまう。
そういう香具師は、トイ・プログラムでもいいから、オブジェクト指向設計
でプログラムを一本インプリメントしてみて、プチ達成感でも味わうのが
よろしいかと。
0922仕様書無しさん2007/03/24(土) 23:27:01
汎化＝＝汎用のああ勘違いｗ
0923仕様書無しさん2007/03/24(土) 23:28:29
>>918 あー、それ書いたの俺だ。すまん、まだ駆け出しだったもんで。
今じゃばっちり理解したから、今度からはうまく作るよ。ゴメンな。
0924仕様書無しさん2007/03/24(土) 23:34:25
Javaでさ、クラスメソッドにfinalつけてる奴どんだけいる。
これを正しく書ける/書けない/そもそも意味が分からないで
とりあえず、OO意識度の大雑把な３段階評価はできるぜ。
0925仕様書無しさん2007/03/24(土) 23:35:26
>>918
>なぜなら全部書き直さないとまともにならないからあきらめてる。 

あきらめて済んでしまうようなメンテなら
やらなければ良いんじゃないの？
0926ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:40:03
俺がコード書くならあんなところでＯＯ使わないね　こんなのだ

１）在庫状況
２）入荷予定
３）発注
４）商品登録
＞

で、在庫状況クラス　入荷予定クラス　発注クラス　商品登録クラスをcommandパターンで作って
インスタンス作っててキューにプッシュバックしてエクゼキューターに渡すと
各インスタンスが自分の文字列を表示して上の画面が出てきて、選択すると各インスタンスが
結合されたビジネスロジックを呼び出して処理するというものだ。

構造化だけなら２０００行、一本で終わるのに、クラスを１０も２０も作ってがばかかあほかと
0927ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:41:30
>>924
オセロのことならあれは「準定数」だ。定数ではない。
拡張したとき変更される可能性があるのでああした。
0928仕様書無しさん2007/03/24(土) 23:46:23
iアプリのリバーシってやっぱこういうコードになってるんだろうなぁ。
0929ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:47:38
構造化だけのと比べて

・工数がかかる
・メンテナンス性が悪い
・意外かもしれないが、余計な結合がいっぱいできていて、一部の変更だけを行うのが非常に困難。
　ピンポイントの仕様変更がしづらい。
0930仕様書無しさん2007/03/24(土) 23:48:05
>>926
>構造化だけなら２０００行、一本で終わるのに

アホか？www
なら書き直せよ。
0931ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:50:51
Ｏｔｈｅｌｌｏ２.javaをＯｔｈｅｌｌｏ.javaにオーバーライドして画面デザインを変更しているではないか。
initSystem()でやってる。
ソース嫁
0932ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:51:34
その画面は一部だよ。
画面数は５０くらいある。
手に負えん
0933仕様書無しさん2007/03/24(土) 23:52:17
>>929
なんでもかんでもOOを適用しちゃだめだって話だな。
ファウラーもむやみにトランザクションスクリプトを切り捨てちゃだめだよって
言ってるしな。
0934仕様書無しさん2007/03/24(土) 23:53:10
>>927
定数じゃない。定数につける奴はいっぱいいるが、メソッドや
クラスにfinalちゃんとつけられる奴はあまり見かけない。
0935仕様書無しさん2007/03/24(土) 23:54:01
構造体＋関数＝＝クラスの単純理解ｗ
0936仕様書無しさん2007/03/24(土) 23:54:51
>>934
つcheckstyle
0937仕様書無しさん2007/03/24(土) 23:56:08
サブクラスに上書きされないためにfinal付けるんだろ。
0938ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:56:44
static finalだろ　
使うときは使うさ
0939仕様書無しさん2007/03/24(土) 23:57:11
アホかコーディング規則じゃなくて、設計上の観点からっつうこと。
0940仕様書無しさん2007/03/24(土) 23:58:43
>>938 なんでstaticがセットになってんだよ、ダメだこいつ...
0941仕様書無しさん2007/03/24(土) 23:59:04
クラス＋ポリモーフィズム＝＝オブジェクト指向な安直さｗ
0942ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/24(土) 23:59:04
コンパイラオプションで無理やりfinalにオーバーライドできなかったっけ？
そんなことした覚えがあるが・・・・
0943仕様書無しさん2007/03/25(日) 00:00:05
>>932
なにそれ？

あのねー、結局、全体では
そのOO厨とやらのコードは何行ぐらいで、
それを tIS/.aX84 が書くと何行ぐらいになるのか言わないと
tIS/.aX84 の主張には何の正当性もないことになるだろ・・・
0944ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/25(日) 00:00:08
定数の話だったろ
final厨はfinal以外知らないみたいだねえ
0945ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/25(日) 00:02:56
ＯＯにしたせいで５－１０倍くらいに増えたかなあ。
0946仕様書無しさん2007/03/25(日) 00:04:27
950踏んだ奴は次スレよろ。

途中あった1の書き込みもテンプレに追加しとけ。
0947仕様書無しさん2007/03/25(日) 00:05:03
クラス実装＝＝オブジェクト指向設計な思い違いｗ
0948仕様書無しさん2007/03/25(日) 00:05:33
>>939
checkstyle常用してなきゃ、まず使ってみれ。
メソッドや引数は基本final
そうすりゃオーバライド出来るものは設計上オーバライドさせたいものに限定される。
0949仕様書無しさん2007/03/25(日) 00:05:59
>>946 もうあるぞ、
http://pc11.2ch.net/test/read.cgi/prog/1174746731/
0950ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/25(日) 00:08:17
おまいがオーバーライドさせたくないかもしれんが俺はオーバーライドしたいんだよ
どうしてくれるんだよ？
0951仕様書無しさん2007/03/25(日) 00:11:00
電球よ、とにかくおまぃは学習が足らん
突っ込まれまくりなんだから自覚したほうが今後のおまぃ自身のため
0952仕様書無しさん2007/03/25(日) 00:12:17
>>950
strutsのソースですら、そういうときあるよな。
アスペクトでも貼っとけ。
0953仕様書無しさん2007/03/25(日) 00:13:38
Javaの第一人者 Joshua Blochの言葉より、
「継承のために設計し、文書化する。そうでなければ継承を禁止する」こと。

継承はプログラムを複雑化する。継承しないですむのであればしないにこ
したことはないんだよ。
0954仕様書無しさん2007/03/25(日) 00:16:50

ID:ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84
を基地外と認定いたしました。
0955仕様書無しさん2007/03/25(日) 00:24:16
【COBOL者用：COBOL→Javaマイグレーションの設計上の問題点】
・密結合によりﾃﾞｽﾏ化したシステムの事例

148 名前：仕様書無しさん[] 投稿日：2007/03/19(月) 22:08:24
ビジネスロジックに対する正しい対処法：

そういうところに関わらない仕事で食っていく。
ドカタ仕事はドカタに投げる。ドカタはそれが技術と思って喜んで作っては捨て作っては捨てを
繰り返す。無限にデスマを続けながら、俺は先端技術者だぜｲｪｰｲと喜ばせておく。

やっすい単金で。
0956仕様書無しさん2007/03/25(日) 00:25:17
OOが嫌な奴はやめておけばいい。それだけのこと。
ただし、電球のように頭から否定する奴は
自分の視野が狭いか見えてないことに気づいた方がいい
全てを理解した上で否定するなら良い意見となるが、
そうでないならガキのわがままと変わらん。
0957仕様書無しさん2007/03/25(日) 00:27:10
>>950 そりゃ設計が悪いからまず設計をみなおせ。
アドホックな解決はそのうち悪い結果を引き起こす。
0958仕様書無しさん2007/03/25(日) 00:33:08
アドホックってなんだ？
アド町っくの親戚か？
0959仕様書無しさん2007/03/25(日) 00:33:28
OOPがある程度冗長になるのは仕方ない
将来的な拡張を見越して作ってるんだから。
しかしプログラムはシンプルなほうが良い。
じゃあどうすればいいんだろうか。
0960仕様書無しさん2007/03/25(日) 00:35:20
OOを否定するつもりは毛頭ないんだけど
細かい部分の理解の仕方や度合いに
拘りすぎるのは本末転倒なんだよな。

どうしても困る部分があるなら
それこそ、要件定義のつもりで
擦り合わせしとけばいいんじゃないか。
0961仕様書無しさん2007/03/25(日) 00:35:57
将来的な拡張を見越してつくるのではなく、拡張を阻害しないようにつくる。
すなわちYAGNI
0962仕様書無しさん2007/03/25(日) 00:36:11
OOPは精鋭が生産性を高めるためのものであって
馬鹿のためのものではない。
的確にOOPで書かれたソースを読めないというのであれば
自分の不勉強を呪えと思うけど。
0963仕様書無しさん2007/03/25(日) 00:37:47
>>959　答えはココ電球になることです。
0964仕様書無しさん2007/03/25(日) 00:40:07
>>959
その時点で不要なものは作らないこと。
そんなものは将来の拡張時の邪魔になるだけだからな。
096569式オサンクローン ◆4E1yVnBRhg 2007/03/25(日) 00:41:06
javaのapiはOOでいいよ。おまいらのシステムは
代入だけでいいんだろ?OOいらねえじゃんか
0966仕様書無しさん2007/03/25(日) 00:41:18
将来的な拡張とか言ってる奴に限って、将来の必要性が何なのかを
充分に理解しないまま設計しているもんだ。
0967仕様書無しさん2007/03/25(日) 00:41:26
>>962
>OOPは精鋭が生産性を高めるためのもの
間違いです。正しくは
OOPはんぽぽんでも生産性を高められるようにするためもの
0968仕様書無しさん2007/03/25(日) 00:41:36
いつまで独り言言ってんだお前







0969仕様書無しさん2007/03/25(日) 00:42:50
具体性の無い話を延々続けるのは、
具体的な話を知らないからだって
じっちゃんのお医者がゆってた
0970仕様書無しさん2007/03/25(日) 00:47:17
>>969 誤診をいっぱーい、いっぱーいしたじっちゃんの話をしてもな
何人をじっちゃんは氏に追いやったんだよ
0971※未承諾広告2007/03/25(日) 00:47:51
ここで視聴者のみなさんに素敵なお知らせがあります。

ただいま、この大願成就のオブジェクト壷、
通常価格￥１０、０００，０００，０００の所を
先着５名様になーんと
　　　　　　￥１０、０００，０００
という特別価格で提供しちゃいます。

しかも！
通常なら別売りの
・隙間アダプター　・・・タンス裏のホコリを取るのに便利ですね！
・高枝切バサミ・ストラテジー　・・・コウルサい上司を簡単に切れますよ。便利ですねぇ！
・収納コンテナー ・・・使わなくなった壷をスマートに格納できますよ。いいですね！
の三点セットで、なんと
　　　　　　　￥１０，０００，０００
いまなら送料無料です。ご注文は画面下側のURLまでどうぞー

0972仕様書無しさん2007/03/25(日) 00:48:15
>>970
待て、あわてるな。
じっちゃんのお医者さんであって、
じっちゃんは公務員だ
097369式オサンクローン ◆4E1yVnBRhg 2007/03/25(日) 00:48:32
議論の核がないからな。要件定義はできない馬鹿どもしかいないっぅことかな。
んぽぽんだから無理はない。
0974仕様書無しさん2007/03/25(日) 00:50:22
カプセル化は使った方がいい。だが、継承とポリモーフィズムは
使わないで済むのであれば、使わないにこしたことはない。
つまり、カプセル化は良心で、継承は傘で、ポリモーフィズムは
クレジットカードだ。傘とカードは有事の際にはとても便利だ。
09759602007/03/25(日) 00:51:24
>>962
俺も不勉強な人間は勉強しなければならないという考えはある。

しかし、お前のPJはほったらかしのやりっぱなしな印象を受けるなw
開発メンバーの力量にあわせたレベルでの調整はしないのか？

実際、そういう事を適切に選択しないとグダグダになりそうだけどな。
0976仕様書無しさん2007/03/25(日) 00:54:42
　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　次スレまだ～？
　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　|　　ﾜｶﾗﾝﾁﾝ祭り中　 |／
0977仕様書無しさん2007/03/25(日) 01:06:34
>>974
ｗｗｗ
カプセル化は作法なので重要度は低い。
継承とポリモーフィスムはアーキテクチャなので重要。
使わないで済むとかどうかの問題ではないのです。
0978仕様書無しさん2007/03/25(日) 01:11:30
↑こういう奴が意味も無く継承ツリーを深くする。
0979仕様書無しさん2007/03/25(日) 01:12:17
>>978
意味が無いように見えるだけで
意味はある
0980ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/25(日) 01:13:42
不勉強じゃなくて不信心の間違いだろ。
0981仕様書無しさん2007/03/25(日) 01:13:49
オレオレ設計乙
0982ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. 2007/03/25(日) 01:16:23
反論するときは経典を持ち出してくるしな。
宗教論をその宗教に興味ない人間に吹っかけても無意味だとなぜ気づかんのだ？
大事なのは現実の生産性や論理、実証、体験であるのに
「論拠主義」という平安時代の古臭い論法で考えてる。
0983仕様書無しさん2007/03/25(日) 01:16:57
もういいからお前はCOBOLでも組んでてくれ
0984仕様書無しさん2007/03/25(日) 01:19:45
電球がここで悦に浸ったとしてもそこには何も残らない
ただ電球がOOは無意味と確信犯として言いふらし、
有識者に冷笑されるだけだ
0985仕様書無しさん2007/03/25(日) 01:24:46
>>979 「意味が無いように見える」って時点でダメだろ。
そんなオナニー設計強制すんなよ。
継承ツリーの深さはエラー率の上昇と関係あんだぞ。
0986仕様書無しさん2007/03/25(日) 01:25:45
OOPの意味はオブジェクト同士の繋がりにあるんだろ？
0987仕様書無しさん2007/03/25(日) 01:25:54
じっちゃん！やっとFF12のヤズマット倒したよ！
0988仕様書無しさん2007/03/25(日) 01:28:37
継承が深くなると、仕様変更に弱くなる。
0989仕様書無しさん2007/03/25(日) 01:29:03
>>979
OO厨に必要なのは話し合いと協調性
厨的に言うと、継承ひとつとっても
ポリシーの適用の違いで継承の仕方も変わってくるだろ。

開発してればわかると思うが万能なものはないし、
万能に近づけたつもりのものは無能なもの(意味がないという意味)に
なったいたりする。

オセロでも将棋でも動くプログラムなんて、まさにそっちの部類だな。

OO厨に言いたい事は
「OOを知って感動してるのは、もう伝わったから早く正気に戻れ」

これだけw
0990仕様書無しさん2007/03/25(日) 01:30:32
結論
オブジェクト指向でこんだけグデングデンだと、
ＳＯＡＰ－ＲＰＣ基い、ワールドワイドウェッブなんて夢のまた夢てことでおＫですか？
0991仕様書無しさん2007/03/25(日) 01:31:49
おＫ
0992仕様書無しさん2007/03/25(日) 01:34:08
たしかに
　　グデンクデン
　だが
そ　こから
　　読み取れ　る
示唆もある
。
0993仕様書無しさん2007/03/25(日) 01:34:33
ソフトの世界で誰でも一定品質なんてのも夢のまた夢
0994仕様書無しさん2007/03/25(日) 01:36:09
>>993 電球いるかぎり㍉
0995仕様書無しさん2007/03/25(日) 01:37:42





　　　　　　　　まぁ１０年前からOOバリバリでWebアプリ作り散らかして

余力でORマッピング付きのJ2EEもどきやら、
XMLもどき使ったWebサービスでPerl-Java連携やってたおいらにゃ、

　　　　　　　　おまいらひよっこはとてもカワイイよ。

　　　　　　　　もっと精進して、対等に渡り合える存在になってくれ。

　　　　　　　　アディオスアミーゴ
0996仕様書無しさん2007/03/25(日) 01:51:24
>>995
似非オブジェクト指向で石ころゴロゴロけつまずくタイプですなwww
0997仕様書無しさん2007/03/25(日) 02:04:19
はぁ？
おまえの発言っていみふめ。
0998仕様書無しさん2007/03/25(日) 02:23:04
>>982
「OOを何故理解できない？」というスレで
「OOは無意味」と唱えることが無意味だと何故解らないの？
0999仕様書無しさん2007/03/25(日) 02:26:12
ああ、文末は

なぜ気づかんのだ？

にすべきだったか
1000仕様書無しさん2007/03/25(日) 02:27:14
石ころゴロゴロけつまずく
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。