Структура проекта Java объясняется для новичков?

Ответ 1

"Простые" проекты J2SE

Как объяснил cletus, структура исходного каталога напрямую эквивалентна структуре пакета и, по сути, встроена в Java. Все остальное немного менее четкое.

Многие простые проекты организованы вручную, поэтому люди могут выбрать структуру, в которой они чувствуют себя хорошо. Что часто делается (и это также отражается в структуре проектов в Eclipse, очень доминирующем инструменте Java) заключается в том, чтобы исходное дерево начиналось в каталоге с именем src. Ваши исходные файлы без пакетов будут располагаться непосредственно в src, и ваша иерархия пакетов, обычно начиная с каталога com, также будет содержаться в src. Если вы CD в каталог src перед запуском компилятора javac, ваши скомпилированные файлы .class будут попадать в одну и ту же структуру каталогов, причем каждый .class файл находится в том же каталоге и рядом с его .java.

Если у вас много исходных и классных файлов, вы хотите отделить их друг от друга, чтобы уменьшить беспорядок. Руководство и организация Eclipse часто размещают каталог bin или classes, параллельный src, поэтому файлы .class попадают в иерархию, которая отражает структуру src.

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

Наконец, есть куча этого и того, что более или менее необязательно:

• docs в doc
• ресурсы в resources
• данные в data Конфигурация
• в conf...

Вы получаете идею. Компилятор не заботится об этих каталогах, это просто способы организовать (или запутать) себя.

Проекты J2EE

J2EE примерно эквивалентен ASP.NET, это массивная (стандартная) структура для организации веб-приложений. Хотя вы можете разработать свой код для проектов J2EE по своему усмотрению, существует стандартный стандарт для структуры, которую веб-контейнер ожидает от вашего приложения. И эта структура, как правило, также немного отражается на исходном макете. Вот страница, в которой подробно описываются структуры проектов для проектов Java (они не очень согласны с тем, что я написал выше) и для проектов J2EE в частности:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Проекты Maven

Maven - очень универсальный инструмент построения проекта. Лично мои потребности в построении прекрасно удовлетворяются ant, что примерно сравнивается с nmake. Maven, с другой стороны, является полным-lifecyle управления строительством с управлением зависимостью болтами. Libs и источник для большей части кода в мире Java свободно доступны в "сети", а maven, если его спросят красиво, будет сканировать его для вас и принести домой все, что вам нужно, без необходимости даже рассказать об этом. Он также управляет небольшим репозитаром.

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

Если вы когда-либо выбираете Maven, вы можете перестать беспокоиться о структуре проекта, потому что может быть только один. Это он: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Ответ 2

Пакет в Java очень похож на пространство имен в .Net. Имя пакета по существу создает путь к классам, которые живут внутри него. Этот путь можно рассматривать как пространство имен классов (в терминах .Net), потому что это уникальный идентификатор для определенного класса, который вы хотите использовать. Например, если у вас есть пакет с именем:

org.myapp.myProject

И внутри у вас была куча классов:

MyClass1
MyClass2

Чтобы конкретно ссылаться на те классы, которые вы использовали бы:

org.myapp.myProject.MyClass1
org.myapp.myProject.MyClass2

Единственное реальное различие между этим и .Net(что я знаю) заключается в том, что Java упорядочивает свои "пространства имен" структурно (каждый пакет представляет собой отдельную папку), тогда как .Net позволяет вам областям видимости с использованием ключевого слова namespace и игнорирует, где находится документ.

Файл JAR примерно аналогичен DLL в большинстве случаев. Это сжатый файл (вы можете открыть их с помощью 7zip), который содержит исходный код из других проектов, которые могут быть добавлены в зависимости от вашего приложения. Библиотеки обычно содержатся в JAR.

То, что нужно помнить о Java, - это очень структурное; ГДЕ файлы живут очень важно. Конечно, есть история, а затем то, что я написал, но я думаю, что это должно заставить вас начать.

Ответ 3

Пакет очень похож на пространство имен .Net. Общее соглашение в Java заключается в использовании вашего обратного имени домена в качестве префикса пакета, поэтому, если ваша компания example.com, ваши пакеты, вероятно, будут:

com.example.projectname.etc...

Его можно разбить на несколько уровней, а не только на одно (имя проекта), но обычно этого достаточно.

Внутри структуры структуры проекта обычно делятся на логические области: контроллеры, модели, представления и т.д. Это зависит от типа проекта.

В Java есть две доминирующие системы построения: Ant и Maven.

Ant - это, в основном, язык сценариев, специфичный для домена, и довольно гибкий, но вы в конечном итоге пишете много деталей шаблонов (задачи сборки, развертывания, тестирования и т.д.). Это быстро и удобно.

Maven более современна и более совершенна и заслуживает внимания (imho). Maven отличается от Ant тем, что Maven заявляет, что этот проект является "проектом веб-приложения" (называемым архетипом). После того, как это объявлено, структура каталогов задается после указания вашей groupId (com.example) и artifactId (название проекта).

Таким образом вы получаете много вещей бесплатно. Настоящий бонус Maven заключается в том, что он управляет вашими зависимостями проекта для вас, поэтому с pom.xml(файл проекта Maven) и правильно настроенным Maven вы можете предоставить это кому-то другому (с исходным кодом), и они могут создавать, развертывать, тестировать и запускайте свой проект с автоматической загрузкой библиотек.

Ant получает что-то подобное с Ivy.

Ответ 4

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

Наилучшей практикой с именами пакетов Java является использование доменного имени организации в качестве начала пакета, но в обратном порядке, например. если ваша компания владеет доменом "bobswidgets.com", вы можете начать свой пакет с "com.bobswidgets".

Следующий уровень вниз часто будет уровнем приложения или библиотеки, поэтому, если это ваши библиотеки электронной коммерции, это может быть что-то вроде "com.bobswidgets.ecommerce".

Далее, чем это часто представляет собой архитектуру вашего приложения. Классы и интерфейсы, которые являются основными для проекта, находятся в "корне", например. com.bobswidgets.ecommerce.InvalidRequestException.

Использование пакетов для разделения функций далее является общим. обычно шаблон состоит в том, чтобы поместить интерфейсы и исключения в любой корень подразделения и реализацию в подпакеты, например.

com.bobswidgets.ecommerce.payment.PaymentAuthoriser (interface)
com.bobswidgets.ecommerce.payment.PaymentException
com.bobswidgets.ecommerce.payment.paypal.PaypalPaymentAuthoriser (implementation)

Это позволяет легко вытащить классы и пакеты оплаты в свой собственный проект.

Некоторые другие примечания:

Java-пакеты тесно связаны с структурой каталогов. Таким образом, в рамках проекта класс с пакетом com.example.MyClass всегда будет в com/example/MyClass.java. Это связано с тем, что когда он упакован в Jar, файл класса определенно будет в com/example/MyClass.class.

Java-пакеты слабо связаны с проектами. Вполне вероятно, что проекты будут иметь свои собственные имена пакетов, например. com.bobswidgets.ecommerce для электронной коммерции, com.bobswidgets.intranet для проекта интрасети.

Файлы Jar будут содержать файлы классов, которые являются результатом компиляции вашего .java-кода в байт-коды. Это всего лишь zip файлы с расширением .jar. Корень файла Jar является корнем иерархии пространства имен, например. com.bobswidgets.ecommerce будет/com/bobswidgets/ecommerce/в файле Jar. Файлы Jar также могут использовать ресурсы контейнера, например. файлы свойств и т.д.

Ответ 5

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

Ожидается, что все классы java имеют пакет, который используется для устранения их неоднозначности. Поэтому, если вы открываете файл jar в своем проекте, например spring, каждый пакет начинается с org.springframework. Погрузчики классов не знают о имени jarfile, они используют только пакет.

Существует обычная практика нарушения вещей по типу объекта или функции, не все согласны с этим. Как и Cletus, размещенные здесь, существует тенденция группировать веб-контроллеры, объекты домена, службы и объекты доступа к данным в свои собственные пакеты. Я думаю, что некоторые люди, работающие с управлением доменами, не считают, что это хорошо. Преимущество состоит в том, что обычно все в вашем пакете имеет одинаковые зависимости (контроллеры могут зависеть от сервисов и объектов домена, сервисов зависят от объектов домена и объектов доступа к данным и т.д.), Поэтому это может быть удобно.

Ответ 6

Итак, в java у вас есть три разных типа access для функций-членов классов и переменных

общественности защищенный <Я > Пакет-частное и частные

Все классы в одном пакете могут видеть все остальные общедоступные, защищенные и связанные с упаковкой элементы.

Пакеты не являются иерархическими в системе. Обычно они организованы иерархически, но, насколько это касается времени выполнения, com.example.widgets - совершенно другой пакет из com.example.widgets.cogs

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

Они планируют добавить модульную систему к Java в JDK7 (называемую Project Jigsaw), и существует существующая система модулей под названием OSGi. Эти модульные системы будут/могут дать вам гораздо больше гибкости и мощности, чем простая система пакетов.

Кроме того, имена пакетов обычно являются строчными.:)

Ответ 7

Из Википедии:

Пакет Java - это механизм для организация классов Java в Пространства имен

и

Пакеты Java могут быть сохранены в сжатые файлы, называемые файлами JAR

Итак, для пакета a.b.c у вас могут быть классы Java в пакетах a, a.b и a.b.c. Обычно вы группируете классы внутри одного пакета, когда они представляют связанную функциональность. Функционально единственная разница между классами в одном пакете и классами в разных пакетах заключается в том, что уровень доступа по умолчанию для членов в Java является "защищенным пакетом", что означает, что доступ к другим классам в одном пакете имеют доступ.

Для класса abcMyClass, если вы хотите использовать MyClass в своем проекте, вы бы import a.b.c.MyClass или, менее рекомендуется, import a.b.c.* Кроме того, чтобы MyClass всегда находился в пакете abc, вы должны объявить его в первая строка MyClass.java: package a.b.c;.

Чтобы сделать это, вы можете добавить весь пакет (включая пакеты b и c и класс MyClass) и поместить этот JAR в свой $CLASSPATH; это сделает его доступным для использования вашего другого исходного кода (через вышеупомянутый оператор импорта).

Ответ 8

Чтобы ответить на примерный вопрос:

package com.smotricz.goodfornaught;

import java.util.HashMap;
import javax.swing.*;

public class MyFrame extends JFrame {

   private HashMap myMap = new HashMap();

   public MyFrame() {
      setTitle("My very own frame");
   }

}

Ответ 9

У файлов .JAR есть скомпилированный код? Или просто сжатые файлы исходного кода?

Они могут содержать оба или даже совершенно разные типы файлов, например картинки. Это архив zip в первую очередь. Чаще всего вы увидите JAR, которые содержат файлы классов, и те, которые содержат исходные файлы (удобные для отладки в вашей среде IDE, если вы используете сторонний код) или те, которые содержат javadoc (sourcecode documentatin), также удобны, если ваша среда IDE поддерживает привязку документации при доступе к функциям lib.

Есть ли веская причина, почему имена пакетов являются строчными?

Да, есть хорошая причина, чтобы имена пакетов были написаны строчными буквами: существует руководство, в котором говорится, что только классные имена написаны с большой буквы спереди.

У пакетов есть "круговые зависимости"? Другими словами, может ли Package.A использовать Package.B и наоборот?

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

Может ли кто-нибудь просто показать типичный синтаксис объявления класса как находящегося в пакете и объявить, что вы хотите ссылаться на другой пакет в классе (может быть?)?

Предположим, вы хотите использовать класс ArrayList из пакета java.util, либо используйте

 import java.util.ArrayList;
 ArrayList myList = new ArrayList(); 

или использовать без импорта (например, вы используете два разных класса с именем ArrayList из разных пакетов)

 java.util.ArrayList myList = new java.util.ArrayList();
 your.package.ArrayList mySecondList = new your.package.ArrayList();

Ответ 10

Хотя работать с круговыми зависимыми классами не так просто, это может быть невозможно. Я заставил его работать в одном случае. класс A и класс B зависели друг от друга и не собирались с нуля. но понимая, что части класса A не нужен класс B, и эта часть была тем, что класс B должен был полностью скомпилировать, я оставил ту часть класса A, которая не нужна классу B, а остальная часть класса A смог скомпилировать, тогда мне удалось скомпилировать класс B. Затем я смог отменить тот раздел класса A, который нуждался в классе B, и смог скомпилировать полный класс A. Оба класса затем функционировали должным образом. Хотя это не типично, если классы связаны друг с другом так, это кошерный и порой, возможно, необходимый. Просто убедитесь, что вы оставляете специальные команды для компиляции для будущих обновлений.