Creazione di classi in R: S3, S4, R5 (RC) o R6?

Question

Sto scrivendo una domanda aperta per cercare vantaggi o svantaggi nella creazione di nuove classi in R. Da quello che posso dire, ci sono essenzialmente quattro diversi paradigmi che vengono utilizzati durante la creazione di classi in R, S3, S4, R5 (o RC) e R6.

S3 è ciò che la maggior parte delle librerie di base di R utilizza, e sembra esserci un merito di attenersi al modello semplice e leggermente strutturato di utilizzare l'invio di metodi generici. Vorrei evitare di usare questo per altri motivi che non mi sono del tutto chiari, come l'incapsulamento, le definizioni dei metodi, ecc. Ad esempio, sembra piuttosto complicato quando si struttura una classe, perché i metodi generici sono definiti al di fuori del classe, e cose di quella natura.

S4 non sembra essere migliore, ma ha una nozione di sicurezza del tipo di uomo povero coinvolto con esso, per rendere evidenti gli errori che potrebbero apparire più evidenti. Tuttavia, mi sento ancora come se le classi S4 fossero difficili da mantenere nel senso che non sono sicuro di cose come l'incapsulamento e quelle che sono coinvolte in queste classi. Un'altra cosa che sembra confondermi è che c'è poco o nessun concetto di namespace.

R5 sembra essere un po 'più simile a quello a cui sono abituato, dove le definizioni dei metodi sono legate alle classi piuttosto che alle funzioni di dispacciamento. Qui, c'è un po 'più di pensiero che entra in gioco con l'organizzazione di un oggetto in termini di una classe a cui sarei abituato. Un possibile svantaggio è che anche R5 è costruito fuori da S4.

R6 sembra essere una riscrittura di R5 da parte di un individuo che aggiunge più funzioni OOP al mix, come funzioni e proprietà private e pubbliche, ma difficilmente trovo alcun supporto per queste classi altrimenti, poiché le informazioni su di esse sembrano essere scarso attraverso la ricerca di Google.

Come si può dire, sto lottando con i concetti OO in R e io non riesco a capire i seguenti sfaccettature che sono normalmente associati con OOP:

1. tipologia di sicurezza/Tipi
2. Vincolo metodo/oggetto, incapsulamento, variabili membro, ecc.
3. Namespace e organizzazione codice
4. Versioni di ereditarietà.

Mi chiedo se qualcuno può fornire una risposta che può descrivere quale sia il sistema di classe preferito nella comunità R e come pensare meglio quando utilizzare le classi.

Answer 1

Sembra che tu sia già a conoscenza di alcune delle definizioni e degli usi per i vari tipi di OOP. Darò la mia opinione su quando è opportuno usare quale.

1. classi Usa S3 per situazioni in cui entrambe le seguenti condizioni: (a) l'oggetto è statico e non auto-modifica, e (b) non si preoccupano di metodo multi-argomento firme, vale a dire, la vostra il metodo invia puramente sul primo argomento, la classe S3 dell'oggetto. Inoltre, le classi S3 sono una buona soluzione quando puoi vivere con queste restrizioni e vuoi sovraccaricare molti operatori.

2. Utilizzare le classi S4 se il proprio oggetto è statico e non si modifica automaticamente, ma si preoccupano delle firme dei metodi con più argomenti. Dalla mia esperienza, S4 OOP è sempre stato più problematico di quanto valga, anche se "garantisce" la sicurezza del tipo in una certa misura.

3. Utilizzare classi di riferimento se l'oggetto è auto-modificante. Altrimenti, dovrai definire molti metodi di sostituzione (ad esempio, some_method<-, che viene chiamato con la sintassi some_method(obj) <- value). Questo è scomodo e computazionalmente lento, poiché R creerà una copia completa dell'oggetto ogni volta. R6 è un buon sostituto, anche se non l'ho trovato necessario per i miei scopi.

La maggior parte delle persone nuove a R pensa che sia confusa; che la ragione per cui ci sono così tante implementazioni OOP è perché non c'era consenso.

Questo non è corretto.

A causa della sua natura statistica, la maggior parte delle strutture eterogenee in R (vale a dire, le cose che dovrebbero essere obiettive) finiscono per essere il risultato di un algoritmo statistico: un oggetto lm, glmnet, gbm, ecc. Di solito è sufficiente per raggruppare queste informazioni e fornire le interfacce previste per riassumerla: print, summary, ecc

Grazie alla sua eredità come un parco giochi statistico, questo libera l'utente dal dover pensare concetti su più avanzate come eredità e allocazione/disallocazione e apre il campo di gioco a più contributori. Ciò significa che è leggermente più fastidioso creare progetti complessi (ad es. Server web, parser di testo, interfacce grafiche, ecc.) In R piuttosto che in un tipico linguaggio basato su oggetti come Ruby, ma la mancanza di un tipo OOP uniforme è equilibrato dalla facilità d'uso.

Un ultimo modo di pensarci è che i diversi approcci sono come transizioni di fase nella materia: solido, gas, liquido. Piuttosto che trattare tutte le strutture eterogenee (cioè le cose simili a OOP) in modo uniforme, alcune cadono più naturalmente sotto una struttura piuttosto che un'altra. Se sto avvolgendo un semplice elenco in una classe S3 per visualizzarlo bene con un metodo sovraccarico print, sarebbe piuttosto sciocco impostare un'intera classe di riferimento per questo scopo.