I metodi del ciclo di vita sono uno schema di progettazione a parte o una classe più generale di schemi di progettazione?

0

Oggi ho visto che React (React JS) ha metodi per il ciclo di vita, come

componentWillMount()

e così quando il componente o il contenitore viene istanziato per la prima volta, questo metodo verrà chiamato se esiste. (se è definito).

Un esempio è quando il componente viene istanziato per la prima volta, se il metodo precedente componentWillMount() è definito nella classe, allora verrà chiamato, e potrebbe fare una chiamata AJAX per recuperare i dati da popolare in questo componente.

E lo stesso vale per la programmazione iOS o Cocoa:

viewDidLoad()
viewWillAppear()

e questo tipo di "se esiste (o è definito), quindi chiamalo" effettivamente era simile ai vecchi tempi di

document.getElementById("foo").onclick = function() { };

Cioè, se onclick è definito, allora chiamalo. Altrimenti, ignoralo. Ma questo è più legato alla gestione degli eventi / modello di osservatore / catena di responsabilità, più dei metodi del ciclo di vita.

(Avendo detto, in realtà, puoi anche visualizzare i metodi del ciclo di vita come gestori di eventi: ad esempio, ora verrà visualizzata la vista o il componente, io (il sistema operativo o il framework) ti sto dicendo / notificando (su questo evento ): se hai bisogno di fare qualcosa, fallo ora (gestiscilo ora)).

La domanda è: fai questi metodi del ciclo di vita componentWillMount() , viewWillApear() un modello di progettazione a sé stante o appartengono a una classe più grande o a una classe più generale di modello di progettazione?

    
posta 太極者無極而生 05.04.2017 - 19:27
fonte

2 risposte

1

Come hai detto nel Javascript nativo hai già un sacco di gestori di eventi:

  • OnShow
  • onclick
  • onFocus
  • ...

Questi sono solo gli stessi principi inclusi nel framework e ne hanno aggiunti alcuni.

Per me non è un modello specifico, è solo il modo in cui Javascript (e anche l'interfaccia utente) di solito funziona: basato su eventi.

    
risposta data 06.04.2017 - 09:25
fonte
0

Si potrebbe sostenere che questa è un'istanza di pipe-and-filter modello architettonico. Solitamente viene utilizzato per elaborare i dati attraverso più passaggi e l'output di ogni passaggio è un input per un altro.

Sebbene ciò non corrisponda alla descrizione fornita, dato che non vengono passati dati espliciti tra i passaggi (in questo caso le funzioni), esiste chiaramente una correlazione tra le funzioni: una non parte prima che il precedente sia finito. Inoltre, le modifiche manuali di ogni funzione / processo possono essere viste come filtraggio implicito dei dati e il contesto corrente (aggiornato) può essere considerato come i dati passati al processo / funzione successivo.

È un modello naturale abbastanza comune, quindi puoi trovarlo in molti posti. Considerato ciò, non ritengo importante quanto la comprensione dei diversi processi che avvengono nella catena e in quali casi vengono eseguiti / ignorati.

    
risposta data 06.04.2017 - 08:54
fonte

Leggi altre domande sui tag