Si può avere troppo di “dinamica” in linguaggi dinamici?

Question

In questi ultimi mesi ho fare una transizione da Java a Groovy e posso apprezzare molti dei benefici che porta: meno codice, le chiusure, i costruttori, MOP che alla fine fa framework come Grails possibili, la facilità con beffarda quando scrittura test ecc.

Tuttavia, mi è stato “accusato” di miei colleghi che il mio codice non è sufficiente groove. Vale a dire, ho ancora dichiaro tipi per i miei parametri ei campi, tendono ad usare ereditarietà e polimorfismo invece di digitare anatra ecc Mi sembra che in queste situazioni non è dinamica solo contro statica, ma anche dinamica vs paradigma orientato agli oggetti tipo di dilemma. In questi casi ho ancora tendo a preferire OO. Sento che OO paradigma ha un grande valore nella sua premessa di base in che consente di astrarre e relazionarsi il codice costruisce a particolari concetti del mondo reale.

Così, qui sono questioni particolari ho bisogno di aiuto:

1. Devo dichiarare i tipi per i miei parametri, campi, etc?

2. Devo dichiarare blocco di codice, come chiusura quando metodo semplice farà?

3. Quando devo usare la tipizzazione anatra al posto di spedizione dinamica polimorfico. Per esempio, in Groovy posso fare animale "$ azione" () o animale def.; animal.action (), anziché animale animale = new Cane (); animal.action (). Riesco a vedere il problema con il primo nel contesto del principio aperto-chiuso, ma tutti gli altri motivi per preferire lo stile OO polimorfismo?

4. Quando devo utilizzare le interfacce in Groovy (se mai)?

Sono sicuro che ci sono alcuni altri dilemmi simili non sono riuscito a scrivere. Penso anche che queste domande sono valide non solo per groove, ma per qualsiasi altro linguaggio dinamico. Qual è la tua opinione?

Answer 1

0,1. Devo dichiarare i tipi per i miei parametri, campi, etc?

Io tendo dichiarare i tipi sulle classi che vengono utilizzati come parte di un'API pubblica, cose che altri sviluppatori saranno consumando un sacco, o dove mi piacerebbe qualche aiuto supplementare da autocomplete IntelliJ. Altrimenti 'def' le cose.

0,2. Devo dichiarare blocco di codice, come chiusura quando metodo semplice farà?

uso i metodi meno che non sia qualcosa che ho intenzione di passare intorno come una variabile. Anche se c'è il "foo. & Bar" operatore metodo dereference, la maggior parte degli sviluppatori non sanno di questo e sono confusi da quando corrono attraverso di esso. Io uso anche le chiusure quando si tratta di un piccolo pezzo di codice che è chiaro a rimanere in un metodo più grande, piuttosto che mettere in un suo metodo per fini descrittivi.

0,3. Quando è consigliabile utilizzare la tipizzazione anatra al posto di spedizione dinamica polimorfico. Per esempio, in Groovy posso fare animale "$ azione" () o animale def.; animal.action (), anziché animale animale = new Cane (); animal.action (). Riesco a vedere il problema con il primo nel contesto del principio aperto-chiuso, ma tutti gli altri motivi per preferire lo stile OO polimorfismo?

Io uso solo l'animale. "$ Azione" () forma quando ho bisogno di quel livello di riferimento indiretto in quanto il nome del metodo varia in base al percorso esecuzione di codice (più spesso durante metaprogrammazione pesante). Io uso animale animale = new Cane (); animal.action () quando voglio l'aiuto del IDE con il completamento automatico, o che il livello della documentazione è utile per il codice chiarezza (e non ferito dal verboseness supplementare che potrebbe essere evidenti o vincolante).

0,4. Quando è consigliabile utilizzare le interfacce in Groovy (se mai)?

I molto raramente li uso. Ho potuto vedere che li utilizzano per lo più come la documentazione dei campi previsti per una chiamata API pubblica, o forse come interfaccia marcatore per aiutare a distinguere un insieme di classi da un altro dal punto di vista metaprogrammazione. Sono molto meno utili groove di quanto lo siano in Java.

Answer 2

Questo non è sempre un parere popolare, ma credo che il più esplicito e chiaro il codice può essere, meglio è.

Cosa non mi piace costrutti che lasciano indovinare proprio quello che sta succedendo ...

Ho lavorato per un anno in Ruby e non mi è piaciuto affatto. Non sto dicendo che non ha luoghi in cui eccelle, sto solo dicendo che mi piace molto per mantenere le cose pulite ed esplicito e non sentire che Ruby aveva che come un obiettivo.

Una cosa che ho fatto capire con certezza - la quantità di battitura che fate non equivale a velocità generale di sviluppo. E 'vero che una base di codice complicato con un sacco di codice ripetuto rende per lo sviluppo molto lento, ma semplicemente riducendo ciò che si digita senza eliminare la duplicazione è inutile, e digitando più a lungo, più chiaro, il codice più esplicito sta per essere generalmente più veloce (oltre il durata del progetto) che lo stesso codice scritto in un linguaggio meno formale concisa.

Se non credere che la tipizzazione non ha alcuna relazione con la velocità di sviluppo, la prossima volta che si rilascia il conteggio di un progetto il numero di linee di codice e dividere per i giorni-uomo esaurito (compreso il debug e test). In altre parole, quanto il codice è stato digitato al giorno. Troverete il risultato di essere un numero molto piccolo -. In realtà digitando il codice è una parte molto piccola di qualsiasi progetto software

Answer 3

Credo che con Groovy si dovrebbe favorire il modo più semplice di fare qualcosa, e ripiegare su caratteristiche groovier solo quando la situazione lo richiede. (Come quando scrittura di macro o la creazione di multimethods in Clojure, se vi trovate a raggiungere per questi strumenti molto si dovrebbe mettere in discussione se stessi.) Il suo approccio cauto sembra che vada bene a me, forse i colleghi sono un po 'intossicato con il loro potere ritrovata . (Non sarebbe la prima volta.)

La cosa buona di avere un linguaggio flessibile come Groovy è che si può iniziare con l'approccio prudente come te favore sapendo di avere alternative più potenti per ricorrere quando ne avete bisogno. Sai, "la cosa più semplice che possa lavorare".

In particolare preferendo duck typing su interfacce e non preoccuparsi con i tipi di parametri sembra che potrebbe essere una buona cosa, può rendere molto più facile per la fornitura di mock a test.

Answer 4

Si tratta di ciò che le persone sono confortevoli, con. Mi piace usare tipo declerations e chiamate di metodo perché mi sento a mio agio in Java. Il codice che scrivo deve essere mantenuta da persone con molta esperienza fuori programmazione dinamica così lo tengo vicino al normale codice Java a meno che non ci sia una buona ragione per usare una funzione groove avanzata. Sembra che il tuo gruppo dovrebbe creare standard di codifica che cercano di spiegare quando dovrebbero generalmente essere utilizzate caratteristiche specifiche di Groovy.

Answer 5

Ci sono due tipi dominanti di linguaggi orientati agli oggetti.

Le lingue nel Simula 67 di famiglia, come C ++ e Java, favorire variabili staticamente tipizzato, compilatori e linker e il metodo VTables.

Le lingue nel Smalltalk famiglia, come Ruby, favorire le variabili dinamicamente tipizzati, l'interpretazione e message-passing invece di funzioni-pointer-tabelle.

Entrambi sono orientato agli oggetti, ma molto diversa assume il concetto di orientamento agli oggetti.

Answer 6

YES

-

No

Ti rendi conto non v'è alcuna vera risposta per questa domanda?