2
如果您有像頁面，新聞等類描述內容項的類，並且您希望實現將附件（文件或其他類型的項目）添加到這些類的能力，您會創建，例如，一個通過使用界面給類提供屬性
public List<Attachment> Attachments { get; set; }
，或者你會重構這個伸到稱爲IAttachmentContainer的接口，僅具有這個屬性
List<Attachment> Attachments { get; set; }
，然後使用該接口與所有這些類（使課程實施國際交流面對）？如你所見，由於我們使用了一個泛型集合（List），我們的界面不需要任何額外的方法或做到了，我錯過了它們？
我最終可能會有很多這些集合（除了附件，還有可能還有小工具等），我想盡可能保持解決方案的清潔。到目前爲止，這種接口方式是最好的接口方式，唯一困擾我的是這些接口大多是無方法。
基本上我最終會與
public class News : IAttachmentContainer, IWidgetContainer, ...
這看起來好不好？
是否有打算成爲類似於不同附件/小工具的屬性/方法？如果是這樣，你可以定義一個接口'IContainer其中T：BaseContainedClass'。儘管如此，你仍然會得到一些相似的東西。 –
在處理所有內容項目（News，Pages，...）中的附件時，將使用類似的或者應該說相同的屬性/方法，但接口本身不會非常相似。例如，附件基本上最終會成爲文件，並且這些文件的行爲與小部件完全不同（小部件更多地是UI項目）。但是，當一個新聞和頁面都實現IAttachmentContainer我希望他們都以同樣的方式處理附件 - 我的意思是相同的數據庫持久性行爲，業務規則，序列化處理等。 – mare
它不應該真的打擾你，一個接口只有屬性而沒有方法。屬性獲取器在概念上不同於不採用參數的方法。至於你的問題，如果沒有更多關於你需要在附件和小部件上執行哪些操作的信息，很難說設計應該如何。 – mquander