Usando new [className] senza un ritorno

Question

Usando new [className] senza un ritorno

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

0

Ho iniziato a utilizzare quanto segue nel mio codice di automazione nei casi in cui non sono interessato a mantenere l'oggetto "vivo" e solo a usarlo come mezzo come un tipo di precondizione. Ad esempio:

Invece del seguente:

Login login = new Login()
login.SetUserName(username).SetPassword(password).Submit()

Faccio ciò che segue (come esempio!):

new Login().SetUserName(username).SetPassword(myPassword).Submit()

Nell'esempio sopra, come si chiama questa tecnica, ed è saggio utilizzarlo nel modo che sto facendo?

Grazie.

c# class test-automation

posta yorkshireflatcap 08.10.2018 - 11:00

fonte

2 risposte

Leggi altre domande sui tag c# class test-automation

DDD - Eventi di dominio vs eventi dell'applicazione ESB è un modello architettonico o è una soluzione?

score 1 · Answer 1

Si chiama interfaccia fluente e non è né male né buona, dipende dall'implementazione.

Personalmente non penso che il tuo esempio aggiunga nulla di leggibilità al tuo esempio o anche solo:

 var login = new Login();
     login.SetUserName(username);
     login.SetPassword(myPassword);
     login.Submit();

Il punto principale di "fluente" è la leggibilità e la sicurezza del tipo nella combinazione delle opzioni.

Una domanda sarebbe, questo:

new Login().SetUserName(username).SetPassword(myPassword).Submit()

aggiungi qualcosa sul metodo statico

Login.Submit(username, password);

Se lo fa (ad esempio perché ha sovraccarichi diversi per il costruttore di login per iniettare un altro client HTTP o qualcosa del genere) allora fantastico. In caso contrario, mi chiedo perché lo rendi così complicato.

score 0 · Answer 2

Dal punto di vista del compilatore, le tue due versioni non sono diverse. La variabile login verrà semplicemente ottimizzata nel primo esempio in quanto non è necessaria. Quindi, in realtà, diventa solo una questione di stile personale su quale utilizzare.

Una terza opzione è sostituire new Login() con un metodo statico che restituisce l'oggetto login per la tua interfaccia fluente, ad esempio:

Login.Create().SetUserName(username).SetPassword(myPassword).Submit();

ma ancora una volta, questa è una cosa di stile. Non esiste un modo corretto per farlo e non ci sono termini specifici per distinguere i due approcci.