« やる夫がデザインパターンをやるようです 第4回 | メイン | やる夫がデザインパターンをやるようです 第6回 »



やる夫がデザインパターンをやるようです 第5回

やる夫がデザインパターンをやるようです 第5回をはてなブックマークに追加 やる夫がデザインパターンをやるようです 第5回をdel.icio.usに追加  Yahoo!ブックマークに登録 やる夫がデザインパターンをやるようです 第5回をGoogle Bookmarksに追加 やる夫がデザインパターンをやるようです 第5回をtwitterにポスト
≪第4回第6回≫

前回のやる夫で学ぶデザインパターンでは、勇者が冒険の中で獲得する、「武器」による攻撃力の強化だけでなく、アクセサリの追加装備により攻撃力のさらなる強化を実現するための追加仕様を、やる夫が検討しました。

検討その1.継承を爆発させた。
検討その2.必要最低限な「武器」クラスを用意して、「強化アイテム」をスーパークラスのメンバ変数で表現。

やる夫が見直した検討その2.のデザインは、武器クラスの拡張には柔軟に対応できますが、強化アイテムの追加や削除、変更が入った場合に柔軟に対応することができません。
class Weapon {
    String description;
    
    // 強化アイテムのブール値
    boolean isBracelet;
    boolean isMantle;
    boolean isHairOrnament;
    boolean isRing;

    getDescription();
    getPower();

    hasBracelet();
    setBracelet();

    hasMantle();
    setMantle();

    hasHairOrnament();
    setHairOrnament();

    hasRing();
    setRing();
}
前回、アーキテクトが気にしていたのは、「同じアイテムを2つ持った場合、その分の武器の強化をどのように実現するか?」ですが、上記のデザインを見ると、強化アイテム1つ1つをメンバに割り当てているのでアイテムが増えたり、強化値が変更される度にこのクラスを検討しなおす必要があります。
・・・「同じ強化アイテムを2つ以上重ねがけできる」仕様はどうすんだ?
          ____
       / \  /\  キリッ
.     / (ー)  (ー)\
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー'´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

          ____
        /_ノ  ヽ、_\ だっておwwwww
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)
| / / /     |r┬-|    | (⌒)/ / / //
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー'´      ヽ /    /
 |    |   l||l 从人 l||l      l||l 从人 l||l
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))


     |  |   |   |
     _||_||__||  ||
    (__/   `ー――
   (___/  r
    (_レノ)\   ___
    (__/__/

       ____
     /⌒  ⌒\ ホジホジ
   /( ○)  (○)\
  /::::::⌒(__人__)⌒::::: \  そんな仕様にするから
  |    mj |ー'´      | ゲームバランスが取れなくなっtt
  \  〈__ノ       /
    ノ  ノ 
仕様そのものに納得できずに実装するプログラマは少なくないかと思いますが、やる夫も「あー。今vip保守してっから仕様書そこに置いとけお」なんていえる立場ではありません。実装という観点でも問題があるということをまず理解する必要があります。

<やる夫>
    _/⌒  ⌒\_
  /:●))(__人__)((● \ せめてヒントがほしいお
  |     |r┬-|     |
  \      `ー'┃     / 




<アーキテクト>
   / ̄ ̄\
 /   _ノ  \
 |    ( ●)(●)
. |     (__人__) ちっ
  |     ` ⌒´ノ 最初から素直にそう言えや
.  |         }
.  ヽ        }
   ヽ     ノ        \
   /    く  \        \
   |     \   \         \
    |    |ヽ、二⌒)、          \ 




     ____
    / ⌒  ⌒  \ (アーキテクトさんがいないと何もできないお!)
  ./( ―) ( ●)  \ ウチのアーキは意外と扱いやすいお。。
  /::⌒(_人_)⌒:::::  |
  |    ー       .|
  \          / 




   / ̄ ̄\
 /   _ノ  \
 |    ( ○)(○)
. |     (__人__)ほう。
  |     ` ⌒´ノ
.  |         }
.  ヽ        }  
   ヽ       ____
   /       / ⌒  ⌒  \ フヒ・・・?
   | .   ./( ○) ( ○)  \
.   |     /::⌒(_人_)⌒:::::  |
.        |    ー       .|
        \          / 





とりあえずてめぇの腹は把握した。
が、仕事は仕事だ。

以前、ストラテジーパターンで学んだことは何だ?
変化する処理をカプセル化するということだな。
今回てめぇが学ぶべきことは「拡張」の扱い方だ。
武器クラスをアイテムクラスで拡張するという風に考えてみろ。
それも既存のコードを修正せずに振舞いを拡張するんだ。

つまり、ニコニコクロニクル1.0で作成した武器クラスに修正を入れずにアイテムクラスで拡張する方法を考えてみろ。すると、「そうせざるを得ない」あることがわかる。
ヒントはjava.ioにある。
        / ̄ ̄\
      /       \
      |::::::        | 
     . |:::::::::::     | 
       |::::::::::::::    |          ....,:::´, .
     .  |::::::::::::::    }          ....:::,,  ..
     .  ヽ::::::::::::::    }         ,):::::::ノ .
        ヽ::::::::::  ノ        (:::::ソ: .
        /:::::::::::: く         ,ふ´..
-―――――|:::::::::::::::: \ -―,――ノ::ノ――
         |:::::::::::::::|ヽ、二⌒)━~~'´ 





    _/⌒  ⌒\_
  /:○))(__人__)((○ \ わかりましたお。
  |     |r┬-|     |
  \      `ー'┃     / 
というわけで、アーキテクトが言うには、やる夫が今回学ぶべきことは「拡張」のようでした。

「こういうことだから、こんなデザインパターンになったよー。」という話の進め方をしたいのですが、なかなか上手くいきませんね。ワタシも正しく理解しているわけではないところがたくさんありますが、次回第6回でデザインパターンに収束してみたいと思います。

≪第4回第6回≫

★このコンテンツに目的の情報はありませんでしたか?


[ 最近のエントリーとその関連エントリー ]


[ スポンサードリンク ]

トラックバック

このエントリーのトラックバックURL:
http://mojalog.com/cgi/mt/mt-tb.cgi/250

コメントを投稿

ツリータイプ・カテゴリー

open all | close all

リファラから検索


サイト内検索