Che cosa significa Rich Hickey quando ha detto: "Tutta quella specificità [di interfacce / classi / tipi] uccide il tuo riutilizzo!"

Non ho visto la presentazione completa di Rich Hickey, ma se lo capisco correttamente e giudicando da quello che dice riguardo al punteggio di 29 minuti, sembra che stia discutendo sui tipi che uccidono il riutilizzo. Sta usando il termine "interfaccia" liberamente come sinonimo di "named type", che ha senso.

Se hai due entità { "name":"John" } di tipo Person e { "name": "Rover" } di tipo Dog , in Java-land probabilmente non possono interagire a meno che non condividano un'interfaccia o un antenato comune (come Mammal , che significa scrivere più codice). Quindi le interfacce / tipi qui sono "uccisione del riutilizzo": anche se Person e Dog hanno lo stesso aspetto, non è possibile utilizzarne uno intercambiabile con l'altro, a meno che non si scriva codice aggiuntivo per supportarlo. Nota Hickey scherza anche sui progetti in Java che richiedono molte classi ("Chi ha scritto un'applicazione Java usando solo 20 classi?"), Che sembra una conseguenza di quanto sopra.

Nelle lingue "orientate al valore", tuttavia, non assegnerai tipi a quelle strutture; sono solo valori che condividono la stessa struttura (nel mio esempio, entrambi hanno un campo name con un valore String) e quindi possono facilmente interagire, ad es. possono essere aggiunti alla stessa collezione, passati agli stessi metodi, ecc.

Per riassumere, tutto questo sembra essere qualcosa su uguaglianza strutturale rispetto a tipo esplicito / uguaglianza dell'interfaccia . A meno che non mi sia sfuggito qualcosa dalle parti del video che non ho ancora visto:)

Probabilmente si riferisce al fatto fondamentale che un'interfaccia non può essere istanziata. Non puoi reuse un'interfaccia. Puoi solo implementare il codice che lo supporta, e quando scrivi il codice per un'interfaccia non c'è riutilizzo.

Java ha una storia di fornire framework di molte API che accettano un'interfaccia come argomenti, ma il team che ha sviluppato l'API non implementa mai una vasta gamma di classi per far sì che riutilizzi con quelli interfacce.

È un po 'come un framework GUI che ha un'interfaccia IWindow per una finestra di dialogo, e quindi è possibile aggiungere IButton interfacce per i controlli. Tranne che non ti hanno mai dato una buona classe Button che implementa IButton . Quindi hai lasciato la tua.

I framework astratti che hanno una vasta gamma di classi base che forniscono funzionalità di base sono più riutilizzabili e funzionano meglio quando quelle classi astratte sono accessibili a chi usa il framework.

Gli sviluppatori Java hanno iniziato a fare questa cosa quando i loro livelli API hanno esposto solo interfaces . È possibile implementare tali interfacce, ma non è mai possibile riutilizzare le classi dallo sviluppatore che ha implementato tali interfacce. È un po 'come lo stile di cappa e spada di sviluppo API.

Penso che la diapositiva 13 alla sua presentazione ( Il valore dei valori ) aiuta a capire questo:

Values

• Don’t need methods
  • I can send you values without code
    and you are fine

La mia comprensione è che Hickey suggerisce che, se devo, ad esempio, raddoppiare il valore che mi hai inviato, scrivo semplicemente codice simile a

    MyValue = Double(YourValue)

Vedete, il codice precedente è lo stesso, indipendentemente dal tipo di valore che avete inviato - una specie di riuso perfetto .

Ora, come sarebbe questo nel linguaggio con oggetti e interfacce?

    Doublable MyValue = YourValue.Double()

oh aspetta! cosa succede se YourValue non implementa Doublable ? non che non possa essere raddoppiato, potrebbe essere perfettamente ma ... e se non ci fosse un metodo Double ? (cosa succede se c'è un metodo chiamato say TwiceAsMuch ?)

Uh oh abbiamo un problema. YourValue.Double non funzionerà, non può più essere riutilizzato . Per la mia lettura della diapositiva di cui sopra, si tratta di cosa intendeva Hickey quando ha detto: "Tutte quelle interfacce uccidono il tuo riutilizzo!"

Come vedi, le interfacce presuppongono che gli oggetti vengano passati "insieme ai loro metodi", insieme al codice che opera su questi. Per utilizzare gli oggetti, è necessario capire come richiamare quel codice, quale metodo chiamare.

Quando manca il metodo , c'è un problema, anche se semanticamente , l'operazione desiderata ha perfettamente senso per un oggetto. Come indicato nella presentazione, i valori non richiedono i metodi ("Posso inviare valori senza codice e stai bene"), consentendo di scrivere codice che li tratti in modo generico.

Nota a margine: la nozione di passare intorno ai valori senza codice mi ricorda in qualche modo un modello di peso vivo in OOP.

^{an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory... Flyweight objects are by definition value objects. The identity of the object instance is of no consequence therefore two Flyweight instances of the same value are considered equal...}

Usi di pesi mosca Ho visto in genere seguito lo stesso approccio di rimozione del codice (metodi, interfacce) dagli oggetti e il passaggio di oggetti in giro come, beh, valori senza codice , in attesa di ricevere il codice ha i mezzi necessari per operare su questi.

Questo sembra più o meno come nella diapositiva, "i valori non hanno bisogno di metodi. Posso inviare valori senza codice e stai bene".

In un (cioè mio) classi e interfacce ideali del mondo descrivono sempre il comportamento, ma il fatto è che troppo spesso finiscono per descrivere i dati. Solo ieri ho visto il video di qualcuno che creava una cosiddetta classe BankAccount che era nient'altro che una% co_de glorificata (anzi era molto meno utile di una int , quindi 'uccidendo' il riutilizzo che avrei avuto era semplicemente stato lasciato come int ), tutto nel nome del design "buono". La quantità di codice, sudore e lacrime sprecati per reinventare continuamente rappresentazioni complicate di dati è sbalorditiva; se non stai utilizzando i dati in modo significativo, per favore lascia che sia.

Ora, questa è la fase in cui Rich Hickey si accontenta di gettare il bambino con l'acqua sporca e dire che dovremmo tutti andare a vivere nella terra dei valori (un vicino al regno dei nomi). Penso, da un lato, che l'OOP possa e promuova il riutilizzo (e soprattutto la reperibilità, che trovo carente nella programmazione funzionale) quando impiegato con giudizio. Se stai cercando un principio OOP che catturi al meglio questa tensione, penso che potrebbe essere link (che ovviamente è un cugino stretto di Demetra)