模型對象的抽象是否合理？

Question

我目前正在一個項目中添加一個新的休息界面。 我寫了一個通用轉換器，將響應轉換爲一些對象。 現在我問自己，如果我應該轉換這些對象，讓我們把他們的rest-interface對象稱爲一組新的對象，這將是我的模型。大多數時候，數據將是相同的 ，但有時我會有不同的數據表示。例如。其餘的響應將有一個日期作爲時間戳，但我的模型對象會有一個日期對象。

另一件好事是，如果我決定將其餘界面改成例如肥皂 我的客戶代碼將只依賴於模型對象，因此我只需要 負責轉換。一個缺點是，如果我必須改變某些東西，我需要在兩個地方完成。

我不確定此主題的最佳做法是什麼。我還會將其餘的接口對象轉換爲模型對象（包括髮送請求和響應兩種方式）的矯枉過正。很高興聽到這方面的一些想法，也許有人知道一些資源解釋得很好。

Answer 1

有沒有聽說過「不成熟的優化」？一般來說，在設計應用程序時，我不會太在意性能。確保創建易讀的代碼，易於維護，易於在將來進行擴展，並且通常可以提供未來的證明（例如，從REST切換到SOAP不會造成更多麻煩;這可能比您想象的更現實的場景時刻）。你不應該去做一個糟糕的設計，只是因爲你「認爲」它可能會有更好的表現，或者你認爲「好設計」可能會表現不佳。

老實說，你打算做多少次REST調用，在單個REST結果中有多少個對象存在？您可以創建最佳設計，如果您稍後出現性能瓶頸（浪費太多CPU時間，浪費太多內存等），那麼您就開始優化這些瓶頸。如果你幸運的話，就不會有瓶頸。如果你主要關心的是創造這個世界上最快的代碼片段，那麼你不會首先使用Java，你可能會使用最低級別的C，並且內聯彙編無論你在哪裏必須擠出最後一部分你的CPU性能下降。

因此，我不會在REST API之後對我的設計進行建模，我會以我認爲應該的方式建模我的設計，最簡單的方式編寫應用程序的其餘部分，然後編寫導入器/導出器將REST轉換爲我的設計，並將我的設計轉換爲REST。如果你轉而使用其他技術，比如SOAP，那麼我只需要重寫導入器/導出器，而不是整個應用程序。

雖然有例外：我個人不喜歡任何OO語言的日期對象。一個時間戳是一個完美的日期表示，恕我直言，這是非常容易處理（比較，增加/減去偏移量等），它有一個非常低的內存開銷（只是數量，通常是原語，甚至沒有內存分配必要）。所以，除非你需要日期對象，否則你不能存儲或顯示這個值，所以我會保留一個時間戳記，如果你將來切換到SOAP，並提供日期而不是時間戳記，我寧願將它們轉換爲時間戳記在進口商和回到出口商的日期。然而，這只是我。