Tôi chỉ bắt đầu với Hibernate, và tất cả các ví dụ tôi nhìn thấy cho đến nay trông khá giống như những hướng dẫn trong tài liệu Hibernate:Có cách nào để khai báo các trường cuối cùng cho các đối tượng được quản lý Hibernate không?
package org.hibernate.tutorial.domain;
import java.util.Date;
public class Event {
private Long id;
private String title;
private Date date;
public Event() {}
/* Accessor methods... */
}
Cụ thể là: không ai trong số các lĩnh vực được khai báo là final
, và phải có một hàm tạo không có đối số để khung công tác Hibernate có thể khởi tạo lớp và thiết lập các trường của nó.
Nhưng đây là điều - tôi thực sự không thích làm cho các lớp học của tôi có thể thay đổi dưới mọi hình thức bất cứ khi nào tôi có thể tránh nó (Java Practices: Đối tượng Immutable làm cho một cuộc tranh luận khá mạnh để làm điều này). Vì vậy, là có bất kỳ cách nào để có được Hibernate để làm việc ngay cả khi tôi đã tuyên bố mỗi cuối cùng của các lĩnh vực '? Tôi hiểu rằng Hibernate sử dụng Reflection để khởi tạo các lớp của nó và do đó cần có khả năng gọi một hàm tạo của một loại nào đó mà không chấp nhận rủi ro nó sẽ chọn hàm tạo sai hoặc truyền giá trị sai cho một trong các tham số của nó, do đó, nó có thể an toàn hơn để gọi hàm tạo no-arg và đặt từng trường một tại một thời điểm. Tuy nhiên, nó không phải là có thể cung cấp các thông tin cần thiết để Hibernate để nó có thể nhanh chóng an toàn các đối tượng không thay đổi?
public class Event {
private final Long id;
private final String title;
private final Date date;
public Event(@SetsProperty("id") Long id,
@SetsProperty("title") String title,
@SetsProperty("date") Date date) {
this.id = id;
this.title = title;
this.date = new Date(date.getTime());
}
/* Accessor methods... */
}
Chú thích @SetsProperty
tất nhiên là hư cấu, nhưng dường như không nên để xa tầm tay.
+1: Ý tưởng tuyệt vời khi sử dụng lớp bao bọc - có vẻ như đây là giải pháp tốt khi cần các lớp/trường cuối cùng. Người ta thậm chí có thể tránh sự mơ hồ mà phiên bản (mutable vs. wrapper) nên được sử dụng bên ngoài bằng cách làm cho phiên bản có thể thay đổi chỉ hiển thị đối với các lớp truy cập dữ liệu. Đối với việc sử dụng cuối cùng, lý do chính của tôi là nó thường chỉ dễ dàng hơn để đảm bảo (chứ không phải giả định) rằng mỗi lĩnh vực được chỉ định chính xác một lần khi xây dựng. Chúng tôi có rất nhiều dữ liệu có ý nghĩa không đổi trong suốt cuộc đời của JVM sử dụng nó, vì vậy sẽ hữu ích khi làm rõ điều này. –
Các trường cuối cùng ngăn người dùng vô tình gán thứ gì đó họ không nên có và giới thiệu một lỗi nhỏ. Nếu bạn biết một cái gì đó sẽ không bao giờ thay đổi, bạn muốn làm cho nó cuối cùng. Xuống đường nếu bạn thấy rằng nó sẽ thay đổi, bạn luôn có thể loại bỏ ràng buộc đó. – corsiKa