2010-08-25 10 views
11

Recentemente stavo guardando un webcast su Clojure. In esso il relatore ha fatto un commento nel contesto della discussione sulla natura FP di Clojure, che è andata come (spero di non travisarlo) "Gli oggetti falsi ti prendono in giro".Programmazione funzioni e oggetti fittizi

Ho anche ascoltato un commento simile poco fa quando guardavo un webcast quando il Reactive Framework di Microsoft stava iniziando a comparire. Andava qualcosa come "Gli oggetti Mock sono per quelli che non conoscono la matematica")

Ora so che entrambi i commenti sono scherzi/iron-in-guancia ecc. Ecc. (E probabilmente mal parafrasati), ma il loro sottostante è ovviamente qualcosa di concettuale che non capisco dato che non ho davvero fatto il passaggio al paradigma del FP.

Quindi, sarei grato se qualcuno potesse spiegare se FP in realtà rende ridicolo il derisorio e se sì come.

+5

In FP, oggetto simulato YOU!/meme – delnan

risposta

8

In puro FP si dispone di funzioni referenzialmente trasparenti che calcolano lo stesso output ogni volta che vengono chiamate con lo stesso input. Tutto lo stato di cui hai bisogno deve quindi essere esplicitamente passato come parametri e come risultato della funzione, non ci sono oggetti stateful che sono in qualche modo "nascosti dietro" la funzione che chiami. Questo, tuttavia, è ciò che i tuoi oggetti simulati di solito fanno: simula alcuni stati o comportamenti esterni nascosti su cui si basa il tuo soggetto in prova.

In altre parole: OO: gli oggetti combinano stato e comportamento correlati. Puro FP: lo stato è qualcosa che si passa tra le funzioni che da sole sono apolidi e si basano solo su altre funzioni senza stato.

+0

OK. Grazie. Ma presumibilmente lo stato passato tra le funzioni potrebbe essere in oggetti finti o "oggetti reali", quindi oggetti finti sarebbero comunque adatti per testare una soluzione FP - no? –

+0

In puro FP, non ci sono oggetti nel senso OO. Ci sono strutture dati, che possono essere definite dall'utente. In alcune lingue ci sono parenti lontani di interfacce: Haskell ha classi di tipi, che sono fondamentalmente un insieme di funzioni che devono essere definite per ogni tipo di dati in quella classe di tipi. Quindi sì, potresti scrivere la tua funzione per operare sui tipi di dati di una determinata classe di tipi e testarla su un altro tipo di dati rispetto a quello che utilizzi nella produzione. In F # o Scala, dove è possibile manipolare effettivamente oggetti .NET o Java in uno stile funzionale, potrebbe essere addirittura necessario utilizzare oggetti fittizi reali. – Christoph

8

Penso che la cosa importante da considerare sia l'idea di utilizzare i test per strutturare il codice. I mazzi servono davvero a rimandare le decisioni che non vuoi prendere ora (e una tecnica largamente fraintesa). Invece di stato dell'oggetto, considera le funzioni parziali. Puoi scrivere una funzione che rimuove parte del suo comportamento in una funzione parziale che è stata trasmessa. In un test unitario, potrebbe essere un'implementazione falsa che ti consente di concentrarti solo sul codice in questione. Successivamente, componi il tuo nuovo codice con un'implementazione reale per creare il sistema.

In realtà, quando stavamo sviluppando l'idea di Mocks, ho sempre pensato a Mazzi in questo modo. La parte dell'oggetto era incidentale.

Problemi correlati