English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Questo esempio spiega il modello di progettazione del pattern di fabbrica astratto in programmazione Android. Condivido con tutti per riferimento, come segue:
Capitolo 1: Introduzione
Il modello di fabbrica astratta (Abstract Factory Pattern) è anche uno dei modelli di design di creazione. Nella sezione precedente abbiamo già imparato il modello di metodo della fabbrica, allora come è questa fabbrica astratta? Ricordiamo che le fabbriche nella vita reale sono tutte concrete, ovvero ogni fabbrica produce un tipo di prodotto specifico, quindi la fabbrica astratta significa che i prodotti prodotti sono incerti, questo non è molto strano? Il modello di fabbrica astratta ha origine nelle soluzioni grafiche per diversi sistemi operativi in passato, come i pulsanti e i controlli di testo nelle diverse piattaforme di sistema operativo, la loro implementazione e la loro presentazione sono diverse. Per ogni sistema operativo, costituisce una classe di prodotto, e i pulsanti e i controlli di testo costituiscono una classe di prodotto, due classi di prodotti due variazioni, ognuna con le proprie caratteristiche, come Button e TextView in Android, Button e TextView in iOS, Button e TextView in Window Phone.
Capitolo 2: Definizione
Fornisce un'interfaccia per creare un insieme di oggetti correlati o dipendenti senza specificare le loro classi specifiche.
Capitolo 3: Scenari di utilizzo
Quando una famiglia di oggetti ha vincoli comuni, può essere utilizzato il modello di fabbrica astratta. Non sembra molto astratto? Facciamo un esempio, sotto Android, iOS, Window Phone ci sono applicazioni di messaggi e applicazioni di chiamate, entrambe appartengono alla categoria di Software, ma i loro piattaforme di sistema operativo sono diverse, persino se lo stesso produttore lancia software, la logica di implementazione del codice è diversa. In questo caso, si può considerare l'uso del modello di metodo della fabbrica astratta per produrre applicazioni di messaggi e applicazioni di chiamate per Android, iOS, Window Phone.
Capitolo 4: Diagramma delle classi UML del modello di fabbrica astratta
Diagramma delle classi UML:
Nonostante ci siano molte varianti del modello di metodo della fabbrica astratta, in sostanza si dividono in 4 categorie:
AbstractFactory: ruolo di fabbrica astratta, dichiara un insieme di metodi per creare un tipo di prodotto, ogni metodo corrisponde a un tipo di prodotto.
ConcreteFactory: ruolo di fabbrica specifica, implementa i metodi di creazione dei prodotti definiti nell'fabbrica astratta, generando un insieme di prodotti specifici, che compongono una categoria di prodotti, ogni prodotto si trova in una certa struttura gerarchica dei prodotti.
AbstractProduct: ruolo di prodotto astratto, dichiara un'interfaccia per ogni tipo di prodotto.
ConcreteProduct: ruolo di prodotto specifico, definisce l'oggetto di prodotto specifico prodotto da una fabbrica specifica, implementando i metodi di business dichiarati nell'interfaccia del prodotto astratto.
Capitolo 5: Realizzazione semplice
Ad esempio, prendiamo l'produzione di componenti automobilistici da parte di un'azienda di costruzione di automobili, A e B due fabbriche di automobili producono diversi pneumatici, motori, sistemi di frenata. Anche se i componenti prodotti e i modelli sono diversi, fondamentalmente ci sono vincoli comuni, ovvero pneumatici, motori, sistemi di frenata.
Classi correlate al pneumatico:
public interface ITire { /** * Pneumatico */ void tire(); } public class NormalTire implements ITire{ @Override public void tire() { System.out.println("Pneumatico normale"); } } public class SUVTire implements ITire{ @Override public void tire() { System.out.println("Pneumatico da fuoristrada"); } }
Classi correlate al motore:
public interface IEngine { /** * Motore */ void engine(); } public class DomesticEngine implements IEngine{ @Override public void engine() { System.out.println("Motore nazionale"); } } public class ImportEngine implements IEngine{ @Override public void engine() { System.out.println("Motore importato"); } }
Classi correlate al sistema di frenatura:
public interface IBrake { /** * Sistema di frenatura */ void brake(); } public class NormalBrake implements IBrake{ @Override public void brake() { System.out.println("Frenatura normale"); } } public class SeniorBrake implements IBrake{ @Override public void brake() { System.out.println("Frenatura avanzata"); } }
Classe astratta di fabbrica di auto:
public abstract class CarFactory { /** * Produzione del pneumatico * * @return Pneumatico * */ public abstract ITire createTire(); /** * Produzione del motore * * @return Motore * */ public abstract IEngine createEngine(); /** * Produzione del sistema di frenatura * * @return Sistema di frenatura * */ public abstract IBrake createBrake(); }
Fabbrica di auto 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(); } }
Fabbrica di auto 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(); } }
Classe cliente:
public class Client { public static void main(String[] args) { //Fabbrica di auto A CarFactory factoryA = new AFactory(); factoryA.createTire().tire(); factoryA.createEngine().engine(); factoryA.createBrake().brake(); System.out.println("---------------"); //Fabbrica di auto B CarFactory factoryB = new BFactory(); factoryB.createTire().tire(); factoryB.createEngine().engine(); factoryB.createBrake().brake(); } }
Risultato:
Pneumatici normale Motore nazionale Freno normale ------------------ Pneumatici fuoristrada Motore importato Freno avanzato
Si può vedere che è stato simulato due fabbriche di auto, se ci sono fabbriche C e D, e i modelli e le tipologie di componenti prodotti da ciascun produttore sono diversi, allora i file di classe che creiamo saranno raddoppiati. Questo è anche uno svantaggio del modello di fabbrica astratto, quindi deve essere bilanciato nell'uso in sviluppo reale.
Sezione sesta: Differenze con il modello di fabbrica a metodo
La sezione precedente ha introdotto il modello di fabbrica a metodo, allora qual è la differenza tra loro? Il modello di fabbrica astratto è una versione avanzata del modello di fabbrica a metodo. Il confronto è il seguente:
Pattern di metodo di fabbrica | Pattern di fabbrica astratto |
---|---|
C'è una sola classe di prodotto astratta | Ci sono più classi di prodotto astratte |
La classe di fabbrica specifica può creare solo un'istanza di una classe di prodotto specifica | L'abstract factory può creare istanze di più classi di prodotti specifiche |
Settima, implementazione nel codice sorgente
L'abstract factory pattern viene utilizzato meno spesso nel codice sorgente di Android, poiché raramente si verificano situazioni con più tipi di prodotti, la maggior parte dei casi può essere risolta utilizzando il factory method pattern.
MediaPlayer
MediaPlayer Factory genererà 4 diverse classi base di MediaPlayer: StagefrightPlayer, NuPlayerDriver, MidiFile e TestPlayerStub, tutti derivano da MediaPlayerBase.
Ottava, sommario
Vantaggi:
Separare l'interfaccia dall'implementazione, il client utilizza l'abstract factory per creare l'oggetto necessario, e il client non conosce l'implementazione specifica, il client programma solo le interfacce del prodotto, il che lo rende decoupled dall'implementazione specifica del prodotto. Allo stesso tempo, basato sulla separazione dell'interfaccia e dell'implementazione, rende più flessibile e facile passare alla classe di prodotto.
Svantaggi:
Prima di tutto, c'è un aumento esponenziale dei file delle classi
Non è facile espandere nuovi tipi di prodotti
I lettori interessati a ulteriori contenuti relativi a Android possono consultare le sezioni speciali di questo sito: 'Tutorial di avvio e avanzamento per lo sviluppo Android', 'Trucchi di debug e soluzioni comuni ai problemi di Android', 'Sommarizzazione dell'uso dei componenti di base di Android', 'Sommarizzazione delle tecniche di View Android', 'Sommarizzazione delle tecniche di layout Android' e 'Sommarizzazione dell'uso dei controlli Android'.
Spero che questo articolo possa essere di aiuto a tutti nella progettazione di applicazioni Android.
Dichiarazione: il contenuto di questo articolo è stato raccolto da Internet, di proprietà del rispettivo autore, il contenuto è stato contribuito e caricato volontariamente dagli utenti di Internet, questo sito non detiene i diritti di proprietà, non è stato editato manualmente e non assume alcuna responsabilità legale correlata. 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 rimuoverà immediatamente il contenuto sospetto di violazione del copyright.