クラスに関しては、プライマリ コンストラクターでorキーワードを使用しないdataことは禁止されています。つまり、すべてのパラメーターが暗黙的にクラス プロパティに変換されます。ただし、各パラメーターをクラス プロパティに変換したくない場合があります。varval
したがって、私が見る限り、コンストラクター内でのみアクセス可能で、インスタンスの構築が完了した後に忘れられるパラメーターをプライマリ コンストラクターに渡す可能性はありません。これには正当な理由がありますか？
これを回避する唯一の方法は、クラスを使用しないdataか、非 var/val プレフィックス変数を許可するセカンダリ コンストラクターを使用することです。ただし、渡す必要のあるパラメーターが多数あるため、2 次コンストラクターはクラスを大幅に拡張します。もちろん、すべてのパラメーターを別のオブジェクトにラップすることもできますが、それは問題を別の場所に移すだけです。
それに対処するために推奨されるアプローチやパターンはありますか?
私が言わなければならない最初のことは、これは私の個人的な意見ですので、塩の粒で受け取ることです.
kotlinの公式ドキュメントより
データを保持することを主な目的とするクラスを頻繁に作成します。このようなクラスでは、いくつかの標準機能とユーティリティ関数がデータから機械的に導出できることがよくあります。
そのdata classesため、データ ホルダーとして使用することになっているため、多くのロジックを含めることはできません。
私の観点から、何かをコンストラクターに渡したいが、クラスがそのデータを保存しない場合、おそらくそれに関連するロジックがいくつかあります。
これを行う一般的な状況は次のとおりです。
フラグを使用してコンストラクターの動作を変更する
必要なすべてのデータをラップするクラスを渡し、それを個々のフィールドに抽出します。
data class最初のケースでは、これがユース ケース の一部ではないことが明確にわかります。
そして 2 番目のケースは単に悪いコードです。別のクラスへの不要な依存関係を導入し、そのクラスが実際に必要とするものを隠します。
コンストラクターは単純である必要があり、クラスが必要とするデータを取得してフィールドにバインドし、そこに多くのロジックを配置する必要はなく、コンストラクターを使用してすべてのデータを準備する必要があります。新しいインスタンスを作成するときに繰り返し可能なコードがある場合は、それfactory methodをカプセル化するために使用することをお勧めします。