Inject classi protette (interne) del pacchetto in fase di esecuzione

Question

Inject classi protette (interne) del pacchetto in fase di esecuzione

#1 da (0 voti)
#2 da (0 voti)

4

Mi riferisco al libro di Robert C. Martins "Architettura pulita" nella parte superiore della pagina 318.

Lì afferma:

In the ports and adapters approach, the OrdersService and Orders interfaces have inbound dependencies from other packages, so they need to be made public. Again, the implementation classes can be made package protected and dependency injected at runtime.

Comprendo appieno l'intenzione di rendere più protetti i componenti protetti anziché pubblici.

La mia domanda è: come possono essere implementate le implementazioni package protected ( internal in C #) se devono essere iniettate in dipendenza? In che modo la composizione root può accedere a questi tipi per registrarli con il contenitore IoC?

O c'è una differenza tra package protected in Java e internal in C #?

O forse sto interpretando male la sua affermazione?

dependency-injection clean-architecture uncle-bob

posta Creepin 19.12.2018 - 13:59

fonte

2 risposte

Leggi altre domande sui tag dependency-injection clean-architecture uncle-bob

Chi ha detto per primo, "Se pensi che il punto di virgola mobile sia la risposta, non capisci il problema." [chiuso] buoni libri per approfondire PHP [chiuso]

score 0 · Answer 1

internal significa che è possibile accedervi solo all'interno dello stesso assembly. package protected in Java significa che è possibile accedervi da altre classi nello stesso pacchetto . Il significato è un po 'diverso.

È plausibile che si possano avere librerie esterne che usano quel pacchetto che potrebbe fare uso di quel servizio, a patto che usino lo stesso nome di pacchetto, quindi non ci sarebbero problemi con le implementazioni che provengono dall'esterno dell'assembly. In C #, suppongo che dovresti dichiararlo come pubblico, poiché non penso esista un equivalente che possa funzionare per le librerie esterne.

score 0 · Answer 2

How should the composition root access these types to register them with the IoC container?

Un modo possibile per affrontare questo è usare una fabbrica. Prendi OrdersService per esempio. Nell'assembly che implementa questa funzione, potresti avere un'interfaccia pubblica IOrdersService e una public OrdersServiceFactory che restituisce un'istanza di IOrdersService . La root della composizione chiama quindi quella factory per risolvere un'istanza di IOrdersService , e viene fornita un'istanza della classe interna, OrdersService .

Se in un secondo momento identificherai la necessità di più di un'implementazione di IOrdersService , allora cambierai solo il funzionamento interno della fabbrica. La radice della composizione non deve cambiare. In questo modo eviti di accoppiare la radice della composizione al funzionamento interno di altri assiemi.

Ma le cose potrebbero anche essere ulteriormente disaccoppiate. Quella implementazione di IOrdersService può essere fatta per essere l'unica posizione che crea un'istanza di IOrders quando ad esempio myOrdersService.CreateOrder(…) viene chiamata. In questo caso, non è necessario esporre una sorta di fabbrica alla radice della composizione. Non ha alcuna responsabilità per la creazione di ordini, quindi non ha bisogno di sapere nulla di tali implementazioni.