Quanto lontano dovrei prendere la trasparenza referenziale?

Question

Sto costruendo un sito Web usando erlang, mnesia e webmachine. La maggior parte della documentazione che ho letto elogia le virtù di avere funzioni referenzialmente trasparenti.

Il problema è che l'accesso al database è uno stato esterno. Ciò significa che qualsiasi metodo che colpisce il database non è più trasparente referenziale.

Diciamo che ho un oggetto utente in un database e alcune funzioni che si occupano di autenticazione.

funzioni referenzialmente opachi potrebbe essere simile:

handle_web_request(http_info) -> 
    is_authorized_user(http_info.userid), 
    ... 
%referentially opaque 
is_authorized_user(userid) -> 
    User = get_user_from_db(userid), 
    User.is_authorized. 

%referentially opaque 
lots_of_other_functions(that_are_similar) -> 
    db_access(), 
    foo. 

referenzialmente trasparenza impone che ridurre al minimo la quantità di codice referenzialmente opaca, in modo che il chiamante deve ottenere l'oggetto dal database e passare che come argomento ad un funzione:

Il codice sopra riportato non è ovviamente un codice di produzione - è costituito esclusivamente a scopo illustrativo.

Non voglio essere risucchiato dal dogma. I vantaggi del codice referentially trasparente (come test di unità provabili) giustificano l'interfaccia meno amichevole? Fino a che punto dovrei andare nella ricerca della trasparenza referenziale?

Answer 1

Perché non prendere la trasparenza referenziale fino in fondo?

Prendere in considerazione la definizione di get_user_from_db. Come fa a sapere come parlare al database? Ovviamente assume un contesto di database (globale). È possibile modificare questa funzione in modo che restituisca una funzione che consideri il contesto del database come argomento. Quello che hai è ...

get_user_from_db :: userid -> User 

Questa è una bugia. Non puoi passare da un ID utente a un utente. Hai bisogno di qualcos'altro: un database.

get_user_from_db :: userid -> Database -> User 

Ora basta curry che con l'ID utente, e dato un database in un secondo momento, la funzione vi darà un utente. Naturalmente, nel mondo reale, Database sarà un handle o un oggetto di connessione al database o altro. Per il test, dargli un database fittizio.

Answer 2

Hai già menzionato il test delle unità, continua a pensare in questi termini. Tutto ciò che trova valore nei test dovrebbe essere trasparente per cui è possibile testarlo.

Se non si dispone di una logica complessa che potrebbe andare storta, e un singolo test di funzionalità/integrazione vedrebbe che è corretto, allora perché preoccuparsi di andare oltre?

Think YAGNI. Ma dove la testabilità delle unità è un'esigenza reale.