私はアプリケーションを構築している最中ですが、プロジェクトの構造を念頭に置いていないと、簡単に新しいパッケージを作成してしまうことに気付きました。
今、私は最初に紙の上でプロジェクト構造全体をやり直そうとしています。プロジェクトの他のいくつかのクラスの設定としてアクセスされる、パブリック プロパティを持つ設定クラスを使用しています。
さて、この設定クラスはプロジェクト全体に適用されるため、パッケージ化する必要があるかどうか、パッケージ化する場合、どのようなパッケージに存在する必要があるかがわかりません。それとも、メイン アプリケーション クラスのルート (既定のパッケージ) に配置する必要がありますか?
utils パッケージに入れることを考えていましたが、実際にはユーティリティではないと思います。たとえば設定クラスのようなパッケージ構造を決定する方法に関する戦略はありますか?
メインを含むクラスであっても、デフォルトパッケージの使用はお勧めできません（Javaでは、私の知る限り、実際には警告として強制されます）。
それ以外はconfig、たとえそれが唯一のクラスであっても、パッケージを持つことを好みます。utilsパッケージに入らないと思います。
私見では、他の多くのクラスがそれに依存しているため、別の低レベルのパッケージに入れる必要がありますが、(おそらく)何にも依存していません。そのため、メイン アプリケーション クラスと一緒に 1 つのパッケージに入れることは絶対に避けてください。ただし、パッケージ内にある場合もあればutils、同じレベルの別のパッケージにある場合もあります (例: config)。
「低レベル」とは、パッケージ B に依存するパッケージ A が B よりも高い「パッケージの依存階層が低い」ことを意味します。したがって、実際のパッケージ階層には直接関係しません。ポイントは、パッケージ間の依存関係のサイクルを回避することです。これにより、パッケージ間でそのような順序付けを行うことができます。
ところで、実際のアプリケーションではルート パッケージを使用しないでください。