Javaのデザインパターンの中でも、抽象ファクトリーパターンは複数の関連オブジェクト群を効率的に生成するための強力な手法です。このパターンは、特定の種類のオブジェクトを動的に作成する場合に役立ちます。特に、アプリケーションが複数のプラットフォームや環境に対応する場合、抽象ファクトリは、異なる設定や条件に応じてオブジェクトの生成をカプセル化し、コードの柔軟性と拡張性を高めます。本記事では、抽象ファクトリーパターンの基本的な概念から、その具体的な使用方法まで詳しく解説します。
抽象ファクトリーパターンとは
抽象ファクトリーパターンは、オブジェクトの生成を目的とする「クリエイショナルデザインパターン」の一つです。このパターンでは、関連するオブジェクト群を一貫して生成するためのインターフェースを提供します。クライアント側は、具体的なクラスの生成を知らずに、抽象的なファクトリを通じてオブジェクトを作成できるため、コードの依存性を減らし、拡張が容易になります。
抽象ファクトリーパターンの特徴は、複数の製品ファミリーをまとめて作成できることです。たとえば、GUIフレームワークで、異なるプラットフォームに対応したボタンやウィンドウを生成する際に便利です。これにより、コードが柔軟に対応できるだけでなく、メンテナンス性も向上します。
抽象ファクトリーパターンの構成要素
抽象ファクトリーパターンは、以下の主要な構成要素で成り立っています。
1. 抽象ファクトリ (AbstractFactory)
抽象ファクトリは、関連するオブジェクト群を生成するためのインターフェースを定義します。このインターフェースには、異なる製品ファミリーを生成するメソッドが含まれます。クライアントは、この抽象ファクトリを通じてオブジェクトを生成しますが、具体的な生成方法やクラスの詳細には依存しません。
2. 具体的ファクトリ (ConcreteFactory)
具体的ファクトリは、抽象ファクトリを実装し、実際にオブジェクトを生成します。それぞれの具体的ファクトリは、特定の製品ファミリーを生成する責任を負います。たとえば、MacOS向けのUIコンポーネントを生成するファクトリや、Windows向けのUIコンポーネントを生成するファクトリなどです。
3. 抽象製品 (AbstractProduct)
抽象製品は、ファクトリによって生成されるオブジェクト群の共通インターフェースを定義します。たとえば、UIコンポーネントの場合、ボタンやウィンドウなどの共通の振る舞いを定義します。
4. 具体的製品 (ConcreteProduct)
具体的製品は、抽象製品を実装し、実際のオブジェクトを提供します。具体的なプラットフォームや環境に対応したオブジェクトが生成されるため、クライアントは適切な製品を使用できます。
5. クライアント (Client)
クライアントは、抽象ファクトリを使用してオブジェクトを生成し、それを利用します。クライアントは具体的な生成過程やクラスに依存せず、抽象ファクトリと抽象製品のインターフェースを通じて操作を行います。これにより、クライアントコードの拡張性と保守性が向上します。
抽象ファクトリーパターンの使用例
ここでは、Javaでの抽象ファクトリーパターンの具体的な使用例を見ていきます。UIコンポーネントを生成する場面を例に、異なるプラットフォーム（MacとWindows）に応じて異なるボタンやウィンドウを生成するコードを示します。
1. 抽象ファクトリの定義
まず、ボタンやウィンドウを生成するための抽象ファクトリを定義します。
// 抽象ファクトリ
public interface GUIFactory {
Button createButton();
Window createWindow();
}2. 抽象製品の定義
次に、ボタンやウィンドウの抽象製品を定義します。
// 抽象製品 - ボタン
public interface Button {
void render();
}
// 抽象製品 - ウィンドウ
public interface Window {
void open();
}3. 具体的製品の定義
次に、MacOS用とWindows用の具体的な製品を実装します。
// MacOS用具体的製品 - ボタン
public class MacButton implements Button {
public void render() {
System.out.println("Mac OS ボタンを表示");
}
}
// MacOS用具体的製品 - ウィンドウ
public class MacWindow implements Window {
public void open() {
System.out.println("Mac OS ウィンドウを開く");
}
}
// Windows用具体的製品 - ボタン
public class WinButton implements Button {
public void render() {
System.out.println("Windows ボタンを表示");
}
}
// Windows用具体的製品 - ウィンドウ
public class WinWindow implements Window {
public void open() {
System.out.println("Windows ウィンドウを開く");
}4. 具体的ファクトリの実装
それぞれの具体的ファクトリが対応するオブジェクトを生成します。
// MacOS用ファクトリ
public class MacFactory implements GUIFactory {
public Button createButton() {
return new MacButton();
}
public Window createWindow() {
return new MacWindow();
}
}
// Windows用ファクトリ
public class WinFactory implements GUIFactory {
public Button createButton() {
return new WinButton();
}
public Window createWindow() {
return new WinWindow();
}
}5. クライアントコード
最後に、クライアントが抽象ファクトリを使ってオブジェクトを生成し、利用するコードを記述します。
public class Application {
private GUIFactory factory;
private Button button;
private Window window;
public Application(GUIFactory factory) {
this.factory = factory;
this.button = factory.createButton();
this.window = factory.createWindow();
}
public void renderUI() {
button.render();
window.open();
}
public static void main(String[] args) {
// Mac環境の場合
GUIFactory macFactory = new MacFactory();
Application macApp = new Application(macFactory);
macApp.renderUI();
// Windows環境の場合
GUIFactory winFactory = new WinFactory();
Application winApp = new Application(winFactory);
winApp.renderUI();
}
}6. 実行結果
実行環境に応じて、以下のような結果が表示されます。
// Mac環境の出力
Mac OS ボタンを表示
Mac OS ウィンドウを開く
// Windows環境の出力
Windows ボタンを表示
Windows ウィンドウを開くこのように、抽象ファクトリーパターンを使用することで、異なる環境に対応した関連オブジェクト群を簡単に生成できます。クライアントは、どの具体的なクラスが使われているかを意識する必要がないため、拡張性や保守性が向上します。
抽象ファクトリパターンのメリット
抽象ファクトリーパターンには、設計の柔軟性やコードのメンテナンス性を向上させる多くのメリットがあります。ここでは、代表的な利点をいくつか紹介します。
1. 依存性の逆転による拡張性
抽象ファクトリパターンでは、クライアントコードが具体的なクラスに依存しないため、将来異なる製品ファミリーを導入したい場合でも、既存のコードをほとんど変更せずに対応できます。新しいファクトリと製品を実装するだけで、新しい環境や要件に適応できる点が大きなメリットです。
2. 一貫性のあるオブジェクト群の生成
抽象ファクトリを使うことで、異なるプラットフォームや製品ファミリーに対応したオブジェクトを、一貫した方法で生成できます。これにより、アプリケーション全体のUIや機能に統一感を持たせることができ、品質を保ちながらも柔軟な対応が可能となります。
3. コードの可読性とメンテナンス性の向上
クライアントコードは、抽象的なインターフェースに依存するため、具体的なクラスの実装が変更されてもクライアント側のコードには影響を与えません。この分離によって、コードの可読性やメンテナンス性が向上し、大規模なプロジェクトでも変更管理が容易になります。
4. テストやモック化が容易になる
抽象ファクトリーパターンを使えば、テスト環境で異なる製品やファクトリを簡単に差し替えることが可能です。モックオブジェクトを使用して、実際のオブジェクトを置き換えることで、テストの柔軟性も大幅に向上します。これにより、単体テストや統合テストがより効果的に行えます。
5. 依存関係の管理が容易
抽象ファクトリパターンは、オブジェクト生成の責任をクライアントからファクトリに委譲するため、依存関係が明確に管理されます。これにより、依存関係の複雑化を防ぎ、依存関係が変更された場合でも、他の部分に与える影響を最小限に抑えられます。
以上のように、抽象ファクトリパターンは拡張性、統一性、可読性、テストのしやすさといった多くのメリットを提供し、特に複雑なシステムや異なる環境に対応するプロジェクトにおいて、その強力さを発揮します。
適用例1：UIコンポーネントの生成
抽象ファクトリーパターンは、複数の異なるプラットフォームに対応したUIコンポーネントの生成に非常に役立ちます。例えば、アプリケーションがWindowsとMacOSの両方で動作する必要がある場合、それぞれのプラットフォームに適したUI部品（ボタン、ウィンドウなど）を一貫して生成できるように設計する必要があります。
1. 異なるプラットフォームに対応したUI部品
WindowsとMacOSでは、UIコンポーネントの見た目や挙動が異なるため、プラットフォームごとに適切なボタンやウィンドウを生成することが重要です。抽象ファクトリーパターンを使用することで、クライアントコードはUI部品の生成方法に依存することなく、ボタンやウィンドウを作成できます。
Windows用のUI部品
Windowsでは、UIコンポーネントがシステムネイティブのスタイルに従う必要があります。たとえば、Windowsスタイルのボタンは角ばったデザインが特徴的です。
public class WinButton implements Button {
public void render() {
System.out.println("Windowsスタイルのボタンを描画");
}
}
public class WinWindow implements Window {
public void open() {
System.out.println("Windowsスタイルのウィンドウを開く");
}
}MacOS用のUI部品
MacOSでは、UIコンポーネントは丸みを帯びたデザインや柔らかな色合いを持っています。Macスタイルのボタンやウィンドウもこれに従って生成されます。
public class MacButton implements Button {
public void render() {
System.out.println("MacOSスタイルのボタンを描画");
}
}
public class MacWindow implements Window {
public void open() {
System.out.println("MacOSスタイルのウィンドウを開く");
}
}2. 抽象ファクトリの活用
抽象ファクトリを使って、どのプラットフォームでも統一的なインターフェースでUI部品を生成することができます。これにより、コードの可読性が向上し、プラットフォームに依存しない形でUIコンポーネントを利用できます。
public class Application {
private Button button;
private Window window;
public Application(GUIFactory factory) {
button = factory.createButton();
window = factory.createWindow();
}
public void renderUI() {
button.render();
window.open();
}
}3. 実行結果
異なるプラットフォームにおいて、適切なUI部品が生成されるため、次のような結果が得られます。
// Windows環境での出力
Windowsスタイルのボタンを描画
Windowsスタイルのウィンドウを開く
// MacOS環境での出力
MacOSスタイルのボタンを描画
MacOSスタイルのウィンドウを開くこのように、抽象ファクトリーパターンは、異なるプラットフォーム間で一貫したUI生成を実現し、アプリケーションの移植性を高めるとともに、コードの変更に強い設計を提供します。
適用例2：データベース接続の管理
抽象ファクトリーパターンは、異なるデータベース環境における接続管理にも応用できます。アプリケーションがMySQL、PostgreSQL、Oracleなど、複数のデータベースに対応する必要がある場合、抽象ファクトリを使って各データベースに応じた接続やクエリ処理を統一的に管理できます。
1. 異なるデータベース接続の抽象化
まず、異なるデータベースとの接続やクエリ実行を抽象化するためのインターフェースを定義します。これにより、データベースの種類に依存せずに、アプリケーションが操作を行えるようになります。
// 抽象製品 - データベース接続
public interface DBConnection {
void connect();
void executeQuery(String query);
}2. 具体的なデータベース接続の実装
次に、各データベースに対応する具体的な接続クラスを実装します。それぞれのデータベースで異なる接続方法やクエリ処理を行います。
// MySQL用具体的製品 - 接続
public class MySQLConnection implements DBConnection {
public void connect() {
System.out.println("MySQLに接続しました");
}
public void executeQuery(String query) {
System.out.println("MySQLでクエリを実行: " + query);
}
}
// PostgreSQL用具体的製品 - 接続
public class PostgreSQLConnection implements DBConnection {
public void connect() {
System.out.println("PostgreSQLに接続しました");
}
public void executeQuery(String query) {
System.out.println("PostgreSQLでクエリを実行: " + query);
}
}
// Oracle用具体的製品 - 接続
public class OracleConnection implements DBConnection {
public void connect() {
System.out.println("Oracleに接続しました");
}
public void executeQuery(String query) {
System.out.println("Oracleでクエリを実行: " + query);
}
}3. 抽象ファクトリの実装
次に、データベース接続を生成するための抽象ファクトリを実装します。クライアントは、どのデータベースに接続するかを知らずに、抽象ファクトリを通じて適切な接続を取得できます。
// 抽象ファクトリ
public interface DBFactory {
DBConnection createConnection();
}
// 具体的ファクトリ - MySQL
public class MySQLFactory implements DBFactory {
public DBConnection createConnection() {
return new MySQLConnection();
}
}
// 具体的ファクトリ - PostgreSQL
public class PostgreSQLFactory implements DBFactory {
public DBConnection createConnection() {
return new PostgreSQLConnection();
}
}
// 具体的ファクトリ - Oracle
public class OracleFactory implements DBFactory {
public DBConnection createConnection() {
return new OracleConnection();
}
}4. クライアントコード
クライアントは抽象ファクトリを使ってデータベース接続を取得し、クエリを実行します。データベースの種類に依存しないため、接続方法や処理を簡単に変更できます。
public class DatabaseApplication {
private DBConnection connection;
public DatabaseApplication(DBFactory factory) {
connection = factory.createConnection();
}
public void runQuery(String query) {
connection.connect();
connection.executeQuery(query);
}
public static void main(String[] args) {
// MySQL接続
DBFactory mysqlFactory = new MySQLFactory();
DatabaseApplication app1 = new DatabaseApplication(mysqlFactory);
app1.runQuery("SELECT * FROM users");
// PostgreSQL接続
DBFactory postgresFactory = new PostgreSQLFactory();
DatabaseApplication app2 = new DatabaseApplication(postgresFactory);
app2.runQuery("SELECT * FROM orders");
// Oracle接続
DBFactory oracleFactory = new OracleFactory();
DatabaseApplication app3 = new DatabaseApplication(oracleFactory);
app3.runQuery("SELECT * FROM products");
}
}5. 実行結果
各データベースに応じて適切な接続とクエリ実行が行われます。
// MySQL環境の出力
MySQLに接続しました
MySQLでクエリを実行: SELECT * FROM users
// PostgreSQL環境の出力
PostgreSQLに接続しました
PostgreSQLでクエリを実行: SELECT * FROM orders
// Oracle環境の出力
Oracleに接続しました
Oracleでクエリを実行: SELECT * FROM productsこのように、抽象ファクトリーパターンを使用することで、異なるデータベース環境に対して柔軟に対応できる接続管理システムを構築できます。新しいデータベースを導入する際も、既存のクライアントコードに影響を与えることなく拡張可能です。
抽象ファクトリパターンの欠点
抽象ファクトリパターンは多くのメリットを提供しますが、その反面、いくつかの欠点も存在します。これらの欠点を理解することで、どのような状況でこのパターンを使用すべきかを正しく判断できます。
1. コードの複雑化
抽象ファクトリパターンを導入すると、クラスの数が増え、コード全体が複雑化する可能性があります。各製品ファミリーに対応する具体的なファクトリや製品クラスを別々に実装する必要があるため、規模の大きなシステムではクラスの管理が難しくなることがあります。特に、シンプルな設計が求められるプロジェクトでは、オーバーエンジニアリングとなりかねません。
2. 柔軟性の制約
抽象ファクトリパターンは、製品群を一貫した方法で生成することに特化していますが、その一方で、製品ファミリー間の違いに対する柔軟性が制限されることがあります。つまり、ファクトリが生成する製品が予め固定されており、製品ごとに異なる動作や設定を求める場合には、柔軟に対応できない可能性があります。
3. 変更が困難になる場合がある
既存の抽象ファクトリや製品群に新たな製品や機能を追加する場合、インターフェースやクラスの変更が必要になることがあります。特に、既に複数のファクトリや製品が導入されている場合、変更の影響範囲が大きくなり、予期しないバグやエラーを引き起こす可能性があります。
4. 製品ファミリーの追加が難しい
新しい製品ファミリーを追加する際には、既存の抽象ファクトリや具体的ファクトリに対応する新しいクラスやインターフェースを追加する必要があります。製品ファミリーを頻繁に追加する必要がある場合、設計や管理が複雑になり、保守性が低下する恐れがあります。
5. 学習コストが高い
抽象ファクトリパターンは、比較的高度なデザインパターンの一つです。特に初学者にとっては、抽象クラスやインターフェースの概念を理解する必要があり、導入に時間がかかることがあります。また、プロジェクトのメンバー全員がこのパターンを理解しているとは限らないため、導入後のコミュニケーションやコードレビューにおいても学習コストが発生します。
以上のように、抽象ファクトリパターンは強力ですが、適切な状況で使用しないと、コードの複雑化や変更の難しさにつながるリスクがあります。設計段階での慎重な検討が必要です。
その他の関連デザインパターン
抽象ファクトリパターンは、オブジェクト生成に特化したクリエイショナルデザインパターンの一つですが、他にも関連するデザインパターンがいくつか存在します。それぞれのパターンには異なる特徴があり、使用するシチュエーションによって最適な選択肢が変わります。ここでは、ファクトリメソッドパターンやビルダーパターンと比較しながら、それぞれの違いを解説します。
1. ファクトリメソッドパターン
ファクトリメソッドパターンも、オブジェクト生成を管理するデザインパターンの一つです。このパターンでは、サブクラスが実装するファクトリメソッドを定義し、そのメソッドを通じてオブジェクトを生成します。ファクトリメソッドパターンは、単一の製品オブジェクトを生成する場合に適していますが、抽象ファクトリのように複数の関連するオブジェクト群を一括で生成することはできません。
// ファクトリメソッドの例
public abstract class Dialog {
public void renderWindow() {
Button okButton = createButton();
okButton.render();
}
protected abstract Button createButton();
}主な違い
- ファクトリメソッドパターンは、1つの製品を生成する際に用いる。
- 抽象ファクトリパターンは、関連する複数の製品をまとめて生成できる。
2. ビルダーパターン
ビルダーパターンは、複雑なオブジェクトの生成を段階的に行うためのパターンです。オブジェクトが複数のパラメータや構成要素を持ち、それらを順次設定していく場合に適しています。ファクトリパターンや抽象ファクトリパターンが「どのオブジェクトを生成するか」に注目しているのに対し、ビルダーパターンは「どのようにオブジェクトを組み立てるか」に焦点を当てます。
// ビルダーパターンの例
public class Car {
private String engine;
private String wheels;
private String color;
// CarBuilderクラスを使用してCarオブジェクトを生成
public static class CarBuilder {
private String engine;
private String wheels;
private String color;
public CarBuilder setEngine(String engine) {
this.engine = engine;
return this;
}
public CarBuilder setWheels(String wheels) {
this.wheels = wheels;
return this;
}
public CarBuilder setColor(String color) {
this.color = color;
return this;
}
public Car build() {
Car car = new Car();
car.engine = this.engine;
car.wheels = this.wheels;
car.color = this.color;
return car;
}
}
}主な違い
- ビルダーパターンは、複雑なオブジェクトを段階的に構築するために使用される。
- 抽象ファクトリパターンは、関連するオブジェクト群を一度に生成することを目的としている。
3. プロトタイプパターン
プロトタイプパターンは、既存のオブジェクトをコピーして新しいオブジェクトを生成するパターンです。複製が簡単に行える場合、もしくはクラスのインスタンスを動的に変更したい場合に有効です。新しいインスタンスを作成するよりも、既存のオブジェクトをコピーする方がコストが低いケースで活用されます。
// プロトタイプパターンの例
public abstract class Shape implements Cloneable {
private String id;
protected String type;
abstract void draw();
public Object clone() {
Object clone = null;
try {
clone = super.clone();
} catch (CloneNotSupportedException e) {
e.printStackTrace();
}
return clone;
}
}主な違い
- プロトタイプパターンは、既存のオブジェクトをコピーして生成する。
- 抽象ファクトリパターンは、製品群を一貫して生成するためのインターフェースを提供する。
4. シングルトンパターン
シングルトンパターンは、特定のクラスに対してインスタンスを一つだけ作成し、そのインスタンスへのアクセスを提供するパターンです。オブジェクトの生成を管理する点でファクトリパターンと関連していますが、シングルトンは特定のクラスのインスタンスが一つしか存在しないことを保証します。
// シングルトンパターンの例
public class Singleton {
private static Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}主な違い
- シングルトンパターンは、単一のインスタンスしか生成しない。
- 抽象ファクトリパターンは、関連する複数のオブジェクトを生成できる。
これらのパターンは、それぞれ異なる目的や状況に応じた使い分けが必要です。抽象ファクトリパターンは、関連するオブジェクト群の一貫した生成に特化していますが、他のパターンと組み合わせて使うことで、より柔軟なシステム設計が可能になります。
実装時の注意点
抽象ファクトリパターンは強力なデザインパターンですが、実装時にいくつか注意すべき点があります。これらの点を考慮しないと、パターンの効果が薄れ、コードの複雑化や誤った設計につながる可能性があります。以下に、実装時の具体的な注意点を解説します。
1. 不必要な抽象化の回避
抽象ファクトリパターンを適用する場合、実際に複数の製品ファミリーが存在するか、今後導入される可能性があるかどうかを慎重に考慮する必要があります。単一の製品ファミリーしか必要としないプロジェクトでは、抽象ファクトリパターンを導入することでかえってコードが複雑になり、過剰な抽象化につながります。シンプルなファクトリメソッドや直接インスタンス化で十分なケースも多くあります。
2. クラスの膨れ上がりに注意
抽象ファクトリパターンでは、製品ごとに抽象クラスやインターフェース、具体的なクラスを定義する必要があるため、プロジェクト全体でクラスの数が増えることがあります。特に、製品ファミリーが多くなると、対応する具体的ファクトリや製品のクラスも増えるため、管理が難しくなる可能性があります。過度にクラスが増えないよう、必要な部分に限定してパターンを適用することが重要です。
3. 一貫性のある製品ファミリーの定義
抽象ファクトリパターンを使う場合、同じ製品ファミリーに属するオブジェクトは、必ず一貫性を保つように設計する必要があります。異なるファミリーの製品が混在してしまうと、アプリケーションの整合性が崩れ、予期しない動作を引き起こす可能性があります。ファクトリが生成するオブジェクト群が一貫性のある振る舞いを提供することを確認することが大切です。
4. アンチパターンに注意
抽象ファクトリパターンを誤用すると、いわゆる「アンチパターン」となることがあります。たとえば、ファクトリが大量の製品ファミリーやオプションを扱いすぎると、ファクトリ自体が複雑になり、かえって拡張やメンテナンスが難しくなります。また、ファクトリを無理に使うことで、実際には単純なクラスの生成が適している場合でもパターンが過度に適用されることがあります。このような場合は、シンプルなアプローチに戻るべきです。
5. パフォーマンスの考慮
抽象ファクトリパターンは、オブジェクト生成の責任をファクトリに委譲しますが、特に大規模なシステムでは、オブジェクトの生成や依存関係の解決が頻繁に行われる場合に、パフォーマンスへの影響を考慮する必要があります。場合によっては、生成したオブジェクトをキャッシュして再利用する方法（シングルトンパターンとの併用など）や、遅延初期化を採用することも有効です。
6. 製品ファミリーの変更や拡張
新しい製品ファミリーを追加する場合、既存の抽象ファクトリや具体的ファクトリに対応するクラスを追加する必要があります。この作業は、設計をよく理解していれば比較的スムーズに行えますが、変更範囲が大きくなることがあるため、既存のファクトリや製品が他の部分に強く依存している場合、慎重に対応する必要があります。依存関係の管理が適切に行われているかを常にチェックしながら変更を進めることが重要です。
これらの注意点を念頭に置いて、抽象ファクトリパターンを適切に実装すれば、コードの拡張性とメンテナンス性を大幅に向上させることができます。パターンの利点を最大限に引き出すためには、状況に応じたバランスの取れた設計が必要です。
応用演習
ここでは、抽象ファクトリパターンの理解を深めるための応用演習を用意しました。この演習では、抽象ファクトリパターンを使用して、複数の関連オブジェクトを生成する実践的な課題に取り組みます。コードを書きながら学ぶことで、パターンの応用方法を体感してください。
演習内容：多言語対応アプリケーションのメッセージ生成
あなたは、多言語対応のメッセージを生成するシステムを設計しています。システムは、言語ごとに異なるメッセージフォーマット（挨拶や感謝のメッセージなど）を出力する必要があります。例えば、英語とフランス語に対応するメッセージをそれぞれ生成します。
演習手順
- 抽象ファクトリの作成
言語ごとのメッセージを生成するための抽象ファクトリを作成します。ファクトリは、挨拶メッセージと感謝メッセージの2つのメソッドを持ちます。
public interface MessageFactory {
GreetingMessage createGreetingMessage();
ThankYouMessage createThankYouMessage();
}- 抽象製品の作成
抽象製品として、GreetingMessageとThankYouMessageのインターフェースを定義します。
public interface GreetingMessage {
String getMessage();
}
public interface ThankYouMessage {
String getMessage();
}- 具体的製品の作成
英語とフランス語に対応した具体的な製品をそれぞれ実装します。
// 英語の挨拶メッセージ
public class EnglishGreetingMessage implements GreetingMessage {
public String getMessage() {
return "Hello!";
}
}
// 英語の感謝メッセージ
public class EnglishThankYouMessage implements ThankYouMessage {
public String getMessage() {
return "Thank you!";
}
// フランス語の挨拶メッセージ
public class FrenchGreetingMessage implements GreetingMessage {
public String getMessage() {
return "Bonjour!";
}
}
// フランス語の感謝メッセージ
public class FrenchThankYouMessage implements ThankYouMessage {
public String getMessage() {
return "Merci!";
}
}- 具体的ファクトリの作成
英語とフランス語のメッセージを生成する具体的なファクトリクラスを実装します。
// 英語のメッセージファクトリ
public class EnglishMessageFactory implements MessageFactory {
public GreetingMessage createGreetingMessage() {
return new EnglishGreetingMessage();
}
public ThankYouMessage createThankYouMessage() {
return new EnglishThankYouMessage();
}
}
// フランス語のメッセージファクトリ
public class FrenchMessageFactory implements MessageFactory {
public GreetingMessage createGreetingMessage() {
return new FrenchGreetingMessage();
}
public ThankYouMessage createThankYouMessage() {
return new FrenchThankYouMessage();
}
}- クライアントコードの作成
クライアントが言語に依存せず、メッセージを生成できるように、抽象ファクトリを使ってオブジェクトを生成します。
public class Application {
private MessageFactory messageFactory;
public Application(MessageFactory factory) {
this.messageFactory = factory;
}
public void displayMessages() {
GreetingMessage greeting = messageFactory.createGreetingMessage();
ThankYouMessage thankYou = messageFactory.createThankYouMessage();
System.out.println(greeting.getMessage());
System.out.println(thankYou.getMessage());
}
public static void main(String[] args) {
// 英語メッセージの生成
MessageFactory englishFactory = new EnglishMessageFactory();
Application englishApp = new Application(englishFactory);
englishApp.displayMessages();
// フランス語メッセージの生成
MessageFactory frenchFactory = new FrenchMessageFactory();
Application frenchApp = new Application(frenchFactory);
frenchApp.displayMessages();
}
}実行結果
// 英語メッセージの出力
Hello!
Thank you!
// フランス語メッセージの出力
Bonjour!
Merci!演習のポイント
- 抽象ファクトリパターンを使い、クライアントが言語の違いを意識せずにメッセージを生成する方法を学ぶ。
- 新しい言語を追加する場合は、新しいファクトリと製品クラスを実装するだけで済むため、拡張が容易であることを確認。
この演習を通して、抽象ファクトリパターンの実践的な利用方法を学ぶことができます。多言語対応のシステムや、異なる条件に応じた製品を生成する必要があるアプリケーションに、このパターンは非常に有効です。
まとめ
本記事では、Javaの抽象ファクトリパターンを用いた関連オブジェクト群の生成について解説しました。抽象ファクトリパターンは、関連する製品ファミリーを一貫して生成するための強力なデザインパターンです。複数のプラットフォームやデータベース接続、UIコンポーネントなど、異なる条件に応じてオブジェクトを生成する際に役立ちます。
また、実装時の注意点や関連するデザインパターン、応用例も紹介し、パターンの効果的な利用方法を学びました。適切に使用することで、システムの拡張性やメンテナンス性を大幅に向上させることができるため、設計段階での判断が重要です。
コメント