矢崎です。
素モードです。
tetsuya@....jpさん wrote:
>
> > > １．ファイルに同じアドレスの行が複数あった場合。重複は
> > > 別々じゃなくて、１つのMemberってしちゃえばいいのよね。
> > >
（略）
>
> 取り急ぎ、気になった点だけ。
>
> メンバリストって、今現在はメンバのメールアドレスだけですが、
> 別ストーリにメンバの配信状態も管理するような話がありませんでし
> たっけ？
>
> その場合も、最初に読み込まれたメンバ情報が優先されるみたいな制
> 約が明確であれば問題ないのですが。
>
メンバリストに関しては、
#以下のURLより
http://wiki.esm.co.jp:8080/
・StoryCard4 - 配信の一時停止
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
顧客ストーリカード: 配信の一時停止
────────────────────────────────
記述:
ML のユーザが、ML のアドレスにコマンドメールを送信することで、
メール配信の一時停止ができる。
その後、ユーザが再配信のコマンドメールを送信することで、配信が
再開される。
────────────────────────────────
備考:
配信停止以外のコマンドメールも想定する。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
・StoryCard5 - メンバの登録・削除
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
顧客ストーリカード: メンバの登録・削除
────────────────────────────────
記述:
メーリングリストに参加したい人は，そのメーリングリストの
コントロールアドレスに，登録コマンドメールを送る．
自分をメーリングリストから削除したい人は，コントロール
アドレスに削除コマンドを送る．
コントロールアドレスとは，メーリングリストが XP@....jp
であるならば，XP-control@....jp というアドレスであり，
コマンドを受け付けることを専門にするアドレスである．
また，登録，削除の両コマンドは，
登録: # subscribe
削除: # unsubscribe
とし，メール本文に書かれるものとする．
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
という２ストーリが関係しそうです。
で、私の考えですが、
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
・今行っているタスクは、一時停止や、登録、削除は考慮外なので、
こうした点をメンバリストファイルで考慮する必要はない。
・しかし、メンバリストファイルは、いろいろな局面（ストーリ）で使われ
る共有リソースである。
・もし、ストーリ４や５が、このイテレーションで開発されているとしたら、
ストーリ４や５で想定しているメンバリストファイルとこちらが想定している
ファイルのイメージが異なる場合は、イテレーションの完了その
ものが危うくなる。つまり、イテレーションの最後で、メンバリストファイル
の調整をして、調整結果によりソースを書き直すか、それが面倒くさいので、
各プログラムごとに、別々のメンバリストファイルを使う（バカな？でも
昔のメインフレームの開発なんかでは、これに類似することは結構あっ
たような気がします）ことになる。
・しかし、今回のイテレーションでは、ストーリ４と５は開発の対象では
ない。よって、メンバリストファイルを気にしなければならないのはストー
リ１だけ。だから、ストーリ１にとって、必要なこと、必要な方法でメンバ
リストファイルを考えてよい。
・仮に今回のイテレーションにストーリ４や５等が入っていた場合、メンバ
リストファイルはプランニングゲームやイテレーションプランニングでコンセ
ンサスを得ておく。また、イテレーションの途中で、何らかの理由で、ファイ
ルのイメージを変更しなければならなくなった場合、スタンドアップ・ミーテ
ィング等で早急に全員に相談し、新しいイメージを決める。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
というものです。ですから、今時点では、配信状態を管理するという
点については考慮せずに、今のストーリに必要十分なファイルイメージ
で進めていけばいいと思っています。
もし、ストーリ４や５を開発するときに、今のメンバリストファイルのイメージ
で問題がでてくれば、変えることになります。でもこの場合でもMemberList
クラスの実装を変えるだけで、MemberListクラスを使っているクラスには
影響がおよばない、という程度の設計は、今のイテレーションにおいても
必要だと思いますが。。
以上、私見です。ご批判や別のご意見お待ちします。
>
> 例外が発生することが分かっているならば、明示的に対処したほうが
> 良いと思います。
>
> ここは、addメソッドを変更して、、、
>
> public void add(Member aMember) {
> if (contains(aMember))
> return;
>
> members.add(aMember);
> }
>
> とした方がシンプルだと思います。
> # テストケースも変更しないと。
>
> と思って、送信しようとしたのですが、addにやらせるのは変ですね。
>
はい、私もaddに重複のチェックをさせるのはどうかと思い、
最初のコードのイメージにしました。
> 折角containsメソッドがあるなら、それでチェックしてからaddすれ
> ばいいはず（自分に言い聞かせてます。）
>
> Member member = new Member(mailAddress);
>
> if (contains(member))
> continue;
>
> add(member);
>
> として、addの実装はそのままとか。
>
これは、おっしゃるとおりですね。Exceptionで判断するのでは
なく、重複がなければ、addする、という、設計の意図が
はっきりします。メソッド名はcontainsではなく、変えたほうがい
いかもしれませんが、、、
>
> Configに習って、BadMemberFileExceptionクラスに置き換えたい
> のですがパッケージを別にしたほうがシンプルに収まるかなと思っ
> ています。
> ちょっと今すぐ思いつかないので、後回し！すみません。
MemberListもsystemパッケージにいれる、という考えでいますが、
私も少し検討したいです。
ありがとうございました。
--
矢崎博英 firo@....jp