When you first move from S3 to S4 in R, I find most developers assume that S4 is just "S3 with a stricter checklist." They think they are just adding a bit of validation to a list and that the way they call functions will stay the same. This is a dangerous assumption because it leads you to try and treat S4 objects like objects in Python or Java, where the method "belongs" to the class.

In S4, the method does not belong to the class. If you try to call a method using the object$method() syntax or expect the object to "carry" its functions, you'll be staring at a NULL or an error for an hour. In S4, we use a "Generic" as a traffic cop that decides which specific implementation to run based on the class of the argument. It's a fundamental shift in how you structure your logic.

The Myth: S4 Objects are Just Validated Lists

In S3, you can create a class by simply assigning a class attribute to a list. It's loose and flexible, but it's a nightmare for large-scale software because anyone can add any field at any time. You might think S4 is just a way to stop people from doing that, but it's actually a formal blueprint system.

Let's look at a real-world example: a FinancialInstrument. If we used S3, we'd just have a list. In S4, we define a formal slot system. This means R actually allocates memory for these specific types, and the object cannot have fields you didn't define.

# The formal way to define a blueprint
setClass("FinancialInstrument",
         slots = list(
           ticker = "character",
           price = "numeric",
           currency = "character"
         ))

# Trying to create an object with a typo in the slot name
# This will fail immediately, unlike S3 which would just let you add a new list element
my_stock <- new("FinancialInstrument", ticker = "AAPL", price = 150, currency = "USD")

I love this because it catches bugs at the moment of instantiation rather than three hours later when a function crashes because ticker was accidentally named tickr.

The Reality: Decoupling Logic via Generic Functions

Now, here is where the real shift happens. In S4, you don't just write a function and hope R finds the right version. You must explicitly define a Generic. Think of the Generic as the "interface" and the Method as the "implementation."

If I want to calculate the "risk value" of my financial instrument, I don't write a function called risk_FinancialInstrument(). I define a generic calculateRisk() and then tell R how to handle that generic specifically for my class.

# 1. Define the Generic (The Traffic Cop)
setGeneric("calculateRisk", function(object) {
  standardGeneric("calculateRisk")
})

# 2. Define the Method (The Actual Logic)
setMethod("calculateRisk", "FinancialInstrument", function(object) {
  # Let's imagine a simple risk calculation based on price
  return(object@price * 0.05) 
})

# Now we call the Generic, and R dispatches it to the correct Method
calculateRisk(my_stock)

Note the use of the @ symbol. In S3, we used $. In S4, we use @ to access slots. I'll be honest: it feels clunky at first, but it serves as a constant visual reminder that you are dealing with a formal S4 object, not a standard list.

Why This Architecture Actually Matters

You might be wondering why we go through all this boilerplate. The power comes when you have multiple classes. Imagine you add a Commodity class and a CryptoCurrency class. You can define different calculateRisk methods for each one. When you pass an object to calculateRisk(), R looks at the class and routes it to the correct logic automatically.

This is called multiple dispatch. While S3 does a basic version of this, S4 allows you to dispatch based on the classes of multiple arguments, not just the first one. This makes it the gold standard for building complex packages (like Bioconductor) where data integrity is non-negotiable.

📋 Practical Task

Building a Validated LabSample Management System

You are tasked with creating a formal system to track laboratory samples. In a lab, a sample must have a sampleID (character), a concentration (numeric), and a storageTemp (numeric). To ensure data quality, the concentration must never be negative.

Your requirements:

• Create an S4 class named LabSample with the three slots mentioned above.
• Implement a validity check within the setClass definition (using the validity argument) that throws an error if concentration is less than 0.
• Define a generic function called summarizeSample.
• Create a method for summarizeSample that returns a formatted string: "Sample [ID] has a concentration of [Value] at [Temp]C".
• Test your system by attempting to create one invalid sample (negative concentration) and one valid sample, then run your summary function on the valid one.