О Компонентах И ​​Интерфейсах. Джава



Введение В предыдущем статья Я писал о различных способах проектирования интерфейсов к компонентам и сокрытии их реализации на C++.

В этой статье я кратко расскажу, как отделить интерфейс от реализации на Java и скрыть реализацию.

Я не буду рассматривать компоненты разных Java EE, я рассмотрю наиболее распространенные jar-библиотеки.

Так.



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

Итак, чтобы написать интерфейс библиотеки, вам на самом деле нужна сама библиотека и объявление экспортируемых классов как общедоступных.

Что-то вроде того:

  
  
  
  
   

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 скрывает реализацию, все публичные методы классов библиотеки остаются нам доступными.

Например, если наш 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 с реализацией.



Краткое содержание
Используя предложенный подход, можно получить множество преимуществ в разработке.

Ну, возьмем, к примеру, эту ситуацию.

Мы разрабатываем сложную систему, состоящую из множества взаимосвязанных компонентов.

Для параллельной разработки очень удобно разрабатывать интерфейсы и выносить их в отдельные библиотеки.

Тогда вы легко сможете распараллелить разработку самих компонентов, их тестов и связанных с ними компонентов.

Все прекрасно скомпилируется и ассемблируется, хотя реализация может быть еще не готова.

Теги: #java #интерфейсы #Компоненты #дизайн интерфейсов #программирование #java #дизайн и рефакторинг

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.