-OOP限定-プログラム設計相談室

-OOP限定-プログラム� ..

277:デフォルトの名無しさん
08/06/21 06:02:48
>>276
"二つの値Constructor"に任せればいいんじゃない？
もしくはMul/Demultiplexerとか？

278:デフォルトの名無しさん
08/06/21 10:29:05
>>276
Comm クラスは汎用的なシリアル通信だけを行うユーティリティクラスで
いいんじゃないかな。制御プロトコルの知識は Monitor に持たせる。

279:デフォルトの名無しさん
08/06/21 12:11:06
>>276
おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。

280:デフォルトの名無しさん
08/08/05 22:06:37
>>279
>おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。

メッセージI/FとパーサーI/F又はどれか一つ用意して
メッセージの詳細はベンダー毎に実装するのが一般的かと思う。

281:デフォルトの名無しさん
08/08/08 03:31:53
>>271
ちょっとOO分析っぽいことやってみたかった．

#　[実験]で[使用する][シリアルポート]から[遠隔操作できる]
#　[温度][調節][機能]付きの[水質モニター]を[管理する]
#　[1分毎]に[水質データ]と[水温]を[取得する]
#　[PC]から[温度]の[管理値]を[変更できる]

必要な名詞(オブジェクト)
　シリアルポート，温度，水質モニター，1分毎，水質データ，水温，温度，管理値
足りない名詞
　タイマー
必要な動詞(メソッド)
　操作，調節，管理，取得，変更

ここまでやったけど別に何を作ろうというわけではない

282:デフォルトの名無しさん
08/08/10 12:13:24
温度がオブジェクトかよー
1分毎もかよー
水温・温度もかよー。

283:デフォルトの名無しさん
08/08/10 13:31:40
当たり前すぎますよねー＾＾

284:デフォルトの名無しさん
08/08/20 20:05:43
クラスの設計に関して悩み中です。
例えば以下のような必要とされる要素が有ったとします。
(要素内容はでたらめです。)

・コード/名称/メッセージ/結果/色/高さ/幅
　/追加日/更新日/削除日/…(全部で20要素ぐらい)

処理1 … コード/名称/メッセージ/結果
処理2 … コード/結果/色/高さ/幅
処理3 … 結果/色/更新日
処理4 … 削除日

各処理は、クラスに個別分類できる処理になり、各処理に少しずつ上記要素が
絡んでくる状態になります。

このような場合、どのようなクラス設計が適していますか？

現在は、コード/名称～などの20要素ぐらいをBaseクラスにして、
処理1～4までを継承させています。
ただ、こうすると必要の無い要素まで入ってしまい、もっとすっきり
させたいなと思っています。

285:デフォルトの名無しさん
08/08/21 02:24:17
>>284
> ただ、こうすると必要の無い要素まで入ってしまい

この時点で継承を選ぶのがおかしい。意味のある単位に切り分けよう。
問題の切り分けじゃなくて、登場人物の切り分けを意識した方がいい。

例えば色／高さ／幅ってGUI上の属性情報なんじゃないの？
処理1と処理4でそれらの情報を使用しないってのなら、
ぱっと聞いただけでも処理１～４は継承関係上の兄弟とは思えない。

> このような場合、どのようなクラス設計が適していますか？

適切な切り分けの単位は要件仕様やその他の背景によって異なるよ。
とっかかりがないなら、それらのデータモデルを構造体化して、
処理の引数に渡してしまえばいい。

286:デフォルトの名無しさん
08/08/21 15:48:42
>>285
どうもです。
いえ、GUIの属性とかではありません。

サーバーへコマンドを投げると上記の値が返ってくるイメージです。

処理1なら
　1.「コマンド処理1」をサーバへ送信

　2.「コード/名称/メッセージ/結果」がサーバより返ってくる。

　3．処理1の処理を行う。

処理2なら … と同じ様な処理が複数あります。

287:デフォルトの名無しさん
08/08/21 23:32:47
サーバーにコマンドを投げるとかいつ説明したよ。
それで相手に適切なクラスの分け方を聞いたわけ？
一応必要なアドバイスは>>285に入ってるから、熟読して悩め。

>>286の情報だけで何を悩めばいいかを挙げるなら以下くらいかな
・全ての処理で共通する送受信データの基本情報（必須情報）って何なの
・送受信データ全体を木構造に表すとどうなるの（構造体のメンバに構造体を持つかなど）
・送受信データに対して、それを継承するって適切なの
　（データモデルとビジネスロジックは普通分けるがね）

恐らくだが、以下みたいな感じに落ち着くんじゃないか
・処理1,2,3,4ってのは、データモデルを引数に受ける関数ポインタ（Javaでいうリスナ）になる
・コマンド処理1,2,3,4と関数ポインタ（Javaならコマンド名のgetterとリスナをセットにしたクラス）と
　送信データを引数とし、受信データを戻り値とする通信クライアントクラスが必要（C++なら受信データも引数で受ける）
・送受信データ中、基本情報以外の情報（構造体メンバの構造体）で使用しないものはNULLを入れる
　基本情報以外が後からいろいろ増えるなら拡張情報をMapで持つ手もある。シリアライズ（デシリアライズ）がいるが。
　最近の流儀だとXMLを使うのも悪い手ではない。（個人的にはJavaやC#ならこれにするな）

あなたのプロジェクトの答えを書いたつもりはないので、参考になるなら参考にして、後は悩め。

288:デフォルトの名無しさん
08/08/21 23:34:15
訂正
×受信データを戻り値とする
○受信データを関数ポインタの引数にしてその関数を実行する

289:デフォルトの名無しさん
08/08/31 16:08:07
ちょっとここの主題とずれるかもしれませんが、
ブラウザ - Webサーバー - APサーバー - DB
という一般的な構成でのエラーチェックで質問です。

入力データのチェックをするときに、未入力や不正文字はMVCのCで
チェックして、DBに問い合わせないとわからないチェックはMでいいですよね。
注文入力をするときに、数量の未入力は前者、在庫チェックは後者です。

でですね、「数量の上限」や「不可能な注文の組み合わせ」みたいに
「ビジネスロジックだけどDBに問い合わせる必要はない」というチェックは
APになげると余計な通信が発生するのでWebサーバーでやろうと思ってます。

Webサーバー側のpackageには原則Actionクラスしかないのですが、
このpackage配下にチェッカークラスを置くのに違和感を感じます。
注文形態が複雑でActionがいっぱいあるので、注文BaseActionを
作ってTemplateMethodパターンでフローを決めてるのですが、
だらだらとバリデートを書くのもフローがわかりにくくなって嫌です。
注文クラスそのものに書くべき？

290:デフォルトの名無しさん
08/08/31 16:34:20
TemplateMethod 使ってるなら、BaseAction に空の Validate メソッド
用意してフローに組み込み、具体的なチェック内容は派生クラスで実装
すればいいんでないの?

なぜ「だらだら」になるかが知りたいところ。

291:デフォルトの名無しさん
08/08/31 16:49:46
そこまではやってるんだけど、さらにその中で「注文条件がこれだったら
これは不可で」「数量をparseして文字列だったらこのエラーメッセージで」
みたいな処理が10以上あって、ロジックは共通なので、その個別のValidateを
BaseActionに書いてたんです。個別Validateのどれを呼ぶかは
Actionによって異なります。で、このチェッカーって切り出すべきだと
思うんだけど、actionパッケージの下にチェッカークラス置くのって
変だよなーと思って相談したわけです。

292:デフォルトの名無しさん
08/08/31 16:50:33
だらだらなのはBaseActionに個別のValidate処理がいっぱい並んでたから。
わかりにくかったですね。すいません。

293:デフォルトの名無しさん
08/08/31 21:00:05
なんとなく状況は把握できた。俺なら BaseAction には単一の Validate
メソッドだけ用意し、チェックメソッドは別クラスにまとめる。たぶん、
このチェッカークラスは stateless になるんじゃないかな。

派生クラスではこのチェッカーを使って個々の Validate メソッドを実装
すれば良い。チェッカークラスの置き場所はまあ、プロジェクト的な決め事
でしょう。

294:デフォルトの名無しさん
08/09/01 00:26:21
そうなんだよね。
今は各Actionクラスの処理の切り出しのイメージだったから
個別ValidatorでsetFieldError()してるんだけど、チェック処理の
多さからいって全public staticなクラスに切り出すべきだと思ってる。
すでにリリースされてるプロジェクトの機能追加なのであまり
リファクタリングしたくないんだけど。

で、最初の質問に戻るんだってば。actionパッケージの下には
actionクラスしかなく、serviceパッケージの下にはリモート呼び出しを
前提としたクラスとそのドメインオブジェクトしかない。

今後のプロジェクトではserviceクラスのメソッドにアノテーションつけて
ローカル実行とリモート呼び出しを分けられるようにしようかと思っていた。
そうするとやっぱ今回もあるべき論的にはserviceパッケージの下に
ローカル実行用のサービスクラスをつくるのかな。でも単純な未入力チェック
みたいのはコントローラーでやるべきだと思うし、うーん。

295:デフォルトの名無しさん
08/09/01 00:42:31
やっぱり、どの個別Validatorを呼び出すかみたいなロジックが
Actionに入ってることがそもそもおかしい気がしてきた。
あ、いやでも注文形態によって入力パラメータの数が違うから
未入力チェックを行うならActionか。

もしかしてstrutsみたいに各フィールドのセッターでvalidationしよう
っていうのが間違っているのか？

Action -> 個別注文クラス生成 -> 個別注文クラス#Validate()呼び出し
→ OKならリモート注文ServiceのValidate()呼び出し

こうするとすごくスッキリする。略してスッキる。ActionはModelの
生成だけでロジックにはノータッチになるし。チェッカークラスが
複雑で外だしにするとしても、個別注文クラスと同じpackageに
いれればしっくりくる。略してしっくる。ドメインオブジェクトがアクセッサしか
持っていないようなドメインモデル貧血症なつくりにはしてないからね。

296:デフォルトの名無しさん
08/11/13 18:02:24
あげ

297:デフォルトの名無しさん
08/11/27 14:40:57
パブリックヘッダファイルとプライベートヘッダファイルの違いが分かりません、
パブリックヘッダファイルで提供する関数と内部で使う関数の分け方すらわかりません。

298:デフォルトの名無しさん
08/11/28 00:16:46
OOP以前の問題だな

299:デフォルトの名無しさん
08/11/28 00:39:31
パブリック複合

300:デフォルトの名無しさん
08/12/06 00:00:34
テンプレート・メソッドパターンの多階層継承はマジ勘弁。
追いづらい。

IService ← テンプレート・メソッドパターン
↑
AbstractLogic ← テンプレート・メソッドパターン
↑
BaseCollectLogic ← テンプレート・メソッドパターン
↑
FileBaseCollectLogic ← テンプレート・メソッドパターン
↑
DomainLogic

カスが

301:デフォルトの名無しさん
08/12/06 01:58:35
それはやりすぎというより、なんか設計がおかしい気がする。

302:デフォルトの名無しさん
08/12/06 06:03:41
エントリーポイントを増やすのが目的なんだろうけど、
うざったいってのはよく分かる。

IService ← テンプレート・メソッドパターン
↑
AbstractLogic ← テンプレート・メソッドパターン
↑
DomainLogic

としてBaseCollectとやらはコンポジションでもっとけと。

303:デフォルトの名無しさん
08/12/06 09:36:21
問題ない。次

304:デフォルトの名無しさん
08/12/06 19:23:37
IService はインターフェースで Run メソッドが定義されてる。

クライアントは、
DomainLogic dl = new DomainLogic();
dl.Run();

あれ？スーパークラス使わないの？
IService はどうした？
IService は？

カスが

305:デフォルトの名無しさん
08/12/06 19:26:08
>>304 は >>300 の続きね

306:デフォルトの名無しさん
08/12/06 19:33:02
で、お前ならどうしたいのよ

307:デフォルトの名無しさん
08/12/06 19:36:49
黙れカスが

308:デフォルトの名無しさん
08/12/06 19:48:28
で、お前ならどうしたいのよ