Cosa intendeva Rich Hickey quando disse: "Tutta quella specificità [di interfacce / classi / tipi] uccide il tuo riutilizzo!"

Nel keynote della stimolante conferenza di Rich Hickey " Il valore dei valori " a 29 minuti sta parlando dell'overhead di un linguaggio come Java e fa una dichiarazione del tipo: "Tutte quelle interfacce uccidono il tuo riutilizzo". Che cosa intende? È vero?

Nella mia ricerca di risposte, mi sono imbattuto in:

• Il principio della minima conoscenza AKA La legge di Demetra che incoraggia le interfacce API ermetiche. Wikipedia elenca anche alcuni svantaggi.

• Obiettivo appropriato è la crisi dell'abbigliamento imperiale di Kevlin Henney che sostiene che l'uso, non il riutilizzo.

• Il discorso di " Stop Writing Classes " di Jack Diederich che si oppone al sovraingegneria in generale.

Chiaramente, qualsiasi cosa scritta abbastanza male sarà inutile. Ma come potrebbe l'interfaccia di un'API ben scritta impedire l'utilizzo di quel codice? Ci sono esempi nel corso della storia di qualcosa fatto per uno scopo e usato più per qualcos'altro . Ma nel mondo del software, se usi qualcosa per uno scopo a cui non era destinato, di solito si rompe.

Sto cercando un buon esempio di una buona interfaccia che impedisce un uso legittimo ma non intenzionale di un codice. Esiste? Non riesco a immaginarlo.

Non ho visto la presentazione completa di Rich Hickey, ma se lo capisco correttamente, e a giudicare da ciò che dice sul punteggio di 29 minuti, sembra che stia discutendo dei tipi che uccidono il riutilizzo. Sta usando il termine "interfaccia" liberamente come sinonimo di "tipo chiamato", il che ha senso.

Se hai due entità { "name":"John" }di tipo Persone { "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, il che significa scrivere più codice). Quindi le interfacce / tipi qui stanno "uccidendo il tuo riutilizzo": anche se Persone Dogsembrano uguali, uno non può essere usato in modo intercambiabile con l'altro, a meno che non si scriva un 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 tali strutture; sono solo valori che condividono la stessa struttura (nel mio esempio entrambi hanno un namecampo con un valore String) e quindi possono facilmente interagire, ad esempio possono essere aggiunti alla stessa raccolta, passati agli stessi metodi, ecc.

Per riassumere, tutto ciò sembra riguardare l' uguaglianza strutturale contro l' uguaglianza esplicita di tipo / 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 è possibile reuseun'interfaccia. Puoi implementare solo il codice che lo supporta e quando scrivi il codice per un'interfaccia non c'è riutilizzo.

Java ha una storia di fornitura di framework di molte API che prendono un'interfaccia come argomenti, ma il team che ha sviluppato l'API non implementa mai una vasta gamma di classi per poterle riutilizzare con quelle interfacce.

È un po 'come un framework GUI che ha IWindowun'interfaccia per una finestra di dialogo e quindi puoi aggiungere IButtoninterfacce per i controlli. Tranne che non ti hanno mai dato una buona Buttonclasse che implementa IButton. Quindi sei rimasto a creare il tuo.

I framework astratti che dispongono di una vasta gamma di classi base che forniscono funzionalità di base sono più riutilizzabili e funzionano meglio quando tali classi astratte sono accessibili a coloro che utilizzano il framework.

Gli sviluppatori Java hanno iniziato a fare questa cosa in cui sono esposti solo i loro livelli API interfaces. È possibile implementare tali interfacce, ma non è mai possibile riutilizzare le classi dallo sviluppatore che ha implementato tali interfacce. È un po 'come uno stile di mantello e pugnale di sviluppo API.

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

Valori

• Non ho bisogno di metodi
  • Posso inviarti valori senza codice
    e stai bene

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

    MyValue = Double(YourValue)

Vedi, il codice sopra è lo stesso, indipendentemente dal tipo di valore che hai inviato - una sorta di riutilizzo perfetto .

Ora, come apparirebbe nel linguaggio con oggetti e interfacce?

    Doublable MyValue = YourValue.Double()

oh aspetta! cosa succede YourValuese non implementare Doublable? non che non possa essere raddoppiato, potrebbe essere perfettamente ma ... e se non ci fosse un metodo Double ? (cosa succede se esiste un metodo chiamato dire TwiceAsMuch?)

Oh oh abbiamo un problema. YourValue.Doublenon funzionerà, non può più essere riutilizzato . Secondo la mia lettura della diapositiva sopra, si tratta di ciò che Hickey intendeva quando disse: "Tutte quelle interfacce uccidono il tuo riutilizzo!"

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

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

Nota a margine: l'idea di passare in giro valori senza codice mi ricorda in qualche modo un modello Flyweight in OOP.

^{un oggetto che minimizza l'uso della memoria condividendo quanti più dati possibile con altri oggetti simili; è un modo per usare oggetti in grandi numeri quando una rappresentazione ripetuta semplice utilizza una quantità inaccettabile di memoria ... Gli oggetti flyweight sono per definizione oggetti valore . L'identità dell'istanza dell'oggetto non ha alcuna conseguenza, pertanto due istanze Flyweight dello stesso valore sono considerate uguali ...}

Gli usi a peso mosca che ho visto in genere hanno seguito lo stesso approccio di togliere il codice (metodi, interfacce) dagli oggetti e far circolare oggetti come pure valori senza codice , aspettandosi che ricevere codice abbia i mezzi necessari per operare su questi.

Sembra quasi come nella diapositiva, "i valori non hanno bisogno di metodi. Posso inviarti valori senza codice e tu stai bene".

In un (cioè il mio) mondo ideale le classi e le interfacce descrivono sempre il comportamento, ma il fatto è che troppo spesso finiscono per descrivere i dati. Solo ieri ho visto il video di qualcuno costruire una cosiddetta BankAccountclasse che non era altro che un glorificato int(in effetti era molto meno utile di un int, quindi "uccidere" il riutilizzo che avrei avuto se fosse stato semplicemente lasciato come un int), tutto in nome del design "buono". La quantità di codice, sudore e lacrime sprecati per reinventare continuamente rappresentazioni contorte di dati è sconcertante; se non stai utilizzando i dati in modo significativo, ti preghiamo di lasciarli.

Ora, questo è il palcoscenico in cui Rich Hickey si accontenta di buttare il bambino con l'acqua del bagno e dire che dovremmo andare tutti a vivere nella terra dei valori (un vicino al regno dei nomi). Penso, d'altra parte, che OOP possa e riusci a promuovere il riutilizzo (e soprattutto la rilevabilità, che trovo carente nella programmazione funzionale) se impiegato con giudizio. Se stai cercando un principio OOP che catturi meglio questa tensione, penso che potrebbe essere http://c2.com/cgi/wiki?TellDontAsk (che ovviamente è un cugino stretto di Demetra)