如何避免軟件開發(fā)中不兼容的設計方法

申請免費試用、咨詢電話：400-8352-114

很多東西都可以和平共處。巧克力和花生就是這樣一個很好的例子，如果您相信Reece的產品的話。但是，我們都知道油和水就不相容。在我們用心創(chuàng)建復雜的大型應用程序時，開發(fā)人員必須非常努力才能夠找到那些能夠在一起和諧工作的東西，避免不兼容的情況出現。隨著開發(fā)小組變得越來越大，讓每個開發(fā)人員的想法都保持一致，把精力放在相同的設計方法上變得越來越難。但是，沒有必要這么做。

下面的例子說明了為什么設計方法會不兼容，以及如何建立一個通用的設計方法。

繼承還是不繼承，這是一個問題

面向對象的開發(fā)有一個基本的設計方法，那就是繼承。這也就是說，我可以說想要一個基類的所有屬性和行為，但是我想對它進行擴展，以支持我自己的思路。并不是每一個應用程序框架都支持面向對象的繼承。有的時候是因為底層組件不支持集成，而其他的時候是因為對集成方案進行測試是一項難以完成的挑戰(zhàn)。

當然這不像它第一眼看上去的那么難處理。只需要用一個封裝方法把它與API集成到一起就行了。利用封裝思路，具備各種功能的對象就被作為一個成員變量包裝在一個新的類里，它的屬性和方法通過您的新類一個接一個地公開。雖然這很乏味，而且不允許基類的新特性通過，但是這是使用不支持繼承的API的一種有效的思路。

反過來，有的API要求您創(chuàng)建的類必須是原有類的子類。這是因為基類的基礎結構要被用在解決方案的基礎結構代碼里。所獲得的類必須能夠讓基礎結構來管理您的新類。這種設計方法從根本上與面向對象的基礎是一致的。

上面這些思路都是正確的。但是這些方法的一致性都不足，對一個類使用一種API對另外一種API造成災難性的后果。

關系型數據和多值字段

關系型數據庫以極其高效的方式將相關的信息放到多個表格里。每個表格都有一系列行，每一行里都有一系列的字段。關系型數據庫引擎所使用的索引機制會利用某個字段里的值快速地尋找到指定的記錄或者一組記錄。

關系型數據庫會處理很多情況，比如可能會有零個或者很多個完整的信息行與第一行建立關系，方法是把它放在一個單獨的表格里，并通過在第一個和第二個表格之間設置一個鍵值來建立聯系。例如，一個數據表格可以代表人員，第二個表格可以包括汽車。每個人可能擁有一輛以上的汽車。在這種情況下，汽車表格里的行可以有一個指明所有人的字段。

這種關系能夠很好地用于多種類型的問題，例如指定的人有多少輛車，某一個人擁有的汽車最多是多少輛，以及誰有車等等。

將人的身份與汽車表格里的汽車進行關聯的另外一種思路是在人表格里加入一個字段，其中含有與汽車記錄對應的人的身份列表。這個字段叫做多值字段，因為它可以包含多個值，所以這就有可能維持一個純粹的汽車記錄，而不用對人員記錄進行參考，但是這樣做的代價太高，讓一個簡單的問題變復雜了。

關于指定的汽車屬于誰的問題變困難了，因為在汽車和人之間沒有明顯的能夠用于查詢的連接鍵。從技術上讓關系型數據庫的引擎對人員表格的汽車字段進行模式匹配是有可能的。但是，這樣做肯定會造成需要對表格進行掃描——這一操作就無法利用索引的優(yōu)勢，從資源利用的角度上講開銷也過大。

關系型數據庫本身在設計上并不擅長處理多值字段。所以試圖在一個數據庫里使用多值字段會有很大的困難。關系型數據庫和多值字段是不兼容的設計思路。如果想要使用多值字段，那么另外一種類型的數據庫可能要比傳統(tǒng)的關系型數據庫更加合適。
 
工廠和枚舉

另外一種比較復雜的設計情形是抽象工廠模型的實現——這種模型允許根據配置創(chuàng)建任何對象。這完全就是一種十分靈活的模型，在創(chuàng)建具有可擴展性的解決方案時這是一種強大的武器。

創(chuàng)建工廠時的一個常見錯誤是使用枚舉來控制工廠實際創(chuàng)建什么樣的對象。這是一個錯誤，因為它使用了一種非常靈活的解決方案，因此能夠被輕易地修改以支持新的功能，并將它集成到一個要求重新編譯代碼的方式。其結果是工廠本來具有的可擴展性被枚舉綁住了手腳。一種更好的思路是使用一種基于標識符的配置，以明確創(chuàng)建什么樣的內容。通過在運行期間的配置而不是編譯期間的枚舉來查看對象類型，您可以很好地保留工廠設計模式的靈活性。

基本的設計思想是不兼容的。工廠是自由靈活、可擴展的。而枚舉則是對值的半剛性定義。

編程就像建立理論

因“Backus-Naur Form”語言句法概念而聞名的Peter Naur在1985年寫了一篇題為《編程就像建立理論（Programming as Theory Building）》的文章。這篇文章的一個基本思想就是大多數人都相信編程更像是在建立一種理論。換句話說，編程是對系統(tǒng)應該如何工作的思維模型的發(fā)展。不同開發(fā)人員的理論基礎越一致，編出來的應用程序的一致性就越高，應用程序的總成本就越低。

如果Peter的思想從根本上講是正確的，那么在同一個應用程序里存在不兼容或者完全對立的設計會讓這個程序的開發(fā)很難進行。如果您必須按照一種理論開發(fā)某個子系統(tǒng)的操作，然后又必須在另一個子系統(tǒng)上應用完全不同的理論，那么這顯然會極大地增加系統(tǒng)的復雜性。

您的目標應該是盡可能地去除設計中不兼容的地方，如果沒有辦法完全消除不一致，至少應該清楚地標示出來并進行文檔說明，這樣才能讓人知道這些地方需要更改理論。

尋找一致性

解決設計思想中不兼容的問題沒有很容易的辦法。但是，如果想要開發(fā)可維護的系統(tǒng)，這是絕對需要解決的問題。一般來說，您必須進行一些重要的工作來解決兼容性的問題。然而，雖然您需要付出努力，但是這些解決辦法一般也不是那么困難找到的。有的時候，這只不過意味著將一種設計思想與另外一種設計思想靠近，以達到兼容的目的。

例如，如果您有一些密封類，它們無法從其他的地方衍生出來，在解決方案里還有其他一些類，它們又必須從其他的地方衍生出來——您可以花點時間和精力來確保密封類可以通過繼承獲得（也就是說非密封的）。

更加復雜一點的（解決方案）是增加一些必要的代碼把多值字段轉換成一個查詢或者跨引用的表格。這也就是說要再創(chuàng)建一個表格，并更新應用程序里任何相關的代碼以便能夠處理它，但是，通過屬性來模擬對多值字段的操作也是可能的，這樣整個系統(tǒng)就不必再更改那些需要通過跨表格才能夠完成的地方。

類似的，您可以把枚舉的內部表示替換成為一個整數（枚舉的基礎類型），然后在您必須知道如何實例化特定類的時候把枚舉交給整數。實現一致性并不總是一帆風順的。但是，它會創(chuàng)造一個從存在設計沖突的模式轉到一個更加兼容的模式的機會，這樣開發(fā)人員就能夠理解和適應那些原本他們令手足無措、困惑萬分、相互矛盾的模式了。(Builder.com.cn)