init（）メソッドはコード臭いですか？

init()型のメソッドを宣言する目的はありますか？

私はコンストラクタよりも優先init()すべきかどうか、または宣言を避ける方法をinit()尋ねていません。

メソッドを宣言する背後に何らかの理由があるのかinit()（それがどれほど一般的かを見て）、それがコードのにおいであり、避けるべきかどうかを尋ねています。

init()イディオムは非常に一般的ですが、私は、任意の真のメリットを見ていません。

メソッドによる初期化を促進する型について話している：

class Demo {
    public void init() {
        //...
    }
}

これはいつプロダクションコードで使用されますか？

コンストラクターがオブジェクトを完全に初期化せず、部分的に作成されたオブジェクトを生成することを示唆しているため、コードの匂いがするかもしれません。状態が設定されていない場合、オブジェクトは存在しないはずです。

これは、エンタープライズアプリケーションの意味で、生産をスピードアップするために使用されるある種の手法の一部である可能性があると信じさせてくれます。それは私がそのようなイディオムを持つことを考えることができる唯一の論理的な理由です。

はい、それはコード臭です。コードのにおいは、必ずしも常に削除する必要があるものではありません。それはあなたが再確認するものです。

ここには、根本的に異なる2つの状態のオブジェクトがあります：pre-initとpost-init。これらの状態には、異なる責任、呼び出せるメソッド、および異なる動作があります。事実上、2つの異なるクラスです。

それらを物理的に2つの別々のクラスにすると、潜在的なバグのクラス全体を静的に削除しますが、その代償として、モデルを「現実世界のモデル」とかなり厳密に一致させません。通常、最初の名前ConfigまたはSetupそのような名前を付けます。

そのため、次回は、construct-initイディオムを2クラスモデルにリファクタリングして、それがどのようになるかを確認してください。

場合によります。

init方法は、コンストラクタから分離オブジェクトの初期化が必要ない場合にコードのにおいです。これらの手順を分離することが理にかなっている場合があります。

簡単なGoogle検索でこの例を見つけました。オブジェクトの割り当て中に実行されるコード（コンストラクター）が初期化自体からより適切に分離される可能性のあるケースを簡単に想像できます。多分あなたはレベル化されたシステムを持っており、割り当て/構築はレベルXで行われますが、初期化はレベルYでのみです。Yだけが必要なパラメータを提供できるからです。「init」はコストがかかり、割り当てられたオブジェクトのサブセットに対してのみ実行する必要があり、そのサブセットの決定はレベルYでのみ実行できます。または、派生オブジェクトの（仮想）「init」メソッドをオーバーライドする場合コンストラクターでは実行できないクラス。レベルXは、継承ツリーから割り当てられたオブジェクトを提供するかもしれませんが、レベルYは、具体的な派生を認識せず、共通のインターフェース（ここで、init 多分定義されます）。

もちろん、私の経験では、これらのケースは、コンストラクターですべての初期化を直接行うことができる標準ケースのごく一部であり、別のinitメソッドを見るときはいつでも、その必要性を疑問視するのは良い考えです。

私の経験は2つのグループに分けられます。

1. init（）が実際に必要なコード。これは、スーパークラスまたはフレームワークが、クラスのコンストラクターが構築中にすべての依存関係を取得することを妨げる場合に発生する可能性があります。
2. init（）が使用されているが、回避できたコード。

私の個人的な経験では、（1）のいくつかのインスタンスだけを見ましたが、（2）の多くのインスタンスを見ました。その結果、私は通常init（）がコード臭であると仮定しますが、これは常にそうではありません。時々あなたはそれを回避することができないだけです。

多くの場合、Builderパターンを使用すると、init（）の必要性/欲求を取り除くことができます。

Initメソッドが役立つ典型的なシナリオは、変更する構成ファイルがあり、アプリケーションを再起動せずに変更を反映させる場合です。もちろん、これはInitメソッドをコンストラクターとは別に呼び出さなければならないという意味ではありません。コンストラクターからInitメソッドを呼び出してから、構成パラメーターが変更されたときに/後で呼び出します。

要約すると、世の中のほとんどのジレンマについては、これがコードのにおいであるかどうかは、状況と状況に依存します。

それらの使用方法に依存します。

ヒープ上のオブジェクトの再割り当てを続けたくない場合（ビデオゲームを作成してパフォーマンスを高く保つ必要がある場合、ガベージコレクターがパフォーマンスを低下させる場合など）、Java / C＃などのガベージコレクション言語でそのパターンを使用します。コンストラクタを使用して、必要な他のヒープ割り当てinitを作成し、再利用するたびに基本的な有用な状態を作成します。これは、オブジェクトプールの概念に関連しています。

また、初期化命令の共通サブセットを共有する複数のコンストラクターがある場合にも役立ちますが、その場合initはプライベートになります。そうすれば、各コンストラクターを可能な限り最小化できるため、各コンストラクターには固有の命令とinit残りを実行するための単一の呼び出しのみが含まれます。

ただし一般的には、コードのにおいです。

init()メソッドは、他のオブジェクトが同時に使用する外部リソース（ネットワーク接続など）を必要とするオブジェクトがある場合に、かなり意味があります。オブジェクトの存続期間中、リソースを独占する必要はないかもしれません。このような状況では、リソースの割り当てが失敗する可能性が高い場合、コンストラクターでリソースを割り当てたくない場合があります。

特に組み込みプログラミングでは、確定的なメモリフットプリントが必要なので、コンストラクタを早期に（おそらく静的に）呼び出し、特定の条件が満たされた後にのみ初期化するのが一般的です（良い？）

そのような場合を除いて、私はすべてがコンストラクターに入るべきだと思います。

一般に、機能的なインスタンスに必要なすべての引数を受け取るコンストラクタを好みます。これにより、そのオブジェクトのすべての依存関係が明確になります。

一方、パラメーターなしのパブリックコンストラクターと、依存関係と構成値を注入するためのインターフェイスを必要とする単純な構成フレームワークを使用します。それが完了すると、構成フレームワークはinitオブジェクトのメソッドを呼び出します。これで、私があなたのために持っているすべてのものを受け取ったので、作業の準備をするために最後のステップを実行します。ただし、注意してください：initメソッドを自動的に呼び出すのは構成フレームワークです。そのため、忘れずに呼び出すことができます。

init（）メソッドがオブジェクトの状態ライフサイクルに意味的に埋め込まれている場合、コードの匂いはありません。

オブジェクトを一貫した状態にするためにinit（）を呼び出す必要がある場合、それはコード臭です。

このような構造が存在する技術的な理由はいくつかあります。

1. フレームワークフック
2. オブジェクトを初期状態にリセットする（冗長性を回避する）
3. テスト中にオーバーライドする可能性

initという名前は不透明な場合があります。車とエンジンを取りましょう。車を起動するには（電源を入れるだけで、ラジオを聞く）、すべてのシステムが準備ができていることを確認します。

したがって、エンジン、ドア、ホイールなどを構築します。画面にはengine = offと表示されます。

これらはすべて高価なので、エンジンなどの監視を開始する必要はありません。次に、キーを回して点火すると、engine-> startを呼び出します。すべての高価なプロセスの実行を開始します。

エンジンがオンになっています。そして点火のプロセスが始まります。

エンジンが利用可能でなければ、車はパワーアップしません。

エンジンを複雑な計算に置き換えることができます。Excelセルのよう。すべてのセルが常にすべてのイベントハンドラーでアクティブである必要はありません。セルに注目すると、セルを開始できます。そのようにしてパフォーマンスを向上させます。