Object-oriented programming Alyssa Frazee computing club, Dec 4 2014 

Definition ● “object” = user-defined data structure ● “attribute” = piece of data associated with the object ● “method” = procedure/function associated with the object I got this from Wikipedia (and remembering stuff from when I took CS101 in 2008) 

What’s the point? It’s convenient to be able to create your own way of storing data. Famous R examples: lm SummarizedExperiment fmridata Note: some people are anti-OOP: http://c2. com/cgi/wiki?ArgumentsAgainstOop 

R has 3 or 4 OO systems ● S3 ● S4 ● Reference classes ● Base types (“not quite OO”) http://adv-r.had.co.nz/OO-essentials.html 

R has 3 or 4 OO systems ● S3 ● S4 ● Reference classes ● Base types (“not quite OO”) http://adv-r.had.co.nz/OO-essentials.html 

S3 

S4 example #' Card #' #' A playing card #' #' @slot suit Is this card a spade, club, diamond, or heart? #' @slot number The card’s value. Can be 2-10, ‘J’, ‘Q’, ‘K’, or ‘A’ #’ @slot trump Is the card a trump card? Boolean. #' #' @exportClass Card setClass("Card", representation( suit = "character", number = "numeric", trump = "logical") ) AllClass.R 

Options for defining methods: ● Just write a function ○ probably the easiest choice if the function name is unique. 

S4 example #' find_pair #' #' Find the card with the same value and color as the given card #' #' @param card Object of class “Card” #' @export find_pair = function(card){ new_suit = switch(card@suit, diamonds = ‘hearts’, hearts = ‘diamonds’, spades = ‘clubs’, clubs = ‘spades’) return(new(‘Card’, suit = new_suit, number = card@number, trump=FALSE)) } find_pair.R 

Options for defining methods: ● Just write a function ○ probably the easiest choice if the function name is unique. ● Extend or create a generic function, then create a way for that function to work with your class of object. ○ required if you need to make a base function like “plot” work with your object ○ optional if function name is unique -- consider whether the function might be useful for existing or future classes of objects 

S4 example #' @name cardplot #' @export #' @docType methods #' @rdname cardplot #' @importFrom graphics plot setGeneric("plot", function(x,y,...) standardGeneric("plot")) Card-plot-method.R 

S4 example #' make an awesome plot of a card! #' @name cardplot #' @exportMethod plot #' @docType methods #' @rdname cardplot #' @aliases cardplot,ballgown-method #' @param x a Card object setMethod("plot", "Card", function(x){ plot(0, 0, type='n', xaxt='n', yaxt='n', xlab='', ylab='', main='My Card!') if(x@number > 10){ s = ifelse(x@number==11, 'Jack', ifelse(x@number==12, 'Queen', ifelse(x@number==13, 'King', 'Ace'))) }else{ s = x@number } text(0, 0, paste(s, 'of', x@suit), cex=2) }) Card-plot-method.R (continued) 

*Key Insight* about R methods *Functions* have different types of *objects* associated with them. (**not** the other way around!) (“generic function OO” vs. “message-passing OO”) 

An example in Python class Card(object): def __init__(self, suit, number, trump=False): self.suit = suit self.number = number self.trump = trump def repr(self): ## like R’s show return str(self.number)+‘ of ’+self.suit def plot(self): ## plotting code, whatever whatever 

message-passing OO mycard.plot() 

An example in Python class Card(object): def __init__(self, suit, number, trump=False): self.suit = suit self.number = number self.trump = trump def __cmp__(self, other): ## THIS is very cool if self.number > other.number: return 1 elif other.number > self.number: return -1 else: return 0 

Python classes 

Syntax Note Many languages (includng Python) use the “.” operator to access attributes and methods of different objects. (e.g. mycard.suit) (The fact that R uses “.” like any other character makes it weird). 

Much more fun to be had! ● inheritance! ○ but things get complicated VERY quickly ● S3 and S4 classes working together; documentation, etc ● questions? discussion? ● R example on github: https://github. com/alyssafrazee/cards