Альтернатива для шаблона декоратора в Java?

предположим, что у вас есть следующая иерархия классов, связанных со статистикой, структурированная аналогично Шаблонный метод шаблон:

interface S {
   // Method definitions up-to and including the S3 class
}

class S0 implements S {
   // Code that counts samples
}

class S1 extends S0 {
   // Code that calls the superclass methods and also computes the mean
}

class S2 extends S1 {
   // Code that calls the superclass methods and also computes the variance
}

class S3 extends S2 {
   // Code that calls the superclass methods and also computes the skewness
}

предположим теперь, что мы хотим расширить каждый из этих классов, например, проверить на сходимость метрики. Для моих целей мне не нужно делать это расширение во время выполнения. Я могу придумать следующие варианты:

• создать подклассы S0C, S1C, S2C и S3C С S0, S1, S2 и S3 соответственно, каждый с копией кода, который проверяет сходимость:

  • плюсы:
    • концептуально прямо вперед
    • результирующие объекты по-прежнему принадлежат к суперклассу
    • исходный код подкласса содержит только дополнительный код проверки сходимости
  • минусы:
    • много-много дублирования кода - с результирующие изменения синхронизации накладных расходов в будущем
  • главные минусы:
    • что делать, если я хочу другой набор классов, например, предварительно обработать образцы? Мы говорим об экспоненциальной репликации одного и того же кода!

• использовать шаблон "декоратор":

  • плюсы:
    • код дублирование!
  • минусы:
    • объекты больше не принадлежат к исходному классу (легко обрабатываются)
    • A очень slight (он существует! Я измерил!) производительность в Java, из-за использования виртуальных вызовов методов, в отличие от специальных вызовов методов. Это не очень важно, но все равно заметно.
  • главные минусы:
    • около мильона методов делегата необходимо синхронизировать с интерфейсом обернутого объекта. Использование интерфейсов гарантирует, что ни один метод не пропущен, но его все еще трудно поддерживать, даже с IDE, которые автоматизируют создание методов делегата.
    • чтобы иметь правильно реализованный шаблон декоратора, все декораторы и обернутые классы должны реализовать точно такой же интерфейс. Это по существу означает, что мне придется добавить, например, методы проверки сходимости к S интерфейс, который полностью уничтожает любую чувство модульности. Единственный способ снять это требование - запретить вложенные декораторы в моем коде.

если бы Java поддерживала множественное наследование, я, вероятно, смог бы справиться с этим, наследовав как от статистики, так и от базового класса проверки сходимости (или что-то еще). Увы, Java не поддерживает множественное наследование (нет, интерфейсы не в счет!).

есть ли лучший способ справиться с эта проблема в Java? Возможно, другой шаблон дизайна? Более техническое решение? Какой-то особый ритуальный танец?

PS: Если я что-то недопонимаю, не стесняйтесь (мягко) указать на это...

EDIT:

кажется, мне нужно немного прояснить свои цели:

• мне не нужна композиция объекта времени выполнения. Я хочу расширить возможности S* занятия с новыми методами. Если бы я мог создавать подклассы как без дублирования кода, я бы, вероятно, сделать это таким образом. Если бы я мог сделать это в месте использования (маловероятно), еще лучше.

• я бы предпочел не писать один и тот же код снова и снова. Примечание: методы делегирования и конструкторы прекрасны, я полагаю, методы, реализующие алгоритмы, нет.

• я хотел бы сохранить мои интерфейсы модульными. Это моя главная проблема с шаблоном декоратора-если только не очень конкретные ограничения вложенности помещенный, вы заканчиваете с супер-интерфейсом всех интерфейсов...

EDIT 2:

чтобы обратиться к нескольким комментариям:

• на S* занятия построены с использованием методов шаблона:

  class S0 {
     int addSample(double x) {
        ...;
     }
  
    double getMean() {
        return Double.NaN;
    }
  }
  
  class S1 extends S0 {
  
  
     int addSample(double x) {
        super.addSample(x);
        ...;
     }
  
     double getMean() {
        return ...;
     }
  }
  

• мой S*C расширенные классы из первого решения будут выглядеть следующим образом:

  interface S {
      int addSample(double x);
      double getMean();
  }    
  
  class S0C extends S0 implements S {
     int addSample(double x) {
        super.addSample(x);
        ...;
     }
  
     boolean hasConverged() {
        return ...;
     }
  }
  
  class S1C extends S1 {
     int addSample(double x) {
        super.addSample(x);
        ...;
     }
  
     boolean hasConverged() {
        return ...;
     }
  }
  

  Примечание дублирования hasConverged() метод.

• A проверка конвергенции декоратора будет выглядеть так:

  class CC<T extends S> implements S {
     T o = ...;
  
     int addSample(double x) {
        o.addSample(x);
        ...;
     }
  
     double getMean() {
        return o.getMean();
     }    
  
     boolean hasConverged() {
        return ...;
     }
  }
  

  проблема: если я хочу объединить другое поведение разделителя помимо проверки сходимости, мне нужен отдельный декоратор, например NB - и для того, чтобы иметь доступ к, например,hasConverged() метод, новый декоратор должен:

  • реализовать тот же интерфейс, что и CC
  • используйте тот же интерфейс, что и CC для своего обернутого типа объекта...
  • ...что заставляет меня используйте этот интерфейс для S* методы, если я хочу иметь возможность использовать NB С S* объекты без использования CC

• при продлении S* классы, мне все еще нужны оригиналы неповрежденными. Помещение, например, функциональности конвергенции в общий супер-класс означает, что связанное поведение (и его влияние на производительность) теперь будет существовать во всех подклассах, что определенно не чего я хочу.