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

【前スレ】

【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

さあ、張り切っていきましょう。

張り切ったら負けかなと思っている。

>>1 乙

　　　　　　　　　｢＼ 　　　　__ 　　　__
　 　　　　　　　│ﾄ､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__ルく_/Ｔ'┬_ヒｽ⊥ｲ ＼ﾉ
　 　 　　　　　　　　ヽ√ ＼丿 ヽ/

>>1のせいで花粉症になった

【参考ページ】
はとても偏向しているね

新スレもまたJava厨がぞろぞろ沸いてくるんだろうな。

オブジェクト指向の話
↓
たとえ話
↓
罵り合い
↓
Java厨の出現

またループを起こすんだろ、もまぃらは
またStrutsの話なんか持ち出すんだろ、もまぃらは

フレームワークについてここで語るのはスレ違いだからな。

アーキテクトを募集してますよ
http://pc11.2ch.net/test/read.cgi/prog/1173263530/225-241

ＯＯ厨 弟w

質問だが、一般的に永続エンティティと呼ばれるドメインクラスが
インタフェース持つ場合ってどんな場合がある？

全部のクラスが必ずインタフェース実装するのは馬鹿らしいし。

>>12
質問の意図が分からん。説明能力に欠けるお前に設計は無理。あきらめろ。

例えばスレッドがあって、レスを1対多でもっている。

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

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

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

どっちがいいかって話。
�@と�Aの区別の基準が知りたい。

>>14
んなもん、適用するデザインパターンで変わってくる。問題をどう解決したいかが重要。

質問内容としてはインタフェースの切り方をどうすればいいかになるのかな。

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

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

>>12と>>14が同内容とは思えない・・・
説明能力に欠ける奴は、理解能力にも欠ける可能性が高く、
レスしている人たちの労力が徒労に終わる可能性も高い・・・

インタフェースを出すんじゃなくて、インタフェースから設計していくわけだが。
あとオブジェクト指向だろうとそうじゃなかろうと、
手抜きの設計すると後で自分が痛い目に合うのはもはや常識。

インターフェースだらけかよ

ではオブジェクト指向ができないあなた。
なぜ理解できないのでしょうか？

　　　　　　 _,..-――-:..、　　　　⌒⌒
　　　　　／.:;;;;;;;;;;;;;;;;;;;;;::.＼　　　　　　^^
　　　　/ .::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::..ヽ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　:::::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　　　_,,,......,,__
　　 :::::;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;::::／_~　,,...:::＿::;; ~"'ヽ
　　　　 :::::::;;;;;;;;;;;;;;;;;;;;;;;;;;;:::::::　(,, '"ヾヽ　 i|i　//^''ヽ,,)　　　　どうすれば、この先生きのこれるのか・・・。
　　　　　　::::::::::::::::::::::::::::　　　 　^ :'⌒i　　　 i⌒"
　　　　　　　　::::::::::::　　　　　　　 　 .（|　 ,;;;;;;|
　　　　　　　　　　　　　　　　　　　　　(ﾉ...,;;;;;;|
-―'――ー'''‐'ー'''―‐'―''''―‐'''ー'''.|　 ,;;;;;;|'-''――'｀'
　,,　''''　　｀、　｀´'､､,　　　'''　　　　'''　ヽ ＿ノ　､､,
　　　　,,,　　　''　　,,　　 ''''' 　　　　　''''' U"U 　,,,,

ご飯をたべれ

ご飯っすかｗ

インタフェース中心で考えると、DOA的に抽出したデータの、
○○を取得するみたいなアクセサメソッドまでインタフェースにしなきゃならなくないですか？

私はデータベースに保存する情報を中心にモデルを構築するのですが、
インタフェース中心の方はそれらの情報も全てインタフェースとして見るのですか？

ご飯食べてきましたｗ

>>24
インタフェースと実装に分けるなら、そうするしかあるまい。
EJB2.xまでのEntity Beanがそうであったように。

EJB 使わないんだったら別にいいんじゃね？ そこまで頑なにならなくても。
インタフェースって必要があるから使うんだろ？ インターフェースありき
じゃねえべ。

1000 名前：仕様書無しさん[age] 投稿日：2007/03/12(月) 23:33:27
1000ならみんなOOD/Pが理解できるようになる！


前スレ１０００サンクス

>>27
元の質問は、インタフェース中心の場合はどうするのか？
じゃないのか？

このスレ、本当に日本語が不自由な奴が多い

はぁ？

○○中心って、全部○○って意味か。なるほど。

アクセサメソッドはクラス内での実装の仕方を隠蔽するためにあるのよ。
っつーかね、会社の連中もそうなんだがなんで一から十まで全部に適用しようとするかね。
頭が固すぎる。有効なところには使えばいいし、面倒なら省いちゃえばいいし、そんなん臨機応変に自分で決められんのかね。

臨機応変ができないから未だにOO厨は必死なんだろ

あるときはインタフェースにして、あるときはインタフェースにしないなんて、
明確な基準がなければバラバラな設計になっちゃいますよね？

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

手順や基準を示してきっちりステップ数、バグ数管理しなきゃ品質の高いシステム開発はできないでしょ。

そんな明確な基準があるとこなんかねーだろ

ステップ数(笑)

「ステップ数」で一体何を管理するんだね？

>>34からは仕事請けたくねぇな

おまいはソフトウェアの品質管理とかやったことない下流ＰＧですか？
ステップ数、バグ数で定量的に品質は分かるんですよ。

Ｊａｖａで実行数これくらい書いたら、過去の数値からこれくらいバグが出るという目安ができ、
それに満たないなら品質が悪いということで試験やり直し。当然でしょｗ

バグが出る数の基準があるとかはじめて知ったよ

Agitatorとかの結構最近の試験ツールとかも行数カウントとかあったけどなぁ
まぁステップ数の多いクラス、分岐の多いコードほどバグのリスクが高いということだよ。
これはOOだとかJavaだとかに関係なくプログラム全般にいえることでしょ。

マ板じゃ生産性や品質評価は荒れるしスレ違いなのでこの辺で。
以後、OOに関する話題をどうぞ。

ステップ数があてにならないのは、処理の複雑度、入出力条件、ＰＧの技量、知識、設計
等に左右されるところが大きいからだ。

>>43
そんなことは自分だってJavaでプログラム書いてるから１００も承知ですよ。
けどね、対外的に品質報告する際にはやっぱ数字の力はすごいわけで。
日本の企業でプログラム書いてれば分かるでしょ？
そもそも、管理職とかの老人は数字でしか品質を見ない。
Junitのテストケース見せていい品質でしょ？とはいえない。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity

>>42
別に構わないんじゃないか？
OOでも荒れるときは荒れるし。
生産性や品質を抜きにして語るのも違う気がするしな。

品質を計るのになんでステップ数がいるのかさっぱりわからん。
テスト結果だけじゃだめなのか？　あぁ、さてはテスト仕様書も
テストデータの作成も外だしか？　それで、テスト時のバグ件数
との比率で結果の妥当性を見ようってのか？　そりゃ結局管理し
てないに等しいな。おじゃまもんといっしょじゃねぇか。

管理が目的ではなくて報告が目的なのだと思われ

>>46
日本語でおk

なんか最近偉い人爺さん方が「見えるか〜見えるか〜」って喚いてるもんな

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

1000 ：仕様書無しさん ：2007/03/12(月) 23:33:27
1000ならみんなOOD/Pが理解できるようになる！

じゃあそろそろオブジェクト指向の話をするんだよな？

このバグちょっと見てくれって言われる事よくあるが、ステップ数押さえて細切れ
にしても組み合わせが悪くてバグになってる時とか却って切り分けに一苦労するよな。
他への影響考えると直すに直せなくて結局小さな専用クラスをたくさん作らされる
羽目になったり。
ちゃんと設計して最初から無理な適用は諦めればいいのに。

コードも読めない、設計も理解できない層を納得させるには、
前時代的観点での数字が有効なのは間違いない。

こちらもそれをうまく利用していい場面というものが
あるのではないかと思う。

まずは数字とオブジェクト指向の関連性を明確にしろよ
それができない限りスレ違い
話はそれからだ

>>42
もうちょっと学習しておいで

みすった
55は>>45

OOPは自己学習でちょっとやってみたことがある程度の、実務未経験者なんだが、
まず初めに思ったのが「クラスって関数と変わらねーんじゃね？」てとこ。
ま、ぶっちゃけクラスと関数じゃ出来ることは多分同じなんだろうけど、
関数を使った従来型のプロシージャ型プログラミングとOOPの違いは以下のようなもんだと勝手に思ってる。


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

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


こんな理解でおk？

変わるところ（仕様変更／機能追加がありそうなところ）と、変わらない
ところを切り分け、その間のやりとり(I/F)を決める。

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

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

クラスメソッドを関数とみるなら逝ってよし。
クラスをその分野に関して機能提供する処理担当とみるなら正解。

>>14
おそれすだけど。
掲示板をどこまでサポートするかによる。

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

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

なんでOOPを含めちゃうかな？
前の設計話のほうが馬鹿入ってこなくて良かったのに。
ミクロな話ばっかりだとつまらん。

純粋なOO設計だけって話題はあり得るのか？
設計は実装のためにあるんだろ。実装にシームレスに繋がらないクラス設計されてもな。

しかも、クラスやメソッドという単語はむしろOO一般の設計の話で、言語の話ではないと思うぞ。

>>61はプログラム組めないなんちゃってSE君だろw

プログラムなら中国人でもインドの山奥の人でも組める。

つまりそんなスキルすら>>61はもってないと

1オブジェクト指向プログラミング言語もできない奴がOO設計など到底無理。

>>63
で、また設計と製造は別物議論が繰り返すと。

まあ、せっかく勉強したJAVAなり何なりと、なんちゃってオブジェクト指向が高尚だと思いたいのは、自己陶酔だと思うけど。

Strutsはくそ

別にStrutsはOOPでも何でも無いし。
だからPを含めるのは嫌なんだよ。馬鹿避けできないから。

DIはくそ

Springは糞だな。

>>68 >>70-71
…あー、なんとなく >>69 の気持ちが理解できたような気がする。

自演乙

>>73
莫迦の定番乙。

お前ら喧嘩すんな、まじめにやれよ

インスタンス、クラス、オブジェクトの違い。

インスタンスはメモリ上のオブジェクト
クラスはインスタンスの型
オブジェクトは物だ！

Strutsは意味ない

たしか支柱っ意味じゃなかったっけ？

strutsはリクエストと処理をコマンドパターンで統一的に扱えるようにし、
コマンドでフォワード先画面を決められるようにしたフレームワークだ。
内部はOOで作られているようだが所詮はシステムの画面遷移の担い手に過ぎんよ。

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

OOの力↓

public class うんこ{

private String 排泄物;

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

}

}



(ﾟдﾟ)

別に

なんでstringが爆発するんだ

アホだから

しかも排泄物はヌルポだろーに

そもそも、うんこをモデリングしなきゃならんドメインがわからない。

たぶん、、、OO理解できないﾔｼって、同じこと何回も書いて、「ステップ数＆工数」の水増ししてる。

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

まぁ、所詮COBOLerの考えることなので、あんまりツッコまないでねｗ

何を言いたいのかさっぱりわからんが、DAOパターンの方がよっぽどまし。

ま、素人はER図からやってみたほうが良いよ
あれは純粋にデータだけを扱えばいいし、
最近はER図からテーブル作ってくれるツールもある

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

SpringやらStrutsやらの話がしたい奴は
別スレ立ててそっちでやれ

>>90は度量の小さい奴だなぁ

>>91
おまぃは業務分割できない奴だなぁ

>>87

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

あと、関連も一度に読み込むならリソースの無駄だからそこはレイジーロードで
必要に応じてフィールドがnullなら読み込むとかにしとけばOKかね。

このスレみて今日試しにオブジェクト指向設計してみたんだが
やっぱり最初は扱うドメイン領域の概念やデータをクラスとして抽出じゃね？

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

で、さらに詳細に属性、メソッドの戻り値とパラメータを決めてクラス図を描く。
ただ、この方法だとデザインパターンを適用したくなったり、IF使ってポリモフィズムとかやりたくなるのが難点だな。
後々こいつらをDBに入れること考えちまうとあんまり継承とか使いたくないし。

>>1のテンプレが頭悪そうでたまらない

俺はそうは思わない

C++だと聞いてクラス図を記述していた俺。
Cでやると聞いてへこんだ俺。
いいよ、確定申告のときのおねーさんが超かわいかったから。

>>96
スレの最初から居る古代人ですか

ちがいます

別にどうでもいいです

>>93
σ（・_・）、COBOLerだから、難しい言葉は理解できません＾＾；；；
でもでも、間違っても>>87の�Bの公開は、静的にしませぬ。
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ﾀｿが言う「テーブルモジュール」ってこうゆうこと？？？

>>101 外部参照テーブルの読み込みはどうすんだよ

viewにすればいいんじゃね？
あくまでgetterの話だから

setterになるとcommitやら排他制御やら
色々ややこしいことになるけどな

1対多とか多対多とか破綻しないか？

>>104
別に。

いっぺんに沢山のレコード読むときどーすんだ、各オブシェクトが格納された
List型で返すのか？そのList型のプロパティーはどれが持つんだ？
Daoパターンの方がきれいじゃね？

>>106
勉強して出直せ。それ以上のレスは恥を晒すだけだ。

↑なんだよ、こいつ。そんなヒステリーおこさずに説明してくれよ。

力量不足な連中が集まるスレはここですか？

ここじゃないです。

ここだと聞いてやってきたのですが間違いないようですね

「不勉強ですが勉強したくないのでピンポイントで教えてください」
なんて質問には親切を装ったウソの回答がふさわしいので
筆の立つウソツキの登場を強く望むものである

抽象で語れず、すぐ具象な話になってしまう。

2chシステムをOOで設計すると、俺らは「名無しさん」で抽象化される。

>>113 抽象で語ってみれ。できるもんなら。

ああ、あれをそれしといて。

メソッドは天使のように優しく設計してくれ。

抽象論で語る奴ばかりが集まると全然物事が進まないねぇ。
話かみ合わないし。

名前は属性に過ぎない

遺憾ながらこの世では属性といえども名前をもっておる

>>115
一口にOOといっても、流儀がいろいろあるけど、主流はやはりUP派閥かねぃ。

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

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

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

ググれ

>>121
UPって何? Unified Process? つか日本語でおk

開発方法論の話がしたい奴は
別スレ立ててそっちでやれ

>>104
「１対多とか多対多」は、普通にDataTableとかRecordsetで処理すればいいでしょ？
設計思想とか顧客の要求によって、それぞれだと思うけど、少なくとも入力系PGなら
「１：１」のアクセスが圧倒的に多いと思いまつ。
例えば、顧客マスタの登録画面で、担当者コードを入力してHitしたらその担当者名を表示、
未登録ならエラーを表示して再入力させるとか…。

まぁ、最近の設計は、コンボボックスから選択っていうのが一般的なのかなぁ？？？
それなら、こんなｼｮﾎﾞいクラスｲﾗﾈなんだけどねｗ

>>121 評判聞くのがお前の抽象論かよwww

>>125って・・・

もまぃらはオブジェクト指向の何が理解できないんだ？
具体的に言ってみろ

いやだ

>>126
同じOOと呼ばれていてもプロテスタントとカトリック、モルモン教ぐらい違うものがある、という認識ない？

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

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

>>130
それUPとかアジャイル関係ねーじゃん。

>>131 キリンさんが好きれす。でも、ぞうさんのほうがもっと好きれすｗ

>130
なんか分かったような分からんような話だが、多分その通りなんだろう。
さすが抽象論だ。で、どうすればいいんだ? 立ち位置と教養を合わせろっ
てことか？

Java厨の自己陶酔なレスを排除すればおｋ

アホか、そんなわがまま通るか、何様だよ。
開発方法論の話がしたけりゃ別スレ立てろ。

OOを特別なものと考えると
うまく行かないだろうな。
所詮は人間様が使う道具なんだから
それを忘れなければうまくいくだろう。

オブジェクト指向は詳細設計の技術である。
機能設計にオブジェクト指向は使えない。
機能設計の画面設計に必要なのは、作法とセンスである。DB設計に必要なのは正規化と経験である。
開発手法にオブジェクト指向は使えない。
プロジェクト運営で必要なのは、経験と分析と実行力と、優秀な営業である。

>>137 画面設計は外部設計ですが？　UMLはオブジェクト使わないのか？

>>133
OOといって違う概念の違う話をしているから、人によって理解している／
理解していないの基準が違う。

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

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

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

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

UMLは一部を除き詳細設計のための資料である。
ユースケース図とシーケンス図は機能仕様の部類に入る場合もあるが、オブジェクト指向とは関係ない。
ちなみに「UML＝オブジェクト指向」ではない。

アホか当たり前だろ、UMLはモデリング言語で、OOは考え方だ。

>>139 smalltalkのOOとJavaのOOは考え方違うのか？
それは知らんかった。つかそれ結局具象の話じゃね？
えらそうに、お前が布教しろよ。

>>139,142
smalltalkのOOかC++(Java)のOOかというよりは、
アラン・ケイのOOか、ビヨーン・ストラウストラップのOOか、の違いじゃないでしょうか。
「メッセージング（動的性や流動性）」重視か、
「ユーザー定義型（カプセル化や型安全性）」重視かの差、ですね。

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

たとえばC++(Java)だってケイのOOっぽいメッセージをイメージしたコードは組めるし（善し悪しは別）、
smalltalkだってストラウストラップのOOっぽく型を意識したことをライブラリでばしばしやっています。

>考え方を特定の言語にくくりつけないほうがよいと思います。
無理。そんなことしたら特定の言語についてしか話せない人間が発言できなくなって寂れる。
個人的にはそのほうが望ましいけど。

>>142
だから、「例えば」の話。

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

>>143
確かに。

　　　　　　　　　　　　（( ⌒ )）
　　　　　　　 　　　　｜・　 ・｜
　　　　　　　 　　　　｜　◎ ｜＜びょ〜ん・すとらうすとらっぷ
　　　　　　　　　　└｜ 　　 ｜┘
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜ 　　 ｜
　　　　　　　 　　　　｜＿＿｜
　　　　　　　　　　　　∪　　∪

つーか、何が分からないって？

ユースケース図は要件の洗い出しに使うし、アクティビティ図は業務分析に
使うよなぁ。おじゃばのいうUMLはこれらは含まないのか？都合のいいUMLだな。

C++やJavaでsmalltalkみたいなメッセージなんて出きるわけねーだろ。
やれるってんなら例を見せてみろ。

つ interpreterパターン

>>149
C++でsmalltalkのエミュレータを作ればいいだろ

クラス指向とメッセージ指向で呼びわけすりゃいいんじゃね？

>>151
C++で書かれたSmalltalk VM＝Squeak
Squeakのコードをコンパイルすると
裏でC++コンパイラが走る。

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

結局はアセンブラに回帰する
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;}


これをオブジェクト指向とやらでもっと保守性と再利用性をやらを高めてみろよ

学習量の違いなのか、
それとも学習過程の違いなのか、
なんにせよおまえら見てると
オブジェクト指向の統一見解が無いってのがはっきりわかる。
誰か本出さないか？
「あなたが思っているそれはオブジェクト指向ではない！」
って感じの、オブジェクト指向の切り分け本。
ちったあ売れるかも。

要求定義と一緒だ。
何をする、だけじゃなくて、
何をしない、ってのを明確にできてないから混乱するんだよ。

さて、脱線もこのくらいにして、そろそろオブジェクト指向の話に戻らないか、もまいら。

うわ・・

本を読めばその内容は分かる。
でも実装の方法がよく分からん。
ってのが実際のところじゃまいか？

>>154 ｶﾜｲｿｽ

>>154
ﾜﾛｽw

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

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

じゃあ、逝っていいよ。
ついでに業界からも逝ってくれ。
害がありすぎだから

>>159と>>160が見事に釣れたわけだが
下魚だったな

>>158は絶対わかってない

あんまり役に立たないんだよな。
面倒が増えるばかりでコストパフォーマンス寺ワロス。

最初が面倒だからな

でもそれを怠るとあとで混沌となる

if と gotoだけじゃダメだべ。
分岐だけで演算なかったら。
全てのアセンブラの命令は分岐と引き算だけで置き換えられる事を
偉い人が証明したって学校で習ったけど、詳細は覚えとらんわ。

次々に現場が変わる偽装請負の連中が９割いる業界で、
再利用性を重視・実施できてるプロジェクトが
どれだけあるのか怪しいもんだ。
結局なんちゃってOOの残骸をバグだらけのまま
使いまわしてプロジェクトの都度同じバグを修正してるところばかりだろ

>>154
アセンブラにifとgotoは無い訳だが。。

あるだろ。。。。。

雑魚しか釣れないね

>>169
あるのはcompareとjumpだが。。

「オブジェクト指向を何故理解できなの？」って質問は、結局、
「何故泳げないの？」とか、「何故楽器を弾けないの？」って質問
と同じで、本人は理解できてるつもりでも、はたから見ると全然
ダメってことなんだよな。程度の差の問題っていうのは、どの領
域でもありうる話で、表面をさらうだけならだれでもわかるが、
実際、それをプロの技として使いこなせるかどうかという話にな
ると、本人の努力とか素質とかセンスに負う所が大きいわけで、
これはいくら言い聞かせも、本人にその気がなければ徒労に終わる。

なんでもそうだけど、信者かアンチの２極化するのをどうにかしてくれ。

>>171
それを言うなら
「何故、平泳ぎで北島のタイムを出せないの？」
だろ。
OOは万能ではそもそもない。

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

OOに限らないけど
やり方の向き不向きを考えないと
本末転倒な結果になる。
OO信者は特に気をつけたほうがいいな。

個人レベルでは使いたくなったら使うでも間に合うんだけどね。
プロトタイプはOO意識せずに作ってみて、まとめた方が楽に扱えそうな
部分だけOOで作り直せばいい。
でも大規模PRJでこれやると予算も納期も破綻するからな。

ちなみに、OSの話は
強引な処理しないでって意味だから。
ここでわざわざ説明する必要はないとは思うけど。

えあ？実装の詳細を気にしないでよいプロトこそOOで作ったほうがよくね？

>>176
たしかに、使い捨てコードを
OOPで書き捨てるのは楽でいいよな。
そのまま使われると、後で地獄見そうだけどw

>>171のオブジェクト指向理解＝C++でインベーダゲーム作るレベル

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

頭は弱いけど、元は優しい子なんです。許してやってもらえませんか？

ああ、例のOODもろくにできないコンサルか。
設計中からデザパタデザパタ喚いて
OODの勘所をはずしまくって、しまいには
全部リファクタリングで改善するとか世迷言を言い出して
蹴り出されたコンサルね。

納得したわ

>>176
過去の資産があるなら楽かもしれんけど、何も無い状態で何ちゃってOOで
プロト作って>>177の言うように「工数短縮のためプロト流用してね」と
言われると元も子も無いよｗ

どんな状況だか、まだ話が見えねー。
もちっと具体的にたのむわｗ

毎回違う外注使って自社でノウハウ貯めない企業が多い時点で
流行る流行らない以前の問題

自演の多いスレだな

すずきたかひろスレｗ

あいでぃびゅーわーは使うなとあれほど、

あいぴーびゅーわーだけど、何か？

OO信者による歪曲ですな。
OOなんて簡単。
馬鹿でも理解できるから、背伸びして実力以上に見せたがるやつが好んで使う。

「おれ平仮名読めるんだぜ」

と吹聴して回るOO信者

・・・と吹聴して回るココ電球（∩T∀T)y-~~~~

ローマ字の方が例えとしては良いかな？

「俺ローマ字読めるんだぜ」と吹聴して回ってる馬鹿が　全部ローマ字で書いた文章作ってきて
「読みにくい」と言われると　「俺だけがローマ字を理解している」　などと有頂天になる。
始末に困るな。こういう輩は

postgres MLスレ消えちゃったね　困るね

あぼ〜んって便利だな

普通はリソースプールとか弄るんだよ、アホか。
しかし、負荷テスト好きだな、このおっさん。
そんな大規模サイトやってるようには見えんが。

ガーン、まちがったorz...

支離滅裂なレスばかりだな

もう、すっかり春だな。

そか、春だったからか

春厨、湧きすぎｗ

>>171もずいぶん必死で煙幕張るんだなぁ。
　>>172-184 に、そんなにマズイ内容が書かれてるのか？

で、なんなんよ
このキメェコテは

>>200
春っぽい奴がまた発生か

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とは、まったく関係ない。

本当にOO開発を分かりたいなら、ファウラーのPoEAAとエバンズのDDDを読め。
英語だが技術者なら読めるだろ。

読めるけど理解できません

PofEAAは和訳あるぞ

もし経営者が本当に開発効率を上げたいのなら、
こんなスレにいるアホな連中を雇ってる金で最高のハッカーを一人雇った方がいいってのはもはや常識

会社立ち上げては逃げ、どっかの会社に潜り込んでは逃げ
会社立ち上げては逃げ、どっかの会社に潜り込んでは逃げ
を繰り返してる経営者には無理だと思いまーす

そんな現実的でない可決策出す時点でお前使えんといわれるだけ

>>203
DDDの概要を1000文字程度 (書き込み制限)で述べよ

Diabolical Daemon Director

複雑なドメインモデル構築時のエバンズの頭の中を順を追って説明していく書物だな。
読む側も考え方や指針が掴めるから理解がしやすい。
あとジョークなんかが織り混ぜられてて、フランクな口調で書かれてるから親しみやすい。
日本語訳が待ち望まれるな。

とりあえずdomain-driven design quicklyとかいうのが無料なので落としてみた
これ読んで良かったら買ってみる

>>211
ｗｗｗｗおいｗｗｗｗちょっとｗｗｗｗそれ単なる読書感想文じゃんｗｗｗｗ
ｗｗ仮にも技術系板でｗｗｗｗそれは低レベル過ぎるぞｗ

>>211
なんとも言いがたい違和感を感じる文章だな

ん
ぽ
ぽ
ん
ま
つ
り
で
す
か
？

215よ、おまぃも春っぽいな

>>154
何これ
これが基準なら、どうやったって保守性再利用性高くなるだろ。

>>217
そっとしといてやれ・・・。

釣れるのは雑魚ばかりか

餌が腐ってやがる。

オブジェクト指向って、
結局はクラスとか継承とかが理解できてりゃそれでおｋ

ポリモーフィズムが理解できていればOKだとは思う。
インタフェースも継承も抽象クラスもそれで使い分けられる。

クラスが部品であることを理解してるかどうかだと思ふ

だから、ＯＯＰは除外すればよかったのに、設計とかの話なら馬鹿混入しないんだから。

↑OOで大規模開発すると言い出して破綻させたバカ

たかひろスレ

たかひろ君が自慢気に出してくるネタは
たいてい情報システム板でたかひろに流し込んだネタだから
馬鹿馬鹿しくなる。
お前はいままで引用時にネタ元に敬意を示した事があるのか？

ここはマ板だからな。設計の話に限定しろという方が馬鹿。
まわりの状況がみえてない。なんでも自分の思い通りにしたがる
どっかの総書記と同じ。

だから、前スレのように分けてあれば良かったといってるの。
排除なんてしないよ、分離。

そもそもたかひろは設計などろくにできない。

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

設計できない人間が、話を設計に限定しようというのだから
いつも話が破綻するのは当然のこと。

× ORマッピングよりObjectStoreの優劣検討
○ ORマッピングとObjectStoreの優劣の比較検討

たかひろって誰よ？
設計話できない電波なら、設計分離すればそっちは平和になるじゃん。
Pの話で勝手に春厨呼び込んでくれよ。

文句ばっか言ってないでお前がスレ立てろよ。過疎らなきゃいいがな。

↑意味不明な春デムパ

>>232
> たかひろって誰よ？

>1のテンプレ書いた人。

設計の話で生産性も品質も度外視したいという妄想は
凄いと思った


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
もうちょっと学習しておいで

前スレの認証話の混迷具合もすげぇな

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

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

更に、この種の課題は
http://pc11.2ch.net/test/read.cgi/prog/1171808096/111
として一般化できる

いや、既存の利用可能な認証システムに依存しない
空理空論の分析モデルの話か。

例があまりに不適切過ぎる。
どうでもいい話だ。

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
ﾜﾛﾀ

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専用
　　　　　　　　ﾋﾞｼﾞﾈｽﾛｼﾞｯｸ

おっと、出力データもDTOだな

>>240
いいか悪いか別として、ありがちな設計だな。

基本設計なのにクラスのことを考えてるってのが古い組織を感じさせるな
まぁ今俺がおるところがそういう感じなんだがorz

あいたたたた、お腹痛い、ちょっとウンコしてくる。

>>240
トンでもない設計だな。

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

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

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

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

こんな基本設計押し付けてくる奴が居たら
俺は即座に理由を説明してダメ出しするだろうな。

また自演かよ

>>243
> 基本設計なのにクラスのことを考えてるってのが古い組織を感じさせるな

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

ビジネスロジックってたいへんなんでねえ。

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

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ

×ドメイン・スクリプト
○トランザクション・スクリプト
orz

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

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ

×ドメイン・スクリプト
○トランザクション・スクリプト
orz orz orz

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

・・・と、これで、
>>1 の主旨に沿って設計論を語る準備ができたぞ。
後は任せたｗ

実際COBOLやってた組織のシステム作るときは>240みたいな設計を押し付けられることが多い。
しかも基本設計という名の下に。
なぜか要件定義段階からStruts拡張自前フレームワークを使用するという前提までつけられる。

本来であればサービスの1メソッド程度のものを、個別のビジネスロジッククラスとして定義させられたりしてな。

要するに、メインフレーム系COBOL等の
オープンシステムへのミグレーションね。

そして、そんな設計押し付けてくる奴には
ダメ出ししなきゃね。

ユーザ企業本体の情報システム部門〜関連子会社の下請けに入る限りは、
そこらへんに変な条件が付帯するのはしょうがないよな。

うひょー。綴り考えながら書いたら、ミスってるし。

× ミグレーション
○ マイグレーション

今時、画面とB/Lの分離もできないっていうのが、致命的なんだよな。
>>240の設計は実装を分離しただけの代物だろ。

>>255
ググった俺の人生を返せ

>>251
開発ﾂｰﾙを使ってｻｸｻｸの部分が失敗して
完全なﾃﾞｽﾏｰﾁ化する事も多いからなぁ…

そうなったときの責任の所在も
曖昧になる事が多いのがなんともね…w

http://science6.2ch.net/test/read.cgi/infosys/1103757092/

これの件は、まぁ俺の責任じゃーねぇな。
より上位から判断できる人間２人には問題点を指摘したし、
その問題を無視して突っ走ったバカの責任だろ。

ネタにされてますよ

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

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

あうあう。ちょっと説明が跳んだなｗ
書き直し。

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


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

問題はその後、＋αの部分だ。
個々の画面に密結合する形で、
画面専用のデータクラス、画面専用のロジッククラス
などというものの設計を許しちゃうから、
クラス数の爆発して、ﾃﾞｽﾏｰﾁ化する、って事。

>>260
ｋｗｓｋ

http://pc11.2ch.net/test/read.cgi/prog/1174154285/

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

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


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

ぉーぃ酔っ払い

話がﾙｰﾌﾟしてるZO!

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

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

やっすい単金で。

>>261
俺が話しているのも
その＋αの部分の話なんだけど
ｿｰｽｼﾞｪﾈﾚｰﾀみたいなﾂｰﾙ開発して解決する前提が
うまく行かず、ﾃﾞｽﾏｰﾁ化が
酷い事になってた時があった。

設計とある程度並行に
実装が進む開発の場合は
ありがちな問題かと思った。

>>261
たしかに、そのときもｿｰｽｼﾞｪﾈﾚｰﾀ周りを
きちんと設計出来てから
開発を進めれば問題なかったかもしれない。

しかし、複数の会社が絡んでいたり
担当者が掛け持ちで仕事して
そっちも忙しかったりで
無理だったと思うけどw

その件に関して、キミを責めたりはしていない。

ってどこのキミかよくわかんないけどｗ
最近耳ぶたが閉じっぱなしで勘が狂いっぱなし・・・花粉のせいか

むしろ基本設計部隊だよなぁ、問題あるのは

　 ε　⌒ﾍ⌒ヽﾌ
　（ 　　( 　・ω・）　基本設計ブタ？
　　しー し─Ｊ

引用しまくってる春厨がいるな

はぁ？引用じゃなく、単に書きなおしてるだけじゃねぇの？

2時か。
春厨確定だな

相変わらず逃げまくりだねぇ、あんたの人生

ﾄｺﾛﾃﾞ ﾅｾﾞ ﾊﾝｶｸ ｶﾅｶﾞ ｵｵｲﾝﾀﾞﾛ

理解でないのではなく使い方、メリットがわからんのだろ
かつての構造化プログラミングが提唱されたときと同じ
自分の作業に疑問をもってないやつは気がつかないのさ

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.

そこまで言われんでも自分で理解しときぃやー。ぼけぇー。

あうあう

ドメインモデル設計と実装は切り離すのではなく一緒に考えるんだ。
SEは良い設計ができるだけでなくバリバリ実装もできるんだ。

ってDDDにかいてあったよ。

議論の文脈との関連を説明せずに
引用のみ書いても意味がない。

相手とかみ合った会話ができないのが
たかひろ の特徴

なんだなんだ？この春厨の多さは！？

お前は泣きながらｵﾅｰﾆしてろ

また>>285という春が釣れたわけだが雑魚すぎて泣けてくる

またお前か。
一般論を隠れ蓑にした
知り合い同士の内輪話だから
お前は顔突っ込むな

また釣れた　雑魚だが

キチガイ警報発令！！！

>>289
お前さっきからウザイぞ
自分のブログに逝け

キチガイ警報発令中！！！

オブジェクト指向を理解してる人って
技術者の何％ぐらいなんやろ？

現場の技術者って何％ぐらいなんやろ？

　　　　　　　　　　　　

キチガイ警報解除

議論の土俵を用意してやっても
一向に議論展開できない ﾍﾀﾚ>>1

５％もいるかな？
オブジェクト指向を掲げる現場は多いけど、
要員集めは言語で集めるしね

言語で集めてるならまだマシだけどな

ﾍﾀﾚ

釣堀かｗ

現場の80%は作業員

議論の土俵を用意されても
一向に議論展開できない ﾍﾀﾚ>>1

>>302
コピペ春厨は消えうせろ

スレ天婦羅に議論展開とは恐れ入ったｗ

なんだ>>1のテンプレは飾りかよ

Martin Fowlerを元ネタに
技術話のネタも書けねぇとは
とんだ池沼だな

おまえが書けボケナス

議論の土俵を用意されても
一向に議論展開できない ﾍﾀﾚ>>1

議論の土俵を用意されても
一向に議論展開できない 池沼>>1

なんで、Martin Fowlerを元ネタにせなあかんねん。一人でオナってろ。

頭悪すぎ

>>309
この高名な先生に逆にMartin Fowlerについて質問してみたらいかがですか？

たぶん>>1の発言待ちにおちつく事が予想されてしまいますが。

この先生はかつてはオープンソースの大家と言われてました。
ただmake installはいつも失敗していたようですが。

議論の土俵を用意されても
一向に議論展開できない 池沼>>1

>>314
では、先生。先生の議論展開をお願いします。

たまに、スレタイに則ったまともな話になっても、
理解できない香具師が暴れるっつーのがこのスレの流れとして定着してきた感があるな。

>>292
>>297
ＯＯを批判してる人は１００％理解している。
ＯＯを支持してる人は２０％くらい

うそつけ。具体的な批判など一度も出てきて無いぞ。

おっさんスレに基地外が住み着いたようなのだが、出所はここか。

おっさんスレのんぽぽんが居るじゃないか
よう、んぽぽん！

>>319
違いますね。
彼は２ちゃんにしか居所のないﾋｷｰ。
２ちゃんのスレをさすらうのが彼の人生。

議論の土俵を用意されても
一向に議論展開できない 奇知guy>>1

どこが違うんだよｗ

>>321
さすが、んぽぽんだけあって、んぽぽんが解ってるな
次はこのスレでんぽぽんするのか

322のような春厨が多発しているスレはここですか？

漏れ思うんだけどさぁ、別に全ての状況で無理にＯＯを意識する必要ないべ？
例えばＰＧ組む時でも、複数のインスタンスを生成した方が便利そうな場合は、
ＯＯ使えばいいし、そうでなければ、普通の構造化だけでいいんじゃね？
つまり、1対多、多対多の関係をもつエンティティを扱う場合はOOがいいし、
単一或いは、1対1の関係しかないエンティティだけの場合は、ＯＯいらないと。
しかし、言語の構造がもはやＯＯを前提にしちゃってるから、まぁ、カプセル化
ぐらいは使うか、とか、場合によっちゃ、継承やポリモも使っちゃうかぐらいの
感覚でいいんじゃねぇかと。 OOやるぞぉって身構えちゃう必要ないよな。

そそ。

そういうときはシングルトンパターンを使え。

シングルトンパターンがどうこう、ってのはオブジェクト指向に含まれるのか？
それって派生した奴の話じゃないの？
少なくとも、今まで読んだ本の中にシングルトンの話は出てないんで
必要性がさっぱりわからん。

実行中にnewすると処理時間を食われる。
複数インスタンス必要なものならいざしらず、単一インスタンスしか必要なく、
実行中に存在してればＯＫなものはシングルトンがむいている。

System.out.println("Hello World!");を実行するためにSystemをnewするような
バカな真似をしたくない。

複数インスタンス必要の場合は何パターンがお勧め？

>>326
そうなんだけど、多分そのやり方じゃうまくはいかないべ
OO覚えてしばらくは厨のように、全てにOO適用デザパタ適用するんだ。
そのうちOO/デザパタを「あえて省略できる」ようになってくる

全部おじゃばに見えてきたw
やべえな

>>332
シングルトン＊Nパターン

インスタンス化する必要のないものまでインスタンス化するのは無駄。
モジュールでＯＫ。

>>335
あまりにも常識過ぎるレスに、逆にワロタヨ

シングルトンってなんだ？
OOでは普通に使うのか？

自分ではなんの答えも出していないのに笑うだけかよ。

素のシングルトンってのはもう流行らんぞ。テストもしにくいし。

シングルトンもマネージャクラスみたいなものには必要かもしれないど、
クラスメソッドで十分な場合も多い。特に単一スレッドの場合は。

http://www.nulab.co.jp/designPatterns/designPatterns2/designPatterns2-1.html
このページを読んでみたが、
梅酒で酔っ払った俺には理解できねーｗ

>>341
そういうの向けにmonostateパターンっていうのがあるぞ

>>343 それっと、ものすげぇの？

誰か梅酒な俺に教えてくれ。
なんとかパターンってのは覚えてないと
オブジェクト指向を理解した、とはみなされないのか？
なんとかパターンって定石みたいなんもんなんだろ？

キチガイが糞質問中

>>346
はいはい、ﾊﾞﾛｽﾊﾞﾛｽ

すぐ、どうでも良いミクロな枝葉な話になる。
厨房の春、にっぽんの春。

>>345
ググればすぐ出てくるものだから覚える必要なんかないよ。

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

ただし、我流OOPをある程度やった後じゃないと理解できん可能性があるかな。

>>348
>>281

>>349
サンクス。まあそんな感じだとは思った。
結論は、オブジェクト指向の根幹に関係ねーってことね。
明日シラフになったら調べてみるわ

キチガイがループ中

352の主治医です。
この度、このようなレスを352が行うに至ったことは、
主治医として、大変残念な事であり、また、治療の効果が
まだまだ現れていないことを証明しているため、そろそろ
最終的な決断を下す必要があるようです。
みなさんお聞きになったことがあるかもしれませんが、
必ずしも心の病は、特殊な病気ではなく、誰もがそうなる
可能性があります。しかし、だからといって、これ以上、
352を放置することは、例えば何の関係もない人を傷つけたり、
逆に352自身の将来にとり、名から図示も良いことではありません。
そこで、私は、352の両親、臨床心理士などとも相談して、
352をしばらくの間、ネットの出来る環境から離して、
濃密な人間関係の中で治療をすることにしました。
352にとっては、納得がいかないことかもしれませんが、私も、
医師免許をかけて、352を徹底して直すことに致しました。
どうかみなさん！352が戻ってきましたら、このような人を悲しませる
スレではなく、みんなに感動を届ける以上の人間になっていると思いますので、
暖かく見守ってやってください。

名から図示も

>>351
覚えていると会話容量を減らせて楽だぞ。
反面、このパターンがどうのこうのとシッタカな厨が釣れてしまうが。

オブジェクト指向を理解してる奴が何％ぐらいいれば、
システム開発はラクになるんだ？

>>353の出現によりスレに基地外スレ警報でました
速やかにスレより非難してください

荒らしは軽やかにスルーしましょう

>>356
設計・実装に関わる人間については100%
一人で設計・実装をやるのが現実的かな

一応マジレスすると

>>352-353

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

・・・そういう現実を皆知ってるから、
基幹系とか大規模開発には関わらないようにしてるんだってｗ

まあ基幹系でも、まともな業種もあるけどな。
金融〜証券の基幹はほぼドキュソの世界。

リンクミス
>>252-253

>>360
基幹系って「十分すぎる程枯れたモノ」を使うところだろうにね。

ハードがそろそろ壊れるとか、処理速度が遅いとか、
金が余ってるとか、なんとなくとか、
いろいろ理由があるんだろ

うまくいかないプロジェクトってのは、単に人を入れすぎなんでしょ。

言語でしか人選しねーからなあ
OO経験なんて確認する現場なんて聞いたことねー

>>366
OO以前の問題。
人集めは自分でやるんだよ。

なんかドラクエみたいだな

人買いから十把一絡げで人員調達してうまくいくプロジェクトなんてないからな。
人集めする権限を自分で持つか、権限を持った人物と知り合いになるかすればよくて
それはそんなに難しくないだろ。

んなもんモジュールごとに担当分けしてＯＯやりたいやつだけ勝手に中でやればいいだろ。
なぜ全体を支配しようとする？
いざとなったら逃げるか放置の癖に

まだ生きてたのか
この糞コテ

ＯＯ厨はモジュールの中に隔離して他に感染しないようにするべき。

もう５年前かなあ
この板でオセロでＯＯ勝負したけどＯＯ厨みんな逃げたね

OOアンチにはモジュラリティなんて概念ごと無いくせに良く言うわ

>>373
勝負ってどうやって？

>>373
日本語でおｋ

>>373
何の勝負か知らんが、俺が受けてやったっていいぜ？ん？

全角英数使ってるようなアホコテの言い出す勝負ってどんなんかwktk

この5年OOアンチでいたことは、技術者として致命的だったな。

この板で「オセロ作って勝負しよう」といって
開発時間とソース公開やったの。
ＯＯの生産性は構造化の1/10くらいだった

いまファイル残ってるの見つけたが
Ｊ２ＳＤＫ１．４だべ

電球の主張がよく分からん

おれも

サンのダウンロードページ行ったら　トップがｃ、ｃ＋＋　ＦＯＲＴＲＡＮじゃん
Ｊａｖａどこいった？

>>380
いろいろあるがまず、構造化とOOがなんで対立する概念みたいなってんのよ。

ＪＡＶＡのＳＤＫのダウンロードページねえですよ？

COBOLとsmalltalkでどっちが速くオセロつくれるかってこと？

構造化だけ
と書いておこう

OOは一からの生産性が高いとはあまり聞かないな。
修正が効き易いという話は聞くが。

っつーわけで開発時間を単純に比較しても仕方ない罠。

java構造化　ＶＳ　ＯＯ何でもいい

修正しにくいかしやすいかはコード書いた人によるところが大きい。
ＯＯ関係ない。

電球は、まず何を言いたいのかはっきりしろ
酔っ払ってんのか？

>392
薬物じゃね

この板はＩＤついてないのでね
質問の一部だけ書かれても意味が判らない。
全文書くか、ハンドルつけるように。

＞電球
全体的に支離滅裂で主張が分からん

>>395
同意

ＯＯは実験の結果とっくに生産性低いと結論が出ている。
５年前もＯＯ厨は「保守性は高い」と逃げたけど、証拠を提示できなかった。
さらに最初は「ＯＯは生産性高い」と触れ込んでたのに、あっさり撤回してたその厚顔さにあきれたもんだ。

>>397
お前の身近で起こったことは宇宙の真理なのか？ん？

だから・・・
実験の詳細を示せ
この程度の内容でまともな文章を書けないとか
お前の程度の低さを証明して終わりでいいのか糞コテ

理論は実証によって裏付けられるべきで
実証に反する理論を掲げ続けるのは空理空論という。

なぜかエイとかウツボの画像が思い浮かんだ。

時間を計っただけだよ。

ＪＡＶＡオセロは三日くらいでできたよ　仕事終わって家でやった。
対してＯＯ側は誰も提出せず、逃げ回ってた
一ヶ月と少し経って、やっとＯＯオセロが提出されたけど、完成度は構造化のみのより低かった。

OOの生産性は高いはずだったのが実は低いという結果が出たんだな。
で、その生産性って奴が構造化10に対してOOが１ってことを主張したいんだよな？

そのソースを出してみれ。
３丁目のおじさんが言ってたよ、なんて話は役に立たんだろ。

糞ｺﾃ降臨で議論妨害か。
懐かしいパターンだな

＞空理空論

お前の言ってる実証って
他人に内容を伝えられない程度の妄想なんだね
OKOK　帰っていいよ

あほらし。
こんな話に付き合ってた俺がどうかしてたわ

ぷ
切れてやんのｗｗ

たかひろ乙

流石に糞コテが哀れ
よくその頭で厚顔無恥なレス繰り返せるもんだ
オレにはできん

荒らしは華麗にスルーしましょう

>408
なぁ、まさか、それ煽ったつもりなの？

ここか
やっとみつかった
http://java.sun.com/javase/ja/6/download.html

電球よ、春休みの課題ちゃんとやっとけよ

たかくんおっきしたお。

オセロって、UI以外では石と盤とロジックぐらいしかクラス対象ねぇじゃん。
ほとんどロジックの実装だっつうの。こんなんで優劣比べようなんて、どうか
してる。オセロ作るんだったら、そりゃ構造化だけでも全然OKだわな。なんで
もOOって考える方が柔軟性なさすぎ。もちっと頭柔らかくしような。
どうせゲームなら、種族や職業が100種類以上あるようなRPGで勝負すっか？

電球が宿題スレと勘違いしているのはここですか？

>>408
いい大人が、愚にもつかないレス垂れ流してみっともないだろ。

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

なんでもいいから議論するに足る意見を書きこんでみろや。

勝負終わったら結果教えてくれ
じゃーな

>416
そこはシムシティで行こうぜ

具体的にこういうところはOO使わないほうが良いとか事例あげて主張するとか
出来ないものかねえ。

だいたい気取って煙草ふかしてるような奴にろくな奴はいない

１．６にコンパイルしなおしてるところだ

勉強スレに行っておいで

そもそも名乗ってるコテ自体にセンスねーんだが・・・
そこは不問にしてあげたほうがいいのか？

春嵐はスルーで

とりあえず泥縄やってる時点で
生産性とか保守性とか語れるレベルじゃねーと思う

え？これで終わり？
尻切れ蜻蛉だな・・・
流石と言うべきか

爺は巣に帰れよ。

つーかこの糞コテなんだったん？

やっと基本設計書き終わった；；
期限めちゃくちゃやし・・・
明日バックレ宣言してやる！！！マジで！
こんなPJしったことか

>>416
違う、OO的オセロは自軍の石がそれぞれ独立した個を持っており、その協調で戦略が完成するんだよ。ｗ

>>432 よし、お前が電球と勝負してやれ。

戦略を与えるのはプレイヤーであって駒ではない。
駒は位置属性と色しか持たず、複数の駒を決められたルールで管理するのはボード。

だから、オセロなんか無理やりOOにしない方がいいっつうの。

オセロはシンプルだからOOの勉強には丁度良い
あとMVCも

>434
隣の駒への参照ぐらいは持ってても良いかもね。

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
　ＪＡＶＡオセロは三日くらいでできたよ　仕事終わって家でやった。
　対してＯＯ側は誰も提出せず、逃げ回ってた
　一ヶ月と少し経って、やっとＯＯオセロが提出されたけど、完成度は構造化のみのより低かった。

竜頭蛇尾だな。
やっぱバカか

オセロのコードなら4,5日前にこのスレでみたような気
がする。気のせいか・・・

オセロキチガイ乙

OO的オセロは、各石が独自の判断で他の石と連携して戦略を盤面に伝えるんだろ？

オセロみたいに思考スピードが要求されるドメインで
OOなんか使ってちんたらやってられっかよ。
データは配列で十分だ。

なにいってんの

結論： ﾆｰﾄにOOは不要。
　　　　OOにﾆｰﾄは不要。

終了

開発によってはOO的な手法が害になるという点と
単純な意味での生産性ではOO的な手法が従来的な手法より劣るという点では
電球の意見も理に適っている。

ただし、実際にはコードの再利用性や保守性が上がる効果が
OOにはあるので単純な比較は難しいけどな。

抽象論ですらない、実に中身のないご意見ですね。

物質指向とは梵が唱えし如来の十号における応供を声聞の成仏たるべしと解了するが如きなるものかな。

設計する上でセマンティック結合は避けた方がいいな、一般に凝集度
は強い方がいいとはされているが、これも場合によりけりである。
ルーチンレベルでの凝集度について検討することがヒューリスティクス
の観点から効果的であることには異論は無い。なかなか現場では実践さ
れないのが残念だが。

>>447
オブジェクト指向は部品指向であって物質指向ではないぞ

テストのし易さを常に念頭において設計することは良いプラクティスだ。

>>449
確かにオブジェクト指向より部品指向と言ったほうが解り易いな。

-早くPGを辞めて、新しい人生を歩くことは良いことだ

PGのスキルを武器に他業種に潜り込むのは良いライフハッキングだ

そのときのオセロＵＰ
Ｊａｖａなんで環境整えないと動かない。

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

環境は　C:\Program Files\Java\jdk1.6.0\　だ。

アップ失敗したくさい
フィルターかかってんのか？

コマクラスのsetter/getterで白黒いれかえるの？

Othello.java　Othello2.java src
ってなんだよ。readmeぐらい入れとけや、ヴぉけ！

http://vipup.sakura.ne.jp/512kb/src/512kb_8358.lzh
今度は成功

理解できるのかよ
羨ますぃー

糞コテが糞ソースを公開してスルーされるスレｗ

結論： 糞ｺﾃにOOは不要。
　　　　OOに糞ｺﾃは不要。

終了

手続き型と言いながら中途半端にOO使ってるし。つっても継承と
UI廻りだけか。どうせなら、全部クラス変数とクラスメソッドにしろよ。
public だらけじゃん。意味ねぇ〜

>>461
そういうキミは、どんなクラスを抽出できたのかな？

ん〜と、今んとこ、電子クラスと陽子クラスと中性子クラスの３つ。

結論：
　　　　池沼にOOは不要。
　　　　OOに池沼は不要。

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

終了

今やBDUFは流行らない。最近の流行はLDUF若しくはENUFだ。
そういう意味では、>>457はプロトタイプとしてはまぁまぁ
の出来だと言えるのではないか。

>>462
View部
　　　　　　(略)
Model部
Game　　１回戦分のゲーム
Score　　対戦記録 (コマンドパターンで譜の再現等)
Step　　　一手 (Commandパターン)
Board　　盤面の管理
Player　　プレイヤ (人間およびコンピュータ)
Strategy コンピュータ側思考 (Strategyパターン)

BDUF： Big Design Up Front
LDUF： Little Design Up Front
ENUF： ENough design Up Front

終了

>>466
あと、審判(指し手交代、パス回数、得点の管理)とか、
ルール(StrategyパターンでOthello/Reversi/源平碁等のルール切替)
があっても良いかもな。

この程度の屑ソースのうpに半日以上かかるアホコテが
保守性だのなんだのって馬鹿も休み休み言えってカンジだな

結論：
　　　　ソースも読めない池沼にOOは不要。

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

終了

>>448のような横文字は嫌だな
独りよがりで敬遠されそうだ

独りよがり、ってなんかエロくね？ひとりーよがり。

電球ソース見たけどpublic好きなのもほどほどにしとけよ
privateが一個もねーし
全然Javaが分かってねーだろ

ＯＯで組んでないっつうの

どうせどっかのアフォが書いたデタラメだと思うけどｗ

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

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

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

「なかなか現場では実践さ れないのが残念だが。 」
＝COBOL現場の常識を、OO屋は理解していない。
　 COBOLの常識を取り入れた俺様こそ日本一のコンサルでーす。

>>475
OOは関係ないぐらいひどいぞ。
言語を理解していないだけだろ。

>>475

で、ココ壱番。
おまいは何をしたいの？
妄想上の仮想的に向かって必死に非難を浴びせたいわけ？

煽り坊しかのこらねーのかよ

>475
OO以前の問題だろ
真性のアホか？

吼えてないで手本をＵＰしる

「よがり」のイメージ検索結果 約 1,820 件中 1 - 20 件目
http://images.google.com/images?hl=ja&lr=&q=%E3%82%88%E3%81%8C%E3%82%8A

>>479
敗北宣言ッスかぁ？

で、逃げて終わると。
毎回同じだね。

終了、終了言ってる奴、見に来なきゃいいのに。知恵遅れか？

>>479
Eclipseで組んでるんだったら
リファクタリング機能あるから学習しとけ
インデントがたがたなのはみっともない

>>481

で、ココ壱番。 おまいは何をしたいの？
お前が糞ソースをUPしたからといって、
俺達がそれに付き合う義務はない。
上に思いつきで書いたクラス分割を参考に、
OO化したソースを書けばいいんじゃねぇの？

>>481
相手にしてやろうと思えるぐらいのまともな作品用意してくれ
ぶっちゃけ話にならん

>>486
タブサイズ＝２で見れ(わらい

>>488
威勢がいいなぁ。
おじさん、威勢がいい子は好きだぞ。
次はおまいがUPしる

つーかコテハン自体がキモいのはどうにかならんのか

もしかしてココ電球って、
５年前にパクったソースうｐしただけじゃねぇの？

これは、ソース内容説明できるかどうか
テストする必要があるなｗ

お前らコードにはコードで対抗しろよ。説得力ないぞ。

はい、ココ電球にテスト質問。

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

まずはこれからだな。
これを簡単に説明できないようなら、パクリ決定

５年前、「オブジェクト指向逝ってよし」というスレをたてた。
そこでハンドルを「逝って良しの１」とした。

>>495
　>>494の解答をどうぞ

こんな保守性の無いソースは久しぶりにみたな
できる奴は遊びソースでも必要にあわせて定数はちゃんと定義するし

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

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

/**ゲームボードの幅*/
public int DESIGN_BOARD_W = 400;

ﾁｸ ﾀｸ ﾁｸ ﾀｸ ﾁｸ ﾀｸ ・・・

>>497
　キミが>>494に解答してもいいんだぞｗ

すべての配置可能ポイントにおいた場合の評価を評価関数をもっておこない、
数手先まで見るときは相手側もそれに対して最大の評価を得られる手を打ってくるとみなして
再帰評価しているのだ。

評価ポイントは裏返せる数＋隅っこのボーナス。
辺および四隅は評価が高い。

>>499
まずは言語の勉強からだろ
finalも知らん奴にアルゴリズムもへったくれもねーし

はい、ココ電球にテスト質問。

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

次はこれだな。
これを説明できないようなら、ソース作成者と認められない

定数と変数をあえて分ける論理的必要性を見出せない。

さっき書いたじゃん

>>503
偽者の相手をしても時間の無駄だよ。
さっさと問3に答えたほうが、観衆の受けがいいよｗ

おまえら、電球はCOBOLERで、一生懸命Javaを勉強したんだ
そんな年寄りをあまりいじめるなよ。
そりゃ、お舞らに比べればはるかに実力が低いの電球だって骨の髄まで解ってよ

いいぞ、電球。がんばれ

ヒント： 712行目
　　　　score += 200;

>>503
あのな、まじめに答えてやるけどさ、
マジでプログラマーとしてやっていくつもりなら、
ちゃんと勉強した方がいいぞ
必要性を見出せないんじゃなくて、わかんねーんだろ
虚勢を張っても分かってる奴が見れば、冷笑もんのソースなんだよ

うまいプログラマーってのは、下手に作ろうと思っても作れないの
お前のソースは下手な奴が作ってるから、下手なソースなんだよ

電球はあれを3日でつくったんだゾ。しかも会社から帰ってから。
少しぐらいソースが汚くたって、俺は尊敬するな。お前らにでき
んのかよ。

その２００はコンピューター側が　相手が置けないように追い詰める評価値なわけだ。
elseじゃないほうはとられる

むしろ、字面にばかり突っ込んで、
内容に一切突っ込めない >>509が
偽者のヨカーン。

あと、問1, 問2はソース読みゃ誰でも判るけど、
問3 は作成者じゃないと説明しにくい。
説明を出ししぶるココ電球はパクリ魔のヨカーン。

ちゃんとアルゴリズムを考えられるところは偉いと思う
でもfinal知らない（使わない？）のは不勉強過ぎるんでわ

３日もかけんなよ・・・

結論： ココ電球＝プログラムできる人
　　　　final厨房＝しったか

だから、コードにはコードで対抗しないと、全然説得力無いって。
虚勢張ってる厨房にしか見えない。

本物と偽者の判別ができたところで、
ココ電球よ、おまいは何を望んでいるんだい。

>>final厨

ヒント：ウィンドウサイズ変更への対応

真実

>>519
何の真実？
あとちっぽけな存在に過ぎない「人間」という種族は、
なかなか真実など語れるものではないよ。

おまえは、電球は"んぽぽん"と思うか？

ほっほっほっほ

どこかにきっと「真実がある」
そう信じて５年間も彷徨い続けたココ電球。
しかし「真実などどこにもない」という老師の言葉に
ただただ唖然とするばかりであった。

電球はこれよんどけ
「なぜ、あなたはJavaでオブジェクト指向開発ができないのか」

５年もプログラマーやってあのソースなのかよ・・・
どの現場からもお荷物扱いされてるんだろうな
ちょっと同情するわ

要するに、オセロはこのスレとは全然関係ない話だったという事で
>>373-523は削除。

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

　　　　　　　　　　　　　　　　　　　終了



＃part1, part2はまともだったんだけどね

テンプレにつっこんでどうするｗｗｗ

池沼にOOは必要なし

結局パクっただけのソースで勝利宣言ってオチか
糞コテらしい

>>1は、議論の土俵を用意されても
一向に議論展開できない池沼

荒らしはスルーで。

オセロの部分、荒しとして削除依頼出しときました。

ループが続いてるな・・・・・
ユースケースってどうよ？

498 名前： 仕様書無しさん [sage] 投稿日： 2007/03/04(日) 10:15:48
ユースケース分析って、機能中心のシステム分析に対するアンチテーゼだろ。

いや、むしろユースケース・シナリオは
システムが提供すべき機能を洗い出す分析手法だろｗ

アンチテーゼってのをいちいちググるのがめんどい

以下無限ループ

>>1は、議論の土俵を用意されても
一向に議論展開できない池沼

現場がオブジェクト指向じゃない奴ってどのぐらいいるの？

以下無限ループ

>>1は、議論の土俵を用意されても
一向に議論展開できない池沼

春だな〜

負け犬乙

オブジェクト指向ってなんで敬遠されるんだろうな
やっぱり用語の乱立も理由の１つなんだろうな

以下無限ループ

荒らしはスルーで

ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ

OOは一朝一夕で身につくものではない。イパーイ本読んで、
イパーイ実践して、イパーイ失敗して、そうやって感覚的に
身に着けていくものだ。イパーイ、ｲﾊﾟ−ｲ、ｲﾊﾟ-ｨ...

覚えることが多いんだよな〜
なんつーか、何が正解なのかがはっきり言えないところがな〜

議論の一つもまともにできずに常駐してるのが
荒らし本人。

推奨されるまでもなくデフォで無視。

はいはい、ﾊﾞﾛｽﾊﾞﾛｽ

>>548
ゆとり教育世代乙。

リアルな世界には正解を示してくれる先生などという
絶対的存在など居なくて、
ただ「(ある面から見て)より良い(と思われる)方法」があるだけなのだよｗ

本読んでるとさ、詳しくは別のこの本を参照してくれみたいなこと書いて
あるじゃん。んで、わざわさその本取り寄せて、読むとその本にも、詳し
くはこの本読めとか書いてあるわけよ。もうきりが無くてさ、何処まで勉
強したらええねんと。モチベーションもガクーンと下がるわけさ。そして
気づいたら、アレ？ 俺、なんで、開発設計の本じゃなくて、建築デザイン
の本とか読んでんだっけとかなるわけよ。まったくこいつらつるんでると
しか思えねぇ。市ね。

>>553
幸せになる壷買わないように気を付けてね^^

>>553
もっと具体的に説明しる
具体性の無い愚痴は、トイレの便器にでも叫んで、
水に流しちゃえ

単に自学自習スキルのない厨房だと思った

>>548
われらが69式オサンはちがうぞ

ｵﾊﾟｰｲ、ｵﾊﾟｰｲ、ｵﾊﾟｰｲが人生の全てさ

厨房にＯＯは必要なし

例のちゃぱつか

実業務ではどれをインターフェースにすればいいか、
なんてことで悩んだりすることが当然出てくる。
こういうことを繰り返していかないとOOは身につかない

偽装請負で作業場所がコロコロ変わるようなこの業界で、
オブジェクト指向の要員なんか探す方が難しい

ソースの良し悪しはともかく、ただの批判しかしない奴よりは断然マシだな。
がんばれ。

俺もStrutsSpringHibernateでオセロ作ってみるわ。
誰かOOまとめWiki作らね？あればそこにうぷするわ。

あのな、犬小屋を作るのと高層ビルを作るのはわけがちがうんだ。
高層建築に適した設計論で犬小屋を作るのは無駄でしかない。
犬小屋には強度計算も必要なければ、資材調達計画も
必要ない。いいか？このスレのオセロの例はそれだ。犬小屋を作って見せて
無駄だと言っている。お前ら、リアルで厨房だろう？春休みで暇なのはわかるが、
留年しないように頑張れよ。

それはいいアイデアだな。
そういう荒唐無稽なプログラムは
学生時代じゃないと決して組むチャンスは無いから
まあ頑張れ。

完成したら教えてくれ。じゃ

じゃあ俺は普通にJavaでオセロ作ってみるか
その前にオセロのマスっていくつだったっけ？

>>564　11個

サンクス
おまぃ　いい奴だな

つまりOOは高層建築のための設計手法であって犬小屋を作るためのものではない。

犬小屋には犬小屋のデザインパターンがあるようにも思う。

犬小屋と高層マンションも入居者が出入りするインターフェースは同じ

犬小屋はPerlでどうぞ。

そのOO高層建築の進捗管理(建築での積算)がステップ数であった場合、
Pjを辞めた渡しは正解ですか?

日本語でおｋ

輪切りの私〜♪

犬をバカにすんな

ちがうだろ、オセロは8x8だっチュウの

お前のネタは実に単調だな。

お前はやり過ぎたんだ。
お前は暇つぶしのために７年間に渡って
２ちゃんのスレを荒し続けた。
その結果、もう誰も２ちゃんになど来なくなった。
お前の残りの人生は、誰も居ない２ちゃんで
ただひたすら独り言を書き続けることになる
・・・命ある限り、永遠に

結局ＶＢが一番ってことだろ。
その次エクセルマクロ。
あとは必要ないよな。
改良もされてくるだろうし。

違うの、C#が一番なの

javaとc#の両方を使ってると
混乱してくる

そんなときはJ#でつよ

石は白と黒しかないので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];
};

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;
}

今回はJavaじゃなくて、C++で書いてみた。

どこがオブジェクト指向なんだ？
クラスを使った構造化なだけ
ここのスレに書くならば
・無駄な処理と分かっても無理やりOO的に書く
・時間が1000倍かかっても無理やりOO的に書く
・見通しがかえって悪くなったとしても無理やりOO的に書く
これがこのスレの掟

>>582
石の操作クラスは別に儲けるべきだと思うが

設計の話もダメ、実装させてみてもダメか。
何の役にたつんだこの糞ｺﾃ。

>>582-583
これだと結局、石を交互に置くというルールしか表現されてないわけだが。
オセロっつったらコンピュータの思考ロジックが一番の肝だろうが、ヴぉけ

これが糞コテクオリティ
次々と自爆荒らししていくんじゃねぇっつーの

Strategyパターンの検討材料としてはよい題材かもな。

>588
ゲーム盤には石を置く機能と、終了判定機能、結果表示機能を持たせるべきだ。
思考ロジックはゲーム盤に入れる機能ではなく、プレイヤークラスを作りそっちに入れるべきだ。
って事だよ。分かった？

御託はいいから実装しれ

おじゃばはこのスレだとスキルが一番高くなれそうだな。

>>591
>そっちに入れるべきだ。
その「べき」の理由を説明したりすると
このｽﾚが有意義なものになるかも知れませんね。

>594
なぜならボードクラスはボードゲームを抽象化したもので、石を置き、終了判定をして、結果を表示するのは、
他のボードゲーム（将棋、囲碁など）にも共通するからだ。これならば、ゲームの内容が変わっても
構造を変更する必要がない。

そしてプレイヤークラスに思考ロジックを実装するのは、プレイヤーを抽象化する事になる。
例えばプレイヤーにはオセロを知っていてやる人ばかりでなく、もしかしたら占いで打ったり、
勘で打ったりする人もいるかもしれない。それをボードには実装するのは明らかに変だ。

>>591 誰もゲーム盤に思考ロジック入れろとは書いてねぇだろ、ヴぉけ
思考ロジックを含めてことコンピュータオセロゲームだっつってんの。

> 石は白と黒しかないのでboolで十分。

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

ゲーム盤クラスとゲームクラスと終了判定インターフェイスと表示クラスまで分離
プレイヤークラスを継承して人間・COM
COMをさらに継承し思考パターン毎にクラスを

御託はいいからその肝心な部分を実装しろ。

で、ゲームクラスはゲーム盤クラスのインスタンスやログを持ち
再ゲームはゲームクラスのインスタンスを再生成して行う

View部
　　　　　　(略)
Model部
　Game　　１回戦分のゲーム
　Score　　対戦記録 (コマンドパターンで譜の再現等)
　Step　　　一手 (Commandパターン)
　Board　　盤面の管理
　Player　　プレイヤ (人間およびコンピュータ)
　Strategy コンピュータ側思考 (Strategyパターン)
あと、審判(指し手交代、パス判定、パス回数、終了判定、得点の管理)とか、
ルール(StrategyパターンでOthello/Reversi/源平碁等のルール切替)
があっても良いかもな。

>>597 が改心の一撃を放った。

オセロの審判は Judge でいいのか？

>601
プレイヤーとCOMプレイヤーは親クラスかインターフェース作って
内部からは同じインターフェースで呼べるようにしたほうが
COMvsCOMやプレイヤーvsプレイヤーにするとき楽では？

ごめん俺なにか読み違ってたｗスマソ

ルールを切り替え可能にするのは良いが、
ルールに従ってJudge, Player, Strategy, (あと場合によっては Board)
の挙動を変えるのは結構めんどい。
単に別途用意したクラスと切り替えるだけなら楽だが。

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/

ルールは大規模な変更じゃなくて、ローカルルールの変更ぐらいに留めた方が良くない？
別のボードゲームだったら、それこそPlayerもJudgeもBoardやStrategyも
そのボードゲーム用に新調した方が良いんでないかと。

>596
この課題の場合、初心者が陥りやすいのは思考ロジックをボード入れようとする事だ。
そのために敢えて思考ロジックを除外してある。って事だよ、分かった？

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

>599
肝心な設計部分はあれで完了だ。
細かい実装はここにいる人間なら、出来て当然なレベルだろう？
そんなの俺にやらせるのか？

ってそのローカルルール変更が問題なのか。スマソ
俺全然ダメだな。

>>609 あんなものをオセロのテンプレートにしろと言うのか？
せいぜい使えても、いくらか改造して、しりとりゲームぐらいだろ。

>611
オブジェクト指向モジュール分割の参考にしろって事だよ。
オセロ作ってもしょうがないだろう。

まあ、春厨には閉鎖空間であるオセロ程度が丁度いいね。

>>612
>参考にしろって事だよ。
○　参考になった
○　参考にならなかった
●　使えねー奴だとわかった

>閉鎖空間
俺用語なのか単なるｦﾀなのか知らんが
どっちみち思考ルーチンに関しては触れないんだろうから
有限確定の二人零和完全情報ゲームだろうと何だろうと関係ないっしょ。

まあローカルルールのぶれは、・用語、見た目
・先行後攻、初期配置
・ボード形状
　(リバーシは8x8以外あり
　　ニップは円形で線の交点に駒を置く)
・終了判定
位。

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

実際は、コンピュータの思考部分(ComStrategyクラス)も入れ替え対象だから、
上の三番目・のように、Ruleクラスと密結合した設計はあまりおすすめできない。

なあんか段ポール箱ひっくり返した机の上が世界の全てな
オブジェクト指向を語っているみたいだな。。。

自己分析乙

反論する時に代替案も出せないようなバカはスルーで。

つか、ここでコードレビューしてどうするんのよｗ
>>1のやりたい事と全くちがうだろう。反論とかそういう問題以前の話。
そういう大きいくくりもコントロールできない>>617 >>618
は設計を語る以前の状態。

散々書いているが、ここは設計限定してないだろ？
だから最初にそれを言ったのに、コードしか語れない馬鹿PGがそれを否定したわけで。

いみふめ



またバカのグダグタ展開か

>>615
実際はルールに依存するような思考ルーチンは多いだろうから
関係はどうしても密になってしまうだろうなあ

思考ルーチンの最適化や学習を考慮すると、
ルール毎に思考ルーチンを作った方がいい。

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

すると、ルールクラスと思考クラスは密に結合する必要はなくなる。
(思考クラスが内部的に別のルールクラスを持っていて、
思考クラスの出力が偶然、外側のルールにも従っている、というイメージ)

反応するのも馬鹿らしいが、
開発プロセスの中で、要求は策定ではなく想定される可能性があり、
アーキテクチャはうやむやにされる可能性があり、テストは短縮さ
れたり省略される可能性がある。だがコードは必ず書かれる。
コードの改善ほど実り多い領域はないとエロい人もいってるぞ。

スレッドを立てたものです。

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

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

なお、私的な意見ですが、厳密に自分の意図を伝えるために実装サンプルと合わせて説明することは良いプラクティスだと思います。
書き込みを読む方も、自分の考え方と違う考え方だからといって否定するのではなく、
改善策や自分の考え方を書いてみましょう。

ちうことで、>>619は的外れの煽り止めるか別スレ立ててやれ。

>>623は、分析クラスで抽出された関連※１は
　※１ 思考がルールに直接依存
実装を考慮した設計クラスでは別の形※２になり得る、
という話。

※２ 思考は内部ルールにのみ従う。
　思考から得られた「手」は
　プレーヤが盤面上に打って初めて、
　審判チェックという形で外部ルールと関連する。

おれ、C++あんまよく知らないんだけど
石を置けるかどうかの判定が全く機能してないんでは。
置けないとこに入力しても白黒番かわっちゃうんじゃないの？

こちらへどうぞ。
>ttp://pc11.2ch.net/test/read.cgi/prog/1152383007/

>>628
　>>582は単なる天婦羅またはｳﾞｧﾁｬｰﾙだろ。
　要するに天婦羅の中身は他の奴が書けっつう。

あと、>>601=>>466-468ではワザとネグっといたんだけど、
オセロの石(Piece)は分析クラスにも設計クラスにも入れといた方が良さそうだな。

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

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

実装上の注意点：
・思考ルーチン内では通常、
　盤面をbitmap配列として保持し、石はbit列として表現される。
　ここに石クラスを持ち込むのは、ナンセンスである。
・もし、bitmap配列とボードクラス、石クラスを関連付ける必要があるのであれば、
　Flyweightパターンの適用を検討するとよい。

オセロって実際作ろうとおもったら、UI周りもめんどいんだよな。
特にアニメーション。そういう意味では電球は馬鹿なりによく作ってる。
電球の場合は、駒反転のアニメーションの状態もintの配列で兼用させて
たみたいだけど、bit列だと表現できないな。つか、ON/OFFだとおじゃば
と同じで駒無しの状態が表現できなくね？　ま、OOとは直接関係ないが。

実際はクラス設計なんてしたこと無いんだろ、お舞ら！！！
ま、クラス設計はPG(コーダー）じゃなくSEの仕事だからな
クラス設計を夢見るCoder諸君、非常加油

擦れ欲嫁

クラス設計ときれいなコードを書くのとどっちがスキルいるかと
言われれば、当然後者だわな。

// ルール記述用仮想クラス
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: ゲームに参加するオブジェクトが、ルールに準拠している事を監査/保証する仕組み */
};

// プレーヤ識別子 (二人限定版)
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 {/* 略 */ };

> bit列だと表現できないな

{黒, 白, 無し} の３状態＝約1.5bitを表現すれば充分。
2bitあれば表現できる。

>>636 爺、全体のクラス設計して、それを晒せよ

>>638
　　　　A1セルに石があるか無いか
　　　　 ↓
　　　■■□□■■□□■■□□■■□□
　　　↑
A1セルの石が白か黒か

>>639
自分でヤレ

>>633
コードは最も詳細なクラス図であり相互作用図だぞ。

>>638
bit列を使うメリットって何？ 早いの？ こんぐらい
のサイズを気にするご時勢じゃないよなぁ。

>>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/

要するに、思考ルーチン内部でたかだか数倍程度のせこい高速化をしたり、
膨大な対戦譜(数百万試合)の学習結果を要約して持っておく時に使われる手法。
高度な思考ルーチンを要求しなければ、関係ない話だ。

敢えてArrayList<Boolean>で表現してみようぜ

{黒, 白, 無し} の３状態＝約1.5bitないと表現できない。
1bitでは表現できない。

またグダグダ展開か

>>632
なに偉そうにゴタク並べてるんだよ

まあ、Ｊａｖａのインストールだけでこのスレの半数は脱落だろ
それからパス通せなくてさらに半数脱落だな。
Ｊａｖａは不便だな。

囲碁や将棋と違ってオセロは簡単に最強クラスのプログラムが組めるよ
そんな難しく考える事は無い。

パタンが単純だからな。強くしようと思ったら総当りで最終手まで
シミュレーションさせればいい。あとはスピードとの兼ね合いか。

>>645
これならどうだッ！？

Boolean(true)
Boolean(false)
null

32bit CPUのアドレス長は32 bit >> 1bit

交互に石を打つ、置けないところはだめ、もっかい入れな、っつ
盤としての最低仕様も満たさないんじゃテンプレにもならん。
いまさらオセロなんか出してきて、C++だってんじゃ
おじゃばさまの名前ってなんなのよｗ

オブジェクト指向を無視した電球ソースをこのスレで語る理由がない
ってのは誰がつっこむんだ？

>654
理由が何もないからつっこまないのでは。

スレタイに、オブジェクト指向を何故理解できないの？、ってあるけど、
オブジェクト指向を理解した、ってのはどうやって判定すんの？

コンピューターレベルは０，１，２だけど
５にしてＣＯＭ同士の対戦にしたら５分くらい考え込む。
学習能力付加して高速化できるな。

>>656
それは非常に簡単。ジャワやってます==理解している

電球、おまぃはスレ違いだ

で一体ココ電球は、ここで何をしたいの？
最強リバーシ対決なら、あっちでヤレ

おまいら最強のリバーシプログラムしてみろよ
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/

>>658
んなわけないだろｗ

>>658
このスレの存在理由問う衝撃発言

ぷぷ。底辺の連中って、煽り合いでしか盛り上がらないんだな。
まるでCOBOL現場みたいｗ

いくら本を読んで内容を理解できても、
なぜか「分かった気になってる」ように感じるんだよ。
実務に活かせるスキルになってないことを自覚しててな。
こっから脱却したいんだけど、どうすりゃいいもんやら。

実戦あるのみかと

理解してるかどうかは実はどうでもいい。
一緒に働く奴と、同じ考えだなと実感できれば
それが役に立つ技術というものだと。
構造化だろうがオブジェクト指向だろうが、
しょせん意思疎通の手段だろ。

結局のところ、設計を語りたいなら
>>240　なり >>601を出発点にすりゃえーんじゃねぇの？

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

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

ってUMLヲタが言ってたｗ

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

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

そして重要なのは修正だ。
単純なオブジェクトに対して、ルールや値を追加して、どこに機能を持たせるか考える。
多くの場合は、設計の誤りに気が付くだろう。しかし最適な場所がある。
ここで継承やインタフェースも出て来るだろう。
この修正を繰り返すたびに、モジュールの結合が緩くなり、完成度が増すのがOOだ。
是非ともこの感覚を味わってもらいたい。まあ、普通の人は1年半後かな？

そもそも、くそ2chの掲示板で図が書けないのが問題なんだよ。
せっかくの俺様のビューチフルなコラボレーション図を藻前ら
に示せないのが残念だ。なんとかしろよ、糞ゆき。

おじゃばはこっちにいたのか。
おっさんスレに帰れよ。
みんな待っているよ。

長文は動揺。

まってねえよ

シンプルでも碁盤と区別がつかないんじゃ困るだろう。

俺だったら、問題を把握したら
その>>667みたいなのはパッと思い浮かんじゃうけどｗ

問題(あるいはそこで認められている問題解決方法)を把握できないまま、
OO分析/設計するっつうのは不安だよなぁ。目隠しして歩けって言われるようなもんでｗ
分析/設計の重要な目標ってのが、
問題の正確な把握、解決策の仮定/検証、そして解決策の実現方法の明確化
にあるとすれば、それを実行するためにうまくOOを使えばいいだけの話じゃないか。
OO使うとうまくいかない〜と言うなら、OOはあきらめればいいだけの話。

>>668
学校で先生に関数は短くって習わなかったのか？

あんな糞ソース晒しといて、よく言うよこのおっさん。

なんで>>601のようなことになるのか、
さっぱり理解できん

傷つきました。仕様書無し潜伏します。

>>668
たかひろ乙。

そして、YAGNAI原則は重要。
ただオツムと問題を比較した時に、
問題の難易度が低い場合、
俺なら >>601から出発するね。

>>677
良い問題提起だ。
限られた時間の中で、解答してあげよう。
質問はないかな？

トップダウンもボトムアップも程よく折衷するのがよろし。

>>670
javaを叩くだけのオッサンスレよりこっちの方がはるかに良いだろうに。
オッサンスレはjavaを叩きすぎて、いまや焦土なっちまったからな。
>>670、老兵の待ってるオッサンスレに帰れ

>>680
いや、>>601で書いてあることは分かる。
けど、実際自分がやれ、って言われると視点というか着眼点が分からない。
どうやればそういう発想を持てるんだろか。

また仕様書無しに潜伏したな。

いる奴は同じような気がしないでもない。

> ただオツムと問題を比較した時に、
> 問題の難易度が低い場合、

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

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

だから >>601が今回のベースラインなんだ。

>>683
OOがへたれな漏れ思うに
やっぱ、OO分析できないと、>>601のようなモデリング出来ないんじゃね
ま、クラス設計の問題だよな

>>683
> いや、>>601で書いてあることは分かる。
> けど、実際自分がやれ、って言われると視点というか着眼点が分からない。
> どうやればそういう発想を持てるんだろか。

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

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

しかし、OOでオセロゲーム作るとえらいのんびりしたものが
できあがりそうだな。これじゃぁ、機能要求は満たせても、
非機能要求は満たせまい。

>>686
たかひろ様に光臨願ったほうがいいじゃない

(>>688の続き)

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

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

こんなところでいかがかな>>683

>>690
いみふめ

とにかく犬を飼うんだったら先に犬小屋を用意しろと。

>>689
> 非機能要求は満たせまい。

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

ヒント：
速度かなぁ〜？
それとも問題領域とOO手法のインピーダンスマッチングかなぁ〜ｗ

コードサイズ。

速度にしとく。快適かつ歯ごたえのある奴がいい。

オセロで2M bytes

いくら言葉を重ねても、ソースが糞ならしかたがない。
この商売はそういうものだ。

imodeのゲームは殆どが糞ソースだが、要件は満たしている。

電球の奴は弱すぎた。あれの十倍ぐらい強くなきゃな。
もちろんレスポンスも大事。

んだ、動いてしまえばこっちのもん。
コンパイルもしないうちにダメだと見切られてちゃねぇ。

>>695
>>696
それは
> 問題領域とOO手法のインピーダンスマッチング
に起因する問題だ。

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

＞ベクター化Fortran、並列化Fortran
このふたつはどう違うの？

違うよ。全然違うよ。

そして現在。

Fortranの作者 John Backusは亡くなり、
数々の並列化言語とJavaを仕様化したGLSは、
「C++に対するJava」に相当する「Fortranに対するFortress」
を提案している。
結局、Javaで数値計算〜数値処理なんて・・・GLSも本気にしていない戯言なんだ。

>>703
自問自答の練習かな？

じゃあ、自分で回答を調べて、
ここでレポートするように。

Strategyで思考ロジックを分離して、そこだけCとかアセンブラで組めば
いいんじゃね？

わぁい、先生に宿題もらっちゃった〜
たのしみだな、答え合わせ。

ところで、C++はだめでFortranならいいのはわかったけど
Cじゃだめなの？並列化ライブラリCとインラインasmで書いてあるんだけど。

>>668
あと、詳細にマジレスしておこう。

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

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

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

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

このJavolutionとかJscienceとかはIPA的にはどうなんですか？
http://javolution.org/
http://www.jscience.org/

>>710
IPAは見通しの良くない無駄な研究テーマに
無駄な研究費を配る慈善団体に過ぎない。
IPAの判断と、I,N,H,F,SGI/Cray,Sunの判断、
どちらが適切かなんて言わずもがなだ。
それでも疑問があるなら、IPAに直接言え。

いくらネタ板とはいえ、体を張って本職のいるとこへ叩かれに来る
おじゃばさまってすごい。もっとがんばれ。超がんばれ。

kusowarota

>>708
一応訂正しといてやると、
Othelloの思考ルーチンならC++で充分なんじゃないかな。
別に数値計算業界みたく、C++を今更始めるのも億劫だし、
アセンブラレベルの最適化まで面倒みたくない、ってな
専門家が居る業界ではないのだから。

>>710
> GLSは、 「C++に対するJava」に相当する「Fortranに対するFortress」 を提案している。
> 結局、Javaで数値計算〜数値処理なんて・・・GLSも本気にしていない戯言なんだ。

>714
いつオセロにもどったんでしょうか？
オセロの思考ルーチンもFortranがいいの？
混乱してるの、先生？仕様書なしさんは一人じゃないんだよ。
インスタンスはたくさんｗ

>>716
> >>708
> 一応（>>708の決め付けを）訂正しといてやると、
> Othelloの思考ルーチンならC++で充分なんじゃないかな。

あふぉか
オセロはどうやってもＯＯにしたら見通し悪いだろうが

>>718
> > 問題領域とOO手法のインピーダンスマッチング
> に起因する問題だ。

ふうん、fortranの話でC++じゃ数値演算はだめ、って流れだったんじゃないんだ。
ごめんね。オセロの思考ルーチンのお話じゃまして。

オセロネタが予想外に伸びて内心うれしい>>718

「俺の知り合いで」話する時点で説得力なかろ。

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

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

問題は、そのようなモデルは、
人間の持つ擬人化能力にはよくマッチするが、
既に計算機向けに形式化され構築された思考モデルとは
極めて相性が悪い、という事なんだ。
OO化したモデルと、計算機向けに形式化されたモデル、
どちらが求められるかは、言うまでもないだろう。

> 「俺の知り合いで」話する時点で説得力なかろ。

はぁ？なんで？
アフォな説に主語を付けただけだが。

△ OO化したモデルと、
　　計算機向けに形式化されたモデル、

◎ 人間向けに擬人化したモデル(OO)と、
　　計算機向けに形式化され最適化されたモデル、

>>723
じゃあ、何なら相性がいいの？
COBOLで作ってた、ビジネスロジックｗの世界かな？
たしかにいまそう使ってるけど、それこそ
「インピーダンスマッチング」が問題なんでしょ。

そして、もし誠実なOO研究者というものがこの世の中に存在するなら、
前者を後者に対応させるコンパイラ の開発に全力をそそぐだろう。

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

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

つまんね議論だな、机上でやっとけよ。

>>726
話が通じなかったかな？
オセロのように研究しつくされている領域では、
既存の成果の利用/流用を通じた、より強い思考ルーチンの構築
こそが課題だ。だから、少なくとも思考ルーチンの内部表現としては
> 　計算機向けに形式化され最適化されたモデル、
を使用するのが適切。

業務システム(COBOL)の場合はもっと話がややこしくて、
・人間による手作業に最適化された処理手順 (必ずしも電算機化には向かないｗ)
・COBOL向けに最適化されたロジック 　　　　　(冗長で構築しにくいｗ)
・OO屋が判り易く構築し易いと信じ込んでいる擬人化モデル (やれやれｗ)
の三つの階層が存在する。
まぁ勝手に戦ってくださいってな感想しか持ち合わせていないがｗ
ああ、ネットビジネスとか、ERPとかとの絡みで改善されてくる部分もあるかもなぁ

>>727
> 前者を後者に対応させるコンパイラ

無理。
つか、わざわざ回りくどい「擬人化モデル」でアプリを記述するのは地獄だろｗ
効果が確認されてる仕様記述言語すらろくすっぽ使われて現状でｗ

結局、 >>601のモデルはさほど間違ってないって結論でおｋ？

>729
うん、OOが役立たずなのがよくわかったよぉ。
ありがとー先生。

ちょいと待たれい、そこの町人

こちなるポストオブジェクト壷は神妙なる効果を持っておってだな、
おい、聞けよあｓｆｈんｇｓｆｊｈｍんｂｂ

ここで視聴者のみなさんに素敵なお知らせがあります。

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

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

まぁ内実を話すとだな、
世界最強！大安成就のポストオブジェクト壷にも大きな弱点があって、
この壷はオブジェクト壷被害者しか買わないって事なんだ。
つまり、オブジェクト壷の被害者が増えれば増えるほど・・・
逆に、オブジェクト壷が全然売れないと・・・
ってことで、オブジェクト壷売りのみなさん、頑張って下さいｗ

OO言語なんてそれこそ大量にあるだろう。

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

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

煽りは何も生まないぞ。

そうそう、OO壷はいいぞぉぅ

そして、OO壷を限界を感じる所まで使い込んだら、
次は是非、ポストOO壷をご購入下さいﾈ。（ぺこり

素敵索敵

>>736
ご発言、どうぞ。

高枝切り鋏を思い出した。

あと>>668、
　>>679
　>>686
　>>709
　どうよ？

おさんスレのゾンビが這い出してきたようだな。

>>686よ
　↓も関連レスだな
　>>723
　>>725
　>>727
　>>729
　どうよ？

ポストオブジェクト指向壷　しーくぁーさ

なんか、売れそうな名前じゃね？

ポストオブジェクト指向壷方法論　くっすん

ﾃﾞｽﾏで泣いてる彼女もｲﾁｺﾛさ

ポストオブジェクト指向壷BBS　おさんねる

おさん、寝た？

俺の隣で寝てるよ

古くさいＯＯ壷方法論のフィンガーテクニックで逝かしたのか。やるな

ここまで流し読み

アホコテのあまりのレベルの低さに驚いた
Javaのインストール如きで苦しむなよ
どんだけレベル低いんだよ >648
ぶっちゃけPGに向いてないとか以前に
死んだほうがいいんじゃね

「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。
これって、括弧の奴をクラスにすればいいの？
教えてエロぃ人

金はクラスにしなくていいな

>>668
> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

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


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

※1 石の色は、黒を先手、白を後手とする。

金じゃなくて「支払い」ならクラスにするかな。
現金　クレジットカード　商品券　つけ　

>>751
> 「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。

　　金を払う　
[客]　→　[店]
　 ＼
　　　 →　[商品]
　　手にとる

>>754
> 金じゃなくて「支払い」ならクラスにするかな。

　　　選ぶ
　┌　→ [商品]
　｜
　｜ 支払う
[客]　→　[店]
　　　　：
　　　[支払]

[客]　→　[店]
　　　　：
　　　 ：
　　[購入]
　　↓　 ↓
[商品]　[支払い]

>>756の点線部
　「客」と「店」の関連「支払う」を、
　関連クラス「支払い」として抽出

>757の点線部
「支払い」では一般に
店から客に何らかの「商品 (物品やサービス)」を提供し、
その対価として客が「支払い」をする。
つまり客が店から「購入」するという関係を抽出した

「客」が「店」から「商品」を「購入」し、対価の「支払い」をする。
「支払い」方法： 現金、カード、商品券

「ツケ」は債権の発生だから、「支払い」とは別扱いにした方が・・・

>>753
それ激しく手続き型だと思うんだが。。

うちは特例としてサービス金券を出していて
月3万以上お買い上げしたお客様には
10万以上の品は10%引き
それ以下は5.8%引きのサービスを行うを追加してください

>>668
> OOの場合は、まず物をイメージして、それがどのような性質（機能や値）を持つかを考える。
> オセロの場合はゲーム盤やプレイヤーをイメージして、それがどのような機能や値を持つかを考えれば良い。

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


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

※1 石の色は、黒を先手、白を後手とする。

>>760
はい？

public 店{
public:
　void 購入(客 customer, 商品 comm)
　{
　　if(customer->getMoney >= comm->getPrice()){
　　　customer->setMoney(customer->getMoney() - comm->getPrice());
　　}
　}
}

>>761
[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　　：　　 [商品　　　　 ]
[残高　　　　 ]　　　：　　 [　　　　　　　 ]
[債務　　　　 ]　　　：　　 [債権　　　　 ]
[クーポン　　]　　　：　　 [割引ルール]
[購入履歴 　]　　　：　　-----------
-----------　　　：
[商品を選ぶ]　　　：
　　　　　　　　　　 ：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↓　
[商品　　　　]　[請求　　　　]　[支払い　　]
-----------　----------　----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------　[クーポン　　]
　　　　　　　　　[割引適用　]

>>765
別の店を相手にする場合は購入履歴はどうなる？

>>767
[客　　　　　　]　----→　[店　　　　　　]
-----------　　　：　　　-----------
[買い物カゴ ]　　　：　　 [商品　　　　 ]
[残高　　　　 ]　　　：　　 [　　　　　　　 ]
[債務　　　　 ]　　　：　　 [債権　　　　 ]
[クーポン　　]　　　：　　 [割引ルール]
[　　　　　　　 ]　　　：　　 [顧客情報　 ]
-----------　　　：
[商品を選ぶ]　　　：
　　　　　　　　　　 ：
　　　　　　　　　[購入　　　　]
　　　　　　　　 ／　 ｜　　　＼
　　　　　　 　↓　 　↓ 　　　　↑
[商品　　　　]　[請求書　　 ]　[支払い　　　]
-----------　----------　-----------
[価格　　　　]　[合計金額　]　[支払い手段]
　　　　　　　　　[請求金額　]　[支払い金額]
　　　　　　　　　----------　[クーポン　　]
　　　　　　　　　[割引適用　]

基本的に返品はうけつけてないんですけど
クレーマーな客の無理やり返品・返金にも対応してください

支払いは例外が多いんだよねえどこの会社も。
只とか相殺とか贈与とか割引、お釣りが無かったのでまけた、などなど

在庫との連動がないと、そのクラスは使い物になりませんね

在庫の引きあてトランザクション処理も追加してください

それはＤＢのだろ　ＯＯじゃなくてＤＢ設計だな。
ちなみにＤＢとＯＯはものすごく相性が悪い。

>>772
DB側であろうがなかろうが、クラスと連携して業務が完結します。
それともこのクラスは業務で使わないのが前提ですか？
DBを使わないのならDBをシミュレートするクラスが必要になります。

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

おまいはトランザクション処理をクライアント側の中で勝手にやる気なのかよ

>>775
シミュレートってんだろうが、このんぽぽん！

直販の仕入れ価格と、代理店の仕切り価格がばらばらだと
その管理も考慮しなくてはなりませんね。

一次代理店と取次ぎ店と二次代理店があった場合は
もっと複雑になってきますね。どーしましょうか？

おまいら本当にバカだな。
適当だから抜けあるかもだが、こんな感じでいいんじゃね？

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

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

続く。。。

続き。。

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

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

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

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

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

さらに続く。。

続き。。

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

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

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

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

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

ちなみに終了判定は、
全体制御クラス→プレーヤークラスのget終了判定()→盤クラスのget終了判定()で呼ばれる。そうする事によってどのプレーヤーが終了したかが分かる。
でも、全体制御クラス→盤クラスでもいいかも。プレーヤーinterfaceにget終了判定持つのはちょっと違和感あるし。

オセロはもう終了しれ

>>782
(´；ω；｀)

複雑になってきたらビジネスロジック設計はスルーされました

>>779
　　　　　　　　　　[Othelloゲーム]
　　　　　　　　　　　◇　　　　　△
　　　　　　　　　　　｜　　　　　 ：
　　　　　　　　　[ルール]　　　[試合]
　　　　　　　　　　　│　　　　　◇
　　　　　　　　　　　↓　　　　　↓

　　　　　　　　　　通知ｗ
[進行係　　　　 ]←──[審判　　　　　 ]　　[記録係　　　　　]
-------------　　　　 -------------　　　　│
-------------　　　　 -------------　　　　│
[先攻後攻決定]　　　　[お手つき判定 ]　　　　│
[開始指示　　　]　　　　[パス判定　　　]　　　　│
[打ち順指示.　 ]　　　　[終了判定　　　]　　　 .│
[終了指示　　　]　　　　[得点集計　　　]　　　 .│
　　　│　　　　　　　　　　　　　│チェック　　　 │記録
指示↓　　　　　　　　打つ.　　└───┐　　 │
[プレーヤ　 ]─────────→[ゲーム盤　]
----------　2　　　　　：　　　　　 1　----------
[石の色　 　]　　　　[手　　　　]　　　　[石の配置 ]
----------　　　　 ---------　　　　----------
[手を考える]　　　　[石の色　]　　　　[初期配置　]
　　　　｜　2◇　　　[位置　　 ]　　　　[ひっくり返す]
考える｜　　│1..64◇　　　　◇
　　　　↓　　└──┤1　　　│
[戦術　　　　]　　[石　　　　]　[位置　　　]
　　　　　　　　　　---------
　　　　　　　　　　[石の色　]
　　　　　　　　　　---------
　　　　　　　　　　[リバース ]

>>785
それだと、人がプレーヤーになれなくないか？

>>786
はい？
>>601に書いたように、
　プレーヤ　∋　人、コンピュータ

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

誰か(>>668)が「継承」や「インターフェース」はまだ書くな
とか世迷言を言ってたから、省略しただけ。

>>785
戦術interfaceをimplementした「戦術クラス」と「人が操作クラス」作って
それぞれを別のプレーヤークラスにinjectionすればいけるか。
そうすると戦術interfaceって名前がいまいちだな。

>>787
　プレーヤ　∋　人、コンピュータ

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

それは分かるんだが、プレーヤーに手を考えるメソッドがあって、
戦術クラスに直繋がりだったから、どうやって人に操作渡すのかと思った。
自己完結したからおk。

　　　　　　[Othelloゲーム]
　　　　　　△　　　　　　◇
　　　　　　 ：　　　　　　 │
　　　　　[試合]　　　[ルール]
　　　　　　◇　　　　　　│
　　　　　　↓　　　　　　↓

　　　　　　　　　 通知(ｗ
[進行係　　　　 ]←─[審判　　　　　 ]　　　　[記録係　　　　]
-------------　　　 -------------　　　　　 ↑
-------------　　　 -------------　　　　　 │記録
[先攻後攻決定]　　　[お手つき判定 ]　　　　　 │
[開始指示　　　]　　　[パス判定　　　]　　　　　 │
[打ち順指示.　 ]　　　[終了判定　　　]　　　　　.│
[終了指示　　　]　　　[得点集計　　　]　　　　　.│
　　　│　　　　　　　　　　　　　│チェック　　　　.│
指示│　　　　　　　　　　　.　　└─────┐│
　　　↓　　　　　　　　打つ　　　　　　　　　　　↓│
[プレーヤ　 ]────────────→[ゲーム盤　]
----------　2　　　　　　　　　：　　　　　　 1 ----------
[石の色　 　]　　　　　　　[手　　　　]　　　　　[石の配置 ]
----------　　　　　　　 ---------　　　　　----------
[手を考える]　　　　　　　[石の色　]　　　　　[初期配置　]
　　　　△　　　　　　　　.　[位置　　 ]　　　　　[ひっくり返す]
　┌─┴──┐　　　　　.◇　　　 ◇
[人　　　]　　[ｺﾝﾋﾟｭｰﾀ]　 │　　　└┐
-------　　　↓　　　　　[石　　]　[ 位置 ]
-------　　[戦略]　　　 .------
[手入力]　　　　　　　　　 [色　　]
　　　　　　　　　　　　　　　------
　　　　　　　　　　　　　　 .[ﾘﾊﾞｰｽ]

支払いは例外が多いか。ならば

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

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

かな？相当例外的な支払いは最悪その場でローカルインナークラス生成とか。

>>オセロ
「その場でユーザ入力してもらう」って戦術を作れば
何も人間プレーヤーとコンピュータ分ける必要ないんじゃ。

>>768
[客　　　　　　] ────→ [店　　　　　　]
-----------　　　：　　　　　-----------
[返品商品　 ]　　　：　　　　 [商品　　　　　]
[口座　　　　 ]　　　：　　　　 [返品ルール. ]
[債務　　　　 ]　　　：　　　　 [債権　　　　 ]
[　　　　　　　 ]　　　：　　　　 [顧客情報　 ]
　　　　　　　　　　　：
　　　　　　　　　[　返品　　 　]
　　　　　　　　　-----------
　　　　　　　　　-----------
　　　　　　　　　[ルール判定]
　　　　　　　 ／　　　│　　　　 ＼
　　　　　　 ↑　　　　↓応じる 　↓応じない
[返品商品 　]　[返金　　　　] 　[リジェクト　 ]
-----------　----------- 　-----------
[購入価格 　]　[返金方法　] 　-----------
[返品送料 　]　[返金金額　]　 [客に通知　 ]
　　　　　　　　　　　　　　　　　　 [商品再返送]

返品は例外で返すべきでは

>>790
石instanceは盤クラスが管理してるから、
記録係は盤がやってもいいんじゃね？
記録方法の変更は石管理のやり方換えればいい訳だし。

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

あと得点集計は別クラスがいい希ガス

>>791
ちょっとまてそれはおかしくね？

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

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

だろ？

>>769
[支払い　　 ]
-----------
[支払方法[]]
[合計金額　]
-----------
[確認　　　　]
　　　　◇
　　　　｜
[支払方法]
---------
[金額　　　]
[確度　　　]
---------
[確度ﾁｪｯｸ]
　　　　 △
┌──┼──┬─────┬─────┬─────┐
現金　　　　　金券　　　　　クレジット　　　　債権相殺　　　クーポン/割引/オマケ/贈与
--------　　--------　　--------　　　　
入金済　　　 有効性　　　 信用　　　　　　　
--------　　--------　　--------
入金確認　　使用可？　　与信処理

>>797
支払いについてはそんな感じになるかなあ

>>795
1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。
　現実の対戦記録は、プレイヤーの打ち手の系列だったりする。
　だから、プレイヤー→盤→記録係　という流れが自然。

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

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

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

　ただ、似たような曖昧さもある。例えば時間制限ルール。
　現実には時間制限は進行係がやる。理由は下っ端だから？

× 1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。

◎ 1. 「盤」の状態変化の記録を、記録係に委譲する、と考えればおｋ。

客店商品の設計してる人達って要件も定義しないで
どうして設計出来るのかと。。
レス読むと仕変が入りまくってぐちゃぐちゃになってきてる訳だが。。
デスマ直行プロジェクトだなww

>>795
1. 「盤」の状態変化の記録を、記録係に委譲する、と考えればおｋ。
　現実の対戦記録は、プレイヤーの打ち手の系列だったりする。
　だから、プレイヤー→盤→記録係　という流れが自然。

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

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

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

　ただ、似たような曖昧さもある。例えば時間制限ルール。
　試合へのルール適用という意味では審判の責務なのだが、
　現実には進行係に委譲されるｗ　理由は下っ端だからかｗｗｗ

>>801
それがジャワポンSEオブジェクト指向宗教家の標準仕様です

> 客店商品の設計してる人達って要件も定義しないで
> どうして設計出来るのかと。。
> レス読むと仕変が入りまくってぐちゃぐちゃになってきてる訳だが。。
> デスマ直行プロジェクトだなww

上に出ているような「仕変」は、
実はよくある一般的な「仕様」の詳細部に過ぎない。
つまり、経験と常識があれば考慮済な話。

>>801
どこまで仕様変更に耐えられるかを通じて
OOPが出来ているかを試してるんだろうが

>>771
> 在庫の引きあてトランザクション処理も追加してください

ｋｗｓｋ

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

直販しているなら問題なっしんぐ。
直販していないなら代理店紹介して終了。

直販&&一次代理店&&取次店&&二次代理店&&紹介手数料支払いルール&&
大量業務販売卸

同一商品の仕入先は多数でその時の相場で変動する

在庫をストックする場所は複数で、在庫連動をマネージする仕組みも必要

輸入品のため、予約注文はインボイス日時の予想をするシミュレータが必要

>>808
それは価格付けルールに関する問題かと。
つまり、商品仕入れ時に個別の値段付けをするか、
あるいは注文と商品の対応付けの際に、値段を付け直すかｗ

>>799
>1. 「盤」の状態変化を記録係に委譲する、と考えればおｋ。

了解

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

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

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

>3. いみふめ
>　 審判の責務は、試合がルールを遵守し、結果を出す事にある。
>　 試合の結果は終了判定と得点なのだから、得点集計は審判の責務。
確かに審判が得点集計を行ってくれと指示を出す。
ただし集計の責務は審判には無い。
通常のスポーツでも審判は判断するだけで、集計は別物だろ？

個人のお客でもある一定ロット数以上の注文ならば
業務販売卸価格を適用できる
この場合は個人客の監査を行い、問題が無ければ顧客リストに登録できる仕様

>>809
既に問題領域の外側に発散した感があるな。

>>810
配送日時はモデルの対象外になってるよね？

>>805
おまいのプロジェクトはデスマ確定だなww
要件確定しないと仕様は無限に増えるぞ？

>>814
>>815
対象範囲を超えているのは理解済み。あえて、クラス疎結合学習のための
例題として出している。

>>815
要件を確定することは重要だがそれはまた別の話だろ
ここはオブジェクト指向スレだぞ？

>>815
「ビジネスロジック設計」スレたてろ　んぽぽん！

さあさあ、んぽってきました。

>>817
ちょ。。おまえら。。
要件確定→クラス図作りました→仕変がありました→どうしましょう？
っていう流れだったらOOのプラクティスとしても意味がある。
だが、今のままじゃぐちゃぐちゃになって終わるだけだぞ。
実際すでにDBの領域にまで突入しようとしてるじゃないか？

オセロだと都合が悪いからなＯＯには
店の売り上げ管理でもＯＯだと都合が悪いから話を中断させようと必死だ。

>>821
お前はカエレ

実用的なのでなんでもいいから具体例だしてみ＞ＯＯ厨

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

が真実かな？

>>823
書き捨てのシステム以外全部

>>812
はいはい。
一部の意見は参照に値するが、
別の一部の意見は主観的ブレの範囲なので
ご自由にどうぞ、という感じ。

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

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

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

とりあえず長々文章書くよりも、>>793の図を修正したらどうか、と。
図の編集には、2chツールのAAエディタがｵﾇﾇﾒ。
　　http://aaesp.at.infoseek.co.jp/

「再利用というものがＯＯではじめて可能になった」
というのは完全な捏造だ。

OOを否定する人間はOOも構造化も
独立性を高め依存度を低くするための手段に過ぎず
本質的に同じものだと言う事を理解していない。

だから上の例で疎結合学習しようぜ

疎結合なら絶対良い、というのであれば、
単純で汎用性の高いXMLファイルをやり取りするようなインタフェースで、
各モジュールをWebサービス化すればいい。

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

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

話を現実から出発しないと、空理空論に終わる。

ルール　　　＝監査基準
審判　　　　 ＝監査役(経営, 品質, 環境, etc)
試合進行係＝社長
プレーヤ　　＝社員

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

上の方に余分にあるクラス (ルール、審判、進行係) は
要するに「監査パターン」っつこったｗ

ソース書きながら考えようぜ

【分析モデル】
　　　　ルールに従う
試合───────→ルール
　　　　　　　　：
　　　　　　　審判


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

【設計モデル２】

　　　　監査　　　　保証
試合←──審判──→ルール
　↑　　　　　 │
　│進行　　 │アドバイス（ｗ
　│　　　　　 │
進行係 ←─┘

んじゃ、まずはXMLの定義からはじめないと

きましたねＸＭＬ
ＷＥＢの本には必ずといっていいほど出てくるＳＯＡＰ,ＵＤＤＩ,ＷＳＤＬ
だが、いまだ日の目を見てない、実物みたことない、抽象論。
JavaScriptや鯖サイＪＡＶＡ,ＣＧＩ(Cがネイティブで使えるし)があるんだからいいじゃん！
ＸＭＬ？平文ネットに流すのか？＞ならSSLにすりゃどーよ
と言う声も。
じゃあ、SOAPの利点＞広域分散処理に関しては？
＞お前やれよｗ
以下ループｗ

AJAX全盛期にしては
突っ込みの古臭さに唖然とした。

REST、とかも良く聞くよな。

>>826
お前詭弁ばっかだな
全く論拠がねぇ
まともな議論ができるようになってから出直しな

　　　　　　　　[Othelloゲーム]
　　　　　　　　△　　　　　　◇
　　　　　　[ 試合 ]◇─[ルール]
　　　　　　　　◇　　　　　　↑従う
{ ルール, プレーヤ,　　　{ 審判, ゲーム盤,
　　　記録, 進行係, }　　　石, (進行係)...}
　　　＿＿＿＿＿＿__　　　　　　　　 ＿＿＿＿＿＿＿
　　　[進行係　　　　 ]　　　　　　　　 [審判　　　　　　 ]
　　　=============　　　　　　　　　==============
　　　[先攻後攻決め]　　　　　　　　 .[　　　　　　　　　 ]
　　　[開始指示　　　]　　　　　　　　 .[お手付き判定　]
　　　[打ち順指示.　 ]←─────[パス判定　　　 ]
　　　[終了指示　　　]←─────[終了判定　　　 ]
　　　￣￣￣|￣|￣￣　　　　　　　　　 ￣￣￣￣￣￣|
　　　　　　　│.│開始/終了/　　　　　　　　　　　　 .│
　　　　　　　│.│手戻り/譜の再現　　　　　　　　　 │ﾁｪｯｸ
　　　　　　　│.└────────────┐　│
　.＿＿＿＿↓　　　　　　　　　打つ　　　　　　　.↓__.↓＿＿　　記録
　[プレーヤ　 ] ───────────→ [ゲーム盤　]────→┐
　----------　2　　　　　 ＿＿：＿＿　　　　1 -----------　　　　　 [記録係]
　[石の色　 　]　　　　　　　[手　　　　]　　　　　[石の配置　]←────┘
　----------　　　　　　　 ---------　　　　　-----------　譜の再現、手戻り等
　[手を考える]　　　　　　　[石の色　]　　　　　.[初期配置　]
　￣￣△￣￣　　　　　.　　[位置　　 ]　　　　　.[ﾘﾊﾞｰｽ　　　]
. .┌─┴──┐ 　　　.　　 ￣◇￣◇　　　　　 [集計　　　　]
＿|＿＿_　　＿|＿＿＿　　 ＿│＿└─┐＿　 ￣￣￣￣￣
[人　　　]　　[ｺﾝﾋﾟｭｰﾀ]　　.[石　　]　　[ 位置 ]　
=======　　 ￣￣ |￣　　　------　　￣￣￣
[手入力]　考える↓＿　　 .[色　　]
￣￣￣　　　[　戦略　 ]　　 ------
　　　　　　　 ￣￣￣￣　　 .[ﾘﾊﾞｰｽ]
　　　　　　　　　　　　　　　　￣￣￣

ＯＯなんて詐欺商売からは足を洗ってまっとうに生きろ。

>>840　電球
世のため、早く氏ね

OO壷売りの皆様、お疲れです。

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

あと、OO壷売りに騙されたと感じたら、
すぐご連絡下さいネ。
即座にポストOO壷の説明にあがりますのでｗ

オブジェクト指向ってさ、理解は誰でもできるんだよね
使いこなしが出来ないだけでさ

すげえ延びてんなこのスレ。。

>>839
こんなに大きな設計になる前に、一度コードに落とすべきだな。

>>843
使いこなすといっても
目的もいろいろだしな。
たとえば、保守性を上げたいのか
拡張性を上げたいのかの違いだけでも
使いこなす方法が変わってくるだろうしな…

>>825
せっかくまともに会話出来る相手がいたとおもたのに【残念です。】

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

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

>>839
うんうん。それかなりイメージと合ってる。

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

ルールクラスで統合的にルールのチェックを行う。

>>826
再利用なんて激しく昔からあるし。
標準ライブラリって名のつく物なんてみんな再利用の為に作られてる。

OOだと再利用出来る(やりやすい)なんて誰が言い出したんだ？アホかと。。
OOなんて大きな事象を細分化する考え方なだけで、
再利用出来るかどうかは設計の内容によるもの。

荒らしはスルーしれ

>>846
はいはい。

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

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

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

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

で、どこが矛盾してるって？

とりあえず二人とも茶でものんでもちつけ

>>846
　はいはい。

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

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


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

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

　>>825 ルールは、（略）　審判と同一視するのは不自然。
　>>830 　
　> ルール　　　＝監査基準
　> 審判　　　　 ＝監査役(経営, 品質, 環境, etc)
　> 試合進行係＝社長
　> プレーヤ　　＝社員
　>
　> と考えれば、
　> ・実行役が監査したり、
　> ・監査基準と監査役が同一物だったり
　> したらおかしいのはすぐ判るだろｗ
　>>850 「ルールは 【注：審判のように】 固有のアプリに強く依存した形で表現すべきではない」というだけの設計上の気持ち

なんだかお互いのこだわりを主張しあってるにしか見えんな

>>850
>で、どこが矛盾してるって？

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

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

>>851
分かった。飲んどくww

>>853
確かにそうだなw
実際の現場でもよくある事ww

何故、明らかに別物のクラスを
一つにマージしようとするのか、
その意図が理解できない。

>>240の例みたく、
画面１クラス〜画面１０００クラス、
画面１専用のロジック１クラス〜ロジック１０クラス
・・・
なんて訳わかんないことやってるわけじゃないしｗ

>>854
あ、わかった。君は粘着質だ。

苦心惨憺で設計したことが、コードに落とすとあっさり実現できてしまったり
その逆もあったりする。
ので、とにかくコードを書いた上で議論したほうがいいとおもう。

>>853
　>>825 主観的ブレの範囲なのでご自由にどうぞ、という感じ。

非常に下らない言い争いを始めた厨房が出てきたんで、
この件へのレスはこれで最後にしておく。後はスルーする。

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

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

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

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

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

２の後半部＝「ルールをアプリと密結合すべきではない」
これが、このｽﾚ >>240 以降の一貫したテーマ。

>>829
>現実に密結合でどうしようもなくﾃﾞｽﾏｰﾁ化したシステム(例えば>>240) 
>をどうしたら良いか

そんな政治や営業上の問題を、
技術で解決しようとするなよ・・・

>>857
粘着はしない。面倒だから(´・ω・`)
納得がいくまで議論したがり質かな？
でも、端から見ると粘着か。。。ORZ

亀田の相手のパンチなんかへろへろだよね。

あー。そー考えちゃうかー。

んー。どうでもいい。

客やﾃﾞｽﾏｰﾁ開発屋の立場からすると、
「これまで手数と人員をかけてきた旧型大規模システムが、
　PCサーバ数台上に簡単に再構築されちゃーたまらん」
って、考える人も居るかもなぁー。俺はどーでもいい。

>>240の密結合ってのは、要するに、
画面設計の下に、ビジネスロジックをぶらさげちゃったのが原因なんだよね。

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

マイグレーション商売では
　・COBOLから業務フロー抽出
　・業務フローからJavaコード作成
なんつーのがメーカ標準だったりするから、
画面とロジックを分離するっつー肝心な事を
一切努力しない。
バカそのもの。いや判っててそうしてるんだよな。
でも、判っててそんなアフォな選択するのはやっぱアフォ。

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

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

とか夜道で誘われて堕ちていく人も多そうな予感

>>864
>画面とロジックを分離するっつー肝心な事を 
>一切努力しない。

だって、そんなことすると、
「この設計書、全然意味ワカンネ」って言われて
没になってしまうんだもん・・・

なんか最近スレに勢いがあるな・・・
春だから？

今年度いっぱいで契約を切られたドカタが暴れていると聞いてとんできました。

画面とロジックがベッタリって、
例えばマイクロソフトあたりが好きなんだよなぁ。

Model/ViewをControlで分離するMVCの代わりに
Document-View アーキテクチャとか、
VisualStudioやVBAで、画面にちょこちょこコールバック書いて
サブルーチン数本作って、業務ツールいっちょあがり、とかｗ

>>868
低学歴乙

図星でしたか・・・。ごめんね。

いや、つか頭悪い奴が沸いてるなぁーって思っただけ。
ごめん、キミを侮辱するつもりはないんだ。

いえいえ侮辱されたつもりはありませんでしたが、四月からどうするんですか？

>>868
そういう奴って、
契約を切られて暇なものだから、
ついつい、皆が自分と同じように
２ｃｈに即レスするもんだと
勘違いしてしまうんだよね・・・

マイグレーションの対象になるような、COBOLとかの開発環境って
いったい今時どんなになってるんだろうね？
もう10年以上前に遠目に見た時は、なんか今のJ2EEと同じ雰囲気で
画面とロジックはそう密接には見えなかったけどｗ
10年位前になると、なんかVisualStudioもどきのGUIとか、CGIまで書ける環境ｗ
になっちゃってたんだよね。でもそんな時代のアプリなら、マイグレーションしないでしょう。

すると、すげぇ厨臭いCOBOL開発者の開発方法論ってのが
「画面指向設計」だったりするのかな？よくわかんね。

おまいら、今日は土曜日ですよ？

オブジェクト指向分析/設計概論オブジェクト指向の大きなメリットの一つはその再利用性の高さにあります。
オブジェクト指向では以下のテクニックを用いて再 ...
(2)はオブジェクト指向による再利用。最下層の部分が再利用できるのは(1)の場合と同じですが、それに加えてプログラムの ...

現在世間に蔓延しているオブジェクト指向の説明では、 むしろ納得しない方がまともだとさえ思えます。
「オブジェクト指向を使えば、生産性が飛躍的に上がり、 プログラムの見通しがよくなり、再利用性も高まる」と聞かされて、
「ホントかあ? ...

Amazon.co.jp： オブジェクト指向における再利用のためのデザイン ...Amazon.co.jp：
オブジェクト指向における再利用のためのデザインパターン: 本:
エリック ガンマ,ラルフ ジョンソン,リチャード ヘルム,ジョン ブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,
本位田 真一,吉田 和樹 by エリック ...

お前、心の病気だろ。

オブジェクト指向の現実ソフトウェアの開発を繰り返していくたびに、再利用できる部品がどんどん揃って、開発は楽になっていき
、開発コストも小さくなっていく、というのが、オブジェクト指向を薦める際の謳い文句であった。
だが現実には、ソフトウェアを部品として再利用 ...

オブジェクト指向技術の基本概念オブジェクト指向では、今の比喩でいう仕事の実行主体のことをオブジェクトと呼んでいます。 ...
こうのように、継承の概念は、ソフトウェアの再利用性を確保する役目を果たし、生産性の向上に役立ちます。
標準的なクラス群を部品として用意しておき、 ...

「オブジェクト指向　再利用」でぐぐるといっぱい出てくる

大丈夫か？

スレが伸びてると思ってみたら
キ○ガイ>>779が勝手なOO論で暴れてるだけwww
ここはいつから厨の隔離スレになったんだ。激ワロスwww

別スレ立ててそこでやれよ。

ココ電頭ダイジョブ？

>>電球
OOが再利用性に有効なのは明らかだから、別に暴れなくていい。

基地外は自分の頭が異常だとはわからない。だろ、ココ電

OO分かる奴、OOと相性いい奴はOOやれ、
OO分かんない奴、OOの有効性に懐疑的な奴は、OOやめとけ
でいいと思うんだけど、ことプロジェクトとなるとそういうわけにも
いかないんだよなぁ。全員が同じ手法でやってもらわなきゃめちゃく
ちゃになっちまう。なぁ、蛍光灯さん。

|　釣れますか？　　　　　　 　　　　　　　　 ,
＼　　　　　　　　　　　　 　 　 　 　 　 　 ,／ヽ
　 ￣∨￣￣￣￣￣￣￣ 　 　 　 　 ,／　　　ヽ
　　 ∧＿∧　 　 　 　 　 ∧∧　　,／ 　 　 　 　 ヽ
　　（　´∀｀） 　 　 　 　 (ﾟДﾟ,,),／　　　 　 　 　 　 ヽ
　　（　　　　）　　　　　　(|電　つ@　　 　 　 　 　 　 　 ヽ
　　｜ ｜　| 　 ＿＿_ 〜|球　|　　　　　　　　　　　　　 　 ヽ
　　（_＿）＿）　|――|. 　∪∪　　　　 　 　 　 　 　 　 　 　 ヽ
　　￣￣￣￣￣￣￣￣￣￣￣￣|　　　　　　　　　　 　 　 　 ヽ
　　／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ　゜~ ~。゜　~ ~　~ ~~　~ ~~　~ ~~　~~　~~
　　⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡　〜　〜〜　〜〜　〜〜　〜　〜

>>768 基本的に返品はうけつけてないんですけどクレーマーな客の無理やり返品・返金にも対応してください
→爺曰く、「ビジネス例外」処理サーバで処理との事。ｗｗｗ

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

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

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

>>813 個人のお客でもある一定ロット数以上の注文ならば業務販売卸価格を適用できる
　　　　 この場合は個人客の監査を行い、問題が無ければ顧客リストに登録できる仕様
→価格付けルール＋顧客管理システムへ丸投げだろｗ

過去の資産を再利用するためには、
資産管理が重要です
まともな設計書が書かれていないデスマーチPJの資産を
再利用するなんてとてもとても
何を再利用したらいいか分かんないんだからね

こぴぺすりゃいいんじゃない

そこでだな、RDF資産管理という壷を薦めてもだな・・・・・・

芸がないな。以前のJavaスレのようなこみ上げてくるようなおかしさがないね。

こみあげる嘔吐感。

まぁコード感覚が研ぎ澄まされた理系サイエンティストの俺に言わせればだな、
「再利用」っつうのは
・古いアプリのコードを再利用する (例：COBOLのビジネスロジックを取り出す)
っつうしょうもない例ばっかじゃなくて、
・コピペで埋め尽くされたダメコードを書かなくても済むようにする
っつう差分プログラミング的側面が大きいんじゃないか、と。
そして、少しだけ新しい世代の差分プログラミングとして、
・アスペクト指向
・メタクラス・プログラミング
みたいなのをもっと広めてもいいんじゃないか、と。

>>889
全てを一つの手法に統一する必要はないだろ？
お前のPJでも全てがOOに統一とか、まずなってないよ。

たとえば、デバイスドライバやOSのAPIはどうよ？
結局、うまく切り分けて設計してるだけで
それに気づいてないのはお前の視野が狭いから。

>>895
お前はいつもの薬飲んで早く寝ろ。
眠れなかったらおさんスレで遊んでろ。

アスペクトがなぜ流行らないか疑問。
あの便利さは異常

あと、コンピュータ・サイエンス出身の若手に頑張ってもらうネタとして
・純関数型プログラミング
・ルールベース・エンジン
なんて笛や太鼓も活用したらえーじゃないか、と。

たかひろが、「一階述語論理」「一階述語論理」騒いで閉口した事があったけど、
要するに Haskellのように型推論を備えた純関数型言語を、
今で言うSOAのルール・エンジンみたいな形で使いたい、
ってそういう話だろ。な、たかひろ？

・純関数型プログラミング
・ルールベース・エンジン

これ使う層は被らなそうだな。。
だがビジネスロジックはオブジェクト指向より
関数型プログラミングの方が適合しそうな気もする。

日本語でおｋ

> だがビジネスロジックはオブジェクト指向より
> 関数型プログラミングの方が適合しそうな気もする。

CommonLispでアプリサーバ書いてる某苫※地氏の所へ
生贄お一人様ご案内〜

> だがビジネスロジックはオブジェクト指向より
> 関数型プログラミングの方が適合しそうな気もする。

恵比寿のO社へ一名様ご案内〜ｗ

あ、やっぱ誰でも思い付くのか。。

個人的にOOPLの一番の恩恵はスコープがもう一段増えた事だったり

２段じゃないの？

オブジェクト指向で、構造体が必要に感じるようではまだまだｗ

>>909 クラスとネームスペース/パッケージ？

言語によっちゃ、内部クラスってのもあるな

あ、あー、そこのチミチミ
チミが埋め立てにかかっているのは百も承知だが
新しいスレにはこのスレのネタをふりまきまくる予定だ
って事もお忘れなくｗ

オブジェクト＝＝インスタンスではまだまだぜんぜんｗ

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

凝集度は強い方がいい。結合度は弱い方がいい。糞レスは無視しした方がいい。

関数＝＝メソッドではほど遠いｗ

某企業の基幹システムの保守をやってますが
メンテナンス性が一番悪いのがＯＯちゅが書いたやつだけど
どうしてくれる？
古参の主任もお手上げだ。
なぜなら全部書き直さないとまともにならないからあきらめてる。
とにかく可読性が悪い。
俺だから読めるけど、前任者と前々任者はお手上げだった。
ノイローゼになってやめたようだ。

推奨ワード：◆tIS/.aX84

>>918
あんたこの前メンテナンス性の良し悪しはコード書いた奴に拠るっていってたじゃないの。
OOに責任転嫁するなよ。

そもそもが自己愛性人格障害の典型的症状に近いので、
プライドは高いために自分の無能さに目を向けることができずに、
他者を批判することでフラストレーションを解消しようとしている
だけと思われ。
まとまった業績のひとつも上げれば頭も冷えるのだが、
焦りがあるので長期的な取組みができず、目先の目新しそうなもの
（で、ちょっとよさげなもの）につい飛びついてしまう。
そういう香具師は、トイ・プログラムでもいいから、オブジェクト指向設計
でプログラムを一本インプリメントしてみて、プチ達成感でも味わうのが
よろしいかと。

汎化＝＝汎用のああ勘違いｗ

>>918 あー、それ書いたの俺だ。すまん、まだ駆け出しだったもんで。
今じゃばっちり理解したから、今度からはうまく作るよ。ゴメンな。

Javaでさ、クラスメソッドにfinalつけてる奴どんだけいる。
これを正しく書ける/書けない/そもそも意味が分からないで
とりあえず、OO意識度の大雑把な３段階評価はできるぜ。

>>918
>なぜなら全部書き直さないとまともにならないからあきらめてる。 

あきらめて済んでしまうようなメンテなら
やらなければ良いんじゃないの？

俺がコード書くならあんなところでＯＯ使わないね　こんなのだ

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

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

構造化だけなら２０００行、一本で終わるのに、クラスを１０も２０も作ってがばかかあほかと

>>924
オセロのことならあれは「準定数」だ。定数ではない。
拡張したとき変更される可能性があるのでああした。

iアプリのリバーシってやっぱこういうコードになってるんだろうなぁ。