English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Questo articolo illustra un esempio di modello di design Factory Method nel programming Android. Condividiamo questo con tutti voi per riferimento, come segue:
Uno: Introduzione
Il modello Factory Method (Factory Pattern) è uno dei modelli di design a creazione. È un modello strutturato semplicemente, che viene applicato molto frequentemente nel nostro sviluppo quotidiano, forse non te ne rendi conto, ma lo hai già utilizzato migliaia di volte, come i vari metodi di ciclo di vita degli Activity in Android, prendiamo ad esempio il metodo onCreate, che può essere considerato come un metodo Factory Method, in cui possiamo costruire i nostri View e restituirli al framework tramite setContentView e così via, i contenuti correlati li esamineremo più avanti, per ora vediamo la definizione dello schema Factory Method.
Due: Definizione
Definire un'interfaccia per creare oggetti, lasciare che le sottoclassi decidano quale classe istanziare.
Tre: Scenari d'uso
Ogni volta che è necessario generare un oggetto complesso, si può utilizzare lo schema Factory Method. Gli oggetti complessi sono adatti all'uso dello schema Factory Method, e gli oggetti creati con new non necessitano dello schema Factory Method.
Quattro: Implementazione semplice del modello
Classe di prodotto astratta:
public abstract class Product { /** /* Metodo astratto della classe di prodotto */ /* Implementato dalle classi di prodotto specifiche */ /* */ public abstract void method(); }
Prodotto specifico A:
public class ConcreteProductA extends Product { @Override public void method() { System.out.println("Sono il prodotto specifico A"); } }
Prodotto specifico B:
public class ConcreteProductB extends Product { @Override public void method() { System.out.println("Sono il prodotto specifico B"); } }
Classe fabbrica astratta:
public abstract class Factory { /** /* Metodo di fabbrica astratto */ /* Implementato specificamente dal sottoclasse */ /* */ /* @return L'oggetto prodotto specifico */ /* */ public abstract Product createProduct(); }
Classe fabbrica specifica:
public class ConcreteFactory extends Factory { /** * 具体工厂类 /* */ @Override public Product createProduct() { return new ConcreteProductA(); } }
Classe cliente:
public class Client { public static void main(String[] args) { Factory factory = new ConcreteFactory(); Product product = factory.createProduct(); product.method(); } }
Risultato:
Sono il prodotto specifico A
I ruoli qui sono molto semplici, principalmente divisi in quattro moduli, primo è la fabbrica astratta, che è il nucleo del modello di metodo di fabbrica; secondo è la fabbrica specifica, che implementa la logica aziendale specifica; terzo è il prodotto astratto, è la superclasse dei prodotti creati dal modello di metodo di fabbrica; quarto è il prodotto specifico, è l'oggetto per implementare un prodotto specifico dell'oggetto astratto.
Nella seguente codice, abbiamo costruito un'istanza di oggetto fabbrica nel Client e prodotto un oggetto prodotto, l'oggetto prodotto che otteniamo è un'istanza di ConcreteProductA, se si desidera ottenere un'istanza di ConcreteProductB, è sufficiente modificare la logica in ConcreteFactory:
public class ConcreteFactory extends Factory { /** * 具体工厂类 /* */ @Override public Product createProduct() { //return new ConcreteProductA(); return new ConcreteProductB(); } }
Questo metodo è abbastanza comune, produce il prodotto richiesto, a volte può anche utilizzare reflection per produrre oggetti di prodotti specifici in modo più conciso, in questo caso, è necessario passare una classe Class come parametro al elenco dei parametri del metodo di fabbrica per determinare quale classe di prodotto:
public abstract class Factory { /** /* Metodo di fabbrica astratto */ /* Implementato specificamente dal sottoclasse */ /* */ /* @param clz Il tipo della classe dell'oggetto prodotto */ /* */ /* @return L'oggetto prodotto specifico */ /* */ public abstract <T extends Product> T createProduct(Class<T> clz); }
Per le classi di fabbrica specifiche, è sufficiente ottenere un'istanza della classe tramite reflection:
public class ConcreteFactory extends Factory { /** * 具体工厂类 /* */ @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; } }
Infine, vediamo l'implementazione nel Client:
public class Client { public static void main(String[] args) { Factory factory = new ConcreteFactory(); Product product = factory.createProduct(ConcreteProductB.class); product.method(); } }
Per ottenere l'oggetto della classe desiderata, basta passare il tipo della classe desiderata, questo metodo è più conciso e dinamico, se non ti piace questo metodo, puoi anche provare a definire una fabbrica specifica per ogni prodotto, ciascuna con il proprio compito.
public class ConcreteFactoryA extends Factory { /** * 具体工厂类 **/ @Override public Product createProduct() { return new ConcreteProductA(); } } public class ConcreteFactoryB extends Factory { /** * 具体工厂类 **/ @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(); } }
In questo modo, avere più fabbriche viene chiamato modello di metodo a fabbrica multipla, allo stesso modo, tornando al nostro modello di metodo di fabbrica originale, quando abbiamo solo una fabbrica, abbiamo comunque fornito una classe astratta per la fabbrica, allora, possiamo semplificarla? Se sei sicuro che la tua classe di fabbrica abbia solo una, semplificare la classe astratta non dovrebbe essere un problema, ci basta cambiare il metodo di fabbrica corrispondente in metodo statico:
public class Factory { /** * 具体工厂类 **/ @Override public static Product createProduct() { return new ConcreteProductA(); } }
Questo tipo di metodo si chiama anche modello Factory Simple o modello Factory Static, è una versione debole del modello Factory Method.
In realtà, fino a questo punto, dovrebbe essere chiaro che il modello Factory Method è completamente conforme ai principi di progettazione, riduce la coupling tra gli oggetti e, il modello Factory Method si basa su un'architettura astratta, delegando il compito di instanziamento ai sottoclassi, con una buona estensibilità.
Sezione 5: Modello Factory Method nel codice sorgente di Android
Variabili di ciclo di vita di Activity
ArrayList e HashSet
Sezione 6: Conclusione
Vantaggi:
Il modello Factory Method è completamente conforme ai principi di progettazione, riducendo la耦合 tra gli oggetti. I moduli di alto livello devono conoscere solo la classe astratta del prodotto, altre implementazioni non devono preoccuparsi di queste.
Buona encapsulazione, struttura del codice chiara. Buona estensibilità.
Svantaggi:
Ogni volta che aggiungiamo un nuovo prodotto al modello Factory Method, dobbiamo scrivere una nuova classe di prodotto. Inoltre, dobbiamo introdurre uno strato astratto, il che inevitabilmente comporterà una complessificazione della struttura delle classi. Pertanto, in alcune situazioni semplici, è necessario valutare i pro e i contro dell'uso del modello Factory Method.
I lettori interessati a contenuti relativi a Android possono consultare le sezioni speciali di questo sito: 'Guida di avvio e avanzamento per lo sviluppo Android', 'Tecniche di debug e soluzioni ai problemi comuni di Android', 'Sommarizzazione dell'uso dei componenti di base di Android', 'Sommarizzazione delle tecniche di View di Android', 'Sommarizzazione delle tecniche di layout di Android' e 'Sommarizzazione dell'uso dei controlli di Android'.
Spero che il contenuto di questo articolo possa essere utile per la progettazione di applicazioni Android di tutti.
Dichiarazione: il contenuto di questo articolo è stato tratto da Internet, il copyright è dell'autore originale, il contenuto è stato contribuito e caricato autonomamente dagli utenti di Internet, questo sito non detiene i diritti di proprietà, non è stato elaborato manualmente e non assume responsabilità legali correlate. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a: notice#oldtoolbag.com (al momento dell'invio dell'e-mail, sostituisci # con @) per segnalare, fornendo prove pertinenti. Una volta verificata, questo sito eliminerà immediatamente il contenuto sospetto di violazione del copyright.