共用方式為


介面設計

介面會針對實作者必須提供的一組成員定義簽章; 介面無法為這些成員提供實作的細節。 例如,ICollection 介面會定義與處理集合有關的成員, 每一個實作此介面的具象類別都必須為這些成員提供實作的細節。 雖然類別只能繼承自單一類別,但是可以實作多個介面。 下列方針可協助您確保介面有正確的設計。

如果您需要某個一般功能由包含某些實值型別的一組型別所支援,則要定義介面。

實值型別必須繼承自 ValueType; 因此,抽象類別不能用來為實值型別指定合約,必須改用介面。

如果您需要在已經繼承自某個其他型別的型別上支援某介面的功能,請考慮定義此介面。

避免使用資料標記介面 (沒有任何成員的介面)。

自訂屬性可提供一個方式來標記型別。 如需自訂屬性的詳細資訊,請參閱撰寫自訂屬性。 當您可以將屬性的檢查延後到程式碼執行時,最好使用自訂屬性。 如果您的情況需要編譯時期檢查,將無法遵行這個方針。

至少要提供一個型別做為介面的實作。

如此可讓您確保此介面的設計完善,且不需要太大的困難就可以實作。 Int32 類別提供 IComparable 介面的實作。

至少要提供一個成員來使用您所定義的每一個介面 (例如,接受此介面做為型別為此介面的參數或屬性的方法)。

這是可讓您確保此介面的設計完善,且不需要太大的困難就可以使用的另一個機制。

請勿將成員加入到之前已經推出的介面。

加入新的成員將會讓實作此舊版介面的程式碼中斷, 這也是通常為何類別優先於介面的一個主要原因。 如需詳細資訊,請參閱在類別和介面之間選擇

如果介面推出時的定義需要額外的成員,您可以實作新的介面以及使用此介面的適當成員。

Portions Copyright 2005 Microsoft Corporation. All rights reserved.

Portions Copyright Addison-Wesley Corporation. All rights reserved.

設計指引的詳細資訊,請參閱"框架設計準則:公約、 成語和可重複使用的模式。網路圖書館"書 Krzysztof Cwalina 和布拉德 · 艾布拉姆斯,2005年艾迪生 - 衛斯理,發表。

請參閱

概念

在類別和介面之間選擇

其他資源

型別設計方針

開發類別庫的設計方針