Layering Design Pattern in stile codice pulito Java

Question

Layering Design Pattern in stile codice pulito Java

#1 da (3 voti)
#2 da (2 voti)
#3 da (2 voti)

2

Come sviluppatore Java, sto sviluppando cercando di utilizzare le regole del codice pulito. Ma nella mia squadra ci troviamo di fronte a un problema concreto:

Abbiamo un livello aziendale che offre un servizio chiamato "createObject", questo servizio rende molte operazioni che possono causare problemi. E.g: parentObjectDontExist, objectAlreadyExist, dontHaveAuthorizationToCreate, operationFailed ...

e vogliamo che l'interfaccia utente utilizzi questo servizio per visualizzare diversi messaggi di informazioni a seconda dell'errore verificatosi.

Nel vecchio java dev, dovremmo creare tutto il tipo di eccezione firmata e lanciarlo in createObject.

Come dice il codice Clean, è vietato utilizzare Exception per la business logic E le eccezioni firmate sono malvagie ... Perché no ... Ma non so come risolvere questo problema e non voglio usare il codice di ritorno.

Come va? Grazie per la tua esperienza di ritorno.

java design-patterns exceptions

posta zeraDev 30.10.2013 - 14:50

fonte

3 risposte

Leggi altre domande sui tag java design-patterns exceptions

Cosa succede con il backlog del progetto se la data di scadenza dello sprint non viene rispettata? Checklist di debug: quanto è necessario avere? [chiuso]

score 3 · Answer 1

La risposta è usare le callback

Crea un'interfaccia che definisca gli output del sistema e invece di lanciare un'eccezione, chiama il metodo giusto da questa interfaccia. Potresti vederlo come "convertire" una delle tue eccezioni firmate in un metodo nell'interfaccia.

Questo vale anche per i valori di "ritorno" non di errore. Come già sai, vuoi evitare eccezioni e restituire valori, nella maggior parte * del tuo codice. Quello che vuoi veramente fare è avere un callback o più tipi di callback da usare per passare le informazioni al gestore corretto.

Questo ti dà l'opportunità di creare il gestore appropriato che implementerà la tua interfaccia di "errore" e gestirà le specifiche di esso.

(Stessa cosa per i percorsi "non-errori"!)

Questo modellerà il tuo codice in modo che tutto sia piccolo, definito ed estendibile. (Leggi principio di responsabilità singola e principio Apri chiudi dai principi SOLID, codice pulito, zio Bob Martin.) Utilizzando le interfacce, anche tu rispettare la L e la D dei principi SOLID .. Meglio di così, se hai creato le interfacce in modo che ognuna di esse rappresenti il metodo di un "dominio", un "cliente", che, ti I.

promemoria:

S. Single Responsibility Principle
O. Open/Closed Principle
L. Liskov Substitution Principle
I. Interface Segregation Principle.
D. Dependency Inversion Principle.

a volte può capitare di restituire un valore e utilizzare un'eccezione. Il trucco è catturare l'eccezione "conosciuta" e utilizzare i metodi di callback dell'interfaccia di output.

score 2 · Answer 2

Le eccezioni controllate non sono malvagie: a volte possono essere utili per es. durante la scrittura di una libreria critica. Ma in realtà le eccezioni di runtime sono preferite nella maggior parte degli scenari.
Definisci le eccezioni in termini di esigenze del chiamante. Il chiamante deve conoscere tutte le eccezioni specifiche che menzioni qui: parentObjectDontExist, objectAlreadyExist, dontHaveAuthorizationToCreate, operationFailed? In caso contrario, sarà sufficiente disporre di un tipo di eccezione comune (ad esempio CreatingObjectException) che verrà lanciato dal servizio con informazioni pertinenti per l'interfaccia utente.

score 2 · Answer 3

Il codice pulito non dice che le eccezioni controllate sono malvagie o proibite. Dice solo che nella maggior parte degli scenari sono un fardello e non è necessario prenderlo.

Tutti i tuoi esempi sono casi eccezionali che non dovrebbero accadere, perché hai definito le precondizioni e ritieni che siano soddisfatte. Zio Bob voleva dire esattamente questo caso quando ha detto che dovresti favorire le eccezioni non controllate rispetto a quelle controllate.

Nessuno dice che non è permesso catturare eccezioni (non controllate). Quindi, puoi avvolgere la tua chiamata in un blocco try-catch e mostrare il messaggio di errore, o, più elegante, gestirlo a un livello più alto (la maggior parte dei framework UI ha un gestore di eccezioni incorporato che mostra un messaggio generico).