Инкапсулировать интерфейс стороннего поставщика услуг

1. Я пытаюсь инкапсулировать стороннюю библиотеку, написав над ней оболочку и используя только необходимые API в соответствии с моими потребностями.

2. Чтобы добиться этого, я создал этот проект-оболочку как отдельный проект со всеми зависимостями сторонней библиотеки.

3. В будущем сторонняя библиотека может быть заменена на лучшую, поэтому требуется высокий уровень развязки.

4. При этом я наткнулся на некоторые интерфейсы поставщиков услуг сторонней библиотеки, которые загружаются с помощью Java ServiceLoader где-то в библиотеке.

5. Я хочу, чтобы пользователи моего проекта-оболочки совершенно не знали об используемой сторонней библиотеке.

6. Чтобы добиться этого, я должен написать свой проект-оболочку таким образом, чтобы пользователям не требовалась никакая зависимость от третьих сторон.

7. Но SPI часто требуют, чтобы их конфигурация выполнялась в файле проекта META-INF/services/{SPIName}, что в конечном итоге приводит к утечке сторонних знаний.

8. Как я могу инкапсулировать эти сторонние SPI, чтобы конечный пользователь совершенно не знал о сторонней библиотеке?

9. Есть ли технический термин для таких случаев? или Существует ли для этого существующее решение или шаблон проектирования?

Я попробовал пару вещей после исчерпания поиска в Интернете.

Сторонний SPI

package com.thirdParty.library;

public interface IDataCollector {
    String getStudentName();
    Integer getMarks();
}

Некоторый класс, в который загружены все поставщики услуг для этого SPI. Обратите внимание, что в реальной третьей стороне все настолько сложно, насколько это возможно.

public class RankCalculator {
    private static final Map<Integer, String> ranks = new TreeMap<>();

    public RankCalculator () {
        ServiceLoader<IDataCollector> dataCollectorLoader = ServiceLoader.load(IDataCollector.class);
        for (IDataCollector dataCollector: dataCollectorLoader) {
            ranks.put(dataCollector.getMarks(), dataCollector.getStudentName());
        }
    }

    public Integer getRank (String name) {
        Integer position = ranks.size();
        for (Map.Entry<Integer, String> entry: ranks.entrySet()) {
            if (entry.getValue().equals(name)) {
                return position;
            }
            position --;
        }
        return -1;
    }
}

Проект-оболочка: я планировал написать интерфейс в своей оболочке IdataCollector, а затем реализовать этот интерфейс, и я также мог зарегистрировать его в META-INF/services. Более того, я думал, что предоставлю IWrapDataCollector конечным пользователям, и они зарегистрируют свои META-INF/сервисы с помощью этого интерфейса. это происходит следующим образом:

package com.myWrapper.test;

import com.thirdParty.library.IDataCollector;

public interface IWrapDataCollector extends IDataCollector {

    default Integer getMarksWrapper() {
        return null;
    }

    default String getStudentsNameWrapper() {
        return null;
    }

    @Override
    default String getStudentName() {
        return getStudentsNameWrapper();
    }

    @Override
    default Integer getMarks() {
        return getMarksWrapper();
    }
}

META-INF/services/com.thirdParty.library.IDataCollector с записью как com.myWrapper.test.IWrapDataCollector, но вскоре я понял, что ServiceLoader может загружать только конкретные классы, а IWrapDataCollector далеко не так близко к этому, и я отказался от этой идеи.
Результаты будут такими же, как и для абстрактного класса, поскольку эти классы не могут иметь объекта.

После провала этой мечтательной идеи
Я попытался (вопреки всем рекомендациям документации) написать конкретную реализацию в качестве моего SPI.

package com.myWrapper.test;

import com.thirdParty.library.IDataCollector;

public class IWrapDataCollector implements IDataCollector {

    public Integer getMarksWrapper() {
        return null;
    }

    public String getStudentsNameWrapper() {
        return null;
    }

    @Override
    public final String getStudentName() {
        return getStudentsNameWrapper();
    }

    @Override
    public final Integer getMarks() {
        return getMarksWrapper();
    }
}

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

И все же я снова понял, насколько глупа эта идея. Этот класс определенно получился, но загрузился только этот класс, что на самом деле правильно, потому что я зарегистрировал этот класс и получил за это заслуженное исключение NullPointerException.

Опять же, как я могу добиться этого и удалить стороннюю зависимость от пользовательского проекта, просто сохранив его в проекте-оболочке.