2014-10-06 11 views
-1

我目前正在嘗試使設計決定我是否應該多次實現一個方法,或者如果我應該將接口添加到沒有其他共同點的對象。代碼複製與添加多個接口

我的方案的結構是這樣的:

BaseObject(名稱,描述,...)< - DocumentedObject(協議,手冊,...)< - RealObject(期滿,位置,...)

這些是抽象類。每個人都有幾個孩子,例如:

BaseObject:

  • 客戶
  • 出貨

DocumentedObject:

  • MyDocumentedObject

RealObject:

  • 產品

此列表只是一個例子,在現實中,我們都在談論〜20個教學班。

應用程序本身的體系結構是服務層(ProductService,CustomerService,...)之上的MVVM(ProductViewModel,CustomerViewModel,...)。層次結構運作良好,因爲這些對象共享許多屬性。但除了屬性一些共享集合,但他們不符合層次結構。例如。客戶和產品具有文檔列表,但MyDocumentedObject不具有。

我看到用於管理這些集合三個選項:(?在視圖模型,在服務上都)

  • 在具有文檔類使用的接口「IHasDocuments」。該接口只包含一個集合文件
  • 實現文檔管理方法的每個對象額外
  • 實現一個文檔管理方法和檢查對象有哪些類型的傳遞(我想這是最糟糕的解決方案)

目前,它看起來像這樣:

BaseObject:

  • 客戶:IHasDocuments
  • 出貨

DocumentedObject:

  • MyDocumentedObject:IHasItems

RealObject:

  • 產品:IHasDocuments,IHasItems

現在想象這與20個類和5個接口(有5個重複收藏)。這是好的,還是我可以解決這個問題?

+3

我猜的代碼審查的東西。 – 2014-10-06 09:28:16

+0

取決於訪問此界面的代碼是做什麼的。 IComparable並非來自對對象結構的分析,而是從對這些對象進行操作的算法/代碼所需要的內容進行分析。 – AaronLS 2014-10-06 15:09:24

+1

這個問題似乎是題外話題,因爲它是關於代碼審查,應該移到那裏或程序員 – 2014-10-06 15:09:39

回答

1

這是錯誤的網站,但我認爲有接口的方法是要走的路。小的緊密定義的界面非常好,只將它應用於需要它的類也是你想要的。

這也意味着您可以擁有知道如何處理擁有文檔的事物的對象,並只傳遞實現IHasDocuments的事物,而不關心其客戶或產品。

那麼20個類和5個接口呢?如果那是你的模型,那就這麼做吧,它不需要管理。

接口以一致的方式定義了處理所需功能的某些方面的協定,並且不用於指示對象'具有共同的東西'。

實現IComparable的對象不一定有任何共同之處,但可以相互比較。

2

對我來說這是一個大破綻:

...實施方法的幾倍,如果我要的接口添加到沒有任何共同點其他對象...

如果您可以定義多個類將實現的接口,那麼他們DO有一些共同之處。它肯定會跳過多次編寫相同的代碼。