Puoi suggerire una buona introduzione alla filosofia e al design dei programmi di Scala?

Question

In Java e C++ la gerarchia degli oggetti del programma di progettazione è piuttosto ovvia. Ma all'inizio di Scala mi sono trovato difficile decidere quali classi definire per utilizzare meglio le strutture sintattiche dello zucchero di Scala (un'ideale persino su come dovrei progettare per ottenere prestazioni migliori). Qualche buona lettura di questa domanda?

Answer 1

Ho letto 4 libri su Scala, ma non ho trovato quello che stai chiedendo. Immagino che tu abbia già letto "Programming in Scala" di Odersky (Artima). In caso contrario, si tratta di un collegamento alla versione on-line:

http://www.docstoc.com/docs/8692868/Programming-In-Scala

Questo libro fornisce molti esempi di come costruire modelli orientati agli oggetti in Scala, ma tutti gli esempi sono molto piccoli in numero di classi. Non conosco nessun libro che ti insegnerà come strutturare sistemi su larga scala usando Scala.

• Imperativo orientamento agli oggetti ha stato intorno dal Smalltalk, così abbiamo sa molto su questo paradigma.
• funzionale orientamento agli oggetti d'altra parte , è un nuovo concetto piuttosto, così in pochi anni mi aspetto libri descrizione di sistemi FOO larga scala per apparire. In ogni caso, penso che il libro PiS ti dà un buon quadro come si può mettere insieme i fondamentali blocchi di costruzione di un sistema, come fabbrica modello, come sostituire il modello strategia con funzione di letterali e così via.

Una cosa che Viktor Klang una volta mi (e qualcosa mi è d'accordo su) ha detto è che una differenza tra C++/Java e Scala OO è che si definisce molto di più classi (più piccoli) quando si utilizza Scala. Perché? Perché tu puoi! Lo zucchero sintattico per lo case class comporta una penalità molto piccola per la definizione di una classe, sia nella digitazione che nella leggibilità del codice. E come sai, molte piccole classi di solito significano un OO migliore (meno bug) ma prestazioni peggiori.

Un'altra cosa che ho notato è che uso lo schema factory molto di più quando si tratta di oggetti immutabili, poiché tutte le "modifiche" di un'istanza si traducono nella creazione di una nuova istanza. Grazie a Dio per il metodo copy() su case class. Questo metodo rende i metodi di fabbrica molto più brevi.

Non so se questo ti ha aiutato, ma penso che questo argomento sia molto interessante anch'io, e anch'io attendo più letteratura su questo argomento. Cheers!

Answer 2

Non penso che ci siano molti tutorial per questo.Io suggerirei di stare con il modo in cui lo si fa ora, ma di guardare attraverso il codice Scala "idiomatica" come bene e di prestare particolare attenzione nei casi seguenti:

• classi dei casi d'uso o caso oggetti invece di enumerazioni o "oggetti di valore"
• uso oggetti per single
• se avete bisogno di un comportamento "a seconda del contesto" o la funzionalità di dipendenza-iniezione-like, uso impliciti
• durante la progettazione di una gerarchia di tipo o se si può scomporre le cose di una classe concreta, utilizzare i tratti quando possibile
• Grana fine le gerarchie di ereditarietà sono OK. Tenete a mente che avete pattern matching
• Conoscere il modello "pimp my library"

E chiedere tutte le domande che si sente è necessario capire un certo punto. La comunità di Scala è molto amichevole ed utile. Suggerirei la mailing list di Scala, Scala IRC o scala-forum.org

Answer 3

Questa è ancora una questione in evoluzione. Ad esempio, la versione 2.8.0 di Scala appena rilasciata supportava l'inferenza del costruttore , che abilitava un modello di classi di in Scala. La stessa libreria Scala ha appena iniziato a utilizzare questo modello. Proprio ieri ho sentito parlare di un nuovo modulo Lift in cui tenteranno di evitare l'ereditarietà a favore delle classi di tipi.

Scala 2.8.0 introduce anche implicazioni con priorità più bassa, oltre a parametri predefiniti e denominati, entrambi possono essere utilizzati, separatamente o insieme, per produrre disegni molto diversi da quelli che erano possibili prima.

E se andiamo back in time, notiamo che le altre caratteristiche importanti non sono che il vecchio sia:

• Extractor metodi su classi case oggetto compagni dove introdotte febbraio 2008 (prima di allora, l'unico modo per farlo l'estrazione su classi di casi è avvenuta attraverso l'abbinamento di modelli).
• Pigro Valori e tipi strutturali dove introdotte luglio 2007.
• tipi astratti supporto per costruttori di tipo è stato introdotto nel maggio 2007.
• Estrattori per le classi non-caso è stato introdotto nel Gennaio 2007.
• Sembra che i parametri impliciti siano stati introdotti solo nel marzo 2006, quando hanno sostituito il modo visualizzazioni sono state implementate.

Tutto ciò significa che stiamo tutti imparando come progettare il software Scala. Assicurati di affidarti a progetti collaudati di paradigmi funzionali e orientati agli oggetti, per vedere come le nuove funzionalità di Scala vengono utilizzate in altri linguaggi, come Haskell e classi di tipi o Python e predefiniti (facoltativo) e parametri con nome.

Alcune persone non amano questo aspetto di Scala, altri lo adorano. Ma altre lingue lo condividono. C# sta aggiungendo funzionalità veloci come Scala. Java è più lento, ma subisce anche le modifiche.Ha aggiunto i generici nel 2004 e la prossima versione dovrebbe apportare alcune modifiche per supportare meglio la programmazione simultanea e parallela.

Answer 4

Ho cercato per errore solo su a file called "ScalaStyleGuide.pdf". Andando a leggere ...