コンストラクタで「new」を使用するのは常に悪いですか？

コンストラクターで「新しい」を使用すること（単純な値オブジェクト以外のオブジェクト）を使用すると、単体テストが不可能になるため（これらのコラボレーターも作成する必要があり、モックできないため）悪い習慣であると読みました。ユニットテストの経験があまりないため、最初に学習するいくつかのルールを収集しようとしています。また、これは使用されている言語に関係なく、一般的に有効なルールですか？

常に例外があり、タイトルの「常に」に問題がありますが、はい、このガイドラインは一般に有効であり、コンストラクターの外部にも適用されます。

コンストラクターでnewを使用すると、SOLIDのDに違反します（依存関係の反転の原則）。単体テストはすべて分離に関するものであるため、コードのテストが難しくなります。具体的な参照がある場合、クラスを分離するのは困難です。

ただし、単体テストだけではありません。リポジトリを一度に2つの異なるデータベースにポイントする場合はどうなりますか？自分のコンテキストを渡す機能により、異なる場所を指す2つの異なるリポジトリをインスタンス化できます。

コンストラクターでnewを使用しないと、コードがより柔軟になります。これはnew、オブジェクトの初期化以外の構造を使用する言語にも適用されます。

ただし、明確に判断する必要があります。を使用しても問題ない場合newや、使用しないほうが良い場合がたくさんありますが、マイナスの影響はありません。どこかの時点で、new呼ばれる必要があります。new他の多くのクラスが依存しているクラス内での呼び出しには注意してください。

コンストラクターで空のプライベートコレクションを初期化するなどのことは問題ありませんが、それをインジェクトするのはばかげています。

クラスへの参照が多いほど、その中から呼び出さないように注意する必要がありますnew。

他の複数のオブジェクトを作成するのではなく、単に新しいインスタンスを初期化するためにコンストラクターを使用することに賛成していますが、ヘルパーオブジェクトは大丈夫です。

クラスがコレクションを表す場合、内部ヘルパー配列またはリストまたはハッシュセットを持つことができます。newこれらのヘルパーの作成に使用され、非常に正常であると見なされます。このクラスは、異なる内部ヘルパーを使用するためのインジェクションを提供しておらず、理由もありません。この場合、オブジェクトのパブリックメソッドをテストします。これにより、コレクション内の要素の蓄積、削除、および置換が行われます。

ある意味では、プログラミング言語のクラス構造は、より高いレベルの抽象化を作成するためのメカニズムであり、問​​題領域とプログラミング言語プリミティブ間のギャップを埋めるためにこのような抽象化を作成します。ただし、クラスメカニズムは単なるツールです。それはプログラミング言語によって異なり、一部の言語では、一部のドメイン抽象化は、単にプログラミング言語のレベルで複数のオブジェクトを必要とします。

要約すると、抽象化は単に1つ以上の内部/ヘルパーオブジェクトを必要とするが、呼び出し元からはまだ単一の抽象化として認識されているのか、または他のオブジェクトは依存関係の制御。これは、たとえば、呼び出し元がクラスを使用してこれらの他のオブジェクトを見たときに提案されます。

すべてのコラボレーターが個別に単体テストを行うほど面白いわけではないため、ホスティング/インスタンス化クラスを介して（間接的に）テストできます。これは、特にテストを行うときに、各クラス、各パブリックメソッドなどをテストする必要があるという一部の人々の考えと一致しない場合があります。TDDを使用する場合、この「コラボレーター」をリファクタリングして、最初のテストプロセスで既に完全にテストされているクラスを抽出できます。

ユニットテストの経験があまりないため、最初に学習するいくつかのルールを収集しようとしています。

遭遇したことのない問題の「ルール」を注意深く学習してください。「ルール」または「ベストプラクティス」に出くわした場合、このルールが使用される「想定」の場所の簡単なおもちゃの例を見つけ、「ルール」が言っていることを無視して自分でその問題を解決しようとすることをお勧めします。

この場合、2つまたは3つの単純なクラスと、それらが実装すべきいくつかの動作を考え出すことができます。自然に感じる方法でクラスを実装し、各動作の単体テストを作成します。発生した問題のリストを作成します。たとえば、一方向に機能することから始めた場合、後で戻って変更する必要がありました。物事がどのように組み合わされるべきかについて混乱した場合; 定型文の作成に悩まされた場合; 等

次に、「ルール」に従って同じ問題を解決してください。繰り返しますが、発生した問題のリストを作成します。リストを比較し、ルールに従うときはどの状況が良いのか、そうではないのかを考えます。

あなたの実際の質問に関しては、「コアロジック」と「サービス」を区別するポートとアダプターのアプローチを好む傾向があります（これは純粋な関数と効果的な手順を区別することに似ています）。

コアロジックとは、問題の領域に基づいて、アプリケーションの「内部」で計算することです。それはのようなクラスが含まれている場合がありますUser、Document、Order、Invoiceコアクラスを呼び出す持っている、などのそれの罰金をnew彼らだ「内部」実装の詳細以来、他のコアクラスのために。たとえば、をOrder作成するInvoiceと、Documentを作成し、注文したものの詳細を作成することもできます。これらはテストしたい実際のものなので、テスト中にこれらをモックする必要はありません！

ポートとアダプターは、コアロジックが外界と相互作用する方法です。物事が好きな場所ですDatabase、ConfigFile、EmailSender、などに住んでいます。これらはテストを困難にするものなので、これらをコアロジックの外部で作成し、必要に応じて（依存性注入またはメソッド引数などとして）渡すことをお勧めします。

これにより、データベース、ファイル、電子メールなどを気にすることなく、コアロジック（重要なビジネスロジックが存在し、最も解約されるアプリケーション固有の部分）を単独でテストできます。いくつかのサンプル値を渡すだけで、正しい出力値が得られることを確認できます。

ポートとアダプターは、データベース、ファイルシステムなどのモックを使用して、ビジネスロジックを気にせずに個別にテストできます。いくつかのサンプル値を渡すだけで、それらが保存/読み取り/送信/などされていることを確認できます。適切に。

ここで重要なポイントと思われるものを集めて、質問に答えさせてください。簡潔にするためにユーザーを引用します。

常に例外がありますが、はい、このルールは一般に有効であり、コンストラクターの外部にも適用されます。

コンストラクタで新しい使用する違反DでSOLID（依存反転プリンシパル）。単体テストはすべて分離に関するものであるため、コードのテストが難しくなります。具体的な参照がある場合、クラスを分離するのは困難です。

-TheCatWhisperer-

はい、new内部コンストラクターを使用すると、多くの場合、設計の欠陥（たとえば、密結合）が発生し、設計が硬直します。はい、テストするのは難しいですが、不可能ではありません。ここでの役割は、弾力性（変化に対する耐性）¹です。

それにもかかわらず、上記の引用は常に真実とは限りません。場合によっては、密結合することを意図したクラスが存在する可能性があります。デビッド・アーノはいくつかコメントしています。

もちろん、クラスが不変の値 オブジェクト、実装の詳細などである場合、例外があります。それらが密結合されることになっている場合です。

-デビッドアルノ-

まさに。一部のクラス（内部クラスなど）は、メインクラスの単なる実装の詳細である可能性があります。これらはメインクラスと一緒にテストされることを意図しており、必ずしも交換または拡張可能ではありません。

さらに、SOLIDカルトがこれらのクラスを抽出させる場合、別の良い原則に違反している可能性があります。いわゆるデメテルの法則。一方で、これは設計の観点から非常に重要だと思います。

したがって、ありそうな答えは、いつものように異なります。内部コンストラクタを使用newするのは悪い習慣です。しかし、常に体系的にではありません。

そのため、クラスがメインクラスの実装の詳細（ほとんどの場合はそうではない）であるかどうかを評価する必要があります。それらがあれば、放っておいてください。そうでない場合は、IoC ContainersによるComposition RootまたはDependency Injectionなどの手法を検討してください。

^{1：SOLIDの主な目標は、コードのテスト性を高めることではありません。コードの変更に対する耐性を高めるためです。より柔軟で、結果として、テストが容易}

^{注： TheWhisperCat、David Arno、私が引用したことを気にしないでください。}

簡単な例として、次の擬似コードを考えます

class Foo {
  private:
     class Bar {}
     class Baz inherits Bar {}
     Bar myBar
  public:
     Foo(bool useBaz) { if (useBaz) myBar = new Baz else myBar = new Bar; }
}

ためnewの純粋な実装の詳細でありFoo、そして両方Foo::BarとFoo::Bazの一部であるFoo、のときにユニットテストFoo存在は、モック部分にはポイントがありませんFoo。単体テストの場合は、外部 の部品のみをモックしFooますFoo。

はい、アプリケーションのルートクラスで「新規」を使用するのはコードのにおいです。これは、特定の実装を使用してクラスをロックすることを意味し、別のクラスを置き換えることはできません。依存関係をコンストラクターに注入することを常に選択します。そうすることで、テスト中にモックされた依存関係を簡単に注入できるだけでなく、必要に応じて異なる実装をすばやく置き換えることができるため、アプリケーションの柔軟性が大幅に向上します。

EDIT：downvotersについて-ここでの可能なコードのにおいとして「新しい」低迷ソフトウェア開発帳へのリンクだ：https://books.google.com/books?id=18SuDgAAQBAJ&lpg=PT169&dq=new%20keyword%20code%20smell&pg=PT169 ＃v = onepage＆q = new％20keyword％20code％20smell＆f = false