基於多響應創建一個設計。它消除了以某種方式存在特殊情況的設計「暗示」。結果代碼將更加一致和強大。
重點應該是對對象本身 - 你再水化後,用它做什麼。不是在我有一個對象或多個對象的微小偶然事件中。這種區別與「4個物體或4個物體」沒有區別。
將容器抽象爲單個類必然會使對象成爲焦點和設計重點。
編輯
認爲它這樣。單個或多個反序列化的對象是有多少對象需要反序列化的結果。這是一個與(反序列化)對象實際使用密切相關的實現細節。 包封物實施細則,就是從客戶端代碼隱藏它們。爲客戶提供以「業務領域」術語表達功能的類和方法。
末編輯
編輯
...我不得不使用動態回報在調用的類來處理兩種可能的響應。我認爲抽象類(或接口?)是一個更好的方法來做到這一點,但我不知道如何實現它。
要點:
P.S.寫完這些之後,我意識到只需要一個「響應」類,現在ClientApi
類就封裝了對象實例。註釋掉的代碼是原創的。
P.P.S.我的方法和參數名稱真的很糟糕。使用在問題域中具有含義的名稱。即用戶的術語。
。
public class ClientApi {
protected MultiResponse MoreThanOne { get; set; }
// protected SingleResponse OnlyOne { get; set; }
protected ClientApi ();
public ClientApi (List<DeserializedResult> theList) {
if (theList == null) throw ArgumentNullException("error message here");
// add overloaded constructors to MultiResponse class.
MoreThanOne = new MultiResponse (theList);
// OnlyOne = null;
}
public ClientApi (DeserializedResult onlyOne)
if (onlyOne == null) throw ArgumentNullException("error message here");
MoreThanOne = new MultiResponse(onlyOne);
// OnlyOne = onlyOne;
}
///<summary>
/// Always returns an object. The list may be empty,
/// but never null
///</summary>
public MultiResponse GetDeHydratedJsonThingy() {
MultiResponse HereYaGo = new MultiResponse();
// if (MoreThanOne !=null) HereYaGo.AddRange(MoreThanOne);
// if (OnlyOne != null) HereYaGo.Add(OnlyOne);
HereYaGo.AddRange(MoreThanOne.Result);
return HereYaGo;
}
}
末編輯
我需要區分反序列化。如果我試圖反序列化一個列表與單個對象,我會得到錯誤。這是我能想到的最簡單,最低限度的方式。 – gilliduck
好的,你需要,但爲什麼要客戶端代碼?做你必須做的事,但是要變換它,讓客戶只處理一件事。不要將您的實施問題暴露給客戶。給他們一個乾淨,一致的API來處理。 – radarbob
「......這是最簡單的,最少的開銷方式......」1類比2更簡單。一種返回類型比2更簡單。考慮客戶端被迫做的事情。我看到至少有一些特殊處理代碼的潛力。你正在使API更復雜,這是重要的。 – radarbob