一般的な iOS デザイン パターン: 工場出荷時のデザイン パターン
単純な工場パターン:
シンプルなファクトリ パターン: 他のクラスのインスタンスの作成を担当するクラス (ファクトリ クラス) を具体的に定義します。作成メソッドのパラメータに従って、異なるクラスのインスタンスを返すことができ、通常、作成されたインスタンスには共通の親クラスがあります。
①ファクトリクラス、Coke抽象クラスを作成します。
② Coca-Cola と Pepsi-Cola は Coke 抽象クラスを継承します。
// 简单工厂实现
@implementation SimpleFactory
+ (Cola *)createColaWithType:(NSInteger)type
{
switch (type)
{
case 0:
//可口可乐
return [CocaCola new];
case 1:
//百事可乐
return [PesiCola new];
default:
return nil;
break;
}
}
@end
アドバンテージ：
- 必要なオブジェクトは、その作成の詳細を知らなくても、合意されたパラメータに従って取得できます。システムの結合を軽減します。
- クライアントは、作成された特定の製品クラスのクラス名を知る必要はなく、特定の製品クラスに対応するパラメータのみを知っていればよいため、開発者のメモリ コストが削減されます。
欠点:
- 新しい製品がビジネスに追加されると、工場クラスの元の判断ロジックを変更する必要があり、これは実際には開閉原則に違反します。
- 製品の種類が多い場合、工場のロジックが複雑すぎる場合があります。したがって、単純な工場モデルは、製品の種類が比較的少なく、増加の可能性が非常に低い状況に適しています。
ファクトリパターン（ファクトリメソッドパターン）
ファクトリ メソッド パターンはファクトリ パターンとも呼ばれます。ファクトリの親クラスは製品オブジェクトを作成するためのパブリック インターフェイスを定義する役割を果たし、ファクトリのサブクラスは特定の製品オブジェクトを生成する役割を担います。つまり、異なる製品は異なるファクトリ サブクラスを通じて作成されます。物体。
単純な工場との違い:
ファクトリーメソッドと単純なファクトリーにはいくつかの違いがあり、単純なファクトリーは鋳造工場によってさまざまな製品を生産しますが、ファクトリーメソッドは工場を抽象化し、特化した特定の工場でさまざまな製品を生産します。コカ・コーラ工場はコカ・コーラの製造を専門とし、ペプシ・コーラ工場はペプシ・コーラの製造を専門としています。
つまり、複数のブランドメーカーに対して、複数の工場が1対1で生産を行っています。
// 工厂抽象类
@implementation Factory
+ (Cola *)createCola
{
return [Cola new];
}
@end
// 可口可乐工厂
@implementation CocaColaFactory
+ (Cola *)createCola
{
return [CocaCola new];
}
@end
// 百事可乐工厂
@implementation
PesiColaFactory
+ (Cola *)createCola
{
return [PesiCola new];
}
@end
アドバンテージ：
- 製品の詳細は気にせず、製品クラスのクラス名も知る必要がなく、必要な製品に応じて対応する工場を見つけて生産します。
- 新しいプロダクトをシステムに追加する場合、抽象ファクトリや抽象プロダクトが提供するインターフェイスを変更したり、クライアントやその他の特定のファクトリや特定のプロダクトを変更したりする必要はなく、特定のファクトリを追加するだけで済みます。およびそれに対応する特定の製品 開閉原理に準拠しています。
欠点:
- 新しい製品がシステムに追加される場合、新しい製品カテゴリに加えて、それに対応する特定の工場カテゴリも提供する必要があります。したがって、システム内のクラスの数がペアで増加し、システムの複雑さが増加します。
抽象的な工場パターン
Abstract Factory Pattern: 特定のクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します。
抽象ファクトリーとファクトリー・メソッドの違い:
製品を生産するファクトリーは抽象です。テーマ工場はコカ・コーラやペプシを生産するだけでなく、同じテーマのさまざまな製品の生産に特化するためにボトルや箱もカスタマイズする必要があります。
アドバンテージ：
- 製品の詳細を作成する必要はありません。製品がどの工場に属しているかを知る必要があるだけです。製品ファミリ内の複数のオブジェクトが連携して動作するように設計されている場合、クライアントは常に同じ製品ファミリ内のオブジェクトのみを使用するようにできます。これは、現在の環境に基づいて動作を決定する必要がある一部のソフトウェア システムにとって、非常に実用的な設計パターンです。
欠点:
- 作成される可能性のあるすべての製品コレクションを指定しますが、製品ファミリ内の新しい製品を拡張するのは難しく、抽象ファクトリのインターフェイスを変更する必要があります。