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

botman_blue iOS
スポンサーリンク

はじめに

前々からデザインパターンについてまとめたいなぁと思ってたので下記のデザインパターンについてまとめようと思います。(正直あんまよくわかってないです。。。)
今回はオブジェクトの生成に関するパターンについて。

  • オブジェクトの生成に関するパターン
    • Singleton パターン
    • Abstract Factory パターン
    • Builder パターン
    • Prototype パターン
    • Factory Method パターン
  • オブジェクトの構造に関するパターン
    • Adapter パターン
    • Bridge パターン
    • Composite パターン
    • Decorator パターン
    • Facade パターン
    • Flyweight パターン
    • Proxy パターン
  • オブジェクトの振る舞いに関するパターン
    • Iterator パターン
    • Command パターン
    • Chain of Responsibility パターン
    • Memento パターン
    • Observer パターン
    • Mediator パターン
    • Interpreter パターン
    • State パターン
    • Strategy パターン
    • Template Method パターン
    • Visitor パターン

基本的には下記2つを参考に書いてます。

Singleton パターン

アプリ全体で1つのインスタンスを共有する仕組み。
最初に呼ばれた一回のみインスタンスを生成し、それ以降は同じインスタンスを参照する。

インスタンスが1つのみであることを保証する仕組みなので外部から init が呼べてはいけないし、サブクラスを作れてもいけません。
どこから呼んでも同じものが得られるという点では setter を持ったプロパティを持ってはいけないし、イニシャライザで引数を持ってもいけないらしい。

iOS だと下記のやつとかが Singleton っぽい

shared, default, standard とか名前にばらつきがあるがきっと Singleton だと思う。
FileManager に関しては singleton instance と書いてある。

グローバル変数っぽい使い方しか見たことないので具体的な使い道はわからない。。。

参考:マンガでわかる Singleton

Abstract Factory パターン

名前の通り抽象的な工場なんだたぶん。あるクラスが何かほしいとき下記のような処理になる。

あるクラスが何かほしい -> 工場に依頼 -> 工場で生成

このときあるクラスは具体的な工場を知る(依存する)必要はなく抽象的な工場を知っていればいい。(抽象に依存せよってやつだと思う)

こんな感じかな?(ちょっとよくわかってない。。。)

参考:マンガでわかる Abstract Factory

Builder パターン

全体の処理手順は Director に、個別の構築処理は Builder に分担し、この2つを組み合わせてオブジェクトを生成する仕組みらしい。

うーん。例が悪いかも。。。(CatBuilder を作ったとしても Director を通すと"わん"と鳴く。。。)

参考サイトの下記コメントにある通り複雑なオブジェクトじゃないと効力は発揮しないかも。

犬小屋作るのに重機を持ってくる必要はないんだから

参考:マンガでわかる Builder

Prototype パターン

既存のインスタンスをコピーして新しいインスタンスをつくる仕組みらしい。(JS の protptype とは完全に別物らしい)

こういうことかな? Struct なら勝手にコピーしてくれるし今までこういうの実装した記憶はない。。。

参考:マンガでわかる Prototype

Factory Method パターン

オブジェクト毎に Factory を用意してオブジェクト生成を外部に任せる仕組み。

これはつくりがそもそも悪い気がするけど AnimalFactory を介さずに Animal を生成すると cry() でクラッシュする可能性がある。

Abstract Factory との違いは下記らしい(うーんわからん。。。)

作り方より先に使い方に着目する Abstract Factory とは違い、こっちは、終始作り方に着目するのがポイントですよ。この差がめちゃくちゃ重要。

参考:マンガでわかる Factory Method

さいごに

デザインパターンはとりあえず盛り込めばいいものではなく、コード書いてるときにこれあのパターンが使えるんじゃね?とかコード読んでるときにこれはあのパターンじゃね?ってなるのが理想なんだと思う。なのでとりあえずふわっとでもいいから知識として知っとくべきかも??

デザインパターン盛り込んで書いてておれのコードめっちゃクールやん?みたいなデザインパターンを導入するのが目的になるとヤバいかもしれない。

github でこんなんみつけた

ochococo/Design-Patterns-In-Swift

参考

コメント

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

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