English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
L'article ci-dessous décrit un exemple de modèle de conception de programmation Android : le pattern de méthode usine. Partageons-le avec vous pour vous référer, comme suit :
un, introduction
Le pattern de méthode usine (Factory Pattern) est l'un des modèles de conception de création. Le pattern de méthode usine est un modèle structuré simplement, largement utilisé dans notre développement quotidien, peut-être que vous ne le savez pas, mais vous avez utilisé ce modèle des centaines de fois, comme les différentes méthodes de cycle de vie des Activity dans Android, par exemple, la méthode onCreate, qui peut être considérée comme une méthode usine, où nous pouvons construire nos View et les renvoyer au framework via setContentView, etc., nous en parlerons en détail plus tard, regardons d'abord la définition du pattern de méthode usine.
deux, la définition
Définir une interface pour créer des objets, permettant aux sous-classes de décider de quelle classe instancier.
trois, les scénarios d'utilisation
Dans tous les endroits où il est nécessaire de générer des objets complexes, on peut utiliser le pattern de méthode usine. Les objets complexes sont bien adaptés à l'utilisation du pattern de méthode usine, et les objets créés avec new n'ont pas besoin de pattern de méthode usine.
quatre, une simple implémentation du modèle
classe de produit abstraite :
public abstract class Product {
/**
* méthode abstraite de la classe de produit
* par les classes de produits spécifiques pour l'implémenter
* */
public abstract void method();
}
Classe de produit spécifique A :
public class ConcreteProductA extends Product {
@Override
public void method() {
System.out.println("Je suis le produit spécifique A");
}
}
Classe de produit spécifique B :
public class ConcreteProductB extends Product {
@Override
public void method() {
System.out.println("Je suis le produit spécifique B");
}
}
Classe d'usine abstraite :
public abstract class Factory {
/**
* Méthode d'usine abstraite
* C'est implémenté par la sous-classe
*
* @return L'objet produit spécifique
* */
public abstract Product createProduct();
}
Classe d'usine spécifique :
public class ConcreteFactory extends Factory {
/**
* Classe de fabrication spécifique
* */
@Override
public Product createProduct() {
return new ConcreteProductA();
}
}
Classe client :
public class Client {
public static void main(String[] args) {
Factory factory = new ConcreteFactory();
Product product = factory.createProduct();
product.method();
}
}
Résultat :
Je suis le produit spécifique A
Les rôles ici sont très simples, principalement divisés en quatre modules : le fabricant abstrait, qui est le cœur du modèle de méthode de fabrication ; le fabricant spécifique, qui implémente la logique métier spécifique ; l'objet produit abstrait, qui est la classe mère des produits créés par le modèle de méthode de fabrication ; et le produit spécifique, qui est l'objet pour une certaine implémentation spécifique de l'objet produit abstrait.
Dans le code ci-dessus, nous avons construit un objet d'usine dans la classe Client et avons produit un objet de produit via cet usine. L'objet de produit que nous obtenons est une instance de ConcreteProductA. Si vous souhaitez obtenir une instance de ConcreteProductB, il suffit de modifier la logique de ConcreteFactory :
public class ConcreteFactory extends Factory {
/**
* Classe de fabrication spécifique
* */
@Override
public Product createProduct() {
//return new ConcreteProductA();
return new ConcreteProductB();
}
}
Cette méthode est assez courante, elle produit le produit souhaité, et elle peut également utiliser la réflexion pour produire des objets de produits spécifiques de manière plus concise. Dans ce cas, il faut passer une classe Class dans la liste des paramètres de la méthode d'usine pour déterminer le type de classe de produit :
public abstract class Factory {
/**
* Méthode d'usine abstraite
* C'est implémenté par la sous-classe
*
* @param clz Le type de classe de l'objet produit
*
* @return L'objet produit spécifique
* */
public abstract <T extends Product> T createProduct(Class<T> clz);
}
Pour les classes d'usine spécifiques, il suffit de récupérer une instance de la classe via la réflexion :
public class ConcreteFactory extends Factory {
/**
* Classe de fabrication spécifique
* */
@SuppressWarnings("unchecked")
@Override
public <T extends Product> T createProduct(Class<T> clz) {
Product product = null;
try {
product = (Product) Class.forName(clz.getName()).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return (T)product;
}
}
Regardons maintenant l'implémentation dans Client :
public class Client {
public static void main(String[] args) {
Factory factory = new ConcreteFactory();
Product product = factory.createProduct(ConcreteProductB.class);
product.method();
}
}
Il suffit d'envoyer le type de la classe correspondante pour obtenir l'objet de la classe souhaitée. Cette méthode est plus concise et dynamique. Si vous n'aimez pas cette méthode, vous pouvez également essayer de définir une usine spécifique pour chaque produit, chacun ayant sa propre responsabilité.
public class ConcreteFactoryA extends Factory {
/**
* Classe de fabrication spécifique
**/
@Override
public Product createProduct() {
return new ConcreteProductA();
}
}
public class ConcreteFactoryB extends Factory {
/**
* Classe de fabrication spécifique
**/
@Override
public Product createProduct() {
return new ConcreteProductB();
}
}
public class Client {
public static void main(String[] args) {
Factory factoryA = new ConcreteFactoryA();
Product productA = factoryA.createProduct();
productA.method();
Factory factoryB = new ConcreteFactoryB();
Product productB = factoryB.createProduct();
productB.method();
}
}
De cette manière, posséder plusieurs usines est appelé le modèle de méthode multi-fabrique. De même, revenons au modèle de méthode d'usine d'origine, lorsque nous avons une seule usine, nous avons toujours fourni une classe abstraite pour l'usine. Alors, pouvons-nous la simplifier ? Si vous êtes sûr que votre classe d'usine n'a qu'une seule instance, il n'y a pas de problème à simplifier la classe abstraite. Nous devons simplement changer la méthode d'usine correspondante en méthode statique :
public class Factory {
/**
* Classe de fabrication spécifique
**/
@Override
public static Product createProduct() {
return new ConcreteProductA();
}
}
Ce genre de méthode est également appelé modèle de méthode usine simple ou modèle de méthode usine statique, qui est une version affaiblie du modèle de méthode usine.
En fait, jusqu'à maintenant, vous devriez pouvoir découvrir que le modèle de méthode usine est parfaitement conforme aux principes de conception, réduit la couplage entre les objets, et que le modèle de méthode usine dépend de l'architecture abstraite, il transfère la tâche d'instanciation aux sous-classes, ce qui en fait une bonne extensibilité.
Cinquième partie : le modèle de méthode usine dans le code source d'Android
Différents cycles de vie d'Activity
ArrayList et HashSet
Sixième partie : conclusion
Avantages :
Le modèle de méthode usine répond parfaitement aux principes de conception, réduit la couplage entre les objets. Les modules de haut niveau n'ont besoin de connaître que la classe abstraite du produit, et n'ont pas besoin de s'inquiéter des autres implémentations.
Bonne encapsulation, structure de code claire. Bonne extensibilité.
Inconvénients :
Chaque fois que nous ajoutons un nouveau produit au modèle de méthode usine, nous devons écrire une nouvelle classe de produit. En même temps, nous devons également introduire une couche abstraite, ce qui entraînera inévitablement une complexification de la structure de la classe, donc, dans certains cas simples, il faut que le concepteur évalue les avantages et les inconvénients de l'utilisation du modèle de méthode usine.
Les lecteurs intéressés par plus de contenu sur Android peuvent consulter les thèmes spéciaux de ce site : 'Entrée et avancement dans le développement Android', 'Astuces de débogage et solutions de problèmes courants en Android', 'Résumé des utilisations des composants de base Android', 'Résumé des techniques des vues View en Android', 'Résumé des techniques de mise en page layout en Android' et 'Résumé des utilisations des contrôles en Android'.
J'espère que l'article décrit ici pourra aider les développeurs Android dans la conception de programmes.
Déclaration : Le contenu de cet article est issu du réseau, propriété de l'auteur original. Le contenu est apporté par les utilisateurs d'Internet et téléchargé spontanément. Le site Web ne détient pas de droits de propriété, n'a pas été édité par l'homme, et n'assume aucune responsabilité juridique connexe. Si vous trouvez du contenu susceptible de violer les droits d'auteur, vous êtes invités à envoyer un e-mail à : notice#oldtoolbag.com (veuillez remplacer # par @ lors de l'envoi d'un e-mail pour signaler une violation, et fournir des preuves pertinentes. Une fois confirmée, le site supprimera immédiatement le contenu suspect de violation de droits d'auteur.)