Implementazione del modello di strategia

7

Devo generare un codice che invierà tramite SMS o e-mail per implementare il requisito OTP (One Time Password) del nostro cliente.

Ho appena finito di creare il design usando il modello di strategia,. .

Questaèlaprimavoltacheutilizzounmodellodistrategianeiprogettidivitareale,quindivorreichiedereselostofacendobene.

Diseguitoèriportatouncodicediesempiocheverràutilizzatodalclient.

//OTPGeneratorStrategygeneratorStrategy=newEmailGeneratorStrategy("[email protected]"); for sending to Email for example
OTPGeneratorStrategy generatorStrategy = new SmsGeneratorStrategy(993454454545);
OTPGeneratorContextgeneratorContext = new OTPGeneratorContext(generatorStrategy);
context.generate("1-12345-0");

OTPValidatorStrategy validatorStrategy = new SmsValidatorStrategy();
OTPValidatorContext validatorContext = new OTPValidatorContext (validatorStrategy );
try {
validatorContext.validate("1-12345-0","e7241f");
} catch (InvalidVerificationKeyException ivk) {
System.out.println("Verification key is invalid!");
} catch(VerificationKeyExpiredException vke) {
System.out.println("Verification key is already expired, Please regenerate");
}

Aggiornamento:

Grazie per il feedback, in realtà non ero in grado di aggiornare il mio ultimo design UML e ho già separato la generazione e la convalida.

E il motivo per cui ho usato Exception piuttosto che enumerazioni perché il progetto è stato creato in java 1.4.

    
posta fuzzy28 08.01.2016 - 05:38
fonte

2 risposte

1

La prima cosa che mi sembra un problema è l'utilizzo di eccezioni per il risultato della convalida. Non utilizzare eccezioni per la logica dell'applicazione. Basta restituire un valore enum. Suppongo che non ci siano molti modi in cui la validazione può finire.

La prossima cosa che metterei in dubbio è l'utilizzo di due strategie. Cosa succederebbe se si usasse il generatore di SMS con il validatore dell'email? Per me, sembra che ci debba essere una sola strategia con entrambi i metodi generate e validate . Per quanto riguarda "la fusione dei due violi SRP", direi che averli separati viola SRP. SRP riguarda la coesione. E la coesione funziona in entrambe le direzioni. Separa il codice non coeso e unisce il codice coesivo che è stato diviso. Chiediti "Se avessi cambiato il modo in cui ha funzionato la politica delle password monouso, avrei modificato solo il generatore o il validatore o avrei dovuto modificarli entrambi?". Sono abbastanza sicuro che avresti bisogno di cambiare entrambi, il che significa che la generazione e la convalida sono parti coesive. Se sei preoccupato di inviare email nell'implementazione della strategia, questa dovrebbe essere la preoccupazione della strategia. OTPContext non ha bisogno di essere disturbato da questo. Non ha bisogno di sapere che la generazione usa una logica speciale, che non è rilevante per la validazione.

L'ultimo nitpick è che preferirei se la strategia fosse impostata su OTPContext in un costruttore invece di getter / setter. Cosa succederebbe se avessi cambiato la strategia del validatore dopo la generazione del codice? Dovresti mantenere le cose in sola lettura a meno che non ci sia un esplicito obbligo di cambiare le cose.

    
risposta data 08.01.2016 - 08:35
fonte
0

Come ex, ma ora appassionato di programmazione orientata agli oggetti, in qualche modo riformato, devo dire: attenzione ai modelli di progettazione. Questo sembra il classico "regno dei nomi" OOP overdesign (dai un'occhiata al classico post sul blog di Steve Yegge sull'argomento: link ).

Consiglio vivamente di provare una semplice implementazione procedurale di questo, oltre a ciò che stai prendendo in considerazione, ad es. un semplice metodo statico che accetta il flag booleano o enum per SMS / e-mail, oltre agli altri input, e segue un semplice flusso lineare di logica, utilizzando semplici istruzioni if per passi diversi tra SMS / email ecc.

Potresti scoprire che il modello strategico porta al codice più semplice, compatto e facile da gestire alla fine, ma conviene sicuramente provare alcuni approcci progettuali. Più codice ho scritto e letto nel corso degli anni, più ho visto come le "migliori pratiche" dell'OOP possono inutilmente complicare eccessivamente le cose.

    
risposta data 09.01.2016 - 08:32
fonte

Leggi altre domande sui tag