Tôi yêu "mẫu" bất biến vì những điểm mạnh của nó, và trong quá khứ tôi đã thấy nó có lợi khi thiết kế hệ thống với các kiểu dữ liệu bất biến (một số, hầu hết hoặc thậm chí là tất cả). Thông thường khi tôi làm như vậy, tôi thấy mình viết ít lỗi hơn và gỡ lỗi dễ dàng hơn nhiều.
Tuy nhiên, đồng nghiệp của tôi nói chung né tránh bất biến. Họ hoàn toàn không có kinh nghiệm (cách xa nó), nhưng họ viết các đối tượng dữ liệu theo cách cổ điển - các thành viên riêng với một getter và setter cho mọi thành viên. Sau đó, thông thường các nhà xây dựng của họ không có đối số, hoặc có thể chỉ lấy một số đối số cho thuận tiện. Vì vậy, thường xuyên, tạo một đối tượng trông như thế này:
Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");
Có lẽ họ làm điều đó ở khắp mọi nơi. Có lẽ họ thậm chí không định nghĩa một hàm tạo lấy hai chuỗi đó, bất kể chúng quan trọng như thế nào. Và có thể họ không thay đổi giá trị của các chuỗi đó sau đó và không bao giờ cần. Rõ ràng nếu những điều đó là đúng, đối tượng sẽ được thiết kế tốt hơn là bất biến, phải không? (constructor có hai thuộc tính, không có setters nào cả).
Làm thế nào để bạn quyết định nếu một loại đối tượng nên được thiết kế là bất biến? Có một bộ tiêu chí tốt để đánh giá nó?
Hiện tại tôi đang tranh luận về việc có nên chuyển một vài loại dữ liệu trong dự án của riêng tôi thành bất biến hay không, nhưng tôi sẽ phải chứng minh nó với các đồng nghiệp của mình và dữ liệu trong các loại có thể thay đổi (RẤT hiếm khi) đó là cách bất biến (tạo một cái mới, sao chép các thuộc tính từ đối tượng cũ ngoại trừ các thuộc tính mà bạn muốn thay đổi). Nhưng tôi không chắc liệu đây chỉ là tình yêu của tôi đối với những thứ bất biến thể hiện qua, hay nếu có nhu cầu thực sự cho / lợi ích từ họ.