エンジニア相談所（java、web）コミュのデザインパターン語り場

デザインパターンに関する、質問・意見・討論などができればと思っています。

デザインパターンと少しずれた話でも、
パターンを学習していたら出てきたという話であればありだと思っています。

パターンはもうバッチリ！という方は質問を待つだけでなく、
「このパターンでこんな話があるんだけど、こういうポイントがあるんだけど知ってる？理解してる？」など
有識者の方からのご意見も頂けたらと思っています。

ではみなさんよろしくお願いします。

コメント(7)

最初
全て
最新の40件

[1] mixiユーザー 08月13日 00:45

最近学習していて、「機能を追加してみてください。」という練習問題をやったときに疑問に思った
話をします。

例えば、
動物クラスと人間クラスがあります。
それぞれに「食べる」メソッドがあった場合に、
動物クラスと人間クラスのスーパークラスを新たに作りそのスーパークラスの
抽象メソッドに「食べる」メソッドをつくり、動物クラスと人間クラスはそのスーパークラスを
継承した方がよい。

というような話がありました。
その時の問題内容をそのまま話しているわけではないので、
今の私の例が悪くて意味合いがちょっとずれていたらすみません。
しかし一般的に上記のようなことはテクニックとして多様されていると思うので、
わかって頂けると思っています。

そして、ここで私の疑問は以下のものです。

１．この使い方がよいとするとスーパークラスはどんなクラス名が適切か？
２．このときのスーパークラスとサブクラスは厳密に言うとis-a関係でないように
　思えます。継承は本来is-a関係が成り立つ場合のみ使うべきだと思うのですが。
　この場合はis-a関係が成り立っているのでしょうか？
　それともis-a関係が成り立たなくても使ってよい例外パターンなのでしょうか？
３．こういうテクニックを使うべき場合と使うべきでない場合がイメージできない＆判断できない

書いてて１．２．に関して思ったのですが、スーパークラスを生き物クラスなどにして、
「食べる」メソッドを抽象メソッドにする。
ならis-a関係も成り立ってスーパークラスに「食べる」メソッドを持たせるのも違和感がないかと思いました。

コメントよろしくお願いします。

[3] mixiユーザー 08月14日 10:12

懸念するように、良くないと思いますよ。

> 書いてて１．２．に関して思ったのですが、
> スーパークラスを生き物クラスなどにして、
> 「食べる」メソッドを抽象メソッドにする。
> ならis-a関係も成り立ってスーパークラスに
> 「食べる」メソッドを持たせるのも違和感がないかと思いました。

生き物として同列に扱いたいなら、ありなのかもしれませんが、実装が被る事は無いのなら、interface にして、処理を委譲する仕組みにした方がいいですね。

[4] mixiユーザー 08月20日 15:59

先日Stateパターンを勉強していたところ、状態を変化させるかの
判定は

・各concretestateがもつ
・Stateを抽象クラスにして、状態遷移の判定のみ実装する

という方法があると思います。

そこでif文で100個の状態を判定してたら大変だと思うのですが、このように状態が多い場合どういう判定方法が考えられますでしょ
うか？

ちなみに、パターンが好きコミュに書いてみましたが数日待っても応答がありませんでしたので、こちらに書かせて頂きます

よろしくお願いします。

[5] mixiユーザー 08月20日 22:24

ちょっとポイントがずれてませんかね。。

State パターンは、状態に応じた処理を状態クラスが持つという部分までなので、State パターンの変更などは、パターン外の処理になります。

まあそこで良く用いられる方法として、State 自体が自分の状態になる条件を判定するインターフェースを持つ事で、分岐処理の追加を容易にするというテクニックになります。

一例ですが、

for (State state : stateList) {
    if (state.isSupported(xxxx)) {
        state.execute();
    }
}

みたいにすれば、if 文の嵐にはならないですよね。

ただそうすると、State のそれぞれを他の状態条件と被らないように実装しなければいけないので、量が多くなると横の把握が難しくなるという話もありますが。

どうでしょうか？

[6] mixiユーザー 08月20日 23:19

んーと、わたしが参考にした本（緑色の結城本）のサンプルですと、

ボタンを押下すると時間帯によって表示されるメッセージが変わるという仕様です。
例えば、
A：12-18時だと、こんにちわ
B：18-03時だと、こんばんわ
C：04-12時だと、おはよう

そこで、Aの状態のときにボタンを押下すると、
・Context役が時間を引数にAの状態クラス内の判定文を呼ぶ
・状態を変える必要があればBの状態クラスを引数にContext役内のchangeStateメソッドを呼び出す
すると、Bの状態クラスに切り替わってBの状態クラスによる出力内容が表示される。

4.で書いた・各concretestateで持つという方法です。
なので、このサンプルのままの方法だと各concretestateが全状態クラスを把握していなければ
いけなくなります。

全状態クラスを知らずに判定できる仕組みを考えたい、という話です。

__________________________________

あーひろさんが言っている方法を用いるとしたら、
context役の中で全状態クラスをリストで持っていて、
全状態クラス内で実装されているisSupportedメソッドを呼んで
trueが帰ってきたクラスに処理を依頼するということですね。

それはいいですね！

[7] mixiユーザー 08月21日 01:02

まあ絶対に変化しない State が生まれないように、各状態の条件を把握しなければ行けないのは、変わりないんですが、状態（＋条件）の追加は簡単になります。

ログインすると、みんなのコメントがもっと見れるよ