реализация интерфейсов после факта

Если вы (можете) управлять ClassLoader , который загружает ваш класс C затем вы можете попытаться выполнить некоторые махинации времени загрузки класса с инструментарием байт-кода, чтобы заставить класс реализовать интерфейс.

Конечно, то же самое можно сделать во время сборки. Это может даже быть проще (так как вам не нужен доступ к ClassLoader).

Couldn't you use a delegate class, i.e. a new class which wraps an instance of "Class C", but also implements "Interface I" ?

public class D implements I {

    private C c;

    public D (C _c) {
        this.c = _c;
    }

    public void method_from_class_C() {
        c.method_from_class_C();
    }
    // repeat ad-nauseum for all of class C's public methods
    ...

    public void method_from_interface_I() {
        // does stuff
    }
    // and do the same for all of interface I's methods too
}

and then, if you need to invoke a function which normally takes a parameter of type I just do this:

result = some_function(new D(c));

(Дополнительное замечание: я думаю, что актеры (D) c, где тип времени выполнения c - C, должен быть допускается, если D является C и единственным Разница в C добавлены методы. Это должно быть безопасно, не так ли?)

Вовсе нет. Если бы вы могли сделать это приведение, то вы могли бы скомпилировать код, который пытался вызвать один из «добавленных методов» для этого объекта, который потерпел бы неудачу во время выполнения, так как этот метод не существует в C.

Я думаю, вы представляете, что Приведение будет определять методы, которые «отсутствуют» в C, и автоматически делегировать их в D. Я сомневаюсь, что это было бы выполнимо, хотя я не могу говорить о последствиях разработки языка.

Мне кажется, что решение вашей проблемы:

Определите класс D, который расширяет C и реализует I
Определите конструктор D (C c), который по существу клонирует состояние данного объекта C в новый объект D.
Объект D может быть передан в существующий код, потому что это C, и он может быть передан в код, который хочет I, потому что это I

Я считаю, что то, что вы хотите, возможно с помощью java.lang.reflect.Proxy ; на самом деле я сделал нечто подобное для текущего проекта. Однако это довольно трудоемкий процесс, и полученные в результате «гибридные объекты» могут демонстрировать странное поведение (поскольку вызовы методов для них направляются к различным конкретным объектам, возникают проблемы, когда эти методы пытаются вызывать друг друга).

Я думаю, вы не можете этого сделать, потому что Java строго типизирована. Я считаю, что это можно сделать на таких языках, как Ruby и Python, с использованием миксинов.

Что касается Java, он определенно выглядит как хорошее использование для шаблона проектирования адаптера (он уже предлагался ранее как объект-оболочка).