Эффективный способ определить класс с несколькими, необязательно пустыми слотами в S4 R?

На мой взгляд...

Подход 2

Это как бы противоречит цели принятия формальной системы классов, а затем создания класса, который содержит неточно определенные слоты («A» или NULL). Как минимум, я бы попытался сделать так, чтобы DataClass1 имел значение по умолчанию, подобное NULL. В качестве простого примера здесь по умолчанию используется числовой вектор нулевой длины.

setClass("DataClass1", representation=representation(x="numeric"))
DataClass1 <- function(x=numeric(), ...) {
    new("DataClass1", x=x, ...)
}

потом

setClass("MasterClass1", representation=representation(dataClass1="DataClass1"))
MasterClass1 <- function(dataClass1=DataClass1(), ...) {
    new("MasterClass1", dataClass1=dataClass1, ...)
}

Одним из преимуществ этого является то, что методам не нужно проверять, является ли экземпляр в слоте NULL или «DataClass1».

setMethod(length, "DataClass1", function(x) length(x@x))
setMethod(length, "MasterClass1", function(x) length(x@dataClass1))

> length(MasterClass1())
[1] 0
> length(MasterClass1(DataClass1(1:5)))
[1] 5

В ответ на ваш комментарий о предупреждении пользователей, когда они обращаются к «пустым» слотам, и помня, что пользователи обычно хотят, чтобы функции что-то делали, а не сообщали им, что они делают что-то неправильно, я, вероятно, вернул бы пустой объект DataClass1(), который точно отражает состояние объекта. Возможно, метод show предоставит обзор, который укрепит статус слота — DataClass1: none. Это кажется особенно уместным, если MasterClass1 представляет собой способ координации нескольких различных анализов, из которых пользователь может выполнять только некоторые.

Ограничение этого подхода (или вашего подхода 2) заключается в том, что вы не получаете диспетчеризацию метода - вы не можете писать методы, которые подходят только для экземпляра с DataClass1 экземплярами, имеющими ненулевую длину, и вынуждены выполнять своего рода ручная диспетчеризация (например, с if или switch). Это может показаться ограничением для разработчика, но оно также относится и к пользователю — пользователь не понимает, какие операции однозначно подходят для экземпляров MasterClass1, которые имеют экземпляры DataClass1 ненулевой длины.

Подход 1

Когда вы говорите, что имена классов в иерархии будут сбивать с толку вашего пользователя, кажется, что это, возможно, указывает на более фундаментальную проблему — вы слишком стараетесь сделать всестороннее представление типов данных; пользователь никогда не сможет отслеживать ClassWithMatrixDataFrameAndTree, потому что он не представляет способ просмотра данных. Возможно, это возможность уменьшить ваши амбиции, чтобы по-настоящему заняться только самыми важными частями области, которую вы исследуете. Или, возможно, возможность переосмыслить, как пользователь может думать и взаимодействовать с данными, которые они собрали, и использовать разделение интерфейса (то, что видит пользователь) от реализации (как вы решили представлять данные в классы), предоставляемые системами классов, чтобы более эффективно инкапсулировать действия пользователя.

Если оставить в стороне названия и количество классов, когда вы говорите «сложно расширить для дополнительных типов данных в будущем», это заставляет меня задуматься, не смущают ли вас какие-то нюансы классов S4? Короткое решение состоит в том, чтобы не писать свои собственные методы initialize и полагаться на конструкторы, выполняющие сложную работу, в соответствии с

setClass("A", representation(x="numeric"))
setClass("B", representation(y="numeric"), contains="A")

A <- function(x = numeric(), ...) new("A", x=x, ...)
B <- function(a = A(), y = numeric(), ...) new("B", a, y=y, ...)

а потом

> B(A(1:5), 10)
An object of class "B"
Slot "y":
[1] 10

Slot "x":
[1] 1 2 3 4 5