Java初心者向けにプロジェクト構造を説明しましたか？
私は.NETのバックグラウンドから来ており、Javaに完全に慣れていないため、Javaプロジェクト構造を回避しようとしています。
私の典型的な.NETソリューション構造には、論理的に別個のコンポーネントを示すプロジェクトが含まれ、通常は次の形式を使用して名前が付けられます。
MyCompany.SomeApplication.ProjectName
通常、プロジェクト名はプロジェクトのルート名前空間と同じです。大規模なプロジェクトの場合、名前空間をさらに細かく分類することもできますが、多くの場合、これ以上名前空間を指定する必要はありません。
Javaでは、プロジェクトで構成されるアプリケーションがあり、新しい論理レベルであるパッケージがあります。パッケージとは何ですか？何を含めるべきですか？このApp.Project.Package構造内の名前空間はどのようになっていますか？ JARは、これらすべてにどこに適合しますか？基本的に、誰かがJavaアプリケーション構造に初心者向けのイントロを提供できますか？
ありがとう！
編集：本当にひどい答えがあります。その後、いくつかのフォローアップの質問：
- .JARファイルにはコンパイルされたコードが含まれていますか？または単に圧縮されたソースコードファイルですか？
- パッケージ名がすべて小文字である理由はありますか？
- パッケージは「循環依存関係」を持つことができますか？言い換えると、Package.AはPackage.Bを使用でき、その逆も可能ですか？
- 誰でもクラスをパッケージ内にあると宣言し、クラス内の別のパッケージを参照することを宣言するための典型的な構文を示すことができます（おそらくusingステートメント？）
Javaのパッケージは、.Netの名前空間に非常に似ています。パッケージの名前は、基本的にその中に存在するクラスへのパスを作成します。このパスは、クラスの名前空間と考えることができます（.Net用語で）これは、使用する特定のクラスの一意の識別子であるためです。たとえば、次の名前のパッケージがある場合：
org.myapp.myProject
そしてその中にはクラスがたくさんありました：
MyClass1
MyClass2
これらのクラスを具体的に参照するには、次を使用します。
org.myapp.myProject.MyClass1
org.myapp.myProject.MyClass2
これと.Net（私が知っている）の唯一の本当の違いは、Javaはその「名前空間」を構造的に編成します（各パッケージは個別のフォルダーです）。 namespaceキーワードは、ドキュメントが実際に存在する場所を無視します。
JARファイルは、ほとんどの場合、DLLと類似しています。これは、7Zipで開くことができます）に依存ファイルとして追加できる他のプロジェクトのソースコードが含まれています。通常、ライブラリはJARに含まれています。
Javaについて覚えておくべきことは、それは非常に構造的であるということです。WHEREファイルのライブは重要です。もちろん、私が投稿したものよりも物語にはもっとあります。
パッケージは.Net名前空間によく似ています。 Javaの一般的な規則は、逆ドメイン名をパッケージプレフィックスとして使用することです。したがって、会社がexample.comの場合、パッケージはおそらく次のようになります。
com.example.projectname.etc...
1つ（プロジェクト名）ではなく、多くのレベルに分割できますが、通常は1つで十分です。
プロジェクト構造の内部では、クラスは通常、コントローラー、モデル、ビューなどの論理領域に分割されます。これはプロジェクトのタイプによって異なります。
Javaには、AntとMavenの2つの主要なビルドシステムがあります。
Antは基本的にドメイン固有のスクリプト言語であり、非常に柔軟性がありますが、多くの定型的なもの（ビルド、デプロイ、テストなどのタスク）を自分で書くことになります。しかし、迅速かつ便利です。
Mavenはよりモダンでより完全であり、使用する価値があります（imho）。 MavenはAntとは異なり、Mavenはこのプロジェクトが「Webアプリケーションプロジェクト」（archetypeと呼ばれる）であることを宣言します。それが宣言されると、groupId（com.example）とartifactId（プロジェクト名）を指定すると、ディレクトリ構造が必須になります。
この方法で無料でたくさんのものを入手できます。 Mavenの本当のボーナスは、pom.xml（Mavenプロジェクトファイル）と正しく構成されたMavenを使用してプロジェクトの依存関係を管理し、それを他の誰か（ソースコード）に渡して、ビルド、デプロイ、テストできることですライブラリを自動的にダウンロードしてプロジェクトを実行します。
AntはIvyでこのようなものを取得します。
以下に、Javaパッケージを開始するための注意事項を示します。
Javaパッケージ名のベストプラクティスは、パッケージの開始として組織のドメイン名を使用することですが、逆に、たとえば会社がドメイン「bobswidgets.com」を所有している場合、 「com.bobswidgets」でパッケージを開始します。
多くの場合、次のレベルはアプリケーションまたはライブラリレベルです。したがって、eコマースライブラリの場合は、「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パッケージは、プロジェクトに疎結合されています。プロジェクトには独自の個別のパッケージ名が付けられることがよくあります。 eコマースの場合はcom.bobswidgets.ecommerce、イントラネットプロジェクトの場合はcom.bobswidgets.intranet。
Jarファイルは、.Javaコードをバイトコードにコンパイルした結果であるクラスファイルをコンテナ化します。これらは、拡張子が.jarの単なるZipファイルです。 Jarファイルのルートは、名前空間階層のルートです。 com.bobswidgets.ecommerceは、Jarファイルでは/ com/bobswidgets/ecommerce /になります。 Jarファイルは、リソースをコンテナ化することもできます。プロパティファイルなど.
パッケージは、互いのパッケージプライベートメソッドおよび変数を参照できるようにするソースファイルのグループです。そのため、クラスのグループは、他のクラスができない相互にアクセスできます。
期待は、すべてのJavaクラスにはそれらを明確にするために使用されるパッケージがあるためです。 jarfile名がわからないため、パッケージのみを使用します。
オブジェクトまたは関数のタイプ別に物事を分類する一般的な慣行がありますが、これについて誰もが同意しているわけではありません。ここに投稿されたCletusと同様に、Webコントローラー、ドメインオブジェクト、サービス、およびデータアクセスオブジェクトを独自のパッケージにグループ化する傾向があります。一部のドメインドリブンデザインの人々は、これは良いことだとは思わないでしょう。通常、パッケージ内のすべてが同じ種類の依存関係を共有するという利点があります（コントローラーはサービスとドメインオブジェクトに依存し、サービスはドメインオブジェクトとデータアクセスオブジェクトに依存するなど）。
わかりましたのでJava 3つの異なるタイプの access がクラスメンバー関数と変数にあります
公共の保護 パッケージプライベート そしてプライベート
同じパッケージ内のすべてのクラスは、public、protected、およびpackage-private要素を相互に見ることができます。
パッケージはシステム内で階層的ではありません。通常、それらは階層的に編成されますが、ランタイムに関する限り、com.example.widgetsはcom.example.widgets.cogsとは完全に異なるパッケージです。
パッケージはディレクトリとして配置されます。これは、物事を整理するのに役立ちます。ファイル構造は常にパッケージ構造に似ています。
彼らはモジュールシステムをJDK7のJava（ Project Jigsaw と呼ばれる））に追加することを計画しており、 OSGi と呼ばれる既存のモジュールシステムがあります。これらのモジュールシステムは、シンプルパッケージシステムよりもはるかに高い柔軟性とパワーを提供します。
また、パッケージ名は通常すべて小文字です。 :)
サブ質問の例に答えるには：
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");
}
}
ウィキペディアから：
Javaパッケージは、Javaクラスを名前空間に編成するためのメカニズムです
そして
Javaパッケージは、JARファイルと呼ばれる圧縮ファイルに保存できます。
したがって、パッケージa.b.cの場合、a、a.b、およびa.b.cパッケージにJavaクラスを含めることができます。一般に、関連する機能を表すクラスは同じパッケージ内でグループ化します。機能的には、同じパッケージのクラスと異なるパッケージのクラスの唯一の違いは、Javaのメンバーのデフォルトアクセスレベルが「パッケージ保護」であるということです。つまり、同じパッケージの他のクラスがアクセスできます。
クラスabcMyClassの場合、プロジェクトでMyClassを使用する場合は、import a.b.c.MyClass、またはあまり推奨されないimport a.b.c.*を使用します。また、MyClassが最初にパッケージabcに存在する場合は、宣言します。 MyClass.Javaの最初の行：package a.b.c;。
これを行うには、パッケージ全体（パッケージbとcおよびクラスMyClassを含む）をJARにして、このJARを$CLASSPATHに入れます。これにより、他のソースコードが使用できるようになります（前述のimportステートメントを使用）。
.JARファイルにはコンパイルされたコードが含まれていますか？または単に圧縮されたソースコードファイルですか？
両方を含む場合もあれば、写真のようなまったく異なる種類のファイルを含む場合もあります。まず、Zipアーカイブです。ほとんどの場合、クラスファイルを含むJAR、およびソースファイルを含むJAR（IDEでデバッグするのに便利）またはjavadoc（ソースコードドキュメント）を含むもの、また、IDEがlibの関数にアクセスするときにドキュメントのツールチップ化をサポートしている場合にも便利です。
パッケージ名がすべて小文字である理由はありますか？
はい、パッケージ名が小文字で書かれているのには十分な理由があります：大文字でクラス名のみが書かれていると言うガイドラインがあります。
パッケージは「循環依存関係」を持つことができますか？言い換えると、Package.AはPackage.Bを使用でき、その逆も可能ですか？
パッケージは互いに使用しません。クラスのみが行います。はい、それは可能かもしれませんが、悪い習慣です。
誰でもクラスをパッケージ内にあると宣言し、クラス内の別のパッケージを参照することを宣言するための典型的な構文を示すことができます（おそらくusingステートメント？）
パッケージJava.utilのArrayListクラスを使用すると仮定します。
import Java.util.ArrayList;
ArrayList myList = new ArrayList();
またはインポートせずに使用します（たとえば、異なるパッケージのArrayListという名前の2つの異なるクラスを使用します）
Java.util.ArrayList myList = new Java.util.ArrayList();
your.package.ArrayList mySecondList = new your.package.ArrayList();
循環依存クラスを機能させるのは簡単ではありませんが、不可能ではないかもしれません。 1つのケースで動作するようになりました。クラスAとクラスBは互いに依存しており、ゼロからコンパイルしません。しかし、クラスAの一部はクラスBを必要とせず、その部分はクラスBが完全にコンパイルするために必要なものであることに気づき、クラスAのその部分、クラスBに不要な部分、およびクラスの残りの部分を削除しましたAはコンパイルでき、それからクラスBをコンパイルできました。それから、クラスBを必要とするクラスAのそのセクションの取り外しを解除し、クラスA全体をコンパイルできました。その後、両方のクラスが正しく機能しました。それは典型的ではありませんが、クラスがこのように結び付けられている場合、それはコーシャであり、時には必要かもしれません。将来の更新のために特別なコンパイル手順を忘れないでください。