Gli intervistati in "architettura pulita" violano il principio di responsabilità unica?

Question

Gli intervistati in "architettura pulita" violano il principio di responsabilità unica?

#1 da (9 voti)
#2 da (2 voti)

3

L'SRP afferma che una classe (modulo) dovrebbe avere solo una ragione per cambiare. I "doveri" di un Interactor nell'architettura pulita di Bob Martin sono, per ogni caso: ricevere richieste / input da un controller; orchestrare le entità di dominio per soddisfare le richieste; e preparare i dati di output.

Questo implica tre motivi per cambiare? (vale a dire ogni volta che gli input cambiano o la funzionalità del dominio viene espansa o vengono aggiunti ulteriori campi di output). Se necessario, quale sarebbe una buona strategia per risolvere questo? (ad es., CQRS?)

Il mio attuale approccio è di creare un modulo Interactor caso d'uso con tre classi, una per ogni preoccupazione e una quarta classe Facade / Mediator per l'interfaccia e l'interfaccia dei client. Tuttavia, non spinge la violazione SRP fino al livello del modulo?

_{Come sottolineato da @Robert Harvey, il termine "doveri" è stato usato piuttosto sciatto. Il vero problema del design sono state le grandi modifiche all'interoperatore necessarie sia quando il dominio è cambiato, sia i campi / formati OutputData modificati (meno con l'input). Non sono questi due distinti motivi di cambiamento?}

_{Come ho capito da @Filip Milovanović e @ guillaume31, SRP non è violato, esp. con tre classi separate nel modulo interactor. Inoltre, a livello di modulo, il "Common Closure Principle" è forse più appropriato rispetto all'SRP. Il CCP ("Raccogliere in componenti ... le classi che cambiano per le stesse ragioni e allo stesso tempo.") Potrebbe suggerire di separare le classi degli interactor. (Ma poi le classi corrispondenti allo stesso caso d'uso sarebbero distribuite tra le varie posizioni.) Grazie alle risposte e ai commenti, questi compromessi mi sono diventati molto più chiari.}

design design-patterns solid

posta Tupolev._ 26.01.2018 - 14:29

fonte

2 risposte

2

Per un metodo, la ricezione di parametri di input e la restituzione di un output non sono di per sé di responsabilità.

Mappare / formattare i dati per renderli pronti per il trasferimento su un altro livello potrebbe essere considerato uno, ma può essere esternalizzato a un oggetto Mapper.

E non importa se si orchestrano le chiamate a uno, due o dieci collaboratori, è ancora una singola responsabilità, quindi nessun problema qui.

risposta data 26.01.2018 - 16:56

fonte

Leggi altre domande sui tag design design-patterns solid

Progetta due classi strettamente correlate Le classi di costanti che dovrebbero implementare un'interfaccia

score 9 · Accepted Answer

The "duties" of an Interactor in Bob Martin's clean architecture are, per use case: receive requests/inputs from a controller; orchestrate domain entities to fulfil the requests; and prepare the output data.

Does this imply three reasons to change?

Stai confondendo doveri con le responsabilità. Più specificamente, stai confondendo "dovrebbe avere una sola responsabilità" con "dovrebbe fare solo una cosa".

La responsabilità di un interactor è di "interagire".

La responsabilità di una classe di accesso ai dati è quella di accedere ai dati. Non ha quattro responsabilità perché crea, legge, aggiorna e cancella; ha quattro doveri.

Se sei un cuoco di breve durata, la tua responsabilità è di preparare i pasti. Non dividi le tue mansioni in dipendenti separati. Non hai un dipendente che spacca l'uovo, un altro dipendente che lo gira e un terzo che lo mette sul piatto. Esegui tutti e tre.