Context for Object Oriented Programming

• Software engineering
• Working together as part of a team
• Allows for modularity of code
  • Split up work
  • Make it easier to maintain

What are Objects?

• abstraction/API for data in your code
  • Lets users/coders programatically access data without lots of code
  • example: automatically connect to a database
• allow for code reuse and modular code design
• Can be a natural way to map data to a problem logically

Why Use Object Oriented Programming?

• You need to go beyond data.frames!
• multiple pieces of information need to go together
  • data.frame: when it was generated, who generated it
• You want your data to be part of a pipeline
• Have other people developing methods
• Large code base that needs to be developed by different people
  • Enables modular code

Any of these is an opportunity to encapsulate data together into an object!

Object Oriented Design

• Should be done in the start of a project!
• Literally its own software engineering topic
• Requires collaboration with domain knowledge experts
  • How do they think about data?
• Object-Oriented Design Patterns explained using practical examples

Use Case (S4 and S6)

Results object for your package

• data = data.frame
• statistics = data.frame

We want people to do something with this object!

What do you want people to do with your results object?

• print(), plot(), summary() (S3)
  • Most R Packages
• Write computing routines as part of a pipeline (S4)
  • BioConductor
• Internal package representation of results (R6)
  • shiny

Chambers

From Chambers:

The main ideas of object-oriented programming are also quite simple and intuitive:

1. Everything we compute with is an object, and objects should be structured to suit the goals of our computations.
2. For this, the key programming tool is a class definition saying that objects belonging to this class share structure defined by properties they all have, with the properties being themselves objects of some specified class.
3. A class can inherit from (contain) a simpler superclass, such that an object of this class is also an object of the superclass.
4. In order to compute with objects, we can define methods that are only used when objects are of certain classes.

https://rstudio-pubs-static.s3.amazonaws.com/150296_904158e070594471864e89c10c0d14f9.html

Classes versus Objects

• A Class is a description or an archetype
• An Object is an instantiation of that class

Basic OOP Concepts

• Object
  • slots/fields for storing data
• Methods
  • code specific to the object
  • may be separate from the object (S3,S4) or part of object (R6)
• Inheritance
  • Can extend previously defined classes
  • Don’t have to reinvent the wheel
  • can override parts of the definition
  • not covered: multiple inheritance
• Polymorphism
  • The ability for one code to react to different inputs
  • S3/S4 Generic Dispatch -> Class-specific methods

WTH

There are three object systems in R:

• S3
• S4
• R6

S3

Lightweight, good enough, all purpose!

Use S3 if:

• You are writing a package that returns a simple results object
• You want to have print(), summary(), and plot() methods for your class
• Someone isn’t going to do something programmatic with your output

S4

Stricter than S3; enforces data types in slots and methods

Use S4 if:

• The class is going to be used in more than one package
  • Examples: matrix (Matrix package), ExpressionSet (Bioconductor)
• You need type checking for slots in your object
• immutability is important
• You need to check the validity of an object
  • make sure that multiple data elements in your object are consistent
  • make sure that metadata is correct

R6

A lot like Java/Python Objects.

Use R6 if:

• Maintaining state is important
• You want methods to be attached to your object
• You want internal validity
• You are used to Java/Python type objects
• Public/Private methods

Functionality of R’s Object Systems

Portions of this tutorial are derived from:

• Hadley Wickham: Advanced R on R’s Object systems