О компонентах и интерфейсах. Java

Вступление

В предыдущей статье я написал о разных способах оформления интерфейсов к компонентам и сокрытия их реализации в C++.
В этой статье расскажу вкратце, как в Java отделить интерфейс от реализации, а реализацию скрыть.
Я не буду рассматривать компоненты разных там Java EE, я рассмотрю самые обычные jar-ники-библиотеки.
Итак.

Что мы имеем

В Java нет функций, есть только классы, соответственно в Java экспортируются классы.
Чтобы класс был экспортирован, нужно чтобы он был объявлен как public.
Итак, чтобы написать интерфейс библиотеки, нужна, собственно, сама библиотека и объявление экспортируемых классов как public.

Что-то типа того:

package com.test;

public class Test {
    private final String string = "Test";

    public String GetString()
    {
        return string;
    }
}

Компилируем, получаем jar-ник, который затем может использовать.
Ну как-то так:

package com.sample;

import com.test.Test;

public class NewClass {
    private static Test test = new Test();
    
    public static void Main()
    {
        System.out.println( test.GetString() );
    }
}

Какие в таком подходе недостатки.
Хоть скомпилированный jar-ник и скрывает реализацию, но у нас остаются доступными все public-методы классов библиотеки. Например если у нас jar-ник состоит из нескольких пакетов (Package-й), и мы использовали в нем вызовы методов между ними, то получится, что разработчик, использующий вашу библиотеку, сможет получить доступ к методам, которые вы не хотели открывать для использования. Т.е. мы опять же открываем реализацию. Так же мы не имеем текстов интерфейсов, которые бы могли отдать разработчикам для изучения.
Что делать в таком случае?
Чтобы полностью скрыть реализацию воспользуется одними из самых удобных инструментов Java — интерфейсами и рефлексией.

Что получилось

Например, у нас есть компонент с таким интерфейсом:

package com.iface;

public interface Component {
    
    public void Method1();

    public void Method2();

    public void Method3();

    public void Method4();
}

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

package com.iface;

public interface Factory {
    public Component getComponent();
}

Экземпляр фабрики создаем статически. Ссылку на фабрику сохраняем. Оформляем классом FactoryCreator следующим образом:

package com.iface;

import java.lang.reflect.Method;

public class FactoryCreator {
    private static Factory instance = null;
    private static Throwable ex = null;

    static {
        try {
            Class cl = Class.forName("com.test.FactoryImpl");
            Method method = cl.getMethod("createInstance", new Class[0]);
            Object obj = method.invoke(cl, new Object[0]);
            if(obj instanceof Factory) {
                instance = (Factory) obj;
            }
            ex = new Exception("Cannot init Factory instance.");
        } catch (Throwable throwable) {
            ex = throwable;
        }
    }

    public static Factory getInstance() throws Throwable {
        if(instance != null) {
            return instance;
        }
        
        throw ex;
    }
}

Итак, как это работает и что у нас получилось.
Все интерфейсы оформляем в одной библиотеке, реализацию полностью оформляем в другой библиотеке. В единственном классе библиотеки интерфейсов статически получаем класс реализации фабрики по его имени. Затем по имени же получаем статический метод этого класса, который создает нам экземпляр фабрики. Вызываем этот метод и сохраняем экземпляр фабрики. Вызов getInstance() просто отдаст нам этот экземпляр. Можно изобрести много таких реализаций, но общая идея отсюда понятна. Для разработки и компиляции достаточно библиотеки интерфейсов. Так же, для удобства изучения, можно полностью раскрыть для разработчиков исходники интерфейсов.
Для запуска приложения нужно только указать java-машине, что помимо загрузки jar-ника с интерфейсами, нужно загрузить jar-ник с реализацией.

Резюме

Используя предложенный подход можно получить много плюсов в разработке. Ну взять хотя бы такую ситуацию. Мы ведем разработку сложной системы, в которой есть много взаимосвязанных компонентов.
Для параллельной разработки очень удобно разработать интерфейсы и сложить их в отдельные библиотеки. Тогда можно легко распараллелить разработку самих компонентов, их тестов, и компонентов, которые с ними связаны. Все будет прекрасно компилиться и собираться, хотя реализация при этом может быть еще не готова.