Разное

Пакет java: Модуль 2. Урок 4. Пакеты в Java.

package — Имена пакетов в Java в единственном или множественном числе?

Ситуация следующая:

Всё время делал названия для пакетов в единственном числе, но недавно у друга в коде заметил все названия в множественном. Например: у меня — dto, controller, model..., у него — dtos, controllers, models...

Стало интересно. Вроде как раньше не задумывался, писал на автомате. Пересмотрел свои исходники, единственный множественный вариант именования — utils, всё остальное в единственном числе.

Есть ли какие-то code conventions или best practices в отношении числительного в названии пакета?

Если общих правил не существует, чем следует руководствоваться?

P.S. поиск выдаёт, что многие выбирают совершенно случайно и допускают оба варианта, но какая-то же логика должна быть. Поэтому хочу поднять этот вопрос.

  • java
  • package
  • best-practice

Называйте во множественном числе пакеты с однородным контентом, и в единственном числе — пакеты с разнородным контентом.

Класс имеет сходство с таблицой в базе данных. Таблицу в базе называют в единственном числе, так как записи в таблице являются экземплярами сущности, которая описывается этой таблицей.

Что касается пакетов, то пакет — это не абстракция над данными. Пакет нужен для организации кода и разрешения конфликтов имен. Если пакет назван в единственном числе, то это не значит что каждый элемент внутри пакета является экземпляром данного пакета: он содержит связанные, но разнородные сущности. Если пакет назван во множественном числе, то ожидается, что он будет содержать однородные сущности.

Например, типы следует называть TaskCollection, а не TasksCollection, так как это коллекция, которая содержит Task. Но если пакет назван com.myproject.task, то это не означает что каждый класс в этом пакете является экзепляром Task. Там может лежать TaskHandler, TaskFactory и т. д. Но пакет с именем com.myproject.tasks будет содержать различные типы тасков: TakeOutGarbageTask, DoTheDishesTask, и т.

д.

https://softwareengineering.stackexchange.com/a/75929

1

Пишу на c#, в нем не пакеты, а пространства имен и проекты, но суть одна и та же) С основным ответом, полностью согласен, если что-то однородное, зову во множественном числе (Models, Controllers), а если нет, обычно в единственном. Единственное, что у меня выпадает из этого правила — DTO, т.к. это уже акроним и не вижу смысла добавлять к нему еще S для множественного числа.

2

К перечисленным выше ответам хочу добавить.

Поиск по style guides не даёт результатов, так как этот момент не регламентируется. Вот к примеру от google и oracle рекомендации по названиям пакетов:

Google Java Style Guide

Oracle Java Documentation

Поэтому я стал спрашивать в крупных чатах разработчиков java. Большинство особо не задумываются и пишут названия пакетов в единственном числе.

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

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

Publishing Java packages with Gradle

Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.

Введение

В этом руководстве показано, как создать рабочий процесс, который публикует пакеты Java в GitHub Packages и центральном репозитории Maven. С помощью одного рабочего процесса можно публиковать пакеты в одном репозитории или в нескольких.

Предварительные требования

Рекомендуется иметь базовое представление о файлах рабочих процессов и параметрах конфигурации. Дополнительные сведения см. в разделе Изучение GitHub Actions.

Дополнительные сведения о создании рабочего процесса CI для проекта Java с помощью Gradle см. в разделе Building and testing Java with Gradle.

Также могут быть полезны базовые знания в следующих областях:

  • «Working with the npm registry»
  • «Variables»
  • «Зашифрованные секреты»
  • «Automatic token authentication»

Сведения о конфигурации пакета

Поля groupId и artifactId в разделе MavenPublication файла build. gradle создают уникальный идентификатор пакета, используемый реестрами для связывания пакета с реестром. Они аналогичный полям groupId и artifactId файла Maven pom.xml. Дополнительные сведения см. в статье «Подключаемый модуль публикации Maven» в документации по Gradle.

Файл build.gradle также содержит конфигурацию для репозиториев управления дистрибутивами, в которые Gradle будет публиковать пакеты. Каждый репозиторий должен иметь имя, URL-адрес развертывания и учетные данные для проверки подлинности.

Публикация пакетов в центральный репозиторий Maven

При каждом создании выпуска можно активировать рабочий процесс для публикации пакета. Рабочий процесс в приведенном ниже примере выполняется при активации события

release с типом created. Если тесты CI проходят успешно, рабочий процесс публикует пакет в центральный репозитории Maven. Дополнительные сведения о событии см. в release разделе Events that trigger workflows.

Вы можете определить новый репозиторий Maven в блоке публикации файла build.gradle, который указывает на репозиторий пакетов. Например, если развертывание в центральный репозиторий Maven выполнялось с помощью проекта размещения OSSRH, файл build.gradle может указывать репозиторий с именем "OSSRH".

С помощью этой конфигурации можно создать рабочий процесс, который публикует пакет в центральный репозитории Maven. Для этого нужно выполнить команду gradle publish. На этапе развертывания необходимо задать переменные среды для имени пользователя и пароля или маркера, используемого для проверки подлинности в репозитории Maven. Дополнительные сведения см. в разделе Зашифрованные секреты.

Этот рабочий процесс выполняет следующие действия:

  1. Извлекает копию репозитория проекта.

  2. Настраивает JDK Java.

  3. Проверяет контрольные суммы всех JAR-файлов программы-оболочки Gradle, имеющихся в репозитории.

  4. Выполняет действие gradle/gradle-build-action с аргументом publish для публикации в репозиторий Maven OSSRH. Переменная среды MAVEN_USERNAME будет задана с содержимым секрета OSSRH_USERNAME, а переменная среды MAVEN_PASSWORD — с содержимым секрета OSSRH_TOKEN.

    Дополнительные сведения об использовании секретов в рабочем процессе см. в разделе Зашифрованные секреты.

Публикация пакетов в GitHub Packages

При каждом создании выпуска можно активировать рабочий процесс для публикации пакета. Рабочий процесс в приведенном ниже примере выполняется при активации события

release с типом created. Если тесты CI проходят успешно, рабочий процесс публикует пакет в GitHub Packages. Дополнительные сведения о событии см. в release разделе Events that trigger workflows.

Вы можете определить новый репозиторий Maven в блоке публикации файла build. gradle, который указывает на GitHub Packages. В этой конфигурации репозитория можно также использовать переменные среды, заданные в рабочем процессе CI. Переменную среды GITHUB_ACTOR можно использовать в качестве имени пользователя, а переменную среды GITHUB_TOKENможно задать с помощью секрета GITHUB_TOKEN.

Секрет GITHUB_TOKEN устанавливается в качестве маркера доступа для репозитория при каждом запуске задания в рабочем процессе. Вам следует установить разрешения для этого маркера доступа в файле рабочего процесса, чтобы предоставить доступ на чтение в области

contents и доступ на запись в области packages. Дополнительные сведения см. в разделе Automatic token authentication.

Например, если организация называется «octocat», а репозиторий называется «hello-world», конфигурация GitHub Packages в файле build.gradle будет выглядеть примерно так, как показано в следующем примере.

С помощью этой конфигурации можно создать рабочий процесс, который публикует пакет в GitHub Packages. Для этого следует выполнить команду gradle publish.

Этот рабочий процесс выполняет следующие действия:

  1. Извлекает копию репозитория проекта.

  2. Настраивает JDK Java.

  3. Проверяет контрольные суммы всех JAR-файлов программы-оболочки Gradle, имеющихся в репозитории.

  4. Выполняет действие

    gradle/gradle-build-action с аргументом publish для публикации в GitHub Packages. Переменная среды GITHUB_TOKEN будет задана с содержимым секрета GITHUB_TOKEN. Ключ permissions указывает доступ, разрешенный секретом GITHUB_TOKEN.

    Дополнительные сведения об использовании секретов в рабочем процессе см. в разделе Зашифрованные секреты.

Публикация пакетов в центральный репозиторий Maven и GitHub Packages

Вы можете опубликовать пакеты в центральный репозиторий Maven и GitHub Packages, настроив каждый из них в файле build. gradle.

Файл build.gradle должен содержать репозиторий для репозитория GitHub и поставщика центрального репозитория Maven.

Например, при развертывании в центральный репозиторий с помощью проекта размещения OSSRH может потребоваться указать его в репозитории управления дистрибутивом — name должен иметь значение OSSRH. При развертывании в GitHub Packages может потребоваться указать его в репозитории управления распределением —

name должен иметь значение GitHubPackages.

Например, если организация называется «octocat», а репозиторий называется «hello-world», конфигурация в файле build.gradle будет выглядеть примерно так, как показано в следующем примере.

С помощью этой конфигурации можно создать рабочий процесс, который публикует пакет в центральный репозиторий Maven и GitHub Packages. Для этого следует выполнить команду gradle publish.

Этот рабочий процесс выполняет следующие действия:

  1. Извлекает копию репозитория проекта.

  2. Настраивает JDK Java.

  3. Проверяет контрольные суммы всех JAR-файлов программы-оболочки Gradle, имеющихся в репозитории.

  4. Выполняет действие gradle/gradle-build-action с аргументом publish для публикации в репозиторий Maven

    OSSRH и GitHub Packages. Переменная среды MAVEN_USERNAME будет задана с содержимым секрета OSSRH_USERNAME, а переменная среды MAVEN_PASSWORD — с содержимым секрета OSSRH_TOKEN. Переменная среды GITHUB_TOKEN будет задана с содержимым секрета GITHUB_TOKEN. Ключ permissions указывает доступ, разрешенный секретом GITHUB_TOKEN.

    Дополнительные сведения об использовании секретов в рабочем процессе см. в разделе Зашифрованные секреты.

Пакет Java

Чтобы создать пакет Java с именем pkg :

  1. Создать каталог с именем pkg .
  2. Поместите все файлы .java для классов и интерфейсов в каталоге pkg .
  3. Начало каждого из файлов .java с объявлением пакета :

    упаковка упак.;

  4. Скомпилировать файлы по работает javac из родительского каталога пакета pkg . Например,

    пакет javac/*.java

  5. Доступ к классам и интерфейсам пакета pkg из других пакетов, импортировав его определения со строкой импорта в каждом файле .java , который их использует:

    импортная упаковка;

  6. Сообщить интерпретатору Java, как найти пакет упак. поместив pkg в родительский каталог на пути к классам, или запустив интерпретатор из этого каталога. Если полный или относительный путь родительского каталога pkg это pname , затем java -cp pname . .. поместит pname в путь к классам и сделать пакет pkg доступным. Если у вас есть несколько пакетов в разных родительских каталогах, разделяйте имена двоеточиями: java -cp pname:name2:dir3 ... .

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

формула пакета ;

Подпакет — это просто пакет в подкаталог каталога другого пакета. Java использует точку в качестве разделителя имени пакета, например / используется как разделитель каталогов (по крайней мере, для цивилизованных операционных систем). Например, сделать подпакет подпункт из упаковки упак. :

  1. Создать подкаталог с именем subp в каталоге pkg .
  2. Поместите все файлы .java для классов и интерфейсов в каталоге pkg/subp .
  3. Начинайте каждый файл .java с объявления пакета:

    пакет pkg.subp;

  4. Скомпилируйте файлы, запустив javac из родительского каталога pkg (так же, как и раньше). Например,

    javac pkg/subp/*.java

  5. Доступ к классам и интерфейсам пакета subp из других пакетов, включая pkg ), импортируя его определения со строкой импорта в каждом файле .java , который их использует:

    импорт pkg.subp;

  6. Ничего другого делать не нужно сообщить интерпретатору Java, как найти пакет уп.подп , так как вы уже говорите ему искать в pkg родительский каталог.

Хотя может показаться, что pkg и subp должны иметь более легкий или более простой доступ друг к другу потому что один является подпакетом другого, это не вариант. Файлы любого пакета должны импортировать другой пакет, чтобы использовать его, точно так же, как файлы любого другого пакета.

Не имеет большого значения, как вы называете свои собственные пакеты, пока имена уникальны. Для опубликованных пакетов существует соглашение об уникальных именах который использует URL-адрес, связанный с вами, пакетом или проектом, частью которого он является. Компоненты URL используются как имена пакетов, в обратном порядке. Например, для проекта ScenarioML чей связанный URL равен http://scenarioml.ics.uci.edu , каждый пакет будет подпакетом edu.uci.ics.scenarioml . Пакет сценария для этого проекта будет иметь это имя в качестве имени пакета:

edu.uci.ics.scenarioml.scenario

и его исходные файлы должны находиться в каталоге с именем

edu/uci/ics/scenarioml/scenario

Чтобы создать jar-файл для одного или нескольких пакетов, перейдите в родительский каталог, из которого вы скомпилируете исходные файлы, и запустить jar , дающий ему все имена файлов классов. Например, для рассмотренного выше пакета сценария , вы должны перейти в каталог, содержащий каталог edu и введите команду

jar cf jarfname edu/uci/ics/scenarioml/scenario/*.class

и получит jarfile с именем jarfname.jar который вы могли бы поместить в путь к классам и таким образом получить доступ к пакету сценария .

Интеграция пакетов Java - MATLAB и Simulink

Основное содержание

Интеграция скомпилированных функций MATLAB ® в приложения Java ®

С MATLAB Компилятор SDK™, интегрирующий скомпилированные функции MATLAB в приложение Java, включает использование комбинации API, которые инициализируйте MATLAB Runtime, загрузите скомпилированные функции MATLAB в MATLAB Runtime и управляйте данными, которые передаются между Java и MATLAB.

Пакеты и приложения Java обеспечивают переносимость и масштабируемость решения для приложений в крупномасштабных корпоративных или веб-средах. Вы можете развернуть сгенерированные пакеты в корпоративной или веб-среде, где MATLAB Runtime установлен.

Java Remote Method Invocation (RMI) — это набор API-интерфейсов, которые позволяют Объекты Java для вызова объектов в другой виртуальной машине Java (JVM). Используйте RMI для разработки клиент-сервер приложения, распределенные приложения и веб-приложения. Для таких приложений, только те части приложения, которые непосредственно вызывают Для функций MATLAB требуется MATLAB Runtime. Другие части приложения могут работать с собственными Типы данных Java.

Functions

compiler.build.javaPackage Create Java package for deployment outside MATLAB
compiler.build.JavaPackageOptions Options for building Java packages
mcrinstaller Отображение информации о версии и местоположении для установщика MATLAB Runtime, соответствующего текущей платформе
mcrversion Return MATLAB Runtime version number that matches MATLAB version

Java API Documentation

MWArray
waitForFigures

Topics

Requirements and Highlights

  • Requirements and Ограничения MATLAB Compiler SDK Java Target
    См. требования к программному обеспечению для использования MATLAB Компилятор SDK для создания пакетов Java.
  • Настройка среды для создания пакетов Java
    Настройка среды Java для компиляции кода MATLAB в пакеты Java с использованием MATLAB Компилятор SDK.
  • Как работает интеграция Java с MATLAB Compiler SDK
    Узнайте, как работает MATLAB SDK компилятора Java обрабатывает данные.
  • Программные интерфейсы, сгенерированные MATLAB Compiler SDK
    Узнайте о сигнатурах функций, созданных для обработки методов MATLAB.

Создание и интеграция с Java

  • Создание пакета Java и создание приложения Java
    Создайте пакет Java в MATLAB и реализуйте его с помощью примера кода Java.
  • Пакет приложений Java из командной строки
    Использование компилятора командной строки для создания приложений Java.

Примеры приложений

  • Интеграция простой функции MATLAB в приложение Java
    Узнайте, как интегрировать сгенерированный MATLAB пакет Java в приложение Java.
  • Показать график MATLAB в приложении Java
    Создайте приложение Java, отображающее график MATLAB.
  • Создать приложение телефонной книги Java с использованием массива структур
    Инкапсулировать функцию MATLAB, которая изменяет массив структур, содержащий телефон числа.
  • Создать приложение Java с несколькими функциями MATLAB
    Реализовать приложение анализатора сигналов, которое включает несколько функций, используя анализ зависимости.
  • Назначение нескольких функций MATLAB классу Java
    Создайте пакет Java, содержащий несколько функций для реализации матричных вычислений программа.
  • Использование класса MATLAB в приложении Java
    Использование объектно-ориентированного проектирования для развертывания класса MATLAB в пакете Java.
  • Передача объектов Java в MATLAB
    Создание пакета Java, который применяет процедуры оптимизации к целевым функциям, используя MWJavaObjectRef класс.
  • Блокировка отображения консоли при создании фигур в Java
    Используйте waitForFigures в консольном приложении Java, которое генерирует фигуры MATLAB.

Управление данными

  • Преобразование данных между Java и MATLAB
    См. инструкции по преобразованию данных между Java и MATLAB.
  • Правила преобразования данных между Java и MATLAB
    См. правила преобразования типов Java в типы MATLAB.
  • Управление ресурсами MATLAB в JVM
    Правильно создавайте и удаляйте данные MATLAB в своем коде.
  • Рендеринг данных изображений MATLAB в Java
    См. методы эффективной работы с данными рисунков и изображений в вашем код.
  • Задайте профиль Parallel Computing Toolbox в приложении Java
    Задайте информацию о профиле для приложений Parallel Computing Toolbox™.

Рекомендации по развертыванию

  • Определить параметры внедрения и извлечения для развертываемого архива Java
    Управлять поведением внедрения и извлечения развертываемого архива с помощью Класс MWComponentOptions или переменные среды.
  • Обеспечьте многоплатформенную переносимость для Java
    Обеспечьте независимость от платформы в скомпилированном коде MATLAB.
  • Ограничения для нескольких пакетов в одном приложении Java
    Узнайте о типах данных, которые нельзя совместно использовать в пакетах Java.
  • Сопоставьте функции с классами Java
    Сопоставьте функции MATLAB с методами класса Java во время компиляции.

Удаленный вызов метода

  • Удаленный вызов метода для клиент-серверных приложений
    Узнайте, как RMI позволяет запускать отдельные процессы на нескольких машинах.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *