Decorator パターンは、既存のクラスを拡張する際にクラスの継承の代替手段として用いられる。継承がコンパイル時に機能を拡張するのに対し、Decorator パターンはプログラムの実行時に機能追加をする点が異なる。

http://ja.wikipedia.org/wiki/Decorator_パターンより。
ふーん?
動的に追加するってのはわかった。 でもピンとこないな。

カテゴリー: NDI

「デコレータ?」への10件のフィードバック

  1. でこれーた。
    継承せずに機能を拡張すること。

    とっぴんぐあいすくりーむ
    抹茶あいすくりーむくらす。めそっどで抹茶あいすくりーむが返るとしたら
    とっぴんぐあいすくりーむクラスのこんすとらくたに抹茶あいすくりーむを設定して
    めそっどでチョコチップ抹茶あいすくりーむが返る
    そんなかんじ。

    ポイントはコンストラクタに修飾するクラスを設定して拡張する。
    ちゃんと使わないとカオスになるデザインパターン

  2. でもさでもさー。
    そんなのチョコチップ抹茶あいすくりーむくラス書けばいいじゃーん
    だめなの;;?

    継承となんとなく方向性が似ているようなものであることまでは分かったんだけど、なんでそんなことをしなきゃならんのかが全く理解できないのね。
    むろん熟考するだけの余裕がないというのはあるんだけど。
    やっぱデザパタ本は読まないといけんね。

  3. Java的になるんだけど

    public interface ice{
    public String getName();
    }

    public class IchigoIce implements ice{
    public String getName(){
    return “いちごアイス”;
    }
    }

    publlic claass MattyaIce Implement ice{
    public String getName(){
    return “抹茶アイス”;
    }
    }

    ここからデコレータ
    public class Topping{
    private Ice ice = null;

    public Topping( Ice ice ){
    this.ice = ice;
    }

    public String getName(){
    return “チョコチップ” + ice.getName();
    }
    }

    上みたいなクラスを継承でチョコチップつけようとするとgetNameオーバーライドで
    もっかい同じイチゴアイスとか書かないとだめでそ?
    そこでインターフェースIceをコンストラクタで設定して、同じ名前のメソッドを実装して
    そこから、IceのgetNameと装飾する処理をつけて戻してやるって感じが
    デコレータ

    実際にうえのを使うと
    IchigoIce ichigo = new IchigoIce();
    MattyaIce mattya = new MattyaIce();

    Topping ichigo_choco = new Topping(ichigo);
    Topping mattya_choco = new Topping(mattya);

    System.out.println(ichigo_choco.getName());
    System.out.println(mattya_choco.getName());

    結果が
    チョコチップいちごアイス
    チョコチップ抹茶アイス

    みたいなー感じ
    Qちゃん的にこれよりも、Bridge, state パターンあたりをちゃんとちゃんと理解するのが
    先と思うー

  4. むむ。むむむむ。
    むー。
    DRYのため(って成分もきっとあるんだろう、)であることは理解できるんだがなあ。
    これはそういうものでござるよと、使って慣れるほうがはやそうなのかのう。

    あ、でもなんだ、バリデーションでデコレータ使ったんだけど、というかデコレータでバリデータを載せる式のつくりにもともとなってんだけど、なんでそうなのかはともかく、便利さはすこーしわかったよ。
    日々勉強でござるね。

  5. バリデータって正当性チェックだよね
    トッピングのコンストラクタに
    public Topping( Ice ice, chekc check ){
    this.ice = ice;
    }

    みたいなー
    public interface chekc{
    public boolean chekc( ice ice);
    }
    見たいなのをつけるとチェック処理が抽象化されて
    利用しやすく
    ハァハァ

  6. あーそうそうそうね
    Pylonsっていうフレームワークだと、そのバリデータ処理を別に切り出して、コントローラクラスのメソッドにデコレーションすることで動作させてるのね
    class PartController(BaseController):

    def add(self):
    pass

    @validate(schema=ValidateFoo(), form=’add’)
    @validate(schema=ValidateVar(), form=’add’)
    def add_confirm(self, id):
    #かくにんがめん
    pass

    @で始まってる箇所がデコレータ指示
    関係ないけどPartController(BaseController)のカッコ内はスーパークラスです
    defの仮引数のselfはpythonのクラスメソッドのお約束で自分ちのクラスを指しまう。

  7. ぱっと見
    2.4とそうとう構文変わってる?
    思ったのはQちゃんはCの人だということw
    やっぱ{}無い世界は慣れないわー
    ふとchekcになってるのは愛嬌だ!(キリッ

  8. あー2.4とは少し違うね
    Pythonはversion3で劇的に変化(後方互換を捨てる)するらしいんですが、2系と3系の橋渡しをするのが2.6あたりで、基盤は2系なんだけど3系で使う概念や構文が追加になってます。
    C由来の構文(いわゆるsprintfでつかう”%02d”みたいな)とかが撤廃されたり、内部エンコードがAsciiじゃなくてunicodeになったり、いろいろちなう。
    これをpython界隈の人はpythonicにする、というらしい

    インデントは慣れだよ!
    ブレース書くのがすっかり嫌いになりました
    仕事でphp書くのもだんだん苦痛にw

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です