Hàm tĩnh so với các lớp

Giả sử tôi muốn xây dựng một số hàm tiện ích để thực hiện một số phép toán cơ bản với BigDecimals, ví dụ tôi muốn có một hàm tính trung bình của a List<BigDecimal>.

Đâu là cách tiếp cận lí tưởng nhất? Một hàm tĩnh hoặc một lớp tiện ích?

public static BigDecimal computeAverage(List<BigDecimal> numbers)

hoặc là

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

Có lẽ tôi sẽ cho đi những phần C # của mình theo cách tồi tệ nhất có thể, nhưng tôi luôn đề xuất các phương thức tĩnh trong các lớp tiện ích. Điều này cung cấp cho bạn tốt nhất của cả hai thế giới. Các lợi ích tổ chức của lớp với khả năng sử dụng các phương thức được truy cập mà không cần khởi tạo một đối tượng để sử dụng chúng. Nếu lớp tiện ích của bạn có lý do để thỉnh thoảng thay đổi hành vi của nó, thì bạn đã có vị trí tốt để làm điều đó bằng cách giới thiệu kế thừa / giao diện sau này nếu bạn cần. Nếu bạn muốn thiết kế của mình dễ di chuyển hơn một chút, thì bạn sẽ thấy mô hình sẽ dễ dàng chuyển sang các ngôn ngữ OO khác.

Nếu bạn muốn thực hiện các chức năng tiện ích, được kết nối bởi một số chủ đề, tạo một lớp cho chúng, làm cho chúng tĩnh trong lớp đó và tạo một hàm tạo của lớp đó thành riêng tư, để loại bỏ khả năng vô tình đưa ra một thể hiện. Vì vậy, sử dụng biến thể thứ hai, nhưng ẩn hàm tạo.

public class BigDecimalUtil

public computeAverage(List<BigDecimal> numbers)

private BigDecimalUtil(){super();}

Có một khả năng nữa - để không tạo constructor và làm cho lớp này trừu tượng. Nhưng theo cách này, bạn không thể sử dụng thể hiện của lớp không chỉ bên ngoài mà cả bên trong nó. Vì vậy, tôi nghĩ rằng, biến thể thứ hai này là quá nghiêm ngặt đối với bạn. Chọn chính mình.

Tôi đồng ý với @Gangnus rằng một lớp "bao bọc" tĩnh có ý nghĩa nếu các phương thức lớp riêng lẻ sẽ luôn được sử dụng một cách cô lập và điều này thường sẽ là một câu trả lời tốt.

Tuy nhiên, có thể có một số giá trị trong một lớp không tĩnh, với các phương thức không tĩnh, nếu bạn có các phép tính liên quan có khả năng được sử dụng cùng nhau. Ví dụ, xây dựng một ListStatsUtilđối tượng với List<BigDecimal>truyền vào constructor, nó có thể là thuận tiện để truy cập getStandardDeviation, getVariancevà getAveragetheo thứ tự mà không đi lại trong đối tượng. Điều này có thể thanh lịch hơn, nhưng cũng có thể hoạt động tốt hơn, đặc biệt là nếu các hoạt động đắt tiền được tính toán có thể được tối ưu hóa trong các hoạt động bằng cách chia sẻ trạng thái riêng tư trong đối tượng.

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
    }
}

Tôi đã bình chọn cho câu trả lời về tiền mã hóa và tôi muốn mở rộng thêm một chút.

Gói các bộ sưu tập trong các lớp học là điều tôi luôn cố gắng thực hiện - quy tắc của tôi là "Không bao giờ vượt qua bộ sưu tập trần trụi". Thất bại lớn nhất của OO tôi từng thấy là khi mọi người sợ thêm phương thức nơi họ thuộc về. Trong trường hợp của bạn, các phương thức thuộc về bộ sưu tập (Hoàn toàn rõ ràng nếu bạn nghĩ về nó), vì vậy hãy đặt chúng ở đó bằng cách gói bộ sưu tập và để đóng băng trên bánh, chỉ hiển thị chức năng bạn cần bên ngoài lớp mới của bạn (như mã hóa đã làm) để bạn có thể nhìn vào lớp học nhỏ, đơn lẻ của mình và dễ dàng hiểu mọi thứ thao túng bộ sưu tập đó.

Bạn không phải giải quyết mọi vấn đề có thể xảy ra vì đó là tất cả mã của bạn, bạn có thể chỉnh sửa trình bao bọc bộ sưu tập dễ dàng như bạn có thể chỉnh sửa các lớp khác tương tác với nó. Điều này cho phép bạn kéo mã khác vào lớp khi cần thiết - nếu bạn không bao giờ để lộ bộ sưu tập, nó sẽ nhanh chóng trở nên rõ ràng mã nào thuộc về trình bao bọc.

Điều này cũng cung cấp cho bạn toàn quyền kiểm soát bộ sưu tập để bạn có thể ngăn không cho nó vào trạng thái không phù hợp với chức năng của nó (Ví dụ: nếu không có mục nào trong bộ sưu tập có thể là null, chỉ cần ngăn không cho bất kỳ ai đưa null vào!)

Hầu hết các mã OO xấu mà tôi từng thấy đã được tạo bởi vì ai đó đã chọn viết các tiện ích tĩnh hoặc mã nội tuyến thuộc về các đối tượng mà họ không thể thêm mã vào thay vì bọc các đối tượng vi phạm bằng mã của riêng họ mà họ có thể sửa đổi .

Nếu tôi không sai và các ngôn ngữ Java là ngôn ngữ OO thuần túy, bạn không thể có các hàm mà không bao bọc chúng trong một lớp.

Vì vậy, câu trả lời của bạn là: cả hai, một hàm tĩnh được bọc trong một lớp tiện ích tĩnh, không giống như lớp Toán.

Làm thế nào về một giao diện CalcAlusiveStrargety được tiêm, và sau đó bạn có thể có các cài đặt trung bình / trung bình / chế độ được tiêm khi cần thiết.

Mỗi cách thực hiện đều dễ kiểm tra và cũng dễ giả để kiểm tra.