模式在面向對象的方式

我有一個顯示的API的概述對象，讓我們說，城市：模式在面向對象的方式

/cities 
/city/{id}

的城市端點返回城市的概況（ID，城市名稱，城市區域），而城市端點返回相同加上一些（人口，圖像，縮略圖...）。現在，在客戶端模擬這種當我看到不同的選擇：

有其中有一個城市的子類，增加了額外的屬性的CityOverview類。
有一個City類，它具有CityOverview子類的所有屬性，該子類隱藏所有額外屬性（例如，在Java中，通過在所有獲取者上爲其所沒有的屬性拋出UnsupportedOperationException）。
讓上述類沒有繼承關係。
有一個City類允許所有額外的屬性爲零。

上述許可和/或任何其他您可以想到的優點和缺點是什麼？

來源

2016-01-13 bluehallu

我會選擇3 - 有2個班級，不是繼承關係。這是決定的原因 -

您需要使用api（例如傑克遜）對序列化的JSON進行反序列化。爲此，您需要一個字段映射的POJO。因爲，現在你有兩個獨立的類，你可以將不同的POJO映射到2個不同的API調用。它使代碼更清潔。
繼承不是一個選項，因爲2個原因 - 1）。有一次，您的任何API調用都會爲父項或子項帶來數據。即根據您所做的API調用，任何一個的字段將始終爲空。這是不必要的浪費。 2）。從OOP設計的角度來看，在城市呼叫中返回的數據對象是而不是是城市{id}呼叫中返回的數據的父級。所以，我們不應該在課堂設計中做到這一點。他們一起組成「城市」實體。

來源

2016-01-13 14:06:23

因此，我個人選擇了目前的選擇1，但這是我正在尋找的那種討論。關於你的第一點，是的，我相應地發送父母或孩子的課程。這裏沒有真正的問題。第二點，我不明白。沒有字段是空的，因爲我只使用第二個端點上的子類。然後從選項3中獲得什麼？ – bluehallu

我認爲我們差不多在同一頁面上。唯一不同的是，在第二點我說CityOverview是「不是」城市的父母。就OOPS而言，City和CityOverview共同組成「城市」實體。然後，如果沒有父子關係，而是兩個類之間的「關聯」，而CityOverview擁有城市的一個實例 - 這是第3點 - 但是既然您說City反正有CityOverview早些時候檢索到的所有字段，那麼我想第3點是不需要的。我將編輯解決方案以使其正確。 –

我認爲如果OverviewCity和City之間沒有太大的區別你應該只保留BE中的一個City類。

在你的/ cities api中，你可以通過你城市的完整列表。
客戶端可以通過城市對象輕鬆創建城市列表，並在每個城市顯示一些城市的細節（OverviewCity）。在後端我不認爲有任何需要支持2個類。

來源

2016-01-13 20:22:50 chenop

我很清楚，後端不需要兩個類，這是我很感興趣的客戶端。我在城市名單中沒有詳細信息的原因是爲了提高效率，因爲此響應可能會很大，否則我不想在客戶端上刪除額外的屬性。 – bluehallu

模式在面向對象的方式

回答

相關問題