2012-02-19 35 views
12

Trong Java, chúng tôi sử dụng các khối khởi tạo tĩnh:Khởi tạo tĩnh có thực hành lập trình tốt không?

private static final ApiKey API_KEY; 

static { 
    API_KEY = new ApiKey(); 
} 

tôi đã tự hỏi rằng

  • Có một thực hành lập trình tốt?
  • Chúng ta nên sử dụng mẫu này ở đâu?

Xin cảm ơn trước.

+1

tôi sẽ bình luận vì không có "màu đen hoặc trắng" câu trả lời cho câu hỏi của bạn. Cá nhân, tôi không tìm thấy accessor tĩnh một người bạn tốt của các lập trình viên.Phụ thuộc tiêm là một thay thế rất tốt đẹp mà còn giúp rất nhiều khi nói về thử nghiệm. –

+1

Tôi đã nhìn thấy một mã mà các chủ đề mới được bắt đầu trong khối tĩnh. :) Nó đã rất tệ. –

Trả lời

9

Ở một mức độ nào đó, đó là vấn đề về hương vị. Đối với tôi nó là tốt chừng nào:

  • Bạn giữ thức lĩnh vực, như bạn đã làm
  • Bạn chắc chắn đối tượng tham chiếu là không thay đổi và thread-safe

Tĩnh học có xu hướng khiến cho việc viết kiểm tra tốt hơn. Nếu bạn từng thấy bạn muốn bắt đầu sửa đổi trạng thái tĩnh thì có thể bạn cần xem xét lại thiết kế.

Cân nhắc xem Google Guice và số rất đẹp Singleton implementation.

Tất nhiên, nếu ứng dụng của bạn là thử nghiệm đơn lớp 10 dòng thì vấn đề này ít hơn rất nhiều.

Lưu ý rằng trong ví dụ của bạn, bạn có thể đơn giản hóa để:

private static final ApiKey API_KEY = new ApiKey(); 

Đó không phải là luôn luôn có thể mặc dù. Có lẽ bạn đã bỏ qua một số mã khởi tạo phức tạp hơn? Trong trường hợp đó, Guice sẽ một lần nữa đáng xem.

3

Bạn có thể tránh sử dụng một khối initializer tĩnh hoàn toàn bằng cách sử dụng đoạn mã sau:

private static final ApiKey API_KEY = new ApiKey(); 

hoặc

private static final ApiKey API_KEY = createNewApiKey(); 

nếu API tạo chính đòi hỏi nhiều hơn chỉ là một cuộc gọi constructor. Điều đó làm cho mã dễ đọc hơn, IMHO. Nhưng nó không quan trọng lắm.

Các initializer tĩnh rất hữu ích khi hai lĩnh vực tĩnh phụ thuộc vào các mã khởi tạo cùng:

static { 
    // compute some values 
    A = somePartOfTheComputedValues(); 
    B = someOtherPartOfTheComputedValues(); 
} 

Nhưng thậm chí sau đó, A và B có thể có lẽ được refactored thành một đối tượng duy nhất, mà sẽ được tạo ra trong một đơn phương pháp.

2

Tôi thích sử dụng enums bất cứ khi nào có thể.

Thay vì

class ApiKey {   
    private static final ApiKey API_KEY; 

    static { 
     API_KEY = new ApiKey(); 
    } 

Tôi sẽ viết

enum ApiKey { 
    INSTANCE; 
Các vấn đề liên quan