oop - libro - R y programación orientada a objetos

programacion orientada a objetos php desde cero

Question

La programación orientada a objetos de una manera u otra es muy posible en R. Sin embargo, a diferencia de, por ejemplo, Python, hay muchas formas de lograr la orientación del objeto:

• El paquete de R.oo
• Clases S3 y S4
• Clases de referencia
• el paquete proto

Mi pregunta es:

¿Qué diferencias principales distinguen estas formas de programación OO en R?

Idealmente, las respuestas aquí servirán como referencia para los programadores R que intentan decidir qué métodos de programación OO se adaptan mejor a sus necesidades.

Como tal, pido detalles, presentados de manera objetiva, basados ​​en la experiencia y respaldados con hechos y referencias. Puntos de bonificación para aclarar cómo se relacionan estos métodos con las prácticas estándar de OO.

Answer 1

S3 y S4 parecen ser los enfoques oficiales (es decir, integrados) para la programación OO. Empecé a usar una combinación de S3 con funciones integradas en la función / método del constructor. Mi objetivo era tener una sintaxis de tipo object method () para que tuviera campos semiprivados. Digo semi-privado porque no hay forma de esconderlos (hasta donde yo sé). Aquí hay un ejemplo simple que en realidad no hace nada:

#'' Constructor
EmailClass <- function(name, email) {
    nc = list(
        name = name,
        email = email,
        get = function(x) nc[[x]],
        set = function(x, value) nc[[x]] <<- value,
        props = list(),
        history = list(),
        getHistory = function() return(nc$history),
        getNumMessagesSent = function() return(length(nc$history))
    )
    #Add a few more methods
    nc$sendMail = function(to) {
        cat(paste("Sending mail to", to, ''from'', nc$email))
        h <- nc$history
        h[[(length(h)+1)]] <- list(to=to, timestamp=Sys.time())
        assign(''history'', h, envir=nc)
    }
    nc$addProp = function(name, value) {
        p <- nc$props
        p[[name]] <- value
        assign(''props'', p, envir=nc)
    }
    nc <- list2env(nc)
    class(nc) <- "EmailClass"
    return(nc)
}

#'' Define S3 generic method for the print function.
print.EmailClass <- function(x) {
    if(class(x) != "EmailClass") stop();
    cat(paste(x$get("name"), "''s email address is ", x$get("email"), sep=''''))
}

Y algunos códigos de prueba:

    test <- EmailClass(name="Jason", "[email protected]")
    test$addProp(''hello'', ''world'')
    test$props
    test
    class(test)
    str(test)
    test$get("name")
    test$get("email")
    test$set("name", "Heather")
    test$get("name")
    test
    test$sendMail("[email protected]")
    test$getHistory()
    test$sendMail("[email protected]")
    test$getNumMessagesSent()

    test2 <- EmailClass("Nobody", "[email protected]")
    test2
    test2$props
    test2$getHistory()
    test2$sendMail(''[email protected]'')

Aquí hay un enlace a una publicación de blog que escribí sobre este enfoque: http://bryer.org/2012/object-oriented-programming-in-r Me gustaría recibir comentarios, críticas y sugerencias sobre este enfoque, ya que no estoy convencido. yo mismo si este es el mejor enfoque. Sin embargo, el problema que estaba tratando de resolver ha funcionado muy bien. Específicamente, para el paquete makeR ( http://jbryer.github.com/makeR ) no quería que los usuarios cambiaran campos de datos directamente porque necesitaba asegurarme de que un archivo XML que representaba el estado de mi objeto permaneciera sincronizado. Esto funcionó a la perfección, siempre y cuando los usuarios cumplan con las reglas que esbozo en la documentación.

Answer 2

Clases S3

• No son realmente objetos, más bien una convención de nombres
• Basado en el. sintaxis: Ej. para imprimir, print llamadas print.lm print.anova , etc. Y si no se encuentra, print.default

Clases S4

• Puede despachar en múltiples argumentos
• Más complicado de implementar que S3

Clases de referencia

• Principalmente útil para evitar hacer copias de objetos grandes (pasar por referencia)
• Descripción de las razones para usar RefClasses

proto

• ggplot2 se escribió originalmente en proto, pero finalmente se reescribirá con S3.
• Concepto ordenado (prototipos, no clases), pero parece complicado en la práctica
• La próxima versión de ggplot2 parece alejarse de ella
• Descripción del concepto y la implementación

Clases R6

• By-reference
• No depende de las clases S4
• " Creating una clase R6 es similar a la clase de referencia, excepto que no es necesario separar los campos y métodos, y no se pueden especificar los tipos de los campos".

Answer 3

Editar el 3/8/12: la respuesta a continuación responde a una parte de la pregunta publicada originalmente que se ha eliminado. Lo he copiado a continuación para dar contexto a mi respuesta:

¿Cómo se relacionan los diferentes métodos de OO con los métodos de OO más estándar utilizados en, por ejemplo, Java o Python?

Mi contribución se relaciona con su segunda pregunta, acerca de cómo los métodos OO de R se asignan a métodos OO más estándar. Como he pensado en esto en el pasado, he regresado una y otra vez a dos pasajes, uno de Friedrich Leisch y el otro de John Chambers. Ambos hacen un buen trabajo para explicar por qué la programación tipo OO en R tiene un sabor diferente al de muchos otros idiomas.

Primero, Friedrich Leisch, de "Creating R Packages: A Tutorial" ( advertencia: PDF ):

S es raro porque es interactivo y tiene un sistema de orientación a objetos. Diseñar clases claramente es la programación, sin embargo, para que S sea útil como un entorno de análisis de datos interactivo, tiene sentido que sea un lenguaje funcional. En los lenguajes "reales" de programación orientada a objetos (OOP), como la clase C ++ o Java, y las definiciones de métodos están estrechamente vinculadas entre sí, los métodos son parte de las clases (y, por lo tanto, de los objetos). Queremos adiciones incrementales e interactivas, como los métodos definidos por el usuario para las clases predefinidas. Estas adiciones se pueden realizar en cualquier momento, incluso sobre la marcha en el indicador de la línea de comando, mientras analizamos un conjunto de datos. S intenta hacer un compromiso entre la orientación del objeto y el uso interactivo, y aunque los compromisos nunca son óptimos con respecto a todos los objetivos que intentan alcanzar, a menudo funcionan sorprendentemente bien en la práctica.

El otro pasaje proviene del excelente libro de John Chambers, "Software for Data Analysis" . ( Enlace al pasaje citado ):

El modelo de programación OOP difiere del lenguaje S en todos menos en el primer punto, aunque S y algunos otros lenguajes funcionales admiten clases y métodos. Las definiciones de métodos en un sistema OOP son locales para la clase; no existe el requisito de que el mismo nombre para un método signifique lo mismo para una clase no relacionada. Por el contrario, las definiciones de métodos en R no residen en una definición de clase; conceptualmente, están asociados con la función genérica. Las definiciones de clase ingresan al determinar la selección del método, directamente o por herencia. Los programadores acostumbrados al modelo OOP a veces se sienten frustrados o confundidos porque su programación no se transfiere directamente a R, pero no puede. El uso funcional de los métodos es más complicado pero también más acorde con las funciones significativas, y no se puede reducir a la versión OOP.