0

この質問は何度か聞かれたことは承知していますが、ここで取り組んでいる特定の例でそれを組み立てたかったのです。メッシュ上で動作する有限要素コードに取り組んでいます。メッシュは論理的にはオブジェクトであり、「構築」または構築されるまで何もできません。メッシュ パラメータをコンストラクタに渡し、コンストラクタにメッシュを構築させるのは理にかなっているようです。Web を検索すると、これは必ずしも良い考えではなく、コンストラクターはできる限り少ないことを行うべきであるという一般的な意見が見られます。

メッシュの生成は、長く複雑なプロセスになる場合があります。一方、メッシュは生成されるまで完全に使用できません。これは、その構成と見なされます。クライアントが呼び出すメソッドとして各ステップをマップすることもできますが、これらのメソッドは常に同じであり、常に同じパラメーターを使用します。内部が変更されたとしても、パブリック インターフェイスが変更される可能性は非常に低いです。さらに、クライアントがメッシュ生成の詳細に関心を持つべきではないことはおそらく理にかなっています。それを念頭に置いて、メッシュをコンストラクターで完全に生成し、その後すぐに使用できる状態にすることは理にかなっているようです。クライアントに対して不透明な単純な生成メソッドを作成することもできますが、コンストラクターで同じことができないのはなぜでしょうか? 使用可能でなければなりません。

このようなものをコンストラクターに入れる際に注意すべき隠れた危険はありますか?

4

2 に答える 2

1

コンストラクターは、後でメソッド内で使用される「必須の」ビルディング ブロックまたは要素を構築する必要があります。メソッドの大部分がメッシュで機能する場合は、コンストラクターを使用してメッシュを生成します。一方、ほとんどのメソッドがメッシュよりも小さい要素で機能する場合は、コンストラクターの下にラップしないでください。

于 2012-05-16T14:36:43.737 に答える
1

あなたが言及していない別の可能性は、高価な操作を遅延して実行することです。つまり、その結果が初めて必要になるときです。

これにより、オブジェクトの構築を安価に保ち、余分なメソッドを呼び出すことでクライアントに負担をかけず、オブジェクトが使用されない場合の高価な操作を完全に回避できます。

主な欠点は、特にマルチスレッドのコンテキストで、複雑さがわずかに増加することです。

于 2012-05-16T14:28:09.227 に答える