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

Dettagli dell'approccio del modello di design della responsabilità su Android

Questo articolo illustra l'pattern di progettazione a catena di responsabilità dell'Android. Lo condivido con tutti per riferimento, come segue:

Uno, presentazione

Il modello a catena di responsabilità (Iterator Pattern) è uno dei modelli di design comportamentali. Cos'è una "catena"? Il modello che si ottiene connettendo più nodi in ordine è chiamato catena, ad esempio, la catena che si vede nella vita quotidiana è costituita da un insieme di anelli rettangolari arrotondati. Per la struttura a catena, ogni nodo può essere smontato e ricollegato, quindi la struttura a catena ha anche una buona flessibilità. Applicare tale struttura al campo della programmazione, considerare ogni nodo come un oggetto, ogni oggetto ha una logica di gestione diversa, trasmettere una richiesta dal capo della catena e trasmettere lungo il percorso della catena a ogni oggetto del nodo, fino a quando un oggetto gestisce la richiesta, questo tipo di modello viene chiamato modello a catena di responsabilità, questa spiegazione è più semplice e intuitiva? Vediamo ancora la definizione standard del modello a catena di responsabilità.

Due, definizione

Fornisce a molti oggetti l'opportunità di gestire la richiesta, evitando così il legame diretto tra il mittente della richiesta e il ricevente. Collega questi oggetti in una catena e trasmette la richiesta lungo questa catena fino a quando un oggetto la gestisce.

Tre, scenari d'uso

Molti oggetti possono gestire la stessa richiesta, ma quale oggetto gestisce la richiesta è deciso dinamicamente durante l'esecuzione.

In caso di gestore della richiesta non chiaro, presentare una richiesta a uno degli oggetti.

Occorre specificare dinamicamente un gruppo di oggetti che gestiscono le richieste.

Quattro, diagramma delle classi UML del modello a catena di responsabilità

Diagramma delle classi UML:

Presentazione dei ruoli:

Handler: ruolo del gestore astratto, dichiara un metodo di gestione della richiesta e mantiene un riferimento all'oggetto gestore del nodo successivo.

ConcreteHandler: ruolo del gestore specifico, che gestisce la richiesta, se non può gestirla, trasmette la richiesta al prossimo oggetto di gestione sul nodo successivo.

Cinque, implementazione semplice

Questo esempio mi sembra molto appropriato. Nella nostra azienda ci sono molte ragioni per cui dobbiamo richiedere il rimborso delle spese, prima di tutto dobbiamo cercare il nostro superiore per l'approvazione, se l'importo del rimborso è all'interno dei poteri del superiore, allora l'approvazione viene accettata, altrimenti il superiore cerca il proprio superiore per l'approvazione, e così via.

Classe astratta di leadership:

public abstract class Leader {
  /**
   /* Gestore del leader superiore
   */
  protected Leader nextHandler;
  /**
   /* Gestione della richiesta di rimborso
   */ 
   /* @param money limite di rimborso approvabile 
   */ 
   */
  public final void handleRequest(int money){
    System.out.println(getLeader());
    if(money <=limit()){
      handle(money);
    }
      System.out.println("Il limite di rimborso è insufficiente, invia al leader");
      if(null != nextHandler){
        nextHandler.handleRequest(money);
      }
    }
  }
  /**
   /* Autorizzazioni di limite personali
   */ 
   /* @return limite
   */
  public abstract int limit();
  /**
   /* Gestione del comportamento di rimborso
   */ 
   /* @param money importo specifico
   */
  public abstract void handle(int money);
  /**
   /* Ottieni il gestore
   */ 
   /* @return gestore
   */
  public abstract String getLeader();
}

In questa classe astratta di leadership sono state fatte due cose: una è definire due metodi astratti per determinare i comportamenti e le proprietà che un leader dovrebbe avere, l'altra è dichiarare un metodo per gestire le richieste di rimborso per determinare se il leader attuale ha la capacità di gestire le richieste di rimborso. Se non ha questa autorizzazione, la richiesta viene inoltrata al leader superiore per essere gestita. Segue l'implementazione delle classi di leadership individuali:

Leader del gruppo (limite 1000):

public class GroupLeader extends Leader{
  @Override
  public int limit() {
    return 1000;
  }
  @Override
  public void handle(int money) {
    System.out.println("Approvazione della richiesta di rimborso"+ money +"€");
  }
  @Override
  public String getLeader() {
    return "Attualmente è il leader del gruppo";
  }
}

Capo (limite 5000):

public class Director extends Leader{
  @Override
  public int limit() {
    return 5000;
  }
  @Override
  public void handle(int money) {
    System.out.println("Approvazione della richiesta di rimborso"+ money +"€");
  }
  @Override
  public String getLeader() {
    return "Attualmente è il capo";
  }
}

Manager (limite 10000):

public class Manager extends Leader{
  @Override
  public int limit() {
    return 10000;
  }
  @Override
  public void handle(int money) {
    System.out.println("Il manager approva il rimborso"+ money +"yuan");
  }
  @Override
  public String getLeader() {
    return "Al momento è il manager";
  }
}

Il boss (quota...):

public class Boss extends Leader{
  @Override
  public int limit() {
    return Integer.MAX_VALUE;
  }
  @Override
  public void handle(int money) {
    System.out.println("Il boss approva il rimborso"+ money +"yuan");
  }
  @Override
  public String getLeader() {
    return "Al momento è il boss";
  }
}

Presentazione della richiesta:

public class Client {
  public static void main(String[] args) {
    //Costruire gli oggetti dei leader
    GroupLeader groupLeader = new GroupLeader();
    Director director = new Director();
    Manager manager = new Manager();
    Boss boss = new Boss();
    //Impostare l'oggetto del trattante superiore
    groupLeader.nextHandler = director;
    director.nextHandler = manager;
    manager.nextHandler = boss;
    //Iniziare la richiesta di rimborso
    groupLeader.handleRequest(8000);
  }
}

Risultato:

Al momento è il capogruppo
Il limite di presentazione è insufficiente, inviare al leader
Al momento è il direttore
Il limite di presentazione è insufficiente, inviare al leader
Al momento è il manager
Il manager approva la rimborso di 8000 yuan

Il modello di catena di responsabilità è molto flessibile, la richiesta può essere inizializzata da qualsiasi nodo della catena di responsabilità, può anche cambiare le regole di trasmissione interne. Ad esempio, se il direttore non è presente, possiamo perfettamente saltare il direttore e passare direttamente dal capogruppo al manager.

Per un oggetto di trattamento nella catena di responsabilità, ci sono due comportamenti. Uno è gestire la richiesta, l'altro è passare la richiesta al nodo successivo, non è permesso che un oggetto di trattamento passi la richiesta al nodo superiore dopo averla trattata.

Per una catena di responsabilità, una richiesta può finire in due modi. Uno è essere gestita da un oggetto di trattamento, l'altro è che nessun oggetto lo gestisce, per il primo caso chiamiamo il modello di catena di responsabilità pura, per il secondo caso non puro. Nel mondo reale, la maggior parte è la catena di responsabilità non pura.

Sesto: Modello di catena di responsabilità nel codice sorgente di Android

1. Distribuzione e gestione degli eventi View

La chiamata ricorsiva della consegna degli eventi di ViewGroup è simile a una catena di responsabilità, una volta che trova il responsabile, il responsabile lo terrà e lo consumerà, che si manifesta nel metodo return di onTouchEvent del View, se restituisce false, significa che il View non sarà il responsabile di questa volta e non lo terrà; se restituisce true, il View terrà l'evento e non lo trasmetterà più.

Settimo: Conclusione

Vantaggio:

Può decouplare la relazione tra richiedenti e gestori, migliorando la flessibilità del codice.

Svantaggio:

Ogni volta è necessario esplorare i gestori di richieste nella catena, se ci sono troppi gestori, l'esplorazione influenzerà sicuramente le prestazioni, specialmente in alcuni chiamanti ricorsivi, quindi è necessario usarli con cautela.

Per chi è interessato a ulteriori contenuti relativi a Android, i lettori possono consultare le sezioni speciali di questo sito: 'Tutorial di avvio e avanzamento di sviluppo Android', 'Techniche di debug e soluzioni di 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 spetta ai rispettivi proprietari, il contenuto è stato contribuito e caricato autonomamente 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 (sostituisci # con @) per segnalare il problema e fornire prove pertinenti. Una volta verificata, questo sito eliminerà immediatamente il contenuto sospetto di violazione del copyright.

Ti piace