こんにちは、岡野です。
たくさんの貴重なご意見ありがとうございました。
ご意見を熟読させて頂きまして、とりあえず現段階で
以下のような設計案を考えさせて頂きました。
当初の自分の稚拙な案よりも、大分精錬された感じに
なったような気がします。
(新設計案)
奥村さんに教えた頂いたアイデアを参考に、
データ構造はCompositeパターンで表現し、
仕組みはCommandパターンをベースに実装し、
更に結城さんからご提案のFlyweightパターンも使って、
CompositeパターンのLeaf役を共有する方向性で
設計を考えております。
■ 結城さんへ
初めまして結城さん。
# ご本ではよく拝見しております
> 岡野さんが解決したい問題とIteratorという解法は直接的には
> 結びつかないように感じました。
> Iteratorは集約された個々の要素の実装に依存せず
> 走査する方法を提供するものかと思いますので。
やはり、Iteratorは無理がありましたか・・・
この一覧・詳細画面は、具体的には注文処理の画面でして
注文の商品によって表示項目・形式が結構違う為、合計20種類程度の
一覧・詳細画面を作る予定なのですが、Iteratorを使って
走査する方式だけは、なんとか共通的に処理できないかなぁと
考えておりました。
> HashMapで管理なさろうとしているのは、全データなのでしょうか。
> それともユーザが更新した分だけなのでしょうか。
> ユーザが更新したデータだけをIteratorで拾い上げるというやりかたなら
> 意味があるかもしれませんね。
そうですね、メモリー上の制約もございますので、
差分データ(ユーザー更新分)だけを保持して、
ユーザーが更新しないデータはデフォルトのデータで、
DBへ更新する方式で考えております。
> メモリーの問題はIteratorでは解決できませんね。
> メモリーの問題で使えそうなパターンは、
> 大きいものをシェアさせるFlyweightでしょうか。
> ただし、Flyweightだと要素はシェアされてしまうので、
> ユーザが個別に書き換える（つまりImmutableでない）場合には、
> 注意が必要になりますね。
Flyweightは使えそうですね。
結城さんのご著書「Java言語で学ぶデザインパターン入門」の321pに
「Flywightパターンを使って、CompositeパターンのLeaf役を共有する
ことができる場合があります」と書かれているのは拝見しまして、
これは使える使えるって思いました。(^o^)
PerlもJavaもデザインパターンも結城さんのご著書が、
初めの一冊にさせて頂いておりまして、その節はお世話になりました。
また、結城さんのHPのドキュメントの書き方について書かれた記事は
SEとしての日々の仕事にも非常に参考にさせて頂いております。
この場を借りてお礼申し上げます。ありがとうございました。
■ 田村さんへ
初めまして田村さん。
> 子要素へのパス（例えば "A/A'", "A/A''")をキーに、一連の属性データ
> を値としたMapを作成し、変更生じたときだけMapに登録するようにすれば、
> 最大2000項目に減らせると思うのですけど、これじゃあダメ？
> メモリはだいぶん節約できそうだけど。
私も確かにデザインパターンに拘らずに、メモリーのことを
考えてご提案頂いた方式の方が現実的かなぁとも考えました。
とりあえず、来月の中旬までにプロトタイプを作る必要がありまして、
そのプロタイプでは、先ほどのデザインパターンで実装させて頂いて
そこでメモリー問題の解決がどうしてもできない場合には、
田村さんからご提案頂いたものも参考にさせて頂くことも考えています。
ありがとうございました。
> DB更新中も、保持しているデータを変更したいのでしょうか。（つまり、
> 読み書きを並行動作したい）
要件としては、更新中の変更は幸いにもありません。
教えて頂いた並行コレクションクラスのIBM Deveropper Worksの説明は
とても参考になりました。
これからの設計の参考にさせて頂きたいと思います
■ 奥村さんへ
初めまして奥村さん。
> おそらくユーザさんとしては
> 少しずつ確認を行いながら修正を加えていって、
> 最終的に全ての変更が問題なくすんでから登録を行うことで
> ・編集中の中途半端な状態は共有しないようにしたい、
> ・もし途中で失敗があっても容易に破棄できるようにしたい、
> というのがご希望の趣旨なんでしょうね。
>
> 何となくCVSなどの動作モデルに近いような気がします。
> あるいは書類をネットワークで共有してみんなで編集していく
> オフィスの共有機能のようなイメージでしょうか。
正にご指摘の通りです！
それに、CVSの比喩は非常に的を得ていて、分かり易かったです。
> 変更操作では変更を行うCommandを生成していって、
> 画面はCommandの適応結果のプレビュー、というような感覚で作り、
> web上の操作はCompositeなCommandを構築していく操作、
> 更新の発行は構築されたCommandの本DBへの適用、
> というような方針では如何でしょう。
> 一つ一つのCommandは実際には単純な子データのdiffの様な物、
> ですむでしょうし、
ありがとうございました。
奥村さんの案を参考に(というより殆どそのまま)、
突き進んでいこうと思っています。感謝感謝です。
> でも恐ろしさは残りますね。
> 本当にCVSのように正データは変更履歴の連続したリポジトリにしてしまって、
> 個々のセッションごとに作業用コピーを作り更新時にdiffを作ってリポジトリに追加、
> とすれば不整合を起こした変更をいつでも取り消せるのでいいかもしれません。
運用上、担当者が決まっている為、コリジョンは発生しないため、
考慮する必要はないと以前ユーザーに言われていますが、
実装上品質上、本当に考慮する必要がないか再度次回ユーザーレビュー
で確認をとる予定です。
■ 土居さんへ
初めまして土居さん。
> 以前、私も似たような要望でシステム開発を行いましたが、最終的にはWebでの
> 開発をあきらめたことがあります。(^_^;)
今のシステムがC/S構成でして、資産配布のコスト削減の観点から
今回WEB化というのが至上命題でして、確かに色々な面で無理が
ありますね。
> さて、今回のケースだと、私が開発するとしたら下記のように設計します。
> １．一覧画面の各レコードに更新ボタンを設ける
> ２．詳細画面の各レコードに更新ボタンを設ける
> ３．一覧画面、詳細画面にそれぞれ対応したワークテーブルを用意する
> ４．一覧画面、詳細画面の更新ボタンではワークテーブルへのデータの書き込み
> ５．一覧画面の全体更新ボタンでワークテーブルから実テーブルへの更新を行う
わざわざ、設計案までお示し頂いてありがとうございました。
ワークテーブルを作る実装案も当初計画していたのですが、
ユーザーが途中でブラウザを閉じてしまった時など、
ワークテーブルのデータを消すタイミングの問題が解決できなくて
諦めてしまいました。
ただ、今回のシステムはメモリを圧迫するような処理があちらこちらに
ありますので、この実装案も完全には捨ててはおりません。
設計候補として、参考にさせて頂きたいと思います。
ありがとうございました。
またまた、長文になってしまいました。
でも、とても参考になりました。
このMLに思い切って投稿した甲斐がありました。
みなさん、本当にありがとうございました。
--
Hideo Okano
okap1975@…
読み込み中...
