ファクトリ デザイン パターンと抽象ファクトリ デザイン パターンの基本的な違いは何ですか?[閉まっている]
-
05-07-2019 - |
質問
ファクトリ パターンと抽象ファクトリ パターンの基本的な違いは何ですか?
解決
Factoryパターンでは、特定のインターフェイスの実装( Apple
、 Banana
、 Cherry
など)のインスタンスを生成します-たとえば、 IFruit
。
Abstract Factoryパターンでは、誰でも独自のファクトリを提供する方法を提供します。これにより、倉庫で果物やジュースに関する知識を必要とせずに、倉庫を IFruitFactory
または IJuiceFactory
にすることができます。
他のヒント
この情報の出典は次のとおりです。 http://java.dzone.com/news/intro-design-patterns-abstract
アブストラクトファクトリー vs.ファクトリーメソッド
抽象ファクトリのメソッドはファクトリ メソッドとして実装されます。抽象ファクトリ パターンとファクトリ メソッド パターンは両方とも、抽象型とファクトリを通じてクライアント システムを実際の実装クラスから切り離します。ファクトリ メソッドは継承を通じてオブジェクトを作成しますが、抽象ファクトリは合成を通じてオブジェクトを作成します。
Abstract Factory パターンは、AbstractFactory、ConcreteFactory、AbstractProduct、ConcreteProduct、および Client で構成されます。
実装方法
抽象ファクトリ パターンは、ファクトリ メソッド パターン、プロトタイプ パターン、またはシングルトン パターンを使用して実装できます。ConcreteFactory オブジェクトのインスタンスは 1 つだけ必要なので、ConcreteFactory オブジェクトはシングルトンとして実装できます。
Factory Method パターンは、Abstract Factory パターンの簡略化されたバージョンです。Factory Method パターンは 1 つのファミリーに属する製品の作成を担当しますが、Abstract Factory パターンは複数の製品ファミリーを扱います。
ファクトリ メソッドは、インターフェイスと抽象クラスを使用して、クライアントをジェネレーター クラスとその結果の製品から分離します。Abstract Factory には、いくつかのファクトリ メソッドのコンテナであるジェネレーターと、クライアントをジェネレーターおよび製品から切り離すインターフェイスがあります。
ファクトリ メソッド パターンを使用する場合
クライアントを、クライアントが使用する特定の製品から切り離す必要がある場合は、ファクトリ メソッド パターンを使用します。ファクトリ メソッドを使用すると、クライアントが製品のインスタンスを作成および構成する責任を軽減できます。
抽象ファクトリー パターンを使用する場合
クライアントを製品クラスから分離する必要がある場合は、Abstract Factory パターンを使用します。特にプログラムの構成と変更に役立ちます。Abstract Factory パターンは、どのクラスを他のクラスと一緒に使用する必要があるかについての制約を強制することもできます。新しいコンクリート工場を作るのは大変な作業かもしれません。
例:
抽象的なファクトリーの例 1
パスタメーカーでさまざまな種類のパスタを準備するためのディスクのこの仕様は抽象的な工場であり、それぞれの特定のディスクは工場です。すべてのファクトリー (パスタメーカーディスク) は、抽象ファクトリーからプロパティを継承します。個々のディスクにはパスタの作り方に関する情報が含まれていますが、パスタメーカーには含まれていません。
抽象的なファクトリーの例 2:
スタンピング装置は、抽象的な製品オブジェクトを作成する操作のインターフェイスであるため、抽象工場に対応しています。金型はコンクリート製品を作るコンクリート工場に相当します。各部品カテゴリ(ボンネット、ドアなど)が抽象製品に対応します。特定の部品(つまり、99カムリのドライバーサイドドア)は、コンクリート製品に対応しています。
ファクトリーメソッドの例:
玩具会社は、製品オブジェクトを作成するために工場を使用する可能性があるため、作成者に相当します。特定の種類のおもちゃ (馬または車) を製造するおもちゃ会社の部門が ConcreteCreator に相当します。
工場パターン: 工場はIProduct実装を生成します
抽象的な工場パターン: 工場工場はIFactoriesを生成し、IFactoriesはIProductsを生成します:)
[コメントに従って更新]
少なくとも Wikipedia によれば、前に書いたことは正しくありません。抽象ファクトリーは、単なるファクトリーインターフェースです。これにより、実行時にファクトリを切り替えて、異なるコンテキストで異なるファクトリを許可できます。例は、異なるOS、SQLプロバイダー、ミドルウェアドライバーなどの異なる工場である可能性があります。
抽象ファクトリーパターン
-
作成用のインターフェースを提供する 関連または扶養家族 それらを指定せずにオブジェクト 具象クラス。
-
Abstract Factoryパターンは非常に ファクトリーメソッドに似ています パターン。の違いの1つ 2つは抽象ファクトリーで パターン、クラスは オブジェクトの責任 を介した別のオブジェクトへのインスタンス化 構成対工場 メソッドパターンは継承を使用し、 サブクラスに依存して処理します 目的のオブジェクトのインスタンス化。
-
実際には、委任されたオブジェクト ファクトリメソッドを頻繁に使用して インスタンス化を実行してください!
工場パターン
-
ファクトリーパターンは例です 創造的なパターン
-
作成パターンは、 オブジェクトのインスタンス化プロセス。彼ら オブジェクトの作成方法を隠して助けます システム全体を独立させる オブジェクトの作成方法と
-
クラス作成パターンは、 継承を使用して決定する インスタンス化されるオブジェクト ファクトリーメソッド
-
オブジェクト作成パターンは、 インスタンス化の委任 別のオブジェクトへ 抽象ファクトリー
リファレンス: Factory vs Abstract Factory
ファクトリーメソッド:特定の基本クラスから派生するオブジェクトを作成するファクトリーがあります
抽象ファクトリ: 他のファクトリを作成するファクトリがあり、これらのファクトリはベースクラスから派生したオブジェクトを作成します。これは、(Factoryメソッドのように)1つのオブジェクトを作成するだけではなく、関連するオブジェクトのコレクションを作成することが多いためです。
Abstract factoryは関連オブジェクトを作成するためのインターフェースですが、factoryメソッドはメソッドです。抽象ファクトリは、ファクトリメソッドによって実装されます。
基本的な違い:
工場: インスタンス化ロジックをクライアントに公開せずにオブジェクトを作成します。
ファクトリーメソッド :オブジェクトを作成するためのインターフェースを定義しますが、サブクラスにインスタンス化するクラスを決定させます。 Factoryメソッドにより、クラスはインスタンス化をサブクラスに延期できます
抽象ファクトリー :具象クラスを指定せずに、関連オブジェクトまたは依存オブジェクトのファミリーを作成するためのインターフェースを提供します。
AbstractFactory パターンは構成を使用してオブジェクトを作成する責任を別のクラスに委任しますが、 Factoryメソッドパターンは継承を使用し、派生クラスまたはサブクラスに依存してオブジェクトを作成します
oodesign の記事から:
工場 クラス図:
例:StaticFactory
public class ShapeFactory {
//use getShape method to get object of type shape
public static Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
FactoryMethodの例を実装する非静的ファクトリは、この投稿で利用可能です:
デザインパターン:Factory vs Factory method vs Abstract Factory
使用するタイミング:クライアントはクラスを必要とするだけで、どの具体的な実装を取得するかは気にしません。
ファクトリメソッド クラスdigaram:
使用するタイミング:クライアントは、実行時に作成する必要がある具体的なクラスを知りませんが、ジョブを実行するクラスを取得したいだけです。
使用する場合:システムで複数の製品ファミリを作成する必要がある場合、または実装の詳細を公開せずに製品のライブラリを提供する場合。
上記の記事のソースコード例は、概念を明確に理解するのに非常に役立ちます。
コード例と関連するSEの質問:
違い:
- Abstract Factoryクラスは、多くの場合Factoryメソッドで実装されますが、Prototypeを使用して実装することもできます
- 設計は、Factory Methodを使用して開始し(複雑さを軽減し、カスタマイズしやすく、サブクラスを増やす)、柔軟性が必要な他の作成パターン(より柔軟で複雑な)に進化します。
- 通常、ファクトリメソッドはテンプレートメソッド内で呼び出されます。
その他の役立つ記事:
factory_method ソースメイキングから
abstract_factory ソースメイキングから
抽象ファクトリーの例/シナリオ
私は、雨季には雨が降り、冬には雪が降り、夏には暑く晴れた場所に住んでいます。風雨から身を守るには、さまざまな種類の服が必要です。そうするために、私は私の家の近くの店に行き、身を守るために衣類/アイテムを求めます。店主は、環境やポケットの深さに応じて適切なアイテムをくれます。彼が私にくれたアイテムは、同じレベルの品質と価格帯です。彼は私の基準を知っているので、そうするのは簡単です。しかし、通りの向こう側から金持ちが同じ要件を思い付くとき、彼は高価な、ブランドのアイテムを手に入れます。 1つの注目すべき点は、彼が私に提供するすべてのアイテムが、用語の品質、標準、およびコストで互いに補完し合うことです。彼らはお互いに行くと言うことができます。この金持ちが手に入れるアイテムについても同様です。
そのため、上記のシナリオを見ると、ショップキーパーの効率に感謝しています。この店主を抽象的な店に置き換えることができます。私たちが抽象アイテムで得たアイテムと私と富裕層の視点のクライアント。必要なのは、ニーズに合った製品/アイテムだけです。
今では、多数のクライアントに一連のサービスを提供するオンラインストアを検討している自分を簡単に見ることができます。各クライアントは、3つのグループのいずれかに属します。プレミアムグループユーザーがサイトを開くと、優れたUI、高度にカスタマイズされた広告ペイン、メニューの追加オプションなどが得られます。これらの同じ機能セットはゴールドユーザーに提示されますが、メニューの機能は少なく、広告はほとんど関連があり、わずかにエゴノミックUIが少なくなりました。最後は私の種類のユーザー、‘無料グループ’です。ユーザー。私は気分を害しないように十分に仕えています。 UIは最低限のものであり、広告はあまりにうまく機能していないため、何が入っているのかわかりません。最後に、メニューはログアウトしているだけです。
このウェブサイトのようなものを構築する機会があれば、私は間違いなくAbstract Factory Patternを検討します。
抽象的な製品:広告ペイン、メニュー、UIペインタ。
Abstract Factory:Webストアユーザーエクスペリエンス
Concreate Factory:プレミアムユーザーエクスペリエンス、ゴールドユーザーエクスペリエンス、一般ユーザーエクスペリエンス。
多くの人が驚くかもしれませんが、この質問は間違っています。インタビュー中にこの質問を聞いた場合、面接官が混乱の場所を理解するのを助ける必要があります。
「工場」だけと呼ばれる具体的なパターンがないという事実から始めましょう。 「Abstract Factory」と呼ばれるパターンと、「Factory Method」と呼ばれるパターンがあります。
では、" Factory"とは何ですか?どういう意味?次のいずれか(参照の範囲に応じて、すべて正しいと見なすことができます):
- 一部のユーザーは、" Abstract Factory "のエイリアス(ショートカット)として使用しています。
- " ファクトリメソッド"のエイリアス(ショートカット)として使用する人もいます。
- 一部の人々は、すべての工場/作成パターンのより一般的な名前としてそれを使用します。例えば。 「Abstract Factory」の両方および「Factory Method」」工場です。
そして、残念なことに、多くの人が" Factory"を使用しています。ファクトリーまたはファクトリー(またはそのインターフェース)を作成する別の種類のファクトリーを示します。彼らの理論に基づいて:
Productは、Factoryによって作成されたIProductを実装します。 AbstractFactoryによって作成されるIFactoryを実装します。
これがいかに馬鹿げているかを理解するために、方程式を続けましょう:
AbstractFactoryはIAbstractFactoryを実装します。 AbstractAbstractFactory ???
要点をご覧ください。混乱しないでください。理由がないために存在しないものを発明しないでください。
-
PS :製品のファクトリはAbstractFactoryであり、抽象ファクトリのファクトリもAbstractFactoryの単なる別の例です。
//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{
public Dough createDough(); //Will return you family of Dough
public Clam createClam(); //Will return you family of Clam
public Sauce createSauce(); //Will return you family of Sauce
}
class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{
@Override
public Dough createDough(){
//create the concrete dough instance that NY uses
return doughInstance;
}
//override other methods
}
テキストブックの定義は、他の回答によって既に提供されています。私もそれの例を提供すると思った。
つまり、ここで PizzaIngredientsFactory
は、関連製品のファミリを作成するメソッドを提供する抽象ファクトリです。
Abstractファクトリの各メソッドは、それ自体が Factoryメソッドであることに注意してください。 createDough()
はそれ自体がファクトリメソッドであり、その具体的な実装は NYPizzaIngredientsFactory
などのサブクラスによって提供されます。そのため、それぞれ異なる場所を使用すると、その場所に属する具体的な材料のインスタンスを作成できます。
ファクトリーメソッド
具体的な実装のインスタンスを提供します
例:
- createDough()
-生地の具体的な実装を提供します。これはファクトリーメソッドです
抽象工場
関連オブジェクトのファミリーを作成するためのインターフェースを提供します
例:
- PizzaIngredientsFactory
は、 Dough
、 Clams
、 Sauce
などの関連オブジェクトセットを作成できる抽象ファクトリです。 。オブジェクトの各ファミリを作成するために、ファクトリメソッドが提供されます。
ヘッドファーストデザインパターン の例p>
次のようにジョンの回答に貢献するポイントがあります:
抽象工場は工場の工場です!
"ファクトリーメソッド" (単に" Factory"があいまいであるため)、特定のインターフェイスの実装( IFruit など)の実装(
Lemon
、 Orange
など)を作成しますコード>。このファクトリは、 CitricFruitFactory
と呼ばれます。
しかし、今度はCitricFruitFactoryで作成できない別の種類のフルーツを作成します。 CrotricFruitFactory
のコードは、その中に Strawberry
を作成すると意味をなさないかもしれません(strawberryはクエン酸の実ではありません!)。
したがって、 Strawberry
、 Raspberry
などを生成する RedFruitFactory
という新しいファクトリを作成できます。
ジョンフェミネラのように:
" Abstract Factoryパターンを使用すると、特定のFactoryインターフェース( IFruitFactory
など)の実装を作成できます。それぞれが異なる種類の果物を作る方法を知っています。"
IFruitFactory
の実装は、 CitricFruitFactory
および RedFruitFactory
です!
私の情報源は次のとおりです。 StackOverflow
, tutorialspoint.com
, programmers.stackexchange.com
そして CodeProject.com
.
Factory Method
(とも呼ばれている Factory
) のクライアントを分離するためのものです。 Interface
実装。サンプルとして、 Shape
2つのインターフェイス Circle
そして Square
実装。次のような決定パラメータを持つファクトリ メソッドを使用してファクトリ クラスを定義しました。 Type
および関連する新しい実装 Shape
インターフェース。
Abstract Factory
複数のファクトリ実装による複数のファクトリ メソッドまたはファクトリ インターフェイスが含まれています。上記の次のサンプルには、 Color
2つのインターフェイス Red
そして Yellow
実装。を定義しました。 ShapeColorFactory
2つのインターフェイス RedCircleFactory
そして YellowSquareFactory
. 。この概念を説明するための次のコード:
interface ShapeColorFactory
{
public Shape getShape();
public Color getColor();
}
class RedCircleFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Circle();
}
@Override
public Color getColor() {
return new Red();
}
}
class YellowSquareFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Square();
}
@Override
public Color getColor() {
return new Yellow();
}
}
ここでの違いは、 FactoryMethod
そして AbstractFactory
. Factory Method
単にインターフェイスの具象クラスを返すだけですが、 Abstract Factory
戻る factory of factory
. 。言い換えると Abstract Factory
一連のインターフェイスの異なる組み合わせを返します。
私の説明がお役に立てば幸いです。
これらの工場の主な違いは、工場で何をしたいのか、いつ使用したいのかです。
IOC(制御の反転、たとえばコンストラクター注入)を実行しているときに、ソリッドオブジェクトを作成できることがわかっている場合があります。上記の果物の例で述べたように、果物のオブジェクトを作成する準備ができている場合は、単純な工場パターンを使用できます。
しかし、多くの場合、ソリッドオブジェクトを作成したくないので、それらはプログラムフローの後半になります。ただし、構成では、オブジェクトを作成する代わりに、開始時に使用するファクトリの種類を指定します。共通ファクトリクラスから派生したファクトリをIOCのコンストラクタに渡すことができます。
だから、オブジェクトの寿命と作成についても考えています。
Factory Method
と Abstract Factory
の両方により、クライアントが具象型から切り離された状態に保たれます。どちらもオブジェクトを作成しますが、 Factory
メソッドは継承を使用しますが、 Abstract Factory
はコンポジションを使用します。
Factory Method
はサブクラスで継承されて具象オブジェクト(製品)を作成しますが、 Abstract Factory
は関連製品のファミリを作成するためのインターフェースと、これらのインターフェースのサブクラスを定義します関連製品を作成する方法。
これらのサブクラスは、インスタンス化されたときに製品クラスに渡され、抽象型として使用されます。 Abstract Factory
の関連製品は、多くの場合、 Factory Method
を使用して実装されます。
John Feminellaの回答の拡張:
Apple
、 Banana
、 Cherry
は、 FruitFactory
を実装し、 Create
はAppleまたはBananaまたはCherryを作成する責任を単独で負います。 Factory
メソッドでこれで完了です。
今、あなたはあなたの果物から特別なサラダを作成
したいと思います、そしてあなたの Abstract Factory が来ます。 Abstract Factoryは、アップル、バナナ、チェリーから特別なサラダを作成する方法を知っています。
public class Apple implements Fruit, FruitFactory {
public Fruit Create() {
// Apple creation logic goes here
}
}
public class Banana implements Fruit, FruitFactory {
public Fruit Create() {
// Banana creation logic goes here
}
}
public class Cherry implements Fruit, FruitFactory {
public Fruit Create() {
// Cherry creation logic goes here
}
}
public class SpecialSalad implements Salad, SaladFactory {
public static Salad Create(FruitFactory[] fruits) {
// loop through the factory and create the fruits.
// then you're ready to cut and slice your fruits
// to create your special salad.
}
}
定義により、2つの違いを引き出すことができます:
Factory:オブジェクトの作成にはインターフェースが使用されますが、サブクラスはインスタンス化するクラスを決定します。オブジェクトの作成は、必要なときに行われます。
Abstract Factory:Abstract Factoryパターンは、他の工場を作成するスーパー工場として機能します。 Abstract Factoryパターンでは、インターフェイスは、具体的なクラスを指定せずに、関連オブジェクトのセットまたは依存オブジェクトを作成する役割を果たします。
したがって、上記の定義では、特定の違いを強調できます。つまり、ファクトリパターンはオブジェクトの作成を担当し、抽象ファクトリは関連オブジェクトのセットの作成を担当します。明らかに両方のインターフェイスを介して。
工場パターン:
public interface IFactory{
void VehicleType(string n);
}
public class Scooter : IFactory{
public void VehicleType(string n){
Console.WriteLine("Vehicle type: " + n);
}
}
public class Bike : IFactory{
public void VehicleType(string n) {
Console.WriteLine("Vehicle type: " + n);
}
}
public interface IVehicleFactory{
IFactory GetVehicleType(string Vehicle);
}
public class ConcreteVehicleFactory : IVehicleFactory{
public IFactory GetVehicleType(string Vehicle){
switch (Vehicle){
case "Scooter":
return new Scooter();
case "Bike":
return new Bike();
default:
return new Scooter();
}
}
class Program{
static void Main(string[] args){
IVehicleFactory factory = new ConcreteVehicleFactory();
IFactory scooter = factory.GetVehicleType("Scooter");
scooter.VehicleType("Scooter");
IFactory bike = factory.GetVehicleType("Bike");
bike.VehicleType("Bike");
Console.ReadKey();
}
}
抽象的な工場パターン:
interface IVehicleFactory{
IBike GetBike();
IScooter GetScooter();
}
class HondaFactory : IVehicleFactory{
public IBike GetBike(){
return new FZS();
}
public IScooter GetScooter(){
return new FZscooter();
}
}
class HeroFactory: IVehicleFactory{
public IBike GetBike(){
return new Pulsur();
}
public IScooter GetScooter(){
return new PulsurScooter();
}
}
interface IBike
{
string Name();
}
interface IScooter
{
string Name();
}
class FZS:IBike{
public string Name(){
return "FZS";
}
}
class Pulsur:IBike{
public string Name(){
return "Pulsur";
}
}
class FZscooter:IScooter {
public string Name(){
return "FZscooter";
}
}
class PulsurScooter:IScooter{
public string Name(){
return "PulsurScooter";
}
}
enum MANUFACTURERS
{
HONDA,
HERO
}
class VehicleTypeCheck{
IBike bike;
IScooter scooter;
IVehicleFactory factory;
MANUFACTURERS manu;
public VehicleTypeCheck(MANUFACTURERS m){
manu = m;
}
public void CheckProducts()
{
switch (manu){
case MANUFACTURERS.HONDA:
factory = new HondaFactory();
break;
case MANUFACTURERS.HERO:
factory = new HeroFactory();
break;
}
Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " + factory.GetScooter().Name());
}
}
class Program
{
static void Main(string[] args)
{
VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
chk.CheckProducts();
chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
chk.CheckProducts();
Console.Read();
}
}
こちらで確認: http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm Factoryメソッドは特定のクラス(抽象ではなく)を基本クラスとして使用し、Abstractファクトリはこれに抽象クラスを使用しているようです。また、抽象クラスの代わりにインターフェイスを使用する場合、結果は抽象ファクトリパターンの異なる実装になります。
:D
Abstract Factoryは、さまざまな種類のインターフェイスを作成するためのテンプレートです。 数量、価格、アイテム固有の情報を含むさまざまな種類のcsvファイルを解析する必要があるプロジェクトがあるとします。たとえば、チョコレートに関する果物やその他のデータに関するデータが含まれ、解析後に、対応するデータベースでこの情報を更新する必要があります。パーサーと修飾子ファクトリーを返す1つの抽象ファクトリーと、このパーサーファクトリーはチョコレートパーサーオブジェクト、フルーツパーサーオブジェクトなどを返します。同様に、修飾子ファクトリーはチョコレート修飾子オブジェクト、フルーツ修飾子オブジェクトなどを返します。
Java8のサンプルコードを見れば、これら2つの違いを理解できると思います。
interface Something{}
interface OneWhoCanProvideSomething {
Something getSomething();
}
interface OneWhoCanProvideCreatorsOfSomething{
OneWhoCanProvideSomething getCreator();
}
public class AbstractFactoryExample {
public static void main(String[] args) {
//I need something
//Let's create one
Something something = new Something() {};
//Or ask someone (FACTORY pattern)
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;
//Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;
//Same thing, but you don't need to write you own interfaces
Supplier<Something> supplierOfSomething = () -> null;
Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
}
}
問題は、どの作成方法を使用する必要があるか、およびその理由です。 最初の方法(パターンなし、単なるコンストラクター):自分で作成することは良い考えではありません。すべての作業を行う必要があり、クライアントコードは特定の実装に関連付けられています。
2番目の方法(Factoryパターンを使用):任意のタイプの実装を渡すことができるという利点があり、何らかの条件(作成メソッドにパラメーターが渡される場合があります)に基づいて異なるタイプを提供できます。
3番目の方法(Abstract Factoryパターンを使用):これにより、柔軟性が向上します。何らかの条件(パラメーターが渡された場合など)に基づいて、さまざまなタイプの作成者を見つけることができます。
2つの条件を組み合わせることでFactoryパターンをいつでも回避できることに注意してください(コードの複雑さとカップリングがわずかに増加します)。 。