Một lớp tiện ích có nên tĩnh không? [đóng cửa]

Nếu tôi phải thiết kế một lớp Tiện ích (chẳng hạn như ByteUtils hoặc StreamUtils hoặc StringUtils), lựa chọn thiết kế tốt nhất cho chúng là gì.

• Nếu chúng là các lớp tĩnh (vì tôi sẽ không có bất kỳ trạng thái nào để lưu trữ)
• Nếu chúng là các lớp không tĩnh (để nếu các đối tượng không được sử dụng, chúng sẽ được gc'd)

PS: Theo lớp tĩnh, ý tôi là một lớp có các phương thức tĩnh (và không phải lớp tĩnh bên trong)

Xin cho lời khuyên về lựa chọn thiết kế cho việc này?

Nếu đó là một tiện ích cho mục đích chung, thì IMO tĩnh sẽ tốt hơn. Bạn đã nói rằng bạn sẽ không có bất kỳ trạng thái nào để lưu trữ, vì vậy tôi không hiểu tại sao bạn nên đặt nó ở chế độ không tĩnh. Khai báo nó là tĩnh cũng sẽ tiết kiệm bộ nhớ.

Các lớp tiện ích của tôi trông như thế này:

// final, because it's not supposed to be subclassed
public final class FooUtil {

    // private constructor to avoid unnecessary instantiation of the class
    private FooUtil() {
    }

    public static int doSomethingUseful() {
    }

    // ...
}

Lưu ý rằng, mặc dù điều này làm cho các phương thức tiện ích có thể dễ dàng kiểm tra và dễ dàng truy cập từ bên ngoài, nó cũng làm cho các lớp sử dụng chúng khó kiểm tra đơn vị, vì không dễ dàng để bắt chước các phương thức tiện ích này. Có quá nhiều lớp tiện ích như vậy có thể là dấu hiệu của việc thiếu thiết kế OO (lập trình thủ tục) và thực sự có thể làm cho mã khó kiểm tra.

Nếu bạn đang sử dụng một khung công tác tiêm phụ thuộc (Spring, Guice, bất cứ thứ gì), có thể là một ý tưởng hay nếu chỉ làm cho lớp tiện ích có thể ngay lập tức, với các phương thức không tĩnh và biến nó thành một singleton có thể tiêm. Bằng cách này, các lớp sử dụng các phương thức tiện ích này có thể được kiểm tra bằng cách giả lập đối tượng tiện ích.

Chỉ vì một cái gì đó có thể tĩnh, không có nghĩa là nó phải tĩnh.

Có một xem xét khác cho tất cả điều này: chế nhạo. Thật khó để bắt chước các phương thức tĩnh trong các bài kiểm tra của bạn hơn là mô phỏng hành vi của một thể hiện của một lớp.

Nói về phân bổ heap không cần thiết và GCing của các đối tượng giúp tôi tối ưu hóa quá sớm. JVM sẽ thực hiện một công việc khá tốt trong việc tối ưu hóa loại vấn đề này.

Cách đơn giản nhất để xác định một lớp Tiện ích là như một enum không có phiên bản

public enum Utility {;
     public static int utilityMethod(int x) { /* ... */ }
}

Một lớp tiện ích không nên có bất kỳ trạng thái nào hoặc có trạng thái tối thiểu, vì vậy bạn không nên lo lắng về GC.

Bạn có thể có các lớp trạng thái khác cho các mục đích cụ thể như Builder, Factory, bạn có thể tạo đối tượng như mong muốn và loại bỏ nó khi bạn đã hoàn thành.

Thật tốt khi làm cho lớp là không tĩnh với một phương thức khởi tạo riêng:

• nếu chúng ta đặt lớp là tĩnh thì lớp sẽ được tải khi ứng dụng được triển khai, nếu nó là không tĩnh thì lớp sẽ được tải khi có lệnh gọi đến một trong các phương thức tĩnh của nó
• tạo một phương thức khởi tạo riêng sẽ tránh việc khởi tạo lớp

Thông thường các lớp tiện ích chứa các phương thức tĩnh và không có thuộc tính, cách tiếp cận này giúp sử dụng các phương thức của chúng dễ dàng hơn mà không cần khởi tạo lớp. Hi vọng điêu nay co ich.

Nếu bạn có thể làm cho chúng tĩnh, thì hãy chắc chắn làm như vậy!

Nói cách khác, nếu chúng không có trạng thái, chúng phải ở trạng thái tĩnh.

Chà, nếu bạn không có trạng thái nào để lưu trữ thì sẽ không có gì đối với GC, vì vậy tôi sẽ sử dụng static, theo cách đó bạn tránh mọi phân bổ heap và GC không cần thiết.

Các lớp tiện ích thuần túy thường phải là tĩnh. Khi bạn có một lớp với đầu vào và đầu ra được xác định rõ ràng, không có tác dụng phụ và không có trạng thái, thì theo định nghĩa, nó phải là một lớp tĩnh.

Nói chung, đừng thêm phức tạp (tiêm phụ thuộc trong trường hợp này) trước khi cần thiết và có lợi khi làm điều đó.

Không ai ở đây đề cập rằng các phương thức tiện ích tĩnh không thể mở rộng. Bạn không thể ghi đè chúng. Bạn không thể tận dụng OOP (đặc biệt là đa hình, là tính năng mạnh mẽ nhất của OOP). Điều đó dẫn đến sự trùng lặp mã.

Tái bút Tôi thấy bài viết này rất hữu ích. http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html