Tôi đang ở trong một tình huống rất cụ thể với một trong các lớp tôi đang mã hóa. Tôi có lớp này gọi là User
trông như thế này:Mẫu thiết kế - Cách thực thi các thuộc tính đối tượng chỉ trong một số trường hợp (mẫu Builder, Dependency Injection)
public class User {
private long id; // + getters and setters
private boolean isDeletable; // + getters and setters
private String name; // + getters and setters
private String password; // + getters and setters
private String email; // + getters and setters
private String authenticationRealm; // + getters and setters
private String displayName; // + getters and setters
private Date deletedDate; // + getters and setters
}
Trong mã của tôi có một số tình huống mà tôi chỉ cần một đối tượng rỗng của các loại User
và do đó chỉ cần xây dựng nó bằng cách sử dụng constructor mặc định: new User()
.
Tuy nhiên, tôi có một lớp khác được gọi là CreateUserRequest
mô hình yêu cầu REST để tạo người dùng trong máy chủ. Trọng tải tối thiểu phải chứa các thuộc tính name
, password
, email
và authenticationRealm
được gửi ở định dạng JSON.
Ngay bây giờ tôi đang xử lý này bằng cách kiểm tra các thông số trong constructor của yêu cầu:
public CreateUserRequest(User user) {
if(user.getName() == null || user.getPassword() == null || user.getEmail() == null || user.getAuthenticationRealm() == null)
throw new RuntimeException("Not enough attributes in User object. Minimum: name, password, e-mail and authentication realm.");
}
này đang làm việc OK nhưng cái gì là ngứa ... Tôi muốn thực hiện điều này một cách an toàn hơn , do đó, mã sẽ thực thi các thuộc tính được phổ biến mà không có khả năng xảy ra ngoại lệ.
Tôi cảm thấy như phải có cách tốt hơn để làm điều này với mẫu thiết kế. Tôi nghĩ về việc tạo ra một lớp học UserRequestBuilder
, nhưng điều đó cũng có thể ngụ ý ném một ngoại lệ trong phương pháp build()
(nếu không, có cách nào tôi có thể đảm bảo rằng các thuộc tính được điền trước build()
?). Việc tiêm phụ thuộc cũng có vẻ giống như một khả năng, nhưng tôi không chắc chắn làm thế nào tôi sẽ đặt nó vào vị trí trong ví dụ cụ thể này ...
Bất kỳ suy nghĩ nào?
Âm thanh giống như một đối tượng khác, đối tượng CreateUser có thể có một hàm tạo và xác thực các giá trị được cung cấp. Bất kỳ lý do nào họ phải dựa trên cùng một lớp vì họ đang thực hiện hai nhiệm vụ khác nhau? – dbugger
Suy nghĩ tức thì của tôi sẽ thêm phương thức isValidUserRequest() mới vào lớp User. Nghĩ rằng lớp người dùng nên tự quyết định xem nó có hợp lệ hay không để sử dụng theo yêu cầu. –
Cảm ơn nhận xét @dbugger. Có - một số cuộc gọi REST hoặc sản xuất hoặc tiêu thụ các đối tượng JSON với cùng thuộc tính của lớp 'User' (tức là lớp User đại diện cho một thực thể từ xa). Các lớp học không thực sự thực hiện các nhiệm vụ khác nhau. Lớp 'CreateUserRequest' xây dựng một cuộc gọi REST chuyển một đối tượng' User' trong tải trọng của nó theo định dạng JSON. – Phil