Come rifattorizzare le classi di visualizzazione "annidate" per evitare chiamate di metodo profonde?

Mi sembra che tu non stia davvero separando il modello e la vista, mentre sei in una situazione in cui tale separazione è esattamente ciò di cui hai bisogno.

Se "una classe View ha un modello che sta riproducendo" allora non c'è davvero alcuna separazione tra loro, puoi semplicemente creare una classe per quello. Non sto dicendo che ci sia qualcosa di intrinsecamente sbagliato in questo, per esempio il framework MVC di Spring (Web) ha una classe ModelAndView che può contenere riferimenti a un modello (composito) e una vista. Sto solo pensando che nel tuo caso sarebbe meglio se esternassi la relazione tra il modello e la vista: fai in modo che le classi del tuo modello siano completamente separate dalle tue classi View, e poi hai una sorta di manager che decide a quale vista si usa mostra quale Modello in un dato momento.

Quindi rendi ognuno di questi granulare quanto necessario per poterli riutilizzare, cioè se hai qualche pezzo di modello e un certo modo per visualizzarlo che viene ripetuto come parte di più viste (ma allo stesso tempo quel pezzo del modello è anche necessario per essere visualizzato in modo diverso in altre viste), quindi creare classi Model e View per ognuna di queste situazioni e chiedere a un manager di decidere quale vista dovrebbe seguire quel modello a seconda del contesto corrente (genitore, richiesta, ecc.) .

Da un lato ci insegniamo a usare schemi di progettazione e tecniche di progettazione del senso comune, da cui emerge l'ideale di progettare modelli vicini a modelli concettuali e, d'altro canto, siamo preoccupati quando i nostri modelli risultanti diventano profondi. E non dovremmo esserlo.

Se concettualmente le tue visualizzazioni sono aggregazioni di altre viste, non vedo alcun problema con le strutture nidificate e il modello di delega risultante. Non vedo alcun problema con le viste che delegano come parte del compimento del loro ruolo, purché la loro interfaccia sia coerente con il loro scopo e parli con un livello coerente di astrazione.

Lasciatemi riaffermare questo. Se dovessi spiegare la tua opinione ai colleghi e la spiegazione descrive al meglio la vista in termini di altre visualizzazioni, allora è come dovrebbe essere il tuo codice.

In effetti, le opinioni che il delegato potrebbe semplicemente sta lavorando per realizzare la legge di Demeter (non è qualcosa per cui andare fanatici , ma sicuramente qualcosa di carino da riconoscere nei tuoi disegni).

Devo dire che applico i suddetti principi nel mio codice di interfaccia utente con buoni risultati. La gestione degli eventi può diventare prolissa, ma hai EventBus in soccorso.

Supponendo che tu abbia un linguaggio di template sufficiente che permetta di mescolare e abbinare i tuoi template, dovresti scomporre ogni pezzo rilevante del tuo modello nel suo modello che può essere usato per creare una vista composita .

Ad esempio, potresti avere un modello Book , che a sua volta contiene dati per Bookmarks , forse alcuni Highlights e forse PageNotes . Ognuno di questi dovrebbe avere il proprio modello che rende il contenuto in modo significativo, e questo dovrebbe essere ottenuto trasferendo solo i dati rilevanti nel modello.

Perché uno vorrebbe seguire questo approccio? Ti consente di separare le tue preoccupazioni. Il modello dovrebbe essere utilizzato per eseguire il marshalling dei dati e spostarli dal punto A al punto B e la visualizzazione dovrebbe semplicemente renderizzarli per il consumo.