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

「客」が「店」に入って「商品」を手にとって「レジ係」に渡して「金」を払う。
これって、括弧の奴をクラスにすればいいの？
教えてエロぃ人

金はクラスにしなくていいな

>>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　　　│
[戦術　　　　]　　[石　　　　]　[位置　　　]
　　　　　　　　　　---------
　　　　　　　　　　[石の色　]
　　　　　　　　　　---------
　　　　　　　　　　[リバース ]