NullObject: Null Object Pattern

In R6P: Design Patterns in R

Null Object Pattern

Description

Model a domain concept using natural lingo of the domain experts, such as "Passenger", "Address", and "Money".

Usage

NullObject()

Details

<div class="alert alert-danger"> **Caution:** NullObject is designed for demonstration purposes. Instead of directly using the design pattern as it appears in the package, you'd have to adjust the source code to the problem you are trying to solve. </div> <!– One line about what the function does –>

Null Object provides special behaviour for particular cases.<div class="alert alert-warning"> **Note:** The Null Object is not the same as the reserved word in R 'NULL' (all caps). </div>

How It Works

When a function fails in R, some functions produce a run-time error while others return NULL (and potentially prompt a warning). What the function evokes in case of a failure is subjected to its programmer discretion. Usually, the programmer follows either a punitive or forgiving policy regarding how run-time errors should be handled.

In other occasions, NULL is often the result of unavailable data. This could happened when querying a data source matches no entries, or when the system is waiting for user input (mainly in Shiny).

If it is possible for a function to return NULL rather than an error, then it is important to surround it with null test code, e.g. if(is.null(...)) do_the_right_thing(). This way the software would do the right thing if a null is present.

Often the right thing is the same in many contexts, so you end up writing similar code in lots of places—committing the sin of code duplication.

Instead of returning NULL, or some odd value such as NaN or logical(0), return a Null Object that has the same interface as what the caller expects. In R, this often means returning a data.frame structure, i.e. column names and variables types, with no rows.

When to Use It

• In situations when a subroutine is likely to fail, such as loss of Internet or database connectivity. Instead of prompting a run-time error, you could return the Null Object as part of a gracefully failing strategy. A common strategy employs tryCatch that returns the Null Object in the case of an error:

# Simulate a database that is 5% likely to fail 
read_mtcars <- function() if(runif(1) < 0.05) stop() else return(mtcars)

# mtcars null object constructor
NullCar <- function() mtcars[0,]

# How does the null car object look like? 
NullCar()
#>  [1] mpg  cyl  disp hp   drat wt   qsec vs   am   gear carb
#> <0 rows> (or 0-length row.names)

# Subroutine with gracefully failing strategy
set.seed(1814)
cars <- tryCatch(
  # Try reading the mtcars dataset
  read_mtcars(), 
  # If there is an error, return the Null Car object
  error = function(e) return(NullCar()) 
)

# Notice: Whether the subroutine fails or succeeds, it returns a tibble with 
# the same structure.
colnames(cars)
#>  [1] "mpg"  "cyl"  "disp" "hp"   "drat" "wt"   "qsec" "vs"   "am"   "gear"
#> [11] "carb"

• In Shiny dashboards

geom_null <- function(...){
  ggplot2::ggplot() + ggplot2::geom_blank() + ggplot2::theme_void()
}

if(exists("user_input")){
  ggplot2::ggplot(user_input, ggplot::aes(x = mpg, y = hp)) + ggplot2::geom_point()
} else {
  geom_null() + geom_text(aes(0,0), label = "choose an entry from the list")
}

• In unit-tests

classes <- function(x) sapply(x, class)
    
test_that("mtcars follows a certain table structure", {
    # Compare column names
    expect_identical(colnames(mtcars), colnames(NullCar()))
    # Compare variable types
    expect_identical(classes(mtcars), classes(NullCar()))
})

See Also

Other base design patterns: Singleton, ValueObject()

Examples

# See more examples at <https://tidylab.github.io/R6P/articles>

colnames(NullObject())
nrow(NullObject())

R6P documentation built on Oct. 3, 2022, 1:05 a.m.