昨日のTDD BootCamp北陸に参加して(今も合宿組は続いていると思いますが) その後、別所で @fujiwoさんと議論をさせてもらいました。
議論内容
@k1ha410: あ、せっかくなので、少し議論につきかってもらいっていいですか?
@k1ha410: 昨日のお題は、twitterのつぶやきの 不適切な語を含むフィルターだったとおもいます。
@k1ha410: で、不適切な語を後から、フィルターに追加できるようにという 仕様変更を頂いて色々検討していきました。
@k1ha410: WordFiltter#Add( word ) な I/F を検討して、その後対象性を求めるためにWordFiltter#Delete(word) な I/F も検討しました。
@k1ha410: で、僕らのチームで Test を書いていく際に次の挙動についてどうなるかについて話題になりました。
@k1ha410: WordFiltter.Add( "AAA") WordFiltter.Add( "AAA") WordFiltter.Delete( "AAA") WordFiltter.Delete( "AAA")
@k1ha410: この手順で呼ばれた時に、どのような挙動をするか、あるいは Delete 1回だけの時にどうなるかです。
@k1ha410: Add /Delete という名前からすると、重複登録が許されるようにも思えるのですが、WordFilter としては 重複登録はいかがなものかと。
@fujiwo: 二回目の WordFiltter.Add( "AAA") は「何もしない」か「失敗する」んじゃないんですか。
@k1ha410: はい、そのような挙動もありだとおもいます。「何もしない」か「失敗する」
@fujiwo: そうでない挙動は何故ありだと考えるんですか。
@k1ha410: で、失敗するは Add という名前でもいいような気がするのですが、何もしないは Add という名前じゃないような気がしました (I/Fの名前は重要なので)
@fujiwo: 何故ですか >何もしないは Add という名前じゃない 。
@k1ha410: 個人的な感想ですが、追加ということは、ある集合に要素が入る事だと思っていました。つまり、今回だと フィルターする単語集合に追加されるということ。
@fujiwo: # 空っぽのリストを空っぽにするのは RemoveAll でいいと思います。
@fujiwo: # 「空っぽにする」=「何もしない」です。両者の挙動がたまたま同じだけ。
@k1ha410: 追加して失敗するは、Add してわかるとおもうのですが、何もされないというのは、どうなものかと。
@fujiwo: Add も同じだと思います。RemoveAll の例と。
@fujiwo: 空っぽのリストにとっては、RemoveAll に対するアクションがたまたま「何もしない」というだけ。
@k1ha410: なるほど。
@fujiwo: メッセージ名と挙動のマッピングをするのは、実インスタンスの判断で構わないと思います。
@fujiwo: メッセージを投げるのは、呼ぶ方の都合。
@fujiwo: メッセージに対するアクションは呼ばれる方の都合。
@k1ha410: はい。
@fujiwo: メソッド名=メッセージ名
@k1ha410: メッセージに対するアクション名 = メソッド名 ではないのでしょうか?
@fujiwo: インタフェースに表れているものは、メッセージ名です。
@k1ha410: メッセージを投げる側は、何も考えず、メッセージ名でなげてるだけのようなので。
@fujiwo: そうです。アクション名=メソッド名だと思います。
@fujiwo: メソッド != メッセージ
@fujiwo: アクション = メソッド
@k1ha410: 多くの言語が、メッセージの名前とメソッド名をダイレクトにマッピングする手抜きをしてるだけのような気がしますが(手抜き?)
@fujiwo: メッセージ=インタフェースに表れる名前
@fujiwo: そうですね。多くの言語でメッセージ名とメソッド名は同じ名前にマッピングされます。
@k1ha410: (ダイナミックな言語では、そこの名前解決に介在できますが)
@fujiwo: はい。
@fujiwo: ですが、たとえば、ポリモーフィズムが良い例で、メッセージに対してアクション (=メソッド) は一対一にマッピングされません。
@k1ha410: あ、それはいい例ですね。
@fujiwo: あるメッセージに対して、「何もしない」というアクション (=メソッド) があっても問題ありません。
@k1ha410: あ、そうか。個人的に興味があったのは、Addという追加メッセージでなにもしないというのが有りかという、名前の問題だという事がわかりました。
@fujiwo: ですから、私はあるメッセージ Add に対して、インスタンスが「その状態によって」「何もしない」というアクションを選択してもおかしくないと考えます。
@k1ha410: というのと、RemoeveAll の何もしないについてに何もしないで違和感を感じなかったのは、別の理由(後始末の処理の過程の制約だから仕方がないかもしれない)からだというのがわかりました。
@fujiwo: ただ、k1ha410さんがもともと問題にされてたのは、インタフェースに「何もしない」が表れるのがおかしい、ということなんですよね。きっと。
@k1ha410: 例えば、AddIfNoExist(word) というインタフェース名(メッセージ)で、追加しないは許します。
@fujiwo: つまり、Add("AAA") を二回成功したんなら、その後は、二回だけ Delete("AAA") が成功すべき、と。
@k1ha410: はい。2度成功したなら、Deleteも2度成功して欲しいとおもいたい。
@fujiwo: なるほど。
@fujiwo: それは先程私がいった、Add の実際のインスタンス側でのアクションが何か、という話とは別ですね。
@fujiwo: インタフェース側に現れてる問題ですから。
@k1ha410: しかし Add("AAA") Delete("AAA") Delete("AAA") で2度目の Delete は 失敗しないという 挙動に関しては仕方がないと感じるかもしれません。
@fujiwo: これは「Add って何?」って問題ではないですか? 違うかな。
@k1ha410: そんな気がしてきました。
@fujiwo: それも「WordFilter にとって、Add とは?」
@fujiwo: Add というのはたぶん名前としては相応しくなくて、AddNGWord とかの方がいいと思います。
@k1ha410: なるほど。
@k1ha410: いま WordFilterという物に AddFilterWord とか AddNGWord とかだと Filterという物に(単語)追加するんだったら、それは フィルターする語だろうから Add で十分だろうと思ってた部分が、も少し考えないといけないのかなという気になってきました。
@k1ha410: AddNGWord だと 2重登録が何もしないについて、なんとなく納得してもいいかもしれない。
@fujiwo: うーん。Add でもいい気がしてきました。
@fujiwo: WordFilter.Add だと、WordFilter.Add(aFilterWord) という引数になる感じがします。それでもいい気がしてきました。
@k1ha410: とすると、Addという動詞の意味になるのかなと。(たぶん、その人の持ってる感性になるんですね)
@fujiwo: AddNGWord だと、Add だけだと Add されるものが限定されないので、AddNGWord としている感じ。
@k1ha410: (ゴシゴシ目を確認中)
@k1ha410: あ、OK
@fujiwo: ちょっと前二つの発言を編集しました。
@k1ha410: (WordFilter) に (単語) を "追加"
@k1ha410: と
@k1ha410: (WordFilter)に (単語)を"NGワードとして追加"
@k1ha410: の違いですね。
@fujiwo: ええ。そうです。Exactly.
@k1ha410: 前者だと、追加なのに、追加されないのは、いかがなものか?だけど、NGワードとして追加だと、追加されないのは、それはそれでいいのかもという気になります。
@fujiwo: ええ。
@k1ha410: たぶん C# とかのコンテキストだと (WordFilter) に (単語) を "追加"は (WordFilter) に (単語:<String:NGWORD>) を "追加" くらいの定義に見えるんですよね。
@k1ha410: ruby だと (WordFilter) に (単語:<NGWORD>) を "追加"
@k1ha410: 大抵引数もメッセージのシグネチャとして見えるので、NGWORD が含まれていると思える。
@k1ha410: public void Add( string NGワード ); だと思うので。
@k1ha410: なんとなく、分かってきました。
@k1ha410: ありがとうございます。
@fujiwo: おもしろいですね。ありがとうございます。
@k1ha410: こんな事を考えてると、テスト1個書くのに時間がかかりました>昨日
@fujiwo: いや。本当にk1ha410さんらしい議論だと思います。
@k1ha410: その後の統計を考えると、重複登録なんてしたくないのは同意できるのですが、それがインタフェース名に現れないといけないだろうという。
@fujiwo: t_wada 賞を受賞した所以だと思います。
@k1ha410: (昨日の例だと、統計処理は、後々の仕様変更だったはずなので、最初の段階では、追加できるだけでいいはず)
@fujiwo: はい。
@fujiwo: これ後日譚として面白いかも知れないので、#tddbc に公開しましょうか。
@k1ha410: はい。したいですね。


コメントする