Detailed explanation of the abstract factory pattern in Android programming design patterns

Ce texte décrit un exemple de modèle de conception d'usine abstraite dans le développement Android. Partageons-le avec vous pour vous référer, comme suit :

Un, présentation

Le modèle d'usine abstraite (Abstract Factory Pattern) est également l'un des modèles de conception de création. Nous avons déjà appris le modèle de méthode de fabrication dans la section précédente. Alors, comment fonctionne cette usine abstraite ? Réfléchissons un instant aux usines réelles de la vie réelle, elles sont toutes spécifiques, c'est-à-dire que chaque usine produit un type de produit spécifique. Alors, l'usine abstraite signifie que les produits produits ne sont pas déterminés, ce qui est très étrange, n'est-ce pas ? Le modèle d'usine abstraite a ses origines dans les solutions graphiques pour différents systèmes d'exploitation dans le passé, comme les boutons et les contrôles de zone de texte différents dans différents systèmes d'exploitation, avec des effets de visualisation différents. Pour chaque système d'exploitation, il constitue une catégorie de produits, et les boutons et les contrôles de zone de texte constituent également une catégorie de produits. Deux catégories de produits, deux changements,各自有自己的特性, comme les Button et TextView dans Android, les Button et TextView dans iOS, et les Button et TextView dans Windows Phone.

Deux, la définition

Fournir une interface pour créer un ensemble d'objets associés ou dépendants les uns des autres, sans spécifier leurs classes spécifiques.

Trois, les scénarios d'utilisation

Lorsque une famille d'objets a des contraintes communes, on peut utiliser le modèle d'usine abstraite. Ça ne semble pas abstrait ? Prenez un exemple, sous Android, iOS et Windows Phone, il y a des logiciels de SMS et des logiciels de dial-up, qui appartiennent tous deux à la catégorie de logiciels Software, mais ils sont sur des plateformes d'exploitation différentes. Même si les logiciels sont produits par la même entreprise, leur logique d'implémentation du code est différente. Dans ce cas, on peut envisager d'utiliser le modèle de méthode de fabrication abstraite pour générer des logiciels de SMS et des logiciels de dial-up pour Android, iOS et Windows Phone.

Quatre, le schéma de classe UML du modèle d'usine abstraite

Schéma de classe UML :

Bien que le nombre de types de schémas de méthodes de fabrication abstraite soit varié, ils sont principalement divisés en4Classe :

AbstractFactory : Un rôle de fabrication abstrait, qui déclare un ensemble de méthodes pour créer un type de produit, chaque méthode correspondant à un produit.

ConcreteFactory : Un rôle de fabrication spécifique, qui implémente les méthodes de création de produits définies dans l'usine abstraite, générant un ensemble de produits spécifiques, qui constituent une catégorie de produits, chaque produit se trouvant dans une certaine hiérarchie de produits.

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

AbstractProduct : Rôle de produit abstrait, il déclare des interfaces pour chaque produit.

ConcreteProduct : Rôle de produit concret, il définit l'objet de produit concret produit par l'usine abstraite, et implémente les méthodes d'affaires déclarées dans l'interface de produit abstrait.

Cinquième partie : Implémentation simple

Classes liées au pneu : Par exemple, dans la production de pièces de voiture par les usines A et B, les deux usines produisent des pneus, des moteurs et des systèmes de freinage différents. Bien que les pièces produites et les modèles soient différents, ils ont fondamentalement des contraintes communes, à savoir les pneus, les moteurs et les systèmes de freinage.

public interface ITire {
  /**
   * Pneu 
   */
  void tire();
}
public class NormalTire implements ITire{
  @Override
  public void tire() {
    System.out.println("Pneu normal");
  }
}
public class SUVTire implements ITire{
  @Override
  public void tire() {
    System.out.println("Pneu tout-terrain");
  }
}

Classes liées au moteur :

public interface IEngine {
  /**
   *Moteur 
   */
  void engine();
}
public class DomesticEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("Moteur national");
  }
}
public class ImportEngine implements IEngine{
  @Override
  public void engine() {
    System.out.println("Moteur importé");
  }
}

Classes liées au système de freinage :

public interface IBrake {
  /**
   *Système de freinage 
   */
  void brake();
}
public class NormalBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("Freinage normal");
  }
}
public class SeniorBrake implements IBrake{
  @Override
  public void brake() {
    System.out.println("Freinage avancé");
  }
}

Classe abstraite d'usine de voiture :

public abstract class CarFactory {
  /**
   * Fabrication de pneu
   * 
   * @return pneu
   * */
  public abstract ITire createTire();
  /**
   * Fabrication de moteur
   * 
   * @return moteur
   * */
  public abstract IEngine createEngine();
  /**
   * Produce braking system
   * 
   * @return Braking system
   * */
  public abstract IBrake createBrake();
}

A car factory:

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 car factory:

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();
  }
}

Client class:

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

Result:

Normal tire
Domestic engine
Normal braking
------------------
Off-road tire
Imported engine
Advanced braking

It can be seen that the above simulation has two car factories. If there are factories C and D, and the models and types of parts produced by each manufacturer are different, then the number of class files we create will double. This is also a disadvantage of the Abstract Factory pattern, so it should be weighed and used in actual development.

Sixth, the difference from the Factory Method pattern

Dans la section précédente, nous avons présenté le modèle de méthode d'usine, alors quel est leur différence ? Le modèle d'usine abstraite est une version améliorée du modèle de méthode d'usine. Voici une comparaison :

Modèle de méthode d'usine	Modèle d'usine abstraite
Il n'y a qu'un seul produit abstrait	Il y a plusieurs produits abstraits
La classe d'usine spécifique ne peut créer qu'une instance de produit spécifique	La classe d'usine abstraite peut créer des instances de plusieurs produits spécifiques

Septième partie, implémentation dans le code source

Le modèle d'usine abstraite est utilisé rarement dans le code source d'Android, car il est rare que plusieurs types de produits apparaissent, et la plupart des cas peuvent être résolus par le modèle de méthode d'usine.

MediaPlayer

La fabrique MediaPlayer génère respectivement4Différentes classes de base MediaPlayer : StagefrightPlayer, NuPlayerDriver, MidiFile et TestPlayerStub, toutes héritent de MediaPlayerBase.

Huitième partie, conclusion

AVANTAGES :

Séparer l'interface de l'implémentation, l'interface client utilise l'usine abstraite pour créer les objets nécessaires, tandis que le client ne connaît pas l'implémentation spécifique, le client ne programme que l'interface du produit, ce qui le dé耦 de l'implémentation spécifique du produit, en même temps, basé sur la séparation de l'interface et de l'implémentation, rend le modèle de méthode d'usine abstraite plus flexible et facile à basculer entre les types de produits.

DÉFICITS :

Premièrement, l'augmentation exponentielle des fichiers de classe

Deuxièmement, il est difficile d'étendre de nouveaux types de produits

Les lecteurs intéressés par plus de contenu sur Android peuvent consulter les sujets spéciaux de notre site : 'Introduction et tutoriel avancé de développement Android', 'Conseils de débogage et solutions de problèmes courants pour Android', 'Résumé des utilisations des composants de base Android', 'Résumé des techniques de vue View Android', 'Résumé des techniques de layout Android' et 'Résumé des utilisations des contrôles Android'.

J'espère que les informations fournies dans cet article seront utiles pour la conception de programmes Android.

Déclaration : le contenu de cet article est issu du réseau, propriété de ses auteurs respectifs, contribué et téléversé par les utilisateurs d'Internet de manière spontanée. Le site n'en possède pas la propriété, n'a pas fait d'édition humaine et n'assume aucune responsabilité juridique. Si vous trouvez du contenu suspect de violation de droits d'auteur, n'hésitez pas à envoyer un e-mail à : notice#w3Pour signaler une violation, veuillez envoyer un e-mail à notice#w avec le # remplacé par @ et fournir des preuves pertinentes. Une fois vérifié, le site supprimera immédiatement le contenu suspect de violation de droits d'auteur.