Trong mã của tôi, tôi tiêm một logger cho nhiều lớp của mình thông qua danh sách tham số của hàm tạo của chúng
Tôi nhận thấy rằng tôi đặt nó một cách ngẫu nhiên: đôi khi nó là cái đầu tiên trong danh sách, đôi khi cuối cùng và đôi khi ở giữa
Bạn có sở thích nào không? Trực giác của tôi nói rằng tính nhất quán là hữu ích trong trường hợp này và sở thích cá nhân của tôi là đặt nó lên hàng đầu để dễ nhận thấy hơn khi thiếu và dễ bỏ qua hơn khi ở đó.
Câu trả lời:
Loggers là những gì chúng ta gọi là "mối quan tâm xuyên suốt." Họ nhường cho các kỹ thuật như Lập trình hướng theo khía cạnh; nếu bạn có cách trang trí các lớp của mình bằng một thuộc tính hoặc thực hiện một số mã dệt, thì đó là một cách tốt để có được khả năng ghi nhật ký trong khi giữ cho các đối tượng và danh sách tham số của bạn "thuần túy".
Lý do duy nhất bạn có thể muốn chuyển vào một logger là nếu bạn muốn chỉ định các triển khai ghi nhật ký khác nhau, nhưng hầu hết các khung ghi nhật ký có tính linh hoạt để cho phép bạn định cấu hình chúng, cho các mục tiêu ghi nhật ký khác nhau. (tệp nhật ký, Trình quản lý sự kiện Windows, v.v.)
Vì những lý do này, tôi thích làm cho việc ghi nhật ký trở thành một phần tự nhiên của hệ thống, thay vì chuyển một trình ghi nhật ký vào mọi lớp cho mục đích ghi nhật ký. Vì vậy, những gì tôi thường làm là tham chiếu không gian tên ghi nhật ký thích hợp và chỉ cần sử dụng trình ghi nhật ký trong các lớp của tôi.
Nếu bạn vẫn muốn truyền vào một logger, sở thích của tôi là bạn biến nó thành tham số cuối cùng trong danh sách tham số (biến nó thành một tham số tùy chọn, nếu có thể). Có nó là tham số đầu tiên không có ý nghĩa nhiều; tham số đầu tiên phải là tham số quan trọng nhất, tham số phù hợp nhất với hoạt động của lớp.
Trong các ngôn ngữ có chức năng quá tải chức năng, tôi cho rằng càng có nhiều khả năng là một đối số là tùy chọn thì càng phải đúng. Điều này tạo ra sự nhất quán khi bạn tạo quá tải khi thiếu:
foo(mandatory);
foo(mandatory, optional);
foo(mandatory, optional, evenMoreOptional);
Trong các ngôn ngữ chức năng, việc đảo ngược sẽ hữu ích hơn - bạn càng có nhiều khả năng chọn một số mặc định, thì càng phải để lại. Điều này giúp việc chuyên môn hóa hàm dễ dàng hơn bằng cách áp dụng các đối số cho nó:
addThreeToList = map (+3)
Tuy nhiên, như đã đề cập trong các câu trả lời khác, có lẽ bạn không muốn vượt qua logger một cách rõ ràng trong danh sách đối số của mọi lớp trong hệ thống.
Bạn chắc chắn có thể dành nhiều thời gian quá kỹ thuật cho vấn đề này.
Đối với các ngôn ngữ có triển khai ghi nhật ký chính tắc, chỉ cần khởi tạo trình ghi nhật ký chính tắc trực tiếp trong mỗi lớp.
Đối với các ngôn ngữ không có triển khai chính tắc, hãy thử tìm một khung mặt tiền đăng nhập và tuân theo nó. slf4j là một lựa chọn tốt trong Java.
Cá nhân tôi muốn gắn bó với một triển khai khai thác cụ thể và gửi mọi thứ đến syslog. Tất cả các công cụ phân tích nhật ký tốt có khả năng kết hợp nhật ký sysout từ nhiều máy chủ ứng dụng thành một báo cáo toàn diện.
Khi chữ ký hàm bao gồm một hoặc hai dịch vụ phụ thuộc cũng như một số đối số "thực", tôi đặt các phụ thuộc cuối cùng:
int calculateFooBarSum(int foo, int bar, IntegerSummationService svc)
Vì các hệ thống của tôi có xu hướng chỉ có năm hoặc ít hơn các dịch vụ như vậy, tôi luôn luôn đảm bảo các dịch vụ được bao gồm theo cùng một thứ tự trên tất cả các chữ ký chức năng. Thứ tự chữ cái là tốt như bất kỳ. (Ngoài ra: duy trì phương pháp tiếp cận phương pháp này để xử lý mutex cũng sẽ làm giảm cơ hội phát triển bế tắc của bạn.)
Nếu bạn thấy mình tiêm hơn một tá phụ thuộc vào ứng dụng của mình, thì hệ thống có thể cần được chia thành các hệ thống con riêng biệt (tôi có dám nói là microservice không?).
Loggers là một chút của một trường hợp đặc biệt bởi vì chúng phải có sẵn theo nghĩa đen ở mọi nơi.
Nếu bạn đã quyết định rằng bạn muốn chuyển một logger vào hàm tạo của mọi lớp, thì bạn chắc chắn nên đặt một quy ước nhất quán cho cách bạn làm điều đó (ví dụ: luôn luôn là tham số đầu tiên, luôn được truyền bởi tham chiếu, danh sách khởi tạo hàm tạo luôn bắt đầu với m_logger (theLogger), v.v.). Bất cứ điều gì sẽ được sử dụng trong toàn bộ cơ sở mã của bạn sẽ được hưởng lợi từ tính nhất quán một ngày nào đó.
Ngoài ra, bạn có thể yêu cầu mọi lớp khởi tạo đối tượng logger của riêng mình mà không cần thông qua bất kỳ thứ gì. Trình ghi nhật ký có thể cần biết một số điều "bằng phép thuật" để làm việc đó, nhưng mã hóa một filepath trong định nghĩa lớp có khả năng là một có thể duy trì nhiều hơn và ít tẻ nhạt hơn so với việc chuyển nó một cách chính xác cho hàng trăm lớp khác nhau, và được cho là ít tệ hơn nhiều so với việc sử dụng một biến toàn cục để bỏ qua tedium nói. (Phải thừa nhận rằng, logger là một trong số rất ít trường hợp sử dụng hợp pháp cho các biến toàn cục)
Tôi đồng ý với những người đề xuất rằng logger nên được truy cập tĩnh hơn là được truyền vào các lớp. Tuy nhiên, nếu có một lý do mạnh mẽ mà bạn muốn vượt qua nó trong (trường hợp có lẽ khác nhau muốn đăng nhập đến các địa điểm khác nhau hoặc một cái gì đó) sau đó tôi sẽ đề nghị bạn không vượt qua nó bằng cách sử dụng constructor nhưng thay vì thực hiện cuộc gọi riêng biệt để làm như vậy, ví dụ như Class* C = new C(); C->SetLogger(logger);thay vì hơnClass* C = new C(logger);
Lý do thích phương thức này là logger không phải là một phần cơ bản của lớp mà là một tính năng được sử dụng cho một số mục đích khác. Đặt nó trong danh sách hàm tạo làm cho nó trở thành một yêu cầu của lớp và ngụ ý nó là một phần của trạng thái logic thực tế của lớp. Chẳng hạn, điều hợp lý là mong đợi (với hầu hết các lớp mặc dù không phải tất cả), nếu X != Ysau đó C(X) != C(Y)nhưng không chắc là bạn sẽ kiểm tra bất đẳng thức logger nếu bạn so sánh quá các thể hiện của cùng một lớp.
Điều đáng nói, một điều mà tôi chưa thấy các câu trả lời khác chạm đến ở đây, đó là bằng cách làm cho logger được tiêm thông qua thuộc tính hoặc tĩnh, điều đó khiến cho đơn vị kiểm tra lớp khó khăn. Ví dụ: nếu bạn thực hiện logger của mình thông qua thuộc tính, bây giờ bạn sẽ phải tiêm logger đó mỗi khi bạn kiểm tra một phương thức sử dụng logger. Điều này có nghĩa là bạn cũng có thể có thể đặt nó làm phụ thuộc hàm tạo bởi vì lớp này yêu cầu nó.
Tĩnh cho vay cùng một vấn đề; nếu logger không hoạt động, thì toàn bộ lớp của bạn sẽ thất bại (nếu lớp của bạn sử dụng logger) - mặc dù logger không nhất thiết là 'một phần' trách nhiệm của lớp - mặc dù nó gần như không tệ như tiêm tài sản vì bạn ít nhất biết rằng logger luôn luôn "ở đó" theo một nghĩa nào đó.
Chỉ cần một số thực phẩm cho suy nghĩ, đặc biệt là nếu bạn sử dụng TDD. Theo tôi, một logger thực sự không phải là một phần của một phần có thể kiểm tra được của một lớp (khi bạn kiểm tra lớp đó, bạn cũng không nên kiểm tra việc ghi nhật ký của mình).
Tôi quá lười biếng để chuyển xung quanh một đối tượng logger cho mỗi thể hiện của lớp. Vì vậy, trong mã của tôi, những thứ này hoặc nằm trong một trường tĩnh hoặc một biến cục bộ của luồng trong trường tĩnh. Loại thứ hai này rất tuyệt và cho phép bạn sử dụng một bộ ghi khác nhau cho mỗi luồng và cho phép bạn thêm các phương thức để bật và tắt đăng nhập để làm điều gì đó có ý nghĩa và được mong đợi trong một ứng dụng đa luồng.