3

APIを設計しています。同じことを行う多くのメソッドがありますが、パラメータープリミティブが異なります。

public void someMethod1(int x);
public void someMethod1(float x);
public void someMethod1(double x);
public void someMethod2(int x, int y);
...
public void someMethod3(int x, int y, int z);
...

プリミティブのせいで、たくさんコピー＆ペーストする必要がありますが、これは時間の経過とともにかなり維持できないと思います。メソッドとコンストラクターでプリミティブを避けるのは良い考えですか？たとえば、上記の置き換えは次のようになります。

public <T extends Number> void someMethod1(T x);
public <T extends Number> void someMethod2(T x, T y);
public <T extends Number> void someMethod3(T x, T y, T z);

編集：

これの欠点は何ですか？

4

4 に答える 4

4

Java 1.5以降では自動ボックス化/自動アンボックス化が行われるため、使用可能になります。intを期待するものに渡すかInteger、またはその逆を行うことができ、キャストは自動的に行われます。同じことが戻り値にも当てはまります。

メソッドの本体では、引数が何らかの形式であるということよりも、引数についてほとんど知らないことに注意してくださいNumber。これは、整数表現と浮動小数点表現を区別する必要がない場合にのみ適しています。

パフォーマンスが向上することはありません。キャストにはわずかなペナルティがありますが、ボトルネックがあることに気付くまで心配する必要はありません。ほとんどのアプリケーションでは、違いは重要ではありません。

List配列ではなく配列を使用するかどうかは、実際には設計によって決定するList必要がありますが、配列が必ずしも必要でない限り、通常は配列を使用することをお勧めします。 Listsはより柔軟になる傾向があり、サイズを変更する必要がなく、CollectionsAPIのすべての利点を備えています。

于 2010-03-07T18:28:43.730 に答える
2

List<T>対についての質問に答えるためにT[]、両方とも実装に関する詳細を公開します。

List<T>T[]クライアントコードを変更せずにリストの実装を変更できるため、より保守しやすくなります。

リストをクライアントコードで変更しない場合はIterable<T>、実装の詳細について何も公開せず、反復以外の操作を防ぐため、より適切です。

于 2010-03-07T18:35:06.550 に答える
1

APIはセマンティクスに関するものなので、前述の質問に対する答えは（API設計でプリミティブを避けるべきか）、APIの機能に依存するということだと思います。

int addOne(int integer)意味的に一貫性があり、問題のドメインを反映しているため、メンテナンスに関する多くの問題は発生しません。

Employee getEmployee(int empID)不適切として分類される可能性があり、従業員IDが文字列などに変更された場合にメンテナンスの問題が発生します。

于 2010-03-07T18:32:37.303 に答える
1

これは有効なパターンであり、model-view-controllerシステムでプロパティを定義するために使用されることがあります。さらに、-128〜127の範囲のintを使用する場合、を使用して変換すると、Javaによって自動キャッシュされます。これにより、作成Integer.valueOf(int)に関して少しスピードアップできます。常に少なくとも127でIntegerあるプロパティを使用して、キャッシュ範囲を増やすこともできます。自動ボクシングでもこの整数キャッシュが使用される場合もありますが、よくわかりません。java.lang.Integer.IntegerCache.highクラスが高性能環境で使用するように設計されている場合は、代わりに他の代替案を検討し、プリミティブを使用します。

于 2010-03-07T18:55:58.470 に答える