静的関数とクラス

BigDecimals を使用していくつかの基本的な計算を行うためのユーティリティ関数を構築したいとします。たとえば、の平均を計算する関数が必要ですList<BigDecimal>。

最善のアプローチは何ですか？静的関数またはユーティリティクラス？

public static BigDecimal computeAverage(List<BigDecimal> numbers)

または

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

おそらく最悪の方法で私のC＃学習を提供するつもりですが、ユーティリティクラス内の静的メソッドを常に推奨します。これにより、両方の長所が得られます。オブジェクトをインスタンス化して使用する必要なくアクセスできるメソッドの使いやすさを備えた、クラスの組織的な利点。ユーティリティクラスに時々その動作を変更する理由がある場合は、必要に応じて後で継承/インターフェイスを導入することで、そのようにすることができます。デザインをもう少し移植しやすくしたい場合は、パラダイムが他のオブジェクト指向言語に簡単に移行できることがわかります。

何らかのテーマで接続されたユーティリティ関数を実行したい場合は、それらのクラスを作成し、それらをそのクラスで静的にし、そのクラスのコンストラクターをプライベートにして、誤ってインスタンスを与える可能性を排除します。したがって、2番目のバリアントを使用しますが、コンストラクターは非表示にします。

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

private BigDecimalUtil(){super();}

もう1つの可能性があります。コンストラクタを作成せずに、このクラスを抽象化することです。ただし、この方法では、クラスのインスタンスを外部だけでなく内部でも使用できません。したがって、この2番目のバリアントは厳しすぎると思います。あなた自身を選択してください。

私は@Gangnusに同意します。静的な「ラッパー」クラスは、個々のクラスメソッドが常に分離して使用される場合に意味があり、これはしばしば良い答えになるでしょう。

ただし、関連する計算が一緒に使用される可能性が高い場合は、非静的メソッドを使用して、非静的クラスに何らかの値がある可能性があります。例えば、構築ListStatsUtilしたオブジェクトをList<BigDecimal>コンストラクタに渡され、それがアクセスに便利かもしれないgetStandardDeviation、getVarianceと、getAverageオブジェクト内の背面を通過せずに順番に。これはより洗練されているかもしれませんが、特にオブジェクト内のプライベート状態を共有することによって操作全体で最適化できる計算コストの高い操作が含まれる場合は、パフォーマンスが向上する可能性があります。

public ListStatsUtil {
    private final List<BigDecimal> numbers;
    public ListStatsUtil(List<BigDecimal> numbers) {
        this.numbers = numbers;
    }
    public BigDecimal getAverage() {
        // return average of this.numbers
    }
    public BigDecimal getStandardDeviation() {
        // return std dev of this.numbers
    }
    public BigDecimal getVariance() {
        // return variance of this.numbers
    }
    public BigDecimal getMax() {
        // return max of this.numbers
    }
    public BigDecimal getMin() {
        // return min of this.numbers
    }
}

私はコーディングアウトラウドの回答に投票しましたが、少し拡張したいと思います。

クラスでコレクションをラッピングすることは、私がいつもやろうとしていることです。私のルールは、「ネイキッドコレクションを絶対に通過させないこと」です。私が見たOOの最大の失敗は、所属するメソッドを追加することを人々が恐れている場合です。あなたの場合、メソッドはコレクションに属します（考えれば明らかですが）、それらをコレクションにラップしてそこに配置し、アイシングをケーキに配置するには、必要な機能のみを新しいクラスの外部に公開します（codingoutloudとして）そうしたので、あなたはあなたの単一の小さなクラスを見て、そのコレクションを操作するすべてのものを簡単に理解することができます。

すべてのコードであるため、考えられるすべての問題を解決する必要はありません。コレクションラッパーは、それとやり取りする他のクラスを編集するのと同じくらい簡単に編集できます。これにより、必要に応じて他のコードをクラスに取り込むことができます。コレクションを公開しないと、ラッパーに属するコードがすぐにわかります。

これにより、コレクションを完全に制御できるため、コレクションの機能と矛盾する状態になるのを防ぐことができます（たとえば、コレクションのエントリがnullになり得ない場合は、誰かがnullを入力できないようにするだけです！）

私が今まで見た悪いOOコードのほとんどは、変更可能な独自のコードで問題のオブジェクトをラップするのではなく、コードを追加できないオブジェクトに属する静的ユーティリティまたはインラインコードを作成することを選択したために作成されました。

私が間違っておらず、Javaが純粋なOO言語であり続けるなら、クラスでそれらをラップせずに関数を作成することはできません。

だからあなたの答えは：Mathクラスとは異なり、どちらも静的ユーティリティクラスにラップされた静的関数です。

注入されたCalcAverageStrategyインターフェースはどうでしょうか。そうすれば、必要に応じて平均/中央値/モードの実装を注入できます。

各実装はテストが簡単で、テスト用にモックするのも簡単です。