Khai báo IDisposable cho lớp hoặc giao diện?

Question

Bắt đầu từ tình hình follwing:

public interface ISample 
{ 
} 

public class SampleA : ISample 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

public class SampleB : ISample 
{ 
    // has no resources that needs to be disposed 
} 

Các SampleA lớp nên thực hiện IDisposable giao diện cho giải phóng tài nguyên. Bạn có thể giải quyết việc này theo hai cách:

1. Thêm giao diện cần thiết cho SampleA lớp:

public class SampleA : ISample, IDisposable 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

2. Thêm nó vào ISample giao diện và lực lượng có nguồn gốc lớp học để thực hiện nó:

public interface ISample : IDisposable 
{ 
} 

Nếu bạn đặt nó vào giao diện, bạn buộc phải triển khai thực hiện IDisposable ngay cả khi chúng không có gì để vứt bỏ. Mặt khác, nó là rất rõ ràng để thấy rằng việc thực hiện cụ thể của một giao diện đòi hỏi một vứt bỏ/sử dụng khối và bạn không cần phải cast như IDisposable để làm sạch. Có thể có một số ưu/nhược điểm khác trong cả hai cách ... tại sao bạn đề nghị sử dụng một cách ưu tiên cho cách khác?

Answer 1

Nếu bạn áp dụng các mô hình using(){} cho tất cả các giao diện của bạn nó là tốt nhất để có ISample xuất phát từ IDisposable vì các nguyên tắc nhỏ khi thiết kế giao diện là để ủng hộ "dễ sử dụng" qua "tính dễ thực hiện ".

Answer 2

Cá nhân, nếu tất cả ISample nên được dùng một lần, tôi sẽ đặt nó trên giao diện, nếu chỉ có một số tôi chỉ đặt nó trên các lớp mà nó cần được.

Có vẻ như bạn có trường hợp sau.

Answer 3

Cá nhân tôi sẽ chọn 1, trừ khi bạn tạo ví dụ cụ thể cho hai. Một ví dụ điển hình về hai là IList.

An IList có nghĩa là bạn cần triển khai chỉ mục cho bộ sưu tập của mình. Tuy nhiên, một số IList thực sự cũng có nghĩa là bạn là IEnumerable và bạn cần có GetEnumerator() cho lớp học của mình.

Trong trường hợp bạn đang do dự rằng các lớp thực hiện ISample sẽ cần phải triển khai IDisposable, nếu không phải mọi lớp triển khai giao diện của bạn phải triển khai IDisposable thì không bắt buộc chúng.

Tập trung vào IDispoable cụ thể, IDispoable trong các lực lượng lập trình viên cụ thể sử dụng lớp học của bạn để viết một số mã xấu xí hợp lý. Ví dụ,

foreach(item in IEnumerable<ISample> items) 
{ 
    try 
    { 
     // Do stuff with item 
    } 
    finally 
    { 
     IDisposable amIDisposable = item as IDisposable; 
     if(amIDisposable != null) 
      amIDisposable.Dispose(); 
    } 
} 

Không chỉ là mã khủng khiếp, sẽ có một hình phạt hiệu quả đáng kể trong việc đảm bảo có một khối finally để vứt bỏ mục cho mỗi lần lặp của danh sách đó, ngay cả khi Dispose() chỉ trả về trong thực hiện.

Dán mã để trả lời một trong các nhận xét ở đây, dễ đọc hơn.

Answer 4

Có thể là một giao diện rất phổ biến, không có hại gì khi giao diện của bạn kế thừa từ giao diện đó. Bạn sẽ tránh việc kiểm tra loại trong mã của bạn với chi phí duy nhất để thực hiện no-op trong một số triển khai ISample của bạn. Vì vậy, lựa chọn thứ 2 của bạn có thể tốt hơn từ quan điểm này.

Answer 5

Một giao diện IFoo lẽ nên thực hiện IDisposable nếu có khả năng là ít nhất một số một số hiện thực sẽ thực hiện IDisposable, và trên ít nhất một số trường hợp các tài liệu tham khảo còn sống sót cuối cùng để một thể hiện sẽ được lưu trữ trong một biến hoặc lĩnh vực loại IFoo. Nó hầu như chắc chắn sẽ thực hiện IDisposable nếu bất kỳ triển khai nào có thể triển khai IDisposable và các phiên bản sẽ được tạo thông qua giao diện nhà máy (như trường hợp với các trường hợp IEnumerator<T>, trong nhiều trường hợp được tạo thông qua giao diện nhà máy IEnumerable<T>).

So sánh IEnumerable<T> và IEnumerator<T> là hướng dẫn. Một số loại thực hiện IEnumerable<T> cũng thực hiện IDisposable, nhưng mã tạo ra các cá thể loại như vậy sẽ biết chúng là gì, biết rằng chúng cần xử lý và sử dụng chúng làm loại cụ thể của chúng. Các trường hợp như vậy có thể được chuyển cho các thường trình khác như loại IEnumerable<T> và các thường trình khác sẽ không có manh mối rằng các đối tượng cuối cùng sẽ cần xử lý, nhưng các thường trình khác trong hầu hết các trường hợp không phải là các đối tượng cuối cùng giữ tham chiếu đến đối tượng. Ngược lại, các trường hợp của IEnumerator<T> thường được tạo, sử dụng và cuối cùng bị bỏ qua, theo mã không biết gì về các loại cơ bản của các trường hợp đó ngoài thực tế là chúng được trả về bởi IEnumerable<T>. Một số triển khai của IEnumerable<T>.GetEnumerator() triển khai trở lại của IEnumerator<T> sẽ bị rò rỉ nguồn lực nếu phương pháp IDisposable.Dispose của họ không được gọi trước khi họ bị bỏ rơi, và hầu hết các mã mà chấp nhận tham số kiểu IEnumerable<T> sẽ không có cách nào để biết nếu loại này có thể được truyền cho nó. Mặc dù nó có thể cho IEnumerable<T> để bao gồm một thuộc tính EnumeratorTypeNeedsDisposal để cho biết liệu trả lại IEnumerator<T> sẽ phải được xử lý hoặc đơn giản yêu cầu các thói quen gọi GetEnumerator() kiểm tra loại đối tượng được trả về để xem nó có thực hiện IDisposable hay không. để vô điều kiện gọi phương thức Dispose mà có thể không làm bất cứ điều gì, hơn là xác định xem Dispose là cần thiết và chỉ gọi nó nếu có.

Answer 6

Tiếp theo Inteface Segregation Principle của SOLID nếu bạn thêm IDisposable vào giao diện bạn đang đưa ra phương pháp cho khách hàng mà không phải quan tâm đến việc vì vậy bạn nên thêm nó vào A.

Bên cạnh đó, giao diện là không bao giờ dùng một lần vì disposability là một cái gì đó liên quan đến việc thực hiện cụ thể của giao diện, không bao giờ với giao diện chính nó.

Bất kỳ giao diện nào cũng có thể được triển khai có hoặc không có phần tử cần được xử lý.

Answer 7

Tôi bắt đầu nghĩ rằng việc đặt IDisposable trên giao diện có thể gây ra một số sự cố. Nó ngụ ý rằng tuổi thọ của tất cả các đối tượng thực hiện giao diện đó có thể được kết thúc một cách đồng bộ một cách an toàn. Ví dụ, nó cho phép bất cứ ai để viết mã như thế này và đòi hỏi tất cả triển khai để hỗ trợ IDisposable:

using (ISample myInstance = GetISampleInstance()) 
{ 
    myInstance.DoSomething(); 
} 

Chỉ mã mà được truy cập vào các loại bê tông có thể biết đúng cách để kiểm soát thời gian tồn tại của đối tượng.Ví dụ: một loại có thể không cần xử lý ở nơi đầu tiên, nó có thể hỗ trợ IDisposable hoặc có thể yêu cầu awaiting quá trình dọn dẹp không đồng bộ sau khi bạn sử dụng xong (ví dụ: something like option 2 here).

Tác giả giao diện không thể dự đoán tất cả các nhu cầu quản lý tuổi thọ/phạm vi có thể có trong tương lai của việc triển khai lớp học. Mục đích của một giao diện là cho phép một đối tượng để lộ một số API để nó có thể được làm cho hữu ích cho một số người tiêu dùng. Một số giao diện có thể có liên quan đến quản lý lâu dài (chẳng hạn như IDisposable chính nó), nhưng trộn chúng với giao diện không liên quan đến quản lý lâu dài có thể làm cho việc thực hiện giao diện khó khăn hoặc không thể. Nếu bạn có rất ít triển khai giao diện và cấu trúc mã của bạn để người tiêu dùng và người quản lý phạm vi/đời sống của giao diện giống nhau, thì sự khác biệt này không rõ ràng lúc đầu. Nhưng nếu bạn bắt đầu truyền đối tượng của bạn xung quanh, điều này sẽ rõ ràng hơn.

void ConsumeSample(ISample sample) 
{ 
    // INCORRECT CODE! 
    // It is a developer mistake to write “using” in consumer code. 
    // “using” should only be used by the code that is managing the lifetime. 
    using (sample) 
    { 
     sample.DoSomething(); 
    } 

    // CORRECT CODE 
    sample.DoSomething(); 
} 

async Task ManageObjectLifetimesAsync() 
{ 
    SampleB sampleB = new SampleB(); 
    using (SampleA sampleA = new SampleA()) 
    { 
     DoSomething(sampleA); 
     DoSomething(sampleB); 
     DoSomething(sampleA); 
    } 

    DoSomething(sampleB); 

    // In the future you may have an implementation of ISample 
    // which requires a completely different type of lifetime 
    // management than IDisposable: 
    SampleC = new SampleC(); 
    DoSomething(sampleC); 
    sampleC.Complete(); 
    await sampleC.Completion; 
} 

class SampleC : ISample 
{ 
    public void Complete(); 
    public Task Completion { get; } 
} 

Trong ví dụ trên, tôi đã trình bày ba loại kịch bản quản lý lâu dài, bổ sung vào hai trường hợp bạn cung cấp.

1. SampleA là IDisposable với sự hỗ trợ đồng bộ using() {}.
2. SampleB sử dụng bộ sưu tập rác nguyên chất (nó không tiêu thụ bất kỳ tài nguyên nào).
3. SampleC sử dụng các tài nguyên ngăn không cho nó bị xử lý đồng bộ và yêu cầu await vào cuối vòng đời của nó (để nó có thể thông báo mã quản lý lâu dài được sử dụng tài nguyên và bong bóng lên bất kỳ trường hợp ngoại lệ nào không đồng bộ).

Bằng cách giữ quản lý đời tách biệt với giao diện khác, bạn có thể ngăn chặn sai lầm phát triển (ví dụ, các cuộc gọi ngẫu nhiên để Dispose()) và sạch hơn hỗ trợ mô hình quản lý đời/phạm vi không lường trước được trong tương lai.