English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية

  1. 位置情報
  2. ホームページ
  3. 経験記録
  4. 本文

Androidのプログラミング設計パターンの抽象工場パターンの詳細解説

この記事では、Androidプログラミングデザインパターンの抽象工場パターンについて説明しています。皆さんにご参考に供えます。以下の通りです：

一、紹介

抽象工場パターン（Abstract Factory Pattern）は、創造型デザインパターンのうちの1つです。前節で工場メソッドパターンについて学びましたが、この抽象工場はどのようなものか考えてみましょう。現実世界の工場は具体的であることが多いです、つまり各工場は特定の具体的な製品を作成するということがあります。それでは抽象工場は生成される製品が不確定であるという意味ですが、これはとても奇妙なことのように感じられます。抽象工場パターンは、以前の異なるオペレーティングシステムのグラフィカルなソリューションから起源を発しています。例えば、異なるオペレーティングシステム内のボタンやテキストボックスコントロールは実現が異なり、表示も異なります。各オペレーティングシステムは自身が製品クラスを構成し、ボタンやテキストボックスコントロールも製品クラスを構成します。二つの製品クラスが二つの変化を持ち、それぞれ独自の特性があります。例えば、AndroidのButtonとTextView、iOSのButtonとTextView、Windows PhoneのButtonとTextViewなど。

二、定義

一連の関連あるいは相互依存するオブジェクトの作成にインターフェースを提供し、それらの具体的なクラスを指定する必要がありません。

三、使用シーン

一つのオブジェクト群が同じ制約を持っている場合、抽象工場パターンを使用することができます。非常に抽象的な感じがしますか？例えば、Android、iOS、Windows Phoneの下にSMSソフトウェアとダイヤルソフトウェアがあり、これらはすべてSoftwareソフトウェアの範囲に属していますが、それぞれのオペレーティングシステムプラットフォームが異なるため、同じ会社が製品を提供している場合でも、そのコードの実現ロジックは異なります。この場合、Android、iOS、Windows PhoneのSMSソフトウェアとダイヤルソフトウェアを作成するために抽象工場メソッドパターンを考慮することができます。

四、抽象工場パターンのUMLクラス図

UMLクラス図：

抽象工場メソッドパターンの種類は多岐にわたるが、主に以下のように分類される。4クラス：

AbstractFactory：抽象工場役割、それが一種の製品を作成するためのメソッドのセットを宣言し、各メソッドが一種の製品に対応している。

ConcreteFactory：具体的工場役割、それが抽象工場で定義された作成メソッドを実現し、一連の具体的な製品を生成し、それが製品種類を構成し、各製品がある製品階層構造に位置づけられている。

AbstractProduct：抽象产品角色，它为每种产品声明接口。

AbstractProduct：抽象製品役割、各製品に対してインターフェースを宣言します。

ConcreteProduct：具体的な製品役割、具体的な工場が生産する具体的な製品オブジェクトを定義し、抽象製品インターフェースで宣言されたビジネスメソッドを実装します。

五、簡単な実装

タイヤ関連クラス：, A、Bの車両工場が異なるタイヤ、エンジン、ブレーキシステムを生産します。生産される部品やモデルは異なるものの、基本的にはタイヤ、エンジン、ブレーキシステムという共通の制約があります。

public interface ITire {
  /**
   * タイヤ 
   */
  void tire();
}
public class NormalTire implements ITire{
  @Override
  public void tire() {
    System.out.println("普通タイヤ");
  }
}
public class SUVTire implements ITire{
  @Override
  public void tire() {
    System.out.println("SUVタイヤ");
  }
}

エンジン関連クラス：

public interface IEngine {
  /**
   *エンジン 
   */
  void engine();
}
public class DomesticEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("国産エンジン");
  }
}
public class ImportEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("輸入エンジン");
  }
}

ブレーキシステム関連クラス：

public interface IBrake {
  /**
   *ブレーキシステム 
   */
  void brake();
}
public class NormalBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("普通ブレーキ");
  }
}
public class SeniorBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("高級ブレーキ");
  }
}

抽象車工場クラス：

public abstract class CarFactory {
  /**
   * タイヤ生産
   * 
   * @return タイヤ
   * */
  public abstract ITire createTire();
  /**
   * エンジン生産
   * 
   * @return エンジン
   * */
  public abstract IEngine createEngine();
  /**
   * ブレーキシステムを生産
   * 
   * @return ブレーキシステム
   * */
  public abstract IBrake createBrake();
}

A車両工場：

public class AFactory extends CarFactory{
  @Override
  public ITire createTire() {
    return new NormalTire();
  }
  @Override
  public IEngine createEngine() {
    return new DomesticEngine();
  }
  @Override
  public IBrake createBrake() {
    return new NormalBrake();
  }
}

B車両工場：

public class BFactory extends CarFactory{
  @Override
  public ITire createTire() {
    return new SUVTire();
  }
  @Override
  public IEngine createEngine() {
    return new ImportEngine();
  }
  @Override
  public IBrake createBrake() {
    return new SeniorBrake();
  }
}

クライアントクラス：

public class Client {
  public static void main(String[] args) {
    //A車両工場
    CarFactory factoryA = new AFactory();
    factoryA.createTire().tire();
    factoryA.createEngine().engine();
    factoryA.createBrake().brake();
    System.out.println("---------------");
    //B車両工場
    CarFactory factoryB = new BFactory();
    factoryB.createTire().tire();
    factoryB.createEngine().engine();
    factoryB.createBrake().brake();
  }
}

結果：

通常タイヤ
国内エンジン
通常ブレーキ
------------------
オフロードタイヤ
インポートエンジン
高級ブレーキ

上記のシミュレーションでは2つの車両工場が模擬されており、C工場、D工場があれば、それぞれのメーカーが生産する部品のモデルや種類が異なる場合、作成するクラスファイルは倍増します。これは抽象工場パターンの欠点の一つであり、実際の開発では使用を検討する必要があります。

6. ファクトリーメソッドパターンの違い

前節で工場メソッドパターンについて紹介しました。それらの違いは何でしょうか？抽象工場パターンは工場メソッドパターンの向上版です。以下に比較します：

工場メソッドパターン 抽象工場パターン
一つの抽象製品クラスしかありません 複数の抽象製品クラスがあります
具体的な工場クラスは、一つの具体的な製品クラスのインスタンスのみを作成できます 抽象工場クラスは複数の具体的な製品クラスのインスタンスを作成できます

七、ソースコードでの実装

抽象工場パターンはAndroidのソースコードで使用されることが少ないです。なぜなら、製品種類が複数ある場合が少ないからです。ほとんどのケースでは、工場メソッドパターンで十分です。

MediaPlayer

MediaPlayer Factoryはそれぞれ生成します4MediaPlayerの基礎クラス：StagefrightPlayer、NuPlayerDriver、MidiFile、TestPlayerStubの四つの異なるクラスがあり、すべてMediaPlayerBaseを継承しています。

八、まとめ

利点：

インターフェースと実装を分離し、クライアントは抽象工場を使用して必要なオブジェクトを作成します。クライアントは具体的な実装が誰であるかを知りません。クライアントは単に製品のインターフェースに向けたプログラミングを行います。これにより、具体的な製品実装から解耦され、インターフェースと実装の分離に基づいて、抽象工場メソッドパターンが製品クラスの切り替え時により柔軟で簡単になります。

欠点：

一つ目はクラスファイルの急増

二つ目は新しい製品クラスの拡張が難しいこと

Androidに関する詳細な内容に興味を持つ読者は、本サイトの特集をチェックしてください：《Android開発入門と進階チュートリアル》、《Androidデバッグ技術とよくある問題の解決方法集》、《Android基本コンポーネントの使用法総説》、《AndroidビューViewの技術的総説》、《Androidレイアウトlayoutの技術的総説》および《Androidコントロールの使用法総説》

この記事で述べたことが皆様のAndroidプログラムデザインに役立つことを願っています。

声明：本文の内容はインターネットから提供されています。著作権は原著者に帰属します。インターネットユーザーにより自発的に貢献し、アップロードされた内容であり、本サイトは所有権を持ちません。人工編集は行われていません。また、関連する法的責任も負いません。著作権侵害が疑われる内容を見つけた場合は、以下のメールアドレスにご連絡ください：notice#oldtoolbag.com（メールを送信する際には、#を@に置き換えてください。報告を行い、関連する証拠を提供してください。一旦確認が取れましたら、本サイトは即座に侵害する可能性のあるコンテンツを削除します。）

基礎教程
おすすめ