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

下面的例子說明了為什么設(shè)計(jì)方法會(huì)不兼容，以及如何建立一個(gè)通用的設(shè)計(jì)方法。

繼承還是不繼承，這是一個(gè)問題

面向?qū)ο蟮拈_發(fā)有一個(gè)基本的設(shè)計(jì)方法，那就是繼承。這也就是說，我可以說想要一個(gè)基類的所有屬性和行為，但是我想對它進(jìn)行擴(kuò)展，以支持我自己的思路。并不是每一個(gè)應(yīng)用程序框架都支持面向?qū)ο蟮睦^承。有的時(shí)候是因?yàn)榈讓咏M件不支持集成，而其他的時(shí)候是因?yàn)閷煞桨高M(jìn)行測試是一項(xiàng)難以完成的挑戰(zhàn)。

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

反過來，有的API要求您創(chuàng)建的類必須是原有類的子類。這是因?yàn)榛惖幕A(chǔ)結(jié)構(gòu)要被用在解決方案的基礎(chǔ)結(jié)構(gòu)代碼里。所獲得的類必須能夠讓基礎(chǔ)結(jié)構(gòu)來管理您的新類。這種設(shè)計(jì)方法從根本上與面向?qū)ο蟮幕A(chǔ)是一致的。

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

關(guān)系型數(shù)據(jù)和多值字段

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

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

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

將人的身份與汽車表格里的汽車進(jìn)行關(guān)聯(lián)的另外一種思路是在人表格里加入一個(gè)字段，其中含有與汽車記錄對應(yīng)的人的身份列表。這個(gè)字段叫做多值字段，因?yàn)樗梢园鄠€(gè)值，所以這就有可能維持一個(gè)純粹的汽車記錄，而不用對人員記錄進(jìn)行參考，但是這樣做的代價(jià)太高，讓一個(gè)簡單的問題變復(fù)雜了。

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

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

工廠和枚舉

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

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

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

編程就像建立理論

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

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

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

尋找一致性

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

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

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

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