Redux sta usando un modello di oggetto Dio sanificato?

Mentre venivo a conoscenza di Redux, mi è venuto in mente il modello a oggetti di Dio (o anti-pattern), entrambi hanno un unico grande oggetto che contiene tutti i dati e i metodi dell'app per manipolarli. Ma Redux ha messo alcuni vincoli come rendere l'oggetto immutabile e gli eventi puri funzioni mantenendo una firma rigorosa.

Quindi è arrivata la domanda: Redux sta usando una versione disinfettata dell'oggetto God? Oppure, c'è qualcosa a che fare con Javascript non essere classico OOP fortemente tipizzato?

redux

— Gulshan
fonte

Risposta breve: no. Risposta lunga (in realtà una domanda che dovrebbe portare alla risposta): un database è una classe? O che ne dici di un file system? O che ne dici di una cache? Anche questi sono tutti schemi di Dio?

— code4life,

IMO sì, lo è. È nella prima affermazione su Redux: "Poiché i requisiti per le applicazioni JavaScript a pagina singola sono diventati sempre più complicati, il nostro codice deve gestire più stato che mai." - questo implica che devi gestire lo stato della tua app come un blob. Penso che sia un problema specifico per le app Web e creato dai framework poveri / mai progettati per questo che vengono utilizzati per implementare le app Web.

— n13

@ n13: Solo perché è accessibile da una posizione centralizzata non significa che sia quindi un enorme blocco. Ad esempio, al mio database si accede in modo centralizzato ( DbContext) ma i suoi dati interni sono suddivisi in parti più piccole (tabelle, schemi).

— Flater,

@Flater un grande blob con molte suddivisioni è ancora un grande blob. Un semplice vecchio modello OO suddivide in compartimenti tutti i dati in base alla necessità, il che significa che ogni oggetto gestisce solo una quantità molto piccola di stato / dati e tutto è abbastanza semplice. Potresti anche archiviare tutto in una gigantesca struttura globale ma non lo fai perché è una cattiva progettazione del software. Software 101.

— n13

@ n13 È possibile separare la logica in sottoclassi (nascoste o meno), rispettare sia la lettera che l' intenzione di buone pratiche, pur centralizzando l'accessibilità alla propria logica. È lo stesso argomento dell'utilizzo dei microservizi rispetto a una singola API. Mentre i microservizi sono un'opzione, ciò non significa che un'API REST "normale" sia quindi una cattiva pratica.

— Flater,

Risposte:

Che cos'è un oggetto Dio? Da Wikipedia:

La maggior parte delle funzionalità generali di [un oggetto God contenente] è codificata in un singolo oggetto "onnisciente", che mantiene la maggior parte delle informazioni sull'intero programma e fornisce anche la maggior parte dei metodi per manipolare questi dati. Poiché questo oggetto contiene così tanti dati e richiede così tanti metodi, il suo ruolo nel programma diventa simile a Dio (onnisciente e onnicomprensivo).

Il negozio Redux contiene solo un oggetto dati e richiede solo 2 o 3 metodi. Sotto questo aspetto è difficile immaginare di pensarlo come un oggetto divino. Decisamente non è "tutto consapevole".

Ora se il tuo riduttore non è affatto rotto, se tutta la logica è in una funzione, allora questo potrebbe qualificarsi, ma è una questione semplice suddividere il riduttore in un gruppo di pezzi più piccoli per evitare la situazione.

— Daniel T.
fonte

Penso che OP si stia chiedendo se tutti i riduttori insieme , più lo Store, contano come "Oggetto di Dio".

— user949300

Tutte le classi modello di un programma insieme contano come un oggetto dio?

— Daniel T.

Direi che nel tradizionale OOP non funzionano tutti sullo stesso "tutto", quindi no.

— user949300,

Inoltre, i riduttori non funzionano tutti con gli stessi dati "tutto". Un singolo riduttore equivale a una singola classe di modello. I dati del riduttore sono equivalenti ai campi della classe e le azioni sono equivalenti ai metodi della classe (vale a dire ogni affermazione del caso equivale a un metodo specifico).

— Daniel T.

IMO, la domanda di cui sopra non dovrebbe sorgere. I concetti di programmazione funzionale non sono paragonabili ai concetti in OOPS, sono solo modi diversi di risolvere lo stesso problema.

— Sutikshan Dubey
fonte

Hai creato questa immagine da tavolo solo per la domanda? Penso che sarebbe più adatto come testo, in modo che si carichi più velocemente e possa essere osservato con uno screen reader

— Phoenix,

OOP non incoraggia anche il flusso di dati unidirezionale? A meno che non si consideri OOP semplicemente il concetto di classi che possono contenere riferimenti reciproci, ma non un design appropriato in cui i riferimenti bidirezionali indicano in genere un difetto di progettazione.

— Steven Jeuris,

La maggior parte delle cose che menzioni sotto OOP e FP non hanno nemmeno nulla a che fare con la dichiarazione del problema nella prima colonna. la composizione delle funzioni, ad esempio, rende solo più difficile comprendere la struttura dello stato e i suoi cambiamenti

— Ski

Sembra che tu preferisca FP, ma nella mia mente la tua risposta in qualche modo conferma il mio sentimento che è un oggetto di Dio. Come OMG, il mio stato è così complesso, perché sto trattando l'intero stato dell'intero programma come una cosa importante. Sì, è complesso. In OOP, ci sono modelli di oggetti logici intorno che vengono aggiornati, il che non è affatto un grosso problema. Se succede in modo asincrono, va bene lo stesso. Le viste riflettono lo stato dell'oggetto ed è molto semplice in pratica.

— n13

La prima pagina chiarisce abbondantemente che Redux risolve un problema specifico delle app Web a pagina singola:

Poiché i requisiti per le applicazioni JavaScript a pagina singola sono diventati sempre più complicati, il nostro codice deve gestire più stato che mai. (da Redux - Motivazione)

La mia traduzione è: le app Web e i framework per la creazione di app Web sono disordinati e poiché sono in esecuzione in un browser si trovano ad affrontare una serie unica di problemi che non si verificano al di fuori delle app Web.

Non fraintendetemi: non sto dicendo che le app Web siano cattive o che i framework siano cattivi. È solo che le pagine web e l'intero paradigma su di esso innegabilmente non sono mai stati progettati pensando alle applicazioni. Alcune app Web funzionano molto bene: ad esempio, adoro Google Documenti, è meglio degli equivalenti delle app native.

Ma Redux è solo uno strumento per gestire i problemi che sorgono quando si devono affrontare le limitazioni e i problemi che derivano dalla creazione di app Web eseguite in un browser.

Per un'app iOS o un'app nativa di qualsiasi tipo, non ha senso. Il modello a oggetti gestisce facilmente le modifiche asincrone e l'interazione dell'utente. Saprai sempre cosa sta succedendo. Il rendering di stati diversi non è un problema ed è automatizzato con MVC ed eventi di aggiornamento.

Non hai mai affrontato una situazione come le app Web.

** Se la tua architettura è male, allora niente può salvarti, nemmeno Redux;)

— n13
fonte