Divisione di 1 oggetto di grandi dimensioni in 2 accoppiati strettamente - buono, cattivo?

Stai descrivendo una relazione di livello più di una relazione accoppiata. A meno che il tuo BusinessLogic non dipenda e faccia chiamate in AppInterface , non è accoppiato. Avere un sacco di dipendenze sul livello sottostante è del tutto naturale e inevitabile. Non ti preoccupare di quanto il tuo BusinessLogic dipende da un livello di database, vero?

Tuttavia, il fatto che alcune chiamate siano involucri sottili e alcune siano spesse mi porta a mettere in discussione i motivi per cui alcuni sono così complessi. Se è solo un'interfaccia dall'aspetto diverso a una funzione BusinessLogic , questa dovrebbe essere spostata in BusinessLogic . Se è perché alcuni argomenti sono più difficili da convalidare rispetto ad altri, dovresti trovare un modo per separare questa preoccupazione. Lo stesso vale per l'autorizzazione.

L'accoppiamento tra due oggetti non è buono. Chiunque avrebbe garantito per questo. Tuttavia, penso che due oggetti accoppiati lo rendano ancora meglio di un oggetto monolitico ogni giorno.

La suddivisione dell'oggetto consente di semplificare almeno il modo in cui il codice viene gestito anche se non sono realmente indipendenti dall'evoluzione.

Per quanto riguarda i tuoi elementi, ho ritenuto che la soluzione migliore sarebbe se fosse possibile ridurre successivamente la dipendenza di AppInterface su Business Object . Un semplice processo che ti consente di pensare in questo modo, è di pensare a un altro Business object che deve accedere allo stesso AppInterface . Cerca di mantenere un comportamento / aspettativa ragionevolmente unico e diverso del secondo BO che imporrà ad AppInterface di essere il più generale possibile.

Non dovresti mai unire AppInterface all'oggetto Business, ma cerca di renderlo il più generico possibile.

Ogni oggetto ha bisogno di accoppiamento. Quello che vuoi evitare è l'accoppiamento stretto . Il tuo oggetto BusinessLogic interrompe l'incapsulamento o dipende dai metodi che vengono chiamati in un ordine specifico? Altrimenti, esiste in uno stato di astrazione fine.

Il AppInterface dipende troppo dai dettagli di come funziona l'oggetto BusinessLogic ? Quindi devi ridisegnare AppInterface . Si noti che a seconda dei valori di ritorno concordati dalle funzioni è corretto.

Per le tue richieste, basta documentare correttamente che cosa "dovrebbe" essere restituito dalle chiamate al metodo e creare un oggetto MockBusinessLogic . Tutti gli stessi metodi, con solo una dichiarazione di ritorno.

Penso che dovresti combinare questi oggetti e cercare un modo diverso per dividerli, se i tuoi oggetti sono strettamente accoppiati non dovrebbero essere separati in questo modo e solo confondendo i futuri programmatori perché gli oggetti A e B hanno sempre da usare insieme per fare qualcosa.

Potresti rifattorizzare l'interfaccia pubblica di BusinessLogic in una classe base separata IBusinessLogic , che fornisce tutte le funzioni necessarie per AppInterface . Quando crei l'istanza AppInterface , passa a un oggetto IBusinessLogic , che nel tuo sistema in esecuzione sarà un'istanza di BusinessLogic .

A scopo di test, sei in grado di creare una classe BusinessLogicMock , che eredita anche da IBusinessLogic . Ora puoi facilmente testare unitamente AppInterface senza fornire un oggetto BusinessLogic in piena regola. Questa potrebbe essere la forma di disaccoppiamento che stai cercando.