L'uso delle classi nidificate è un esempio di accoppiamento stretto? (JavaFX)

Question

L'uso delle classi nidificate è un esempio di accoppiamento stretto? (JavaFX)

#1 da (2 voti)

3

Quindi sto lavorando a questo gioco in cui ho una classe nidificata che ha per ottenere l'accesso alle funzioni membro e alle variabili della classe esterna per poter eseguire le sue funzionalità. In particolare la classe esterna contiene funzioni membro e dati relativi agli oggetti del gioco mentre la classe nidificata estende un AnimationTimer che fondamentalmente deve utilizzare la posizione degli oggetti di gioco per disegnarli sulla tela. Anche la classe esterna deve chiamare il metodo start () su AnimationTimer , quindi ci sarà sicuramente bisogno di un'istanza di AnimationTimer nella classe esterna. Da quando sono un po 'nuovo a questo, sono un po' confuso da questo post quindi

Questo è davvero il caso di un accoppiamento dati stretto?
Che cosa suggerisci in questo scenario, dovrei convertirlo in una classe non annidata e accedere alle funzioni dei membri "genitori" tramite il modificatore statico (nel qual caso perché sarebbe corretto e perché no)?

Qualsiasi suggerimento è ben accetto:)

object-oriented java coupling static

posta johndoe123 15.12.2017 - 03:40

fonte

1 risposta

Leggi altre domande sui tag object-oriented java coupling static

È ragionevole strutturare i test unitari in una classe per l'esecuzione dei test e uno per la configurazione? Dove dovrebbe un QC all'interno della squadra eseguire i test in uno scenario di ramificazione delle funzionalità?

score 2 · Accepted Answer

L'accoppiamento stretto dei dati non è un anti-pattern; è una funzione . Si utilizza un accoppiamento dati stretto quando sono necessari i vantaggi che fornisce.

Il motivo per cui ti stai interrogando su questo è che senti parlare molto di rendere le tue lezioni liberamente accoppiate in questi giorni. Esiste un accoppiamento libero per consentire la modularità. Rendi accoppiate le tue classi o moduli quando vuoi una netta separazione delle responsabilità e la possibilità di sostituire i moduli con qualcos'altro. L'accoppiamento lento consente di fare ciò senza rompere le cose.

Ma in un gioco, potresti avere diverse classi che devono essere strettamente coordinate, e non devi necessariamente preoccuparti dei benefici che l'accoppiamento libero offre. In questo contesto, l'accoppiamento lento potrebbe effettivamente essere un danno; aggiunge complessità senza vantaggi significativi e può avere un impatto negativo sulle prestazioni.

Questo è il motivo per cui i framework UI usano l'ereditarietà piuttosto che la composizione (al contrario di quanto ti è stato insegnato a favore della composizione sull'ereditarietà), perché è più adatto alle gerarchie di classi richieste dall'interfaccia utente. I riferimenti all'assemblaggio in linguaggi come C # e Java sono strettamente accoppiati.