如何設計被不同程式使用的物件？ -有解無憂

讓我們假設：

我們有一些形狀類

我們有一堆形狀類

每個形狀都有一個公共的 Draw() 方法，并且知道如何繪制自己。

我們有一個程式，其唯一的任務是加載和顯示檔案中的形狀，而不是改變它們

我們有一個工具，它是用來在檔案中顯示形狀的。

我們有一個用于可視化編輯形狀類的工具，這意味著一個形狀類將被繪制到螢屏上，用戶可以選擇它并編輯其資料

。

用戶可以將形狀序列化到一個檔案，顯示形狀的程式應該能夠反序列化形狀，使其看起來與用戶從工具中保存的形狀相同

。

形狀包含決定公共方法行為的非公共欄位，例如，告訴 Draw() 方法以何種顏色繪制形狀的顏色欄位

。

像這樣的欄位可以被工具編輯，但對于顯示形狀的程式來說不應該是可見的

。

因此，問題是如何實作這些形狀？

在一個可被兩個程式使用的共享庫中實作它們將打破封裝，但會有一個單一的實作。
為編輯器提供一個實作，為繪制形狀的程式提供另一個實作，這兩個實作應該具有標準化的去/序列化（相同的成員），因此它們可以被正確地去/序列化。這解決了封裝問題，但我們必須維護兩個實作。

如果我不希望繪圖程式知道它們可以被編輯，我應該如何設計這些形狀物件？

目前，我傾向于第二種方案。是否有我沒有看到的第三種選擇？您的建議是什么，為什么？

uj5u.com熱心網友回復：

如果你要在程式之間交換檔案，或者可能要長期存盤這些檔案，并在以后程式改變后加載它們，那么你就不要只使用作業物件的默認序列化，它將寫出私有欄位，并在你改變它們時中斷。

在這些情況下，資料格式是物件的界面的一部分。它需要被設計和指定。

設計資料格式。

設計資料格式與設計方法呼叫介面是一項不同的作業。您的主要考慮因素通常是諸如：

設計資料格式與設計方法呼叫介面不同。

向后兼容性：你將如何確保你現在撰寫的資料能夠被未來的程式使用？這通常是由一個版本計劃來處理的。
前向兼容性：你將如何確保未來程式所寫的資料將盡可能地被今天的程式所使用？這通常是由一個擴展機制來處理的。
語言獨立性。您是否需要確保處理資料的程式能夠輕松/方便地用其他編程語言撰寫？這通常意味著您不依賴于由您的語言或庫定義的復雜的序列化格式。
文本、二進制或兩者之間？文本格式（通常基于 JSON、YAML 或 XML）便于除錯并易于記錄。二進制格式則更為緊湊。有時你可以使用一個中間地帶。例如，MS Office 檔案是打包在 .zip 檔案中的文本檔案。

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/313408.html

標籤：