Swiftでのデザインパターンまとめ2(オブジェクトの構造に関するパターン)

botman_blue iOS
スポンサーリンク

はじめに

その1の続き。今回はオブジェクトの構造に関するパターンについてです。

  • オブジェクトの構造に関するパターン
    • Adapter パターン
    • Bridge パターン
    • Composite パターン
    • Decorator パターン
    • Facade パターン
    • Flyweight パターン
    • Proxy パターン

その1同様、基本的には下記2つを参考に書いてます。

github でこんなんみつけたのでこれ見ればいいと思うよ!(私まだ理解してないので。。。)

ochococo/Design-Patterns-In-Swift

Adapter パターン

異なる2つのインターフェースを変換してつなげる仕組み。ラッパー??みたいなやつだと思う。
Target と Adaptee を Adapter を介してつなげるらしい。

Android の ListView とかの Adapter はこれなのか??

参考:マンガでわかる Adapter

Bridge パターン

クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。

使い方はこれであってんのかな??

参考:マンガでわかる Bridge

Composite パターン

木構造モデルを一つのオブジェクトとして操作する仕組み。

View も Composite パターンになるのかな??

参考:マンガでわかる Composite

Decorator パターン

既存のクラスを修正することなく機能を追加する仕組み。(きっとデコレーションするって意味だと思う)

これでパンケーキクラス(構造体だけど)をいじらずにチョコレートやホイップクリームをトッピングできるようになった!

参考:マンガでわかる Decorator

Facade パターン

複数のオブジェクトの連携でひとつの処理をするときに窓口を使って操作する仕組み。(ファサードは外観とかそういう意味っぽい)

ちょっと具体的な処理については思いつかなかった。。。

参考サイトには下記のように書いてあった。。。1:1だと Adapterらしい。

Adapter や Decorator パターンなどの、単一のオブジェクト関係に着目したものと異なり、Facade は複数のオブジェクトを集約するラッパークラスです。

ラッパークラスのメソッドが、つねにひとつの内部オブジェクトに 1:1 でマップされる場合、それがいくら矢面に立つ受付であっても、それは Adapter です。

参考:マンガでわかる Facade

Flyweight パターン

既存のインスタンスがあればそれを共有して負荷を減らす仕組み。

参考:マンガでわかる Flyweight

Proxy パターン

ユーザと対象オブジェクトの間に入って対象オブジェクトの代理としてユーザとやり取りする仕組み。

よくわかんなかったので ochococo/Design-Patterns-In-Swift の Virtual Proxy載せときます。

Decorator と似てるけど Decorator は機能拡張が目的で Proxy は効率的な運用が目的らしい。

参考:マンガでわかる Proxy

さいごに

うーん。。。なんとなくわかった気になったけど実務で使えるレベルではない。。。
きっと数年後見返したときに何か気づきがあるだろう。たぶんなんで使うかっていう目的がよくわかってないからな気がするので目的については後日追記するかも。。。

参考

コメント

  1. […] その2の続き。今回はオブジェクトの振る舞いに関するパターンについてです。 […]

タイトルとURLをコピーしました