私は最近、クラスでこのコンストラクターを見ました:
public MyClass(){ }
他のコンストラクターはありませんでした。
これには理由がありますか?Java はデフォルトのコンストラクターを自動的に作成するのに、なぜそれを明示的に宣言するのでしょうか? それとも、単一ステートメントの if ステートメントに中括弧を使用するのと同じように、これは良い習慣と見なされますか?後で他のコンストラクターが追加され、デフォルトがないことを忘れた場合に備えて...?
私は最近、クラスでこのコンストラクターを見ました:
public MyClass(){ }
他のコンストラクターはありませんでした。
これには理由がありますか?Java はデフォルトのコンストラクターを自動的に作成するのに、なぜそれを明示的に宣言するのでしょうか? それとも、単一ステートメントの if ステートメントに中括弧を使用するのと同じように、これは良い習慣と見なされますか?後で他のコンストラクターが追加され、デフォルトがないことを忘れた場合に備えて...?
この場合、あなたがそれを見た理由である可能性が低いいくつかのマイナーなポイント.
「後で他のコンストラクターが追加され、デフォルトがないことを忘れた場合」の限り、それが理由かもしれません。ただし、デフォルト以外のコンストラクターが追加された場合、デフォルトのコンストラクターを使用したコードはコンパイルに失敗するため、新しいコンストラクターを追加する人は通常、デフォルトの ctor の定義も追加する必要があります。
繰り返しになりますが、空の ctor を定義することによる特に害は考えられません (ただし、これを入力したので、誰かが C++ のどこかを指摘する可能性があるのではないかと思います)。
何の役割も果たさず、安全に削除できます。
コンストラクターを技術レベルで明示的に追加しても何も得られませんが、それを行う理由が考えられます。1 つは、クラスがリフレクションによってインスタンス化されている場合、新しいコンストラクターを追加してもコンパイル エラーが発生しない場合でも、デフォルト コンストラクターが必要であることを示すために、既定のコンストラクターにドキュメントを配置することです。
もう 1 つは、このクラスが持つべきコンストラクターの種類を明示的に示すために、一部のコーディング標準がそれを好むことです。
Java言語仕様の内容は次のとおりです。
クラスにコンストラクター宣言が含まれていない場合、パラメーターを取らないデフォルトのコンストラクターが自動的に提供されます。
- 宣言されているクラスが基本クラスの Object である場合、デフォルトのコンストラクターは空の本体を持ちます。
- それ以外の場合、デフォルトのコンストラクターはパラメーターをとらず、単に引数なしでスーパークラス コンストラクターを呼び出します。
とにかく、デフォルトのコンストラクターが作成されます。そうしないと書いても意味がありません。した方が良い。
IMOコンストラクターの可視性レベルを変更する場合、つまりプライベートにするか、パッケージを保護する場合にのみ行う必要があります
あなたは python の禅の2 番目の文を信じているからです。
明示的は暗黙的よりも優れています。
私が間違っている場合は訂正してください (私はしばらく Java を行っていません)。しかし、これは親コンストラクターへの呼び出しを妨げませんか? その場合、理由は明らかに、このクラスで発生したくないことを親が自動的に実行しようとしているということです。
Java Bean 仕様では、パブリックのデフォルト コンストラクターが必要であると教えられました。ウィキペディアのページhttp://en.wikipedia.org/wiki/Java_Beanにも、要件として記載されています。
一方で、Sun/Oracle のサイトを見てみましたが、それについての言及は見つかりませんでした。http://java.sun.com/developer/onlineTraining/Beans/Beans1/simple-definition.htmlを参照してください。
実際には、これらの回答に記載されていないものを含める正当な理由があります。
引数のないコンストラクターの存在がオブジェクトのコントラクトの明示的な一部である場合は、明示的に宣言する必要があります。
Java Swing などのように、クライアントがコードをサブクラス化することを明示的に意図している場合は、他のコンストラクターがなくても、アクセス可能な引数なしのコンストラクターを明示的に作成することをお勧めします。それ以外の場合、別のプログラマーが賢明に別のコンストラクターを作成することを決定した場合、新しい明示的なコンストラクターは暗黙的な引数なしのコンストラクターを削除し、クライアント コードを壊します。
コードが独自のコード ベースでサブクラス化されている場合、これはコンパイラ エラーとして表示されますが、コードが jar として公開され、クライアントによってサブクラス化される場合、コンパイラ エラーは発生しません。
もちろん、それが契約の一部である場合、そのためのjunitテストが必要であると主張することができ、あなたは正しいでしょう! しかし、毎日のビルドでテストを実行するのに何時間もかかる大規模なコード ベースで作業している場合、明示的なコンストラクターを追加するときに引数なしのコンストラクターを明示的に作成する必要があることを忘れていたため、毎日のビルドが壊れてしまいます。コメントは、エラーの可能性を回避できたでしょう。
良いコードの目標は、他の開発者が間違いなくコードをできるだけ簡単に変更できるようにすることです!