Ha pattern matching di Scala violano la / Closed linea di principio?

Question

Se posso aggiungere una nuova classe caso, significa che ho bisogno per la ricerca in tutto il codice pattern matching e scoprire dove deve essere gestita la nuova classe? Ho imparato la lingua di recente, e come ho letto su alcuni degli argomenti a favore e contro il pattern matching, sono stato confuso su dove dovrebbe essere usato. Vedere il seguente:

Pro: Odersky1 Odersky2

Con: Beust

I commenti sono abbastanza buone in ogni caso, anche. Così si pattern matching qualcosa di cui essere entusiasti o qualcosa che dovrei evitare di usare? A dire il vero, immagino la risposta è "dipende da quando lo si utilizza," ma quali sono alcuni casi di utilizzo positivi per esso e quali sono alcuni tra quelli negativi?

Answer 1

Jeff, penso che tu abbia l'intuizione giusta: dipende

.

gerarchie di classi orientata agli oggetti con metodo la spedizione virtuale sono buoni quando si dispone di un insieme relativamente fisso di metodi che devono essere attuate, ma molti potenziali sottoclassi che potrebbero ereditare dalla radice della gerarchia e attuare quei metodi. In una tale configurazione, è relativamente facile aggiungere nuove sottoclassi (basta implementare tutti i metodi), ma relativamente difficile aggiungere nuovi metodi (è necessario modificare tutte le sottoclassi per assicurarsi che implementano correttamente il nuovo metodo).

I tipi di dati con funzionalità sulla base di pattern matching sono buoni quando si dispone di un insieme relativamente fisso di classi che appartengono a un tipo di dati, ma molte funzioni potenziali che operano su quel tipo di dati. In una tale configurazione, è relativamente facile aggiungere nuove funzionalità per un tipo di dati (appena partita modello su tutte le sue classi), ma relativamente difficile aggiungere nuove classi che fanno parte del tipo di dati (è necessario modificare tutte le funzioni che corrispondono a sul tipo di dati per assicurarsi che essi supportano correttamente la nuova classe).

L'esempio canonico per l'approccio OO è la programmazione GUI. elementi GUI devono supportare la funzionalità molto poco (se stessi disegnare sullo schermo è il minimo indispensabile), ma i nuovi elementi della GUI sono aggiunti tutti i tempi (pulsanti, tabelle, grafici, cursori, ecc). L'esempio canonico per l'approccio pattern matching è un compilatore. I linguaggi di programmazione di solito hanno una sintassi relativamente fisso, quindi gli elementi del albero di sintassi cambieranno raramente (se non mai), ma vengono continuamente aggiunti nuovi interventi su alberi di sintassi (ottimizzazioni più veloci, tipo più approfondita analisi, ecc).

Per fortuna, Scala consente di combinare entrambi gli approcci. classi case possono essere entrambi abbinati modello e sostenere il metodo di spedizione virtuale. classi regolari supportano metodo spedizione virtuale e possono essere abbinati modello definendo un estrattore nell'oggetto guidata corrispondente. E 'fino al programmatore di decidere quando ogni approccio è appropriato, ma credo che entrambi sono utili.

Answer 2

Mentre io rispetto Cedric, è completamente sbagliato su questo tema. pattern matching di Scala può essere completamente incapsulato da cambiamenti di classe quando lo si desidera. Se è vero che un cambiamento ad un caso classe sarebbe necessario spostare istanze qualsiasi modello corrispondente corrispondenza, questo è solo quando si usano tali classi in modo naive.

modello di Scala corrispondenza sempre delegati al decostruttore di oggetto associato di una classe. Con una classe caso, questo decostruttore viene generato automaticamente (insieme con un metodo factory nell'oggetto compagna), anche se è ancora possibile ignorare questa versione auto-generata. In ogni momento, è possibile affermare il controllo completo del processo di pattern matching, isolanti eventuali modelli da potenziali cambiamenti nella classe stessa. Così, pattern matching è semplicemente un altro modo di accesso ai dati di classe attraverso il filtro sicuro di incapsulamento, come qualsiasi altro metodo.

Quindi, l'opinione del Dr. Odersky sarebbe quello di fiducia qui, in particolare data l'enorme volume di ricerche si è esibito in materia di programmazione e di progettazione orientata agli oggetti.

Per quanto riguarda dove dovrebbe essere utilizzato, che è del tutto a seconda dei gusti. Se si rende il codice più conciso e mantenibile, usarlo! In caso contrario, non lo fanno. Per la maggior parte dei programmi orientati agli oggetti, pattern matching non è necessaria. Tuttavia, una volta che si inizia a integrare i modi di dire più funzionali (Option, List, ecc) Penso che troverete che il pattern matching ridurrà significativamente il sovraccarico sintattica, nonché a migliorare la sicurezza offerta dal sistema tipo. In generale, ogni volta che si desidera estrarre i dati allo stesso tempo testare alcune condizioni (ad esempio, l'estrazione di un valore da Some), pattern matching sarà probabilmente d'uso.

Answer 3

Il pattern matching è decisamente buono se si sta facendo programmazione funzionale. In caso di OO, ci sono alcuni casi in cui è buona. Nell'esempio di Cedric stesso, dipende da come si visualizza il metodo di print() concettualmente. Si tratta di un comportamento di ogni oggetto Term? O è qualcosa di fuori di esso? Io direi che è al di fuori, e ha senso fare pattern matching. D'altra parte se si dispone di una classe Employee con varie sottoclassi, è una scelta cattiva progettazione per fare pattern matching su un attributo di esso (dire il nome) nella classe di base.

Anche il pattern matching offre un modo elegante di estrazione, i membri di una classe.