Рубрики
Без рубрики

Java SE 9: Разработка и тестирование Подразумеваемой Читаемости Между Модулями С помощью IntelliJ IDEA (Часть 5)

Я уже обсуждал многие теоретические концепции о “Системе модулей Java 9”, а также разработал пару примеров использования командной строки и IDE в своем

Автор оригинала: Pankaj Kumar.

Я уже обсуждал многие теоретические концепции о “Системе модулей Java 9”, а также разработал пару примеров использования командной строки и IDE в своих предыдущих постах.Теперь я собираюсь обсудить “Как разрабатывать и тестировать подразумеваемую читаемость между модулями с помощью IDE IntelliJ IDEA” в этом посте.

В этой серии постов “Система модулей Java 9” это мой пятый пост. Прежде чем прочитать этот пост, пожалуйста, просмотрите мой предыдущий пост, перейдя по следующим ссылкам, чтобы понять некоторые основы модулей Java 9.

  • Введение в систему модулей Java 9
  • Основы модуля Java 9 и дескриптора модуля
  • Модуль Java 9 HelloWorld с командной строкой
  • Модуль Java 9 Hello World с Eclipse и идеей IntelliJ

Опубликуйте Краткое содержание:

  • Что такое Читабельность?
  • Что такое доступность?
  • Что такое Подразумеваемая Читабельность?
  • Разработка Зависимости Модуля С Плохим Подходом
  • Проверьте Зависимость Модуля От Неправильного Подхода
  • Развивайте Подразумеваемую Читабельность(Хороший Подход)
  • Преимущества подразумеваемой читабельности

Что такое Читабельность?

Если Модуль-1 напрямую зависит от модуля-2, то он известен как “Модуль-1 Считывает Модуль-2”. Другими словами, мы можем сказать, что “Модуль-2 читается модулем-1”.

Таким образом, это известно как соотношение читаемости между модулем-1 и модулем-2. Давайте рассмотрим это с некоторыми модулями JDK 9, используя приведенную ниже схему.

Здесь модуль “java.sql” читает “java.xml”, модули “java.база” и “java.ведение журнала”.

Что такое доступность?

Если модуль-1 имеет связь читаемости с Модулем-2, то Модуль-1 может “Получить доступ” ко всем общедоступным API Модуля-2. Это известно как Взаимосвязь доступности между этими двумя модулями. Как мы обсуждали в моих предыдущих постах, Модуль может иметь только публичный API или как публичный, так и частный API.

Проще говоря, Общедоступный API означает Общедоступные типы. Если вы плохо в этом разбираетесь, мы обсудим “Как разрабатывать публичный и частный API” в моих следующих постах.

Концепции удобочитаемости и доступности являются основой для достижения двух основных целей Модульной системы Java 9:

  • Надежная Конфигурация
  • Сильная Инкапсуляция

Мы можем определить отношения читаемости и доступности между модулями, используя следующие концепции:

  • положение об экспорте
  • требуется оговорка
  • публичный модификатор
  • к пункту

Мы обсудим все эти концепции в этом посте с примерами, кроме последнего (проверьте мои ближайшие посты).

Что такое Подразумеваемая Читабельность?

Если Модуль-1 считывает данные с Модуля-2, а Модуль-2 считывает данные с Модуля-3, то Модуль-1 считывает данные с Модуля-3. Этот вид транзитивной зависимости известен как “Подразумеваемая читаемость” от модели-3 до модуля-1.

Это также известно как Подразумеваемая зависимость.

Предположим, что у нас есть связь между тремя модулями, как показано на приведенной ниже диаграмме.

“Модуль “Фамилия” зависит от “Имени”, модуль “Полное имя” зависит от обоих модулей: “Имя” и “Фамилия”. Это означает, что между этими тремя модулями существует Переходная зависимость: ” Полное имя ==> Фамилия ==> Имя

В системе модулей Java 9 у нас есть два подхода к разрешению этих зависимостей модулей. 1. Плохой подход Этот подход решает Транзитивную зависимость между модулями без использования “Подразумеваемой читаемости”.

Здесь “Полное имя” импортирует оба модуля, используя предложения “требуется”, как показано ниже:

module FirstName{ 
  exorts FirstName;
}
module LastName{
   requires FirstName;
   exports LastName;
}
module FullName{
   requires FirstName;
   requires LastName;
   exports FullName;
}

Это плохой подход, потому что Фамилия уже импортирует модуль имени, тогда почему бы нам не получить эту функцию импорта в модуль полного имени?? Вместо того, чтобы использовать это, Полное имя импортирует оба модуля. Это прекрасно работает, однако это не рекомендуемый подход.

В проектах реального времени у нас будут такие зависимости от многих модулей, хорошо ли импортировать все модули?? Определенно НЕТ, верно.

2. Хороший подход Этот подход решает Транзитивную зависимость между модулями, используя метод “Подразумеваемой читаемости”.

Здесь “Полное имя” импортирует только модуль фамилии, используя предложение “требуется”, но он автоматически получает “Имя” без импорта, как показано ниже:

module FirstName{ 
  exorts FirstName;
}
module LastName{
   requires public FirstName;
   exports LastName;
}
module FullName{
   requires LastName;
   exports FullName;
}

Этот хороший подход также известен как “Подразумеваемая читаемость” в системе модулей Java 9. Таким образом, мы можем реализовать “Подразумеваемую читаемость”, используя модификатор “public”, как показано в приведенном выше примере.

Мы разработаем оба подхода в следующих разделах, чтобы хорошо понять это.

Пожалуйста, ознакомьтесь с этим постом Java 9 Hello World Модуль с Eclipse и IntelliJ Идея, чтобы узнать о “Как разрабатывать модули Java 9 с помощью IntelliJ IDE”.

Выработайте Плохой Подход

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

Давайте разберемся в этом подходе с помощью этой диаграммы:

  • Создайте проект идеи IntelliJ
  • Название проекта: Подразумеваемая зависимость

  • Разработка кода модуля FirstName
    • Создать модуль с именем
    • Имя модуля:: com.имя

    • Создайте пакет модуля с первым именем
    • Название упаковки: com.firstname.name

    • Создание компонентов Java(ов)
    • Создание компонентов Java(ов)

    • Создать Дескриптор модуля с именем
    • Создать Дескриптор модуля с именем

  • Разработка Кода Модуля Фамилии
    • Создать модуль фамилии
    • Имя модуля:: com.фамилия

    • Создать Пакет модуля с именем
    • Название пакета: com.последний name.name

    • Создание компонентов Java(ов)
    • Создание компонентов Java(ов)

      Создание компонентов Java(ов)

    • Создать Дескриптор модуля фамилии
    • Создать Дескриптор модуля фамилии

      Поскольку этот модуль зависит от модуля FirstName, мы должны добавить в этот модуль предложение “требуется”, как показано в приведенном выше примере.

  • Разработать Код Модуля Полного Имени
    • Создать модуль полного имени
    • Имя модуля:: com.полное имя

    • Создать пакет модуля с полным именем
    • Название пакета: com.полный name.name

    • Создание компонентов Java(ов)
    • Создание компонентов Java(ов)

      Создание компонентов Java(ов)

    • Создать Дескриптор модуля с полным именем
    • Создать Дескриптор модуля с полным именем

      Поскольку этот модуль зависит от модулей FirstName и LastName, мы должны добавить предложения requires к обоим из них, как показано в приведенном выше примере.

Разработайте Тестовый модуль и Протестируйте Плохой подход

В этом разделе мы разработаем Тестовый модуль для проверки этого плохого подхода.

  • Создать Модуль Тестирования
  • Имя модуля:: com.name.test

  • Создать Пакет Тестового Модуля
  • Имя пакета: com.name.test

  • Создание компонентов Java(ов)
  • Создание компонентов Java(ов)

  • Окончательный проект выглядит так, как показано ниже.
  • Запустите класс тестера имен
  • Выход:-

Это прекрасно работает, однако это не рекомендуемый подход. Давайте разработаем такое же приложение, используя метод “Подразумеваемой читаемости”.

Разработка и тестирование подразумеваемой зависимости

  • Пожалуйста, выполните те же действия, что и мы при плохом подходе.
  • Изменить Дескриптор модуля “Фамилия”
  • Изменить Дескриптор модуля “Фамилия”

    Здесь мы можем наблюдать этот модификатор “public” перед именем модуля. Когда мы используем это в предложении requires, как показано в приведенном выше дескрипторе модуля, это означает, что любой модуль, который считывает этот модуль “Фамилия”, может также автоматически считывать модуль “Имя”. Нет необходимости использовать дополнительное предложение “требуется”.

  • Измените Дескриптор модуля “Полное имя”
  • Измените Дескриптор модуля “Полное имя”

    Здесь мы не используем дополнительное предложение “требуется” для модуля “Имя”. Тем не менее, он может считывать этот модуль из-за метода “Подразумеваемой читаемости” модуля “Фамилия”.

  • Используйте тот же модуль тестера для тестирования этого приложения.
  • Тот же вывод и для этого приложения.

ПРИМЕЧАНИЕ:- Здесь мы используем всего несколько модулей. Однако в проектах реального времени это не то же самое. Модуль реального времени может зависеть от большего количества модулей, и это неправильный подход для импорта всех из них. я прав??

Несколько важных моментов, которые следует запомнить

В этом разделе мы кратко обсудим некоторые важные моменты, которые следует помнить о системе модулей Java 9.

  • Каждый модуль, по определению, читает сам себя.
  • Модульная система Java 9 НЕ поддерживает циклические графики, что означает, что она поддерживает только ациклические графики.
  • Два или более модулей могут иметь одинаковые имена пакетов. Это означает, что мы можем использовать одни и те же имена пакетов в двух разных модулях.
  • По умолчанию все модули Java 9 (модули JDK или определяемые пользователем модули) зависят от модуля “java.base”.

Вот и все о теме “Разработка и тестирование подразумеваемой зависимости с помощью Eclipse IDE”. Мы обсудим еще несколько концепций разработки модулей Java SE 9 в моих следующих постах.

Пожалуйста, напишите мне комментарий, если вам нравится мой пост или у вас есть какие-либо вопросы/предложения/ошибки типа.

Спасибо, что прочитали мои учебные пособия.

Счастливого Обучения Java SE 9!