2009-04-28 39 views
25

Tôi muốn chia sẻ một đối tượng giữa các trường hợp khác nhau của các đối tượng của cùng một lớp.Ý nghĩa chính xác của các trường tĩnh trong Java là gì?

Về mặt lý thuyết, trong khi chương trình của tôi đang chạy, tất cả các đối tượng của lớp A truy cập cùng một đối tượng của lớp B.

I have seen that static là toàn hệ thống và sử dụng của nó không được khuyến khích. Điều đó có nghĩa là nếu tôi có một chương trình khác đang chạy trên cùng một JVM để khởi tạo các đối tượng của lớp A, các đối tượng này có thể truy cập cùng một đối tượng B như một đối tượng được truy cập trong chương trình trước đó?

Nói chung các lỗ hổng đằng sau việc sử dụng các trường tĩnh là gì?

Có bất kỳ giải pháp thay thế nào (không yêu cầu nỗ lực thực hiện lớn) không?

+1

tĩnh là JVM rộng vì vậy có nếu bạn có hai chương trình trong cùng một máy ảo, chúng phải được nhập cùng một đối tượng B –

+8

Nuno: Trường hợp trình nạp lớp rộng. –

Trả lời

55

Tĩnh không hoàn toàn có nghĩa là "được chia sẻ bởi tất cả các trường hợp" - điều đó có nghĩa là "không liên quan đến một trường hợp cụ thể nào". Nói cách khác, bạn có thể nhận được ở trường tĩnh trong lớp A mà không bao giờ tạo ra bất kỳ trường hợp nào.

Đối với chạy hai chương trình trong cùng một JVM - nó thực sự phụ thuộc vào chính xác những gì bạn có nghĩa là "chạy hai chương trình". Trường tĩnh là hiệu quả được liên kết với đối tượng lớp, do đó được kết hợp với trình nạp lớp. Vì vậy, nếu hai chương trình này sử dụng các cá thể lớp trình nạp riêng biệt, bạn sẽ có hai biến tĩnh độc lập. Nếu cả hai đều sử dụng cùng một trình nạp lớp, thì sẽ chỉ có một người để họ thấy các thay đổi của nhau.

Để thay thế - có nhiều tùy chọn khác nhau. Một là chuyển tham chiếu đến đối tượng "được chia sẻ" tới hàm tạo của từng đối tượng mà bạn tạo mà cần nó. Sau đó, nó sẽ cần phải lưu trữ tài liệu tham khảo đó cho sau này. Điều này có thể là một chút đau đớn và hút bộ nhớ nhiều hơn một chút so với một phương pháp tiếp cận tĩnh, nhưng nó làm cho dễ dàng testability.

+0

cảm ơn cho sự thay thế ... đó là những gì tôi đã làm trước đây, tôi quên đề cập đến ... nhưng các nhà xây dựng cho phép để vượt qua các đối tượng chia sẻ không còn có sẵn trong thư viện tôi sử dụng .... – LB40

2

Phương pháp và thành viên tĩnh không được khuyến khích vì chúng thường xuyên bị sử dụng sai mục đích, nhưng điều này nghe có vẻ giống như tình huống tĩnh là cách chính xác. Như tĩnh được chia sẻ trên nhiều chương trình, đây không phải là trường hợp. Mỗi chương trình chạy trong môi trường hoàn toàn riêng biệt.

-1

Điều bạn đang tìm kiếm được gọi là Singleton Pattern.

+2

Ông đã không có yêu cầu cho instantiation lười biếng của lớp B. Overapplication của Singleton kiếm được ire của tôi. – Welbog

+0

Sự khởi đầu lười biếng không phải là lý do duy nhất để sử dụng Singleton. Nó cũng hữu ích nếu bạn cần một thể hiện SINGLE của một lớp để chia sẻ giữa các đối tượng khác, do đó tên. –

+3

Tĩnh là đủ để có được ví dụ đó. Đó là những gì tĩnh là cho. Singleton được sử dụng đặc biệt khi bạn muốn một ví dụ duy nhất và bạn cần phải dụ nó lười biếng. Sử dụng Singleton khi điều này là không cần thiết là một ứng dụng sai của Singleton, dòng dưới cùng. – Welbog

-1

Giả sử mọi thứ đều nằm trong cùng một trình nạp lớp, thì tại sao không sử dụng mẫu monostate để thực hiện việc này?

tĩnh chia sẻ của bạn ẩn trong monostate:

 

    public class Monostate { 

     private static String str = "Default"; 

     public String getString() { 
      return str; 
     } 

     public void setString(String s) { 
      str = s; 
     } 
    } 

Sau đó, bạn có thể tự do tạo bao nhiêu trường hợp của monostate như bạn muốn, nhưng họ đều có chung đối tượng cơ bản giống nhau do sự tham khảo tĩnh.

 
    Monostate mono = new Monostate(); 
    mono.setString("Fred"); 
    System.out.println(mono.getString()); 
+0

Tại sao không? Bởi vì nó nằm về những gì nó làm. Nó làm cho "mẫu" đơn giản trông hợp lý. –

+0

Tất cả những gì tôi cố gắng làm là trao cho LB một giải pháp thay thế, đó là những gì anh ta yêu cầu. Có lẽ ví dụ tôi đưa ra ở trên là quá đơn giản. Có lẽ bài báo này của Robert Martin so sánh và tương phản với tiền bối và singleton có thể giúp: http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf –

Các vấn đề liên quan