Trong cơ sở mã Java của chúng tôi, tôi tiếp tục thấy mẫu sau:
/**
This is a stateless utility class
that groups useful foo-related operations, often with side effects.
*/
public class FooUtil {
public int foo(...) {...}
public void bar(...) {...}
}
/**
This class does applied foo-related things.
*/
class FooSomething {
int DoBusinessWithFoo(FooUtil fooUtil, ...) {
if (fooUtil.foo(...)) fooUtil.bar(...);
}
}Điều làm phiền tôi là tôi phải vượt qua một ví dụ FooUtilở khắp mọi nơi, bởi vì thử nghiệm.
- Tôi không thể làm cho
FooUtilcác phương thức tĩnh, vì tôi sẽ không thể chế nhạo chúng để thử nghiệm cả haiFooUtilvà các lớp máy khách của nó. - Tôi không thể tạo một ví dụ
FooUtiltại nơi tiêu thụ với mộtnewlần nữa vì tôi sẽ không thể chế giễu nó để thử nghiệm.
Tôi cho rằng đặt cược tốt nhất của tôi là sử dụng thuốc tiêm (và tôi cũng vậy), nhưng nó bổ sung thêm những rắc rối riêng. Ngoài ra, việc truyền một số trường hợp sử dụng làm tăng kích thước của danh sách tham số phương thức.
Có cách nào để xử lý việc này tốt hơn mà tôi không thấy?
Cập nhật: vì các lớp tiện ích là không trạng thái, tôi có thể có thể thêm một INSTANCEthành viên singleton tĩnh hoặc getInstance()phương thức tĩnh , trong khi vẫn giữ khả năng cập nhật trường tĩnh bên dưới của lớp để kiểm tra. Không có vẻ siêu sạch, quá.
4
Và giả định của bạn rằng tất cả các phụ thuộc cần phải được chế giễu để thực hiện kiểm tra đơn vị một cách hiệu quả là không chính xác (mặc dù tôi vẫn đang tìm kiếm câu hỏi thảo luận về điều đó).
—
Telastyn
Tại sao các phương thức này không phải là thành viên của lớp có dữ liệu mà chúng thao tác?
—
Jules
Có một bộ Junit riêng biệt gọi fns tĩnh nếu FooUtility. Sau đó, bạn có thể sử dụng nó mà không cần chế giễu. Nếu đôi khi bạn cần phải chế giễu thì tôi nghi ngờ nó không chỉ là một tiện ích mà còn thực hiện một số IO hoặc logic nghiệp vụ và trên thực tế nên là một tham chiếu thành viên lớp và được khởi tạo thông qua phương thức constructor, init hoặc setter.
—
tgkprog
+1 cho bình luận của Jules. Lớp Util là một mùi mã. Tùy thuộc vào ngữ nghĩa nên có một giải pháp tốt hơn. Có lẽ các
—
valenterry
FooUtilphương thức nên được đưa vào FooSomething, có thể có các thuộc tính FooSomethingcần được thay đổi / mở rộng để các FooUtilphương thức không còn cần thiết nữa. Xin vui lòng cho chúng tôi một ví dụ cụ thể hơn về những gì FooSomethinggiúp chúng tôi cung cấp một câu trả lời tốt cho câu hỏi này.
@valenterry: Lý do duy nhất các lớp sử dụng là mùi mã là vì Java không cung cấp một cách tốt để có các hàm độc lập. Có những lý do rất tốt để có các chức năng không dành riêng cho các lớp.
—
Robert Harvey