BigDecimalが別のものよりも大きいかどうかを知る現在の方法は次のとおりです。
_bigDecimal.compareTo(otherBigDecimal) > 0
_
(またはone.compareTo(another) == 1
)ですが、あまりにも不格好で表現力がありません。 bigDecimal.isGreaterThan(otherBigDecimal)
は理解しやすいです。
Javaに慣れていて、compareTo()
がどのように機能するかを知っている人にとっては、現在の方法が理にかなっています。OOプログラミングの経験がある人にとっては) Java以外では、この操作でマジックナンバーが何のためにあるのかを理解するためにAPIを調べる必要があると思います。
GuavaまたはApacheのNumberUtilsでこれを修正する試みは見られず、すでにJava 9に到達しようとしています。
Gistで私が求めているのは、BigDecimalsを比較するこの不格好な方法がやり直されていない正当な理由はありますか? (「Javaで修正することがたくさんあることを除いて、これは優先事項ではありません。」)
実際は別として:
Javaで修正することはたくさんありますが、これは優先事項ではありません。
もう1つあります。 isGreaterThan
がある場合は、isLesserThan
も必要になることを意味します。これはyourのニーズを解決しますが、isSuperiorTo
とisInferiorTo
を検索する開発者のニーズは解決しません。オートコンプリートで対応するメソッドが表示されない場合はがっかりします。
さらに重要なことに、compareTo
で何をしますか?削除しますか?はいの場合、これは、このメソッドを使用する以前に記述されたコードallを壊します。それを維持すると、2つの冗長な方法と、アクションを実行する2つの異なる方法があり、フォーラムスレッドがあり、これら2つのアプローチのどちらが優れているかを人々が議論します。
別のアプローチは、enum
を使用することです。
_bigDecimal.compareTo(otherBigDecimal) == Comparison.firstIsBigger;
_
ただし、この変更には下位互換性もありません。
非常によく似た問題がJUnitスタイルのライブラリに関係しています。アサーションヘルパーをどんどん含めるか、インターフェイスを軽くして ユーザーにお気に入りのメソッドが実装されなかった理由を尋ねさせる のどちらかを常に選択できます。基本的に、ユニットテストフレームワークにはassert(something)
のみを含める必要があります。他のヘルパーも便利ですが、すべてのユーザーのすべてのニーズに対応しようとすると、フレームワークは何千ものメソッドで終了し、それは使用できなくなります。