2009-12-29 37 views
6

Tôi đang làm việc trên một dự án .NET, cần tương tác với một số lớp do người dùng định nghĩa - được sắp xếp thành "công việc". Tất cả các lớp công việc phải thực hiện một giao diện cụ thể IJob theo thứ tự cho thư viện để tiêu thụ chúng. Đôi khi một lớp công việc có thể chứa tài nguyên không được quản lý, cần phải được xử lý rõ ràng.Tôi nên đảm bảo xử lý các vật thể có thể dùng một lần như thế nào?

Làm cách nào để đảm bảo rằng tất cả công việc được xử lý đúng cách sau khi sử dụng, nếu tôi không biết trước nếu công việc cần xử lý rõ ràng? Tôi có một vài ý tưởng bản thân mình, nhưng tôi muốn nghe ý kiến ​​của bạn/gợi ý:

  1. Hãy IJob : IDisposable, buộc tất cả các công việc để thực hiện một phương pháp Dispose(). Điều này sẽ cho phép tôi làm việc với các công việc trong các khối using, nhưng vì hầu hết công việc là không phải được mong đợi cần xử lý rõ ràng, điều này có thể thêm nhầm lẫn không cần thiết cho các nhà phát triển ứng dụng khách.

  2. làm tất cả công việc liên quan đến công ăn việc làm trong try-finally khối, và sử dụng finally để đảm bảo rằng Dispose() được gọi là nếu công việc thực hiện IDisposable. Điều này làm cho nó dễ dàng hơn cho các khách hàng để thực hiện một lớp công việc mới - bằng cách không phải thực hiện một phương thức trống rỗng Dispose() - nhưng nó cũng che giấu thực tế rằng thư viện biết và quan tâm đến các công việc dùng một lần.

Sau khi viết điều này, tôi có xu hướng nghiêng về giải pháp # 1, nhưng tôi vẫn nghĩ sẽ rất tốt khi xem các giải pháp thay thế và các ưu điểm khác.

Trả lời

8

Có một tiền lệ: Các lớp cơ sở Stream là IDisposable nad do đó tất cả các hậu duệ Streams là . Nhưng MemoryStream không cần Disposing.
Nhưng đừng cố gắng cố gắng/cuối cùng, khối using() { } là viết tắt thuận tiện hơn.

Vì vậy, lựa chọn của bạn là: Bạn có muốn tất cả Công việc là IDisposable hoặc chỉ một số?

Tùy chọn đầu tiên phát sinh một chi phí nhỏ, thứ hai giúp dễ dàng quên Quên (sử dụng) khi cần thiết.

+0

Điểm tốt. Tuy nhiên, hầu hết các luồng sẽ cần xử lý, và tôi mong đợi một thiểu số công việc cần thiết. –

+0

Nó xảy ra với tôi rằng 'System.Web.IHttpModule' cũng yêu cầu người triển khai của nó cung cấp phương thức' Dispose() ', mặc dù chỉ có vài mô-đun (IMHO) cần nó. Tôi đoán điều này cung cấp ưu tiên bổ sung cho # 1. –

+1

+1, tôi nghĩ rằng hơn nữa, nó có ý nghĩa để cung cấp một phương pháp tiêu chuẩn hóa cho một công việc để làm sạch những gì nó được sử dụng. Bằng cách sử dụng 'IDisposable' bạn sẽ được hưởng lợi từ sự hỗ trợ khung và người dùng cuối được hưởng lợi từ ít nhất là phải suy nghĩ về nơi để đặt mã dọn dẹp thích hợp. – user7116

2

Tôi sẽ đi với # 2 và tài liệu rằng bất kỳ đối tượng dùng một lần nào sẽ được xử lý. Về cơ bản, nếu bạn sở hữu một đối tượng, bạn có nghĩa vụ phải vứt bỏ các đối tượng thực hiện IDisposable.

Nếu bạn đọc Effective C#/More Effective C#, Bill Wagner cho cùng một lời khuyên (mà tôi đồng ý với rõ ràng ;-)

+0

Các OP đã được xử lý đối tượng sở hữu trong cả hai lựa chọn, vì vậy tôi không thấy như thế nào đây là một cuộc tranh cãi trong 2 tùy chọn #. –

3

Tôi nghĩ về nó theo cách này. Tôi muốn một nhà phát triển triển khai phương thức Dispose trống hơn là quên thực hiện phương thức Dispose cần thiết.

5

# 2 là cách xây dựng công trình foreach. Đó cũng là cách hoạt động của thùng chứa Autofac.

Sự khác biệt ngữ nghĩa là liệu bạn có nói rằng một công việc riêng của mình dùng một lần hoặc việc triển khai có thể là dùng một lần hay không.

Rõ ràng từ ví dụ của bạn rằng trước đây là không đúng sự thật, công việc đó vốn không phải là dùng một lần.Vì vậy, tôi khuyên bạn nên # 2, nhưng với một phương pháp mở rộng để tập trung các try/finally:

public static void Execute(this IJob job) 
{ 
    try 
    { 
     job.Run(); 
    } 
    finally 
    { 
     var disposableJob = job as IDisposable; 

     if(disposableJob != null) 
     { 
      disposableJob.Dispose(); 
     } 
    } 
} 
+0

+1, tôi thích đối số của bạn về ngữ nghĩa, nhưng tôi nghĩ tôi sẽ đi với giải pháp đầu tiên, vì những lý do được đề cập trong các câu trả lời khác và chính câu hỏi đó. –

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