段湘寧，楊 梅

（葫蘆島市信息中心，125001）

1 對接口編程

“對接口編程”是面向?qū)ο笤O(shè)計（OOD）的第一個基本原則。它的含義是：使用接口和同類型的組件通訊，即對于所有完成相同功能的組件，應(yīng)該抽象出一個接口，它們都實現(xiàn)該接口。

具體到 Java 中，可以是接口（interface），或者是抽象類（abstract class），所有完成相同功能的組件都實現(xiàn)該接口，或者從該抽象類繼承。我們的客戶代碼只應(yīng)該和該接口通訊，這樣，當我們需要用其他組件完成任務(wù)時，只需要替換該接口的實現(xiàn)，而我們代碼的其他部分不需要改變。

2 優(yōu)先使用對象組合，而不是類繼承

“優(yōu)先使用對象組合，而不是類繼承”是面向?qū)ο笤O(shè)計的第二個原則。并不是說繼承不重要，而是因為每個學(xué)習(xí)面向?qū)ο缶幊蹋∣OP）的人都知道OO 的基本特性之一就是繼承，以至于繼承己經(jīng)被濫用了，而對象組合技術(shù)往往被忽視了。

下面分析繼承和組合的優(yōu)缺點。

1)類繼承允許根據(jù)其他類的實現(xiàn)來定義一個類的實現(xiàn);

2)對象組合是類繼承之外的另二種復(fù)用選擇;

繼承和組合各有優(yōu)缺點。類繼承是在編譯時刻靜態(tài)定義的，且可直接使用，類繼承可以較方便地改變父類的實現(xiàn)。但是類繼承也有一些不足之處。首先，因為繼承在編譯時刻就定義了，所以無法在運行時刻改變從父類繼承的實現(xiàn)。更糟的是，父類通常至少定義了子類的部分行為，父類的任何改變都可能影響子類的行為。如果繼承下來的實現(xiàn)不適合解決新的問題，則父類必須重寫或被其他更適合的類替換。這種依賴關(guān)系限制了靈活性并最終限制了復(fù)用性。

對象組合是通過獲得對其他對象的引用而在運行時刻動態(tài)定義的。由于組合要求對象具有良好定義的接口，而且，對象只能通過接口訪問，所以我們并不破壞封裝性；只要類型一致，運行時刻還可以用一個對象來替代另一個對象；更進一步，因為對象的實現(xiàn)是基于接口寫的，所以實現(xiàn)上存在較少的依賴關(guān)系。

優(yōu)先使用對象組合有助于保持每個類被封裝，并且只集中完成單個任務(wù)。這樣類和類繼承層次會保持較小規(guī)模，并且不太可能增長為不可控制的龐然大物（這正是濫用繼承的后果）。另一方面，基于對象組合的設(shè)計會有更多的對象（但只有較少的類），且系統(tǒng)的行為將依賴于對象間的關(guān)系而不是被定義在某個類中。

在理想情況下，通常不用為獲得復(fù)用而去創(chuàng)建新的組件，只需要使用對象組合枝術(shù)，通過組裝已有的組件就能獲得需要的功能。但是事實很少如此，因為可用的組件集合并不豐富。使用繼承的復(fù)用使得創(chuàng)建新的組件要比組裝已有的組件來得容易 這樣，繼承和對象組合常一起使用。然而，比如前面所說，千萬不要亂用繼承而忽視了對像組合技術(shù)。

相 關(guān) 的 設(shè) 計 模 式 有：Bridge、Composite、Decorator、Observer、Strategy 等。

下面的例子演示了這個規(guī)則，這里實現(xiàn)的是：對同一個數(shù)據(jù)結(jié)構(gòu)，需要以任意的格式輸出。

程序 1 使用基于繼承的框架，可以看到，它很難維護和擴展。程序 1 使用基子繼承的框架

程序 2 使用基于對象組合技術(shù)的框架，每個對象的任務(wù)都清楚地分離開，我們可以替換、擴展格式類，而不用考慮其他的任何事情。

程序 2 使用給予對象組合技術(shù)的框架

這里用到了類似于“抽象工廠”的組件創(chuàng)建模式，它將組件的創(chuàng)建過程交給manager 來完成，Example Formatter 是所有格式的抽象父類。

3 將可變的部分和不可變的部分分離

“將可變的部分和不可變的部分分離”是面向?qū)ο笤O(shè)計的第三個原則。如果使用繼承的復(fù)用技術(shù)，我們可以在抽象基類中定義好不可變的部分，再由其子類去具體實現(xiàn)可變的部分。不可變的部分不需要重復(fù)定義，而且便于維護。如果使用對象組合的復(fù)用技術(shù)，我們可以定義好不可變的部分，而可變的部分可以由不同的組件實現(xiàn)，根據(jù)需要，在運行時動態(tài)配置。這樣，我們就有更多的時間關(guān)注可變的部分。

對于對象組合技術(shù)而言，每個組件只完成相對較小的功能，相互之間耦合比較松散，復(fù)用率較高，通過組合，就能獲得新的功能。

4 減少方法的長度

通常，我們的方法應(yīng)該只有盡量少的幾行，太長的方法會難以理解，而且，如果方法太長，則應(yīng)該重新設(shè)計。對此，可以總結(jié)為以下原則。

.三十秒原則：如果另一個程序員無法在三十秒之內(nèi)了解開發(fā)者的函數(shù)做了什么 （What），如何做（How）及為什么要這樣做（Why），那就說明該代碼是難以維護的，必須得到提高；

.一屏原則：如果一個函數(shù)的代碼長度超過一個屏幕，應(yīng)該拆分成更小的子函數(shù)；

.一行代碼應(yīng)盡量簡短，并且保證一行代碼只做一件事：那種看似技巧性的冗長代碼只會增加代碼維護的難度。

5 消除循環(huán)判斷的case／if 語句

要盡量避免在代碼中出現(xiàn)判斷語句，來測試一個對象是否是某個特定類的實例。通常，如果需要這么做，那么，重新設(shè)計可能會有所幫助。比如在使用Java 做XML 解析時，對每個標簽映射了一個Java類，采用 SAX（簡單的XML接口 API：Simple API for XML）模型。結(jié)果，代碼中反復(fù)出現(xiàn)了大量的判斷語句，來測試當前的標簽類型。

可以這樣來改進，重新設(shè)計文檔類型定義 DTD（Document Type Definition），為每個標簽增加了一個固定的屬性“class name”，同時重新設(shè)計了每個標簽映射的Java 類的接口，統(tǒng)一了每個對象的操作。增加屬性；

通過這樣的方式，徹底消除了所有的測試當前的標簽類型的判斷語句。每個對象通過Class.for Name（a Element.attributes.get Attribute（”class name”））.new Instance（）；動態(tài)創(chuàng)建即可。

6 盡可能的減少參數(shù)個數(shù)

有大量參數(shù)需要傳遞的方法，通常很難閱讀。我們可以將所有參數(shù)封裝到一個對象中來完成對象的傳遞，這也有利于錯誤跟蹤。

許多程序員認為，太多層的對象包裝對系統(tǒng)效率有影響，但是，和它帶來的好處相比，我們寧愿做包裝。畢竟，“封裝”也是OO 的基本特性之一，而且，“每個對象完成盡量少 （而且簡單）的功能”，也是OO 的一個基本原則。

模型中非期望產(chǎn)出的處理。在DEA模型的投入產(chǎn)出要素中，地區(qū)生產(chǎn)總值為期望產(chǎn)出，碳排放為非期望產(chǎn)出，期望產(chǎn)出越大越好，非期望產(chǎn)出越少越好，違反了方程的一致性，必須進行處理。本文以非期望產(chǎn)出作為投入的方法處理碳排放問題。

7 類層次的最高層應(yīng)該是抽象類

在許多情況下，提供一個抽象基類有利于做特性化擴展。由于在抽象基類中，大部分的功能和行為己經(jīng)定義好，使我們更容易理解接口設(shè)計者的意圖是什么。

由于Java 不允許“多繼承”。從一個抽象基類繼承，就無法再從其他基類繼承了。所以，提供一個抽象接口（interface）是個好主意，一個類可以實現(xiàn)多個接口，從而變相地實現(xiàn)了“多繼承”，為類的設(shè)計提供了更大的靈活性。

8 盡量減少對變量的直接訪問

對數(shù)據(jù)的封裝原則應(yīng)該規(guī)范化，不要把一個類的屬性暴露給其他類，而應(yīng)該通過訪問方法去保護它們，比如設(shè)置為私有方法。如果某個屬性的名字改變，只需要修改它的訪問方法，而不是修改所有相關(guān)的代碼。

9 子類應(yīng)該特性化，完成特殊功能

如果一個子類只是使一個組件變成組件管理器，而不是實現(xiàn)接口功能，或者，重載某個功能，那么，就應(yīng)該使用一個外部的容器類，而不是創(chuàng)建一個子類。程序3 接口定義了組件的功能。

程序3 發(fā)送消息類接口定義

發(fā)送消息類Msgreceiver 實現(xiàn)了接口，而其子類Pool 只是管理多個Msgreceiver 對象，并沒有提供自己的接口實現(xiàn)。使用繼承的方式實現(xiàn)的代碼如程序4 所示。

程序4 使用繼承的方式實現(xiàn)接口

在這種情況下，建議使用組合方式實現(xiàn)，而不是繼承的方式，

10 拆分大類

11 作用截然不同的對象應(yīng)該拆分

類的域、方法個數(shù)太多時，應(yīng)該予以適當?shù)牟鸱?。在?gòu)建的過程中，會遇到這樣的問題：對同樣的數(shù)據(jù)，有不同的視圖。某些屬性描述的是數(shù)據(jù)結(jié)構(gòu)怎樣生成，而某些屬性描述的是數(shù)據(jù)結(jié)構(gòu)本身。最好將這兩個視圖拆分到不同的類中，從類的名稱上就可以區(qū)分出不同視圖的作用。

12 盡量減少對參數(shù)的隱含傳遞

兩個方法處理類內(nèi)部的同一個數(shù)據(jù)（域），并不意味著它們就是對該數(shù)據(jù)（域）做處理。許多時候，該數(shù)據(jù)（域）應(yīng)該作為方法的參數(shù)輸入，而不是直接存取，在工具類的設(shè)計中尤其應(yīng)該注意，兩個方法都對List 對象pool 做了操作，但是，實際上，我們可能只是想對List接口的不同實現(xiàn)Vector、Array List 等做存取測試。所以，代碼應(yīng)該如程序7 所示。

要在不改動原有代碼的前提下使用類。有兩種方活：合成（composition）和繼承（inheritance）。所有非primitive 對象都有一個to string（）方法，當編譯器需要一個string 而它卻是個對象的時候，編譯器就會自動調(diào)用這個方法。所以當編譯器從”Source ＝’＋Source 中看到，當想把一個字符串同一個非字符串相加的時候，它就會說“由于string 只能同string 相加，因此要調(diào)用 source 的to string（），因為只有這樣才能把它轉(zhuǎn)換成 string！”。于是就把這兩個string 連起來，然后再以string 的形式把結(jié)果返還給輸出函數(shù)system.out.print ln（）。如果想讓類也具備這個功能，只要寫一個to string（）的方法就行了。

為每個類都創(chuàng)建一個main（）方法，這也是一種值得提倡的編程方法。這樣一來，測試代碼就都能放進main（）方法里了。即使程序包括很多類，它也只會調(diào)用我們在命令行下給出的那個類的 main（）方法。于是，當輸入“java test l”的時候，它就會調(diào)用test l.main（）。這種在每個類里都放一個main（）的做法，能讓類的單元測試變得更容易一些。做完測試之后，不必移除main（），留下它可以供以后的測試用。

JSP 的編程開發(fā)中，如果遵循這些規(guī)范進行開發(fā)，逐步養(yǎng)成編寫可復(fù)用代碼的習(xí)慣，一定能體會到其中的好處。一個好的編程習(xí)慣并不容易養(yǎng)成，可是一旦養(yǎng)成了一個好的編程習(xí)慣，無論對自己還是對整個開發(fā)團隊，都會受益。

[1]JSP 網(wǎng)站開發(fā)詳解，北京：電子工業(yè)出版社2009。