Tạo các quy tắc thực thể

Question

Tôi muốn biết câu trả lời cho câu hỏi đơn giản này.

Khi tôi tạo đối tượng thực thể và tôi muốn hạn chế cài đặt thuộc tính (ví dụ: tôi không muốn cho phép bất kỳ ai đặt giá trị số nguyên nhỏ hơn 1 thành thuộc tính), tôi nên triển khai nó trong setter của thuộc tính này hoặc tôi nên kiểm tra hạn chế này sau trong một lớp xử lý các đối tượng này? Nói chung, tôi có thể thực hiện getters và setters tuy nhiên tôi muốn miễn là getters của tôi trở lại và setters thiết lập thuộc tính?

Tôi biết có một số quy tắc (quy ước mã) trong java, vì vậy tôi không muốn phá vỡ bất kỳ thứ gì trong số đó.

Cảm ơn trước, hy vọng câu hỏi của tôi đủ rõ ràng và xin lỗi vì bất kỳ sai lầm ngữ pháp nào mà tôi có thể đã thực hiện: /.

Answer 1

Có getters/setters rất hữu ích cho điều đó.

ví dụ:

public void setAge(int age){ 
if(age < 0){ 
    throw new IllegalArgumentException("Invalid age : " + age); 
    //or if you don't want to throw an exception you can handle it otherways too 
} 
} 

Bạn cũng có thể sử dụng Java EE của Bean Validators cho điều này

public class Person{ 

    @Min(value = 0) 
    @Max(value = 99) 
    private Integer age; 

    //some other code 
} 

Answer 2

Đây là mục tiêu của getters và setters.

Nếu chúng tôi không thể thêm một số hành vi trong các phương pháp này, thì ... tại sao chúng ta không sử dụng các thuộc tính công khai?

Answer 3

Từ sự hiểu biết của tôi về câu hỏi của bạn, nó khá nhiều liên quan đến nguyên tắc đóng gói OO. Bạn có thể xem bài viết này: http://www.tutorialspoint.com/java/java_encapsulation.htm

Answer 4

Cách tiếp cận ưa thích của tôi là sử dụng JSR 303 (API xác thực đậu) để đảm bảo rằng các thuộc tính của lớp là hợp lệ.

Bạn hoàn toàn có thể thực hiện xác thực trong các trình cài đặt, nhưng đây không phải lúc nào cũng là một cách tiếp cận mong muốn. Có khả năng trộn lẫn nhu cầu của một số bối cảnh không liên quan đến nhau. Ví dụ, một số thuộc tính của bạn không bao giờ được thiết lập từ giao diện người dùng, và thay vào đó sẽ được tính bởi một dịch vụ, trước khi được duy trì. Trong một sự kiện như vậy, nó không được mong muốn để có logic này bên trong một setter, cho bạn sẽ cần phải biết bối cảnh trong đó setter đang được gọi; bạn sẽ cần phải áp dụng các quy tắc khác nhau trong lớp giao diện người dùng và trong lớp kiên trì của bạn. JSR 303 cho phép bạn tách các mối quan tâm này bằng cách sử dụng các nhóm xác nhận, do đó nhóm xác thực giao diện người dùng của bạn khác với nhóm xác thực tồn tại của bạn.

Trong JPA 2.0, khi bạn chú thích lớp học của bạn sử dụng các ràng buộc được đánh giá bởi một validator JSR 303, nhà cung cấp kiên trì của bạn có thể tự động đánh giá những khó khăn trên PrePersist, PreUpdate và PreRemove (thường không được thực hiện, xem dưới đây) sự kiện vòng đời của thực thể. Để thực hiện xác thực các thực thể trong nhà cung cấp JPA của bạn, bạn phải chỉ định phần tử validation-mode hoặc thuộc tính javax.persistence.validation.mode trong tệp persistence.xml của mình; các giá trị phải là AUTO (mặc định) hoặc CALLBACK (và không phải NONE).

Sự hiện diện của nhà cung cấp xác thực Bean là đủ để đảm bảo xác thực xảy ra trên các sự kiện vòng đời thực thể JPA, vì giá trị mặc định là AUTO. Bạn nhận được điều này theo mặc định, trong một máy chủ ứng dụng Java EE 6; Glassfish sử dụng sự thực thi RI của JSR 303 là Hibernate Validator, và nó hoạt động khá tốt với EclipseLink.

Chế độ CALLBACK sẽ cho phép bạn ghi đè các nhóm xác thực sẽ được áp dụng khi các sự kiện vòng đời được kích hoạt. Theo mặc định, nhóm xác thực Bean mặc định (Default) sẽ được xác thực để cập nhật và duy trì các sự kiện; sự kiện xóa không liên quan đến bất kỳ xác thực nào. Chế độ CALLBACK cho phép bạn chỉ định nhóm xác thực khác cho những sự kiện này, sử dụng các thuộc tính javax.persistence.validation.group.pre-persist, javax.persistence.validation.group.pre-update và javax.persistence.validation.group.pre-remove. Hãy nhớ rằng việc xác thực JSR 303 có thể được sử dụng bên ngoài một thùng chứa Java EE, mặc dù liên kết tài liệu API Validation API mà tôi đã đăng ở trên là từ tài liệu API Java EE 6.

Answer 5

Getters và setters là tuyệt vời để thêm các hạn chế, giống như Jigar Joshi có trong câu trả lời của mình. Bằng cách đó bạn sẽ nhận được phản hồi ngay lập tức và có thể xử lý vấn đề khi được giới thiệu.

Một giải pháp khác là sử dụng xác thực đối tượng (ví dụ như triển khai JSR-303) sẽ cho phép bạn chú thích trường bằng giá trị tối thiểu và tối đa. Một cái gì đó như

@Min(value=1) 
private int myvalue; 

Sau đó, bạn có thể xác thực toàn bộ đối tượng trong một lần và nhận tất cả thư nếu bạn có các trường bị giới hạn khác. Điều này rõ ràng là không hữu ích ở khắp mọi nơi, nhưng nếu nó phù hợp với nhu cầu của bạn thì đó là một lựa chọn.

Cuối cùng, khi bạn nói "thực thể", tôi nghĩ về thứ gì đó được lưu trữ trong cơ sở dữ liệu hoặc liên quan đến các công cụ ORM. Nếu trường hợp đó xảy ra, bạn sẽ cần phải cẩn thận với những gì bạn làm trong getter của bạn. Ví dụ, nếu bạn khởi tạo lười biếng trong getter một số nhà cung cấp ORM sẽ đánh dấu thực thể là bẩn và cố gắng để tuôn ra nó vào cơ sở dữ liệu có thể gây ra một viết không mong muốn.