Diciamo che ho uno classA, che ha i propri metodi con i propri campi privati e che cosa avete (basicamente aderiscono agli standard di incapsulamento). Quindi ho classB, che ha bisogno per la sua esecuzione dello stato finale (che è ottenuto attraverso uno dei metodi di classA, che rompe un po 'l'incapsulamento) dello classA. E poi abbiamo classC, che ha ancora bisogno dello stato finale di classB. E così via e così via, per dire a classM. E 'considerato un accoppiamento troppo alto o no?Accoppiamento troppo alto o ok per progettare in questo modo?
Modifica: Ok, diciamo che stavo progettando il sistema di bottino, che dipende se la caduta avviene in base al nemico sconfitto (ogni nemico ha diverse possibilità di caduta). Se il nemico viene sconfitto, la classe che maneggia la battaglia rotola un dado, se cade qualcosa o no, e poi ho bisogno di propagare quello stato nell'altra classe che gestisce la distribuzione del bottino. In caso di interruzione, il loot di gestione classi esegue la generazione e la distribuzione di bottino al giocatore, in caso contrario, void.
L'esecuzione finale sarebbe qualcosa di simile:
classA a = new classA;
... //classA does its stuff
classB b = new classB(a.getFinalState());
... // again class does its stuff based on outcome of A
classC c = new classC(b.getFinalState());
E così via.
Non capisco il problema qui? Perché non passare semplicemente l'oggetto a al costruttore dell'oggetto b? Può interrogarlo con mezzi normali per determinare lo stato senza interrompere l'incapsulamento. Se sei preoccupato di esporre troppo, magari provare a utilizzare i getter privati del pacchetto o isolare le interfacce nei propri moduli? Stai facendo delle buone domande, ma stai pensando troppo. ;-) – jgitter