ファクトリ パターンを使用すると、オブジェクトの作成プロセスと使用を分離 (つまり、分離) することができ、オブジェクト作成プロセスのカプセル化が促進されます。
前回の記事「初心者のための Java デザイン パターン学習に関するメモ - ファクトリ パターン」の例1と4を確認すると、次のような疑問が生じるかもしれません。
なぜ抽象製品クラスがあるのでしょうか?
ファクトリ メソッドが抽象製品クラス型を返すのはなぜですか?
クライアントによって呼び出されたときに、製品クラス オブジェクトも抽象製品クラスを通じて定義されるのはなぜですか?
これは、ファクトリ パターンにおける製品クラスの多態性です。
特定の製品クラスは抽象製品クラスを継承 (または実装) するため、クライアントは特定の製品の実際のタイプを知る必要がなく、必要な製品を取得できます。
このポリモーフィズムは、ファクトリ パターンのカプセル化効果を促進し、ファクトリ クラスは、どの製品が作成されるか、および製品オブジェクトの作成方法の詳細を完全にカプセル化します。
現実世界を通してポリモーフィズムを理解する:
お客様Aは当初Audi A6の購入を希望していましたが、たまたまメーカーがAudi A8の新型を生産し、Audi A6は生産中止となり、価格もほぼ同じでした。そこで、顧客 A は注文を変更して、Audi A8 を購入しました。
次に、例 1 に基づいて、新しい特定の製品クラス AudiA8Car を追加し、ファクトリ クラス CarFactory を変更するだけです。
例 5:
Audi A8 (特定の製品の役割):
一汽フォルクスワーゲンが生産する新車という、新しい特定の製品カテゴリが追加されました。
/*
* 奥迪A8，是一汽大众生产的一款汽车 （具体产品类）
*/
public class AudiA8Car extends Car {
public AudiA8Car(){
this.name = "奥迪A8";
}
public String toString(){
return "一辆"+ this.name;
}
}
一汽フォルクスワーゲン (工場の役割):
静的ファクトリ メソッド manufactureCar() が変更され、当初はAudiA6Carのオブジェクトを返していましたが、現在はAudiA8Carのオブジェクトを返すようになりました。
/*
* 生产汽车的工厂，一汽大众 （工厂类）
*/
public class CarFactory {
/*
* 生产汽车（通过一个静态方法来得到一辆汽车的对象）
*/
public static Car manufactureCar(){
// 奥迪A6停产了
// return new AudiA6Car();
// 新款汽车奥迪A8
return new AudiA8Car();
}
}
車 (抽象的な製品の役割):
例 1 と同じですが、変更は加えられません。
/*
* 奥迪A6，是一汽大众生产的一款汽车 （具体产品类）
*/
public class AudiA6Car extends Car {
public AudiA6Car(){
this.name = "奥迪A6";
}
public String toString(){
return "一辆"+ this.name;
}
}
このアウディ A6 車を購入した顧客 A (クライアント):
こちらも例 1 と同じですが、変更はありません。
/*
* 购买汽车的顾客A(客户端)
*/
public class CustomerA {
public static void main(String[] args){
// 通过汽车工厂来制造出了一辆汽车
Car myCar = CarFactory.manufactureCar();
System.out.println("一辆汽车被造好，并且出厂了。");
// 顾客得到了一辆汽车，十分的高兴
System.out.println("我终于买了"+myCar+"。真是太好了！");
}
}
操作結果:
一辆汽车被造好，并且出厂了。
我终于买了一辆奥迪A8。真是太好了！
上記の実行結果によれば、この多態性の利点がわかります。
カプセル化効果が向上し、クライアントは変更を加えずに要件の変更を実現できます。
一般的に、
ファクトリ パターンは、デカップリングとポリモーフィズムを通じてオブジェクトの作成と使用を分離し、複雑なオブジェクト作成プロセスをカプセル化し、オブジェクトの使用を統合します。
コードのメンテナンスと変更が容易になり、コードが要件の変更に適応しやすくなり、システムに対する変更の影響が軽減されます。