デザインパターンはソフトウェアエンジニアリングの問題に対する異なる解決策です。 デザイン パターンがなくてもソフトウェアを構築することはできますが、それは非常に困難です。
Design Pattern に関する 3 部構成のシリーズをリリースする予定です。 今回は、創造的デザインパターンについて説明します。
創造的デザインパターンは、オブジェクト生成のメカニズムを扱うデザインパターンで、状況に適した方法でオブジェクトを生成しようとします。 オブジェクト生成の基本形では、設計上の問題が発生したり、設計が複雑化したりする可能性がある。
Source: wikipedia.org
ここでは、5つの創造的デザインパターンと、それらをswiftでどのように使用できるかを説明します。
このタイプのデザインパターンは、prototypeという既存のオブジェクトを複製して新しいオブジェクトをインスタンス化するために使用されます。
Appleクラスで実装されているFruitプロトコルの抽象的なクローン関数を見ると、実際には現在のオブジェクト自身を返しています。
上のコードをプレイグラウンドで実行してみましょう。
// Create a prototype
let prototype = Apple(count: 4)// Create a copy of existing object
let redApple: Apple = prototype.clone() as! Apple
redApple.count // 4// add own properties
redApple.set(price: "")
redApple.price // // Create a copy of existing object
let greenApple: Apple = prototype.clone() as! Apple
greenApple.count // 4// add own properties
greenApple.set(price: "")
greenApple.price //
– オブジェクトを複製すると、そのオブジェクトのすべてのプロパティは
別のオブジェクトにコピーされる。
– このデザインパターンは、そのクラスの階層を知らずにオブジェクトを作成する必要がある場合に使用されるべきです
The Factory Method Pattern
これは最も一般的に使用されるデザインパターンです。
必要なオブジェクトの型を返すFruitFactoryというクラスを作成します。
FruitTypeというenumをパラメータとして受け取り、実行時に必要なオブジェクトを返す静的メソッドを追加します。
ファクトリーが返すすべてのインスタンスは、ファクトリー候補クラスが必ず実装する必要のある(スイフトのプロトコルにおける)インターフェース型になるでしょう。
上記のコードをプレイグラウンドで実行すると、
// get the object of class Orange from the FruitFactory class
let orange = FruitFactory.getFruit(forType: .orange)
orange?.getPrice() // "
orange?.getCount() // 2// get the object of class Grapes from the FruitFactory class
let grapes = FruitFactory.getFruit(forType: .grapes)
grapes?.getPrice() // ""
grapes?.getCount() // 1
– 作成されるオブジェクトの型は実行時に決定されます。
– このデザインパターンは、新しい型の追加や削除に対してコードベースをより柔軟にします。
これは、実装ではなくインターフェースへのプログラムの概念を導入します。
このデザインパターンは、その具体クラスを特定せずに関連オブジェクトの家族を作るためのインターフェースを提供します。
異なる製品を作成するために、家具工場という抽象的な工場があります。 具象ファクトリクラスFactoryは、Furniture Factoryプロトコルを実装することになります。
上記のコードを実行すると、次のようになります。
// create MyChair class object
let chair = Factory.createChair()
chair.count() // 4// create MyTable class object
let table = Factory.createTable()
table.count() // 1
– 実装ではなくインターフェイスを明らかにする
– 抽象ファクトリーは、オブジェクトを作成するために具象クラスで使用するプロトコルのようなものです
Builder Pattern
このデザインパターンは、実際の使用からオブジェクトの作成処理を分離するものです
最初に製品を作るための抽象プロトコル(またはインターフェース)を宣言します。 この場合、それはShoeShopプロトコルです。
クラスNikeは、製品作成プロセスをカプセル化する具体的なビルダーです。
ディレクターはビルダープロトコルを使用してオブジェクトを作成します。 DirectorはShoeShopプロトコルに準拠したオブジェクトで初期化する必要がある。
コード実行後
// create a nike object
let nike = Nike()// instantiate Director with nike object
let director = Director(shoeShop: nike)// encapsulated the process of producing the nike product
director.produce() // "Shoe produced"
– パブリックAPI構築時にBuilderパターンを使用すると、実装詳細を明らかにしない
– 複雑性を隠すことができる。
Singleton Design Pattern
Swift では static キーワードを使用してシングルトン クラスを定義します。 これは、オブジェクトが一度だけインスタンス化されることを意味します。 静的プロパティは遅延初期化され、呼び出されるまでインスタンス化されません。
このオブジェクトのコピーは1つだけで、他のオブジェクトによってグローバルに使用されます。
// Shared url session
let urlSession = URLSession.shared// user defaults
let userDefaults = UserDefaults.standard
コードを実行した後
Vehicle.sharedInstance.getName() // "Car"
– let キーワードを使用して、shredInstance の値が変更されないことを確認します
– private initialiser を追加して、他のクラスがそのデフォルト初期化子を呼び出すのを防ぐのを忘れないでください
以下は、プレイグラウンド ファイルへのリンクです。
Creational Design Pattern を使用する主な理由は、オブジェクトの作成ロジックをその使用法から切り離すためです。 これは、すでに述べたテスト済みのソリューションを使用して制御された方法でオブジェクトを作成することにより、複雑さを軽減するのに役立ちます。
動作設計パターンについて読むには、ここにブログへのリンクがあります。