编码与实现课件

*

編碼與實現

*

8.1結構化程式設計

做為軟體工程過程的一個階段，程式編碼是設計的繼續。程式編碼就是將軟體設計的結果翻譯成為用某種程式設計語言描述的源代碼。其中涉及到方法、工具和過程。*8.1.1程式設計語言的選擇

程式設計語言的特性和程式設計風格會深刻地影響軟體的品質和可維護性。程式員必須深刻理解、熟練掌握並正確地運用程式設計語言的特性。為某個特定開發專案選擇程式設計語言時，從技術角度、工程角度、心理學角度評價和比較各種語言的適用程度，考慮現實可能性。需要作出某種合理的折衷。*在選擇與評價語言時，首先要從問題入手，確定它的要求是什麼?這些要求的相對重要性如何?再根據這些要求和相對重要性來衡量能採用的語言。通常考慮的因素有：用戶的要求；可以使用的編譯程序；可以得到的軟體工具；工程規模；程式員的知識；軟體可移植性要求；軟體的應用領域。*程式設計語言的分類程式設計語言有多種分類法：按照語言的抽象級別，有低級語言和高級語言。低級語言包括機器語言(第一代語言)和組合語言(第二代語言)，它們都是與特定電腦硬體密切相關的程式設計語言。高級語言是不反映特定電腦體系結構的程式設計語言，其表示方法更接近待解決問題的表示方法，包括FORTRAN、C等，即第三代語言。*按照應用的範圍，有通用語言和專用語言。通用語言可適用於多種應用，包括FORTRAN、COBOL、C等。專用語言是為特殊的應用而設計的語言。通常具有自己特殊的語法形式，面對特定的問題，輸入結構及辭彙表與該問題的相應範圍密切相關。例如Lisp、PROLOG、FORTH等。按照對用戶的要求，有過程性語言和非過程性語言。*

過程性語言是一種通過指明一系列可執行的運算和運算次序來描述計算過程的語言，如C、FORTRAN、COBOL、C等。非過程性語言是一種不顯式指定處理細節的程式設計語言，如查詢語言、程式生成器、判定支持語言、原型語言、形式化規格說明語言等，包括C++、VC、DELPHI、vF等。按照語言所包含成分的性質，有順序語言，併發語言，並行語言，分佈語言。*8.1.2程式設計風格

程式實際上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程式具有良好的風格。

根源程式文檔化

數據說明

語句結構

輸入／輸出方法*1.根源程式文檔化（1)符號名的命名符號名即識別字，包括模組名、變數名、常量名、標號名、副程式名、數據區名以及緩衝區名等。這些名字應能反映它所代表的實際東西，應有一定實際意義。例如，表示次數的量用Times，表示總量的用Total，表示平均值的用Average，表示和的量用Sum等。*名字不是越長越好，應當選擇精煉的意義明確的名字。必要時可使用縮寫名字，但這時要注意縮寫規則要一致，並且要給每一個名字加注釋。同時，在一個程式中，一個變數只應用於一種用途。

new.balance.accounts.payable

//名字太長

nbalap

//需加注釋

N

//？*（2)程式的注釋

夾在程式中的注釋是程式員與日後的程式讀者之間通信的重要手段。注釋決不是可有可無的。一些正規的程式文本中，注釋行的數量占到整個根源程式的1/3到1/2，甚至更多。注釋分為序言性注釋和功能性注釋。*1)序言性注釋通常置於每個程式模組的開頭部分，它應當給出程式的整體說明，對於理解程式本身具有引導作用。有些軟體開發部門對序言性注釋做了明確而嚴格的規定，要求程式編制者逐項列出。有關專案包括：

程式標題；有關本模組功能和目的的說明；*

主要演算法；

介面說明：包括調用形式，參數描述，副程式清單；

有關數據描述：重要的變數及其用途，約束或限制條件，以及其他有關資訊；

模組位置：在哪一個原始檔案中，或隸屬於哪一個軟體包；

開發簡歷：模組設計者，復審者，復審日期，修改日期及有關說明等。*2)功能性注釋功能性注釋嵌在根源程式體中，用以描述其後的語句或程式段是在做什麼工作，或是執行了下麵的語句會怎麼樣。而不要解釋下麵怎麼做。例如，

/*addamounttototal*/

TOTAL=AMOUNT＋TOTAL

不好。

*如果注明把月銷售額計入年度總額，才能使讀者理解了下麵語句的意圖：

/*addmonthly-salestoannual-total*/

TOTAL=AMOUNT＋TOTAL要點

描述一段程式，而不是每一個語句；用縮進和空行，使程式與注釋容易區別；注釋要正確。*（3)視覺組織空格、空行和移行恰當地利用空格，可以突出運算的優先性，避免發生運算的錯誤。例如，將運算式

(A＜－17)ANDNOT(B＜＝49)ORC

寫成

(A＜－17)ANDNOT(B＜＝49)ORC自然的程式段之間可用空行隔開；*移行也叫做向右縮格。它是指程式中的各行不必都在左端對齊，都從第一格起排列。這樣做使程式完全分不清層次關係。對於選擇語句和迴圈語句，把其中的程式段語句向右做階梯式移行。使程式的邏輯結構更加清晰。例如，兩重選擇結構嵌套，寫成下麵的移行形式，層次就清楚得多。*

IF（…）THEN

IF（…）THEN

……

ELSE

……

ENDIF

……

ELSE

……

ENDIF*2.數據說明在設計階段已經確定了數據結構的組織及其複雜性。在編寫程式時，則需要注意數據說明的風格。為了使程式中數據說明更易於理解和維護，必須注意以下幾點。數據說明的次序應當規範化說明語句中變數安排有序化使用注釋說明複雜數據結構*（1)數據說明的次序應當規範化數據說明次序規範化，使數據屬性容易查找，也有利於測試，排錯和維護。原則上，數據說明的次序與語法無關，其次序是任意的。但出於閱讀、理解和維護的需要，最好使其規範化，使說明的先後次序固定。如在FORTRAN程式中數據說明次序: ①常量說明

②簡單變數類型說明*

③數組說明

④公用數據塊說明

⑤所有的檔說明在類型說明中還可進一步要求。如可按如下順序排列：

①整型量說明

②實型量說明

③字元量說明

④邏輯量說明*（2)說明語句中變數安排有序化當多個變數名在一個說明語句中說明時，應當對這些變數按字母的順序排列。帶標號的全程數據(如FORTRAN的公用塊)也應當按字母的順序排列。例如，把

integersize,length,width,cost,price

寫成

integercost,length,price,size,width*（3)使用注釋說明複雜數據結構如果設計了一個複雜的數據結構，應當使用注釋來說明在程式實現時這個數據結構的固有特點。例如,對PL/1的鏈表結構和Pascal中用戶自定義的數據類型，都應當在注釋中做必要的補充說明。*3.語句結構在設計階段確定了軟體的邏輯流結構，但構造單個語句則是編碼階段的任務。語句構造力求簡單，直接，不能為了片面追求效率而使語句複雜化。（1）在一行內只寫一條語句

在一行內只寫一條語句，並且採取適當的移行格式，使程式的邏輯和功能變得更加明確。*

許多程式設計語言允許在一行內寫多個語句。但這種方式會使程式可讀性變差。因而不可取。例如，有一段排序程式

FORI:=1TON－1DOBEGINT:=I；FORJ:=I＋1TONDOIFA[J]＜A[T]THENT:=J；IFT≠ITHENBEGINWORK:=A[T]；A[T]:=A[I]；A[I]:=WORK；ENDEND；由於一行中包括了多個語句，掩蓋了程式的迴圈結構和條件結構。*FORI:=1TON-1DO//改進佈局

BEGIN

T:=I；

FORJ:=I＋1TONDO

IFA[J]＜A[T]THENT:=J；

IFT≠ITHEN

BEGIN

WORK:=A[T]；

A[T]:=A[I]；

A[I]:=WORK；

END

END；*（2）程式編寫首先應當考慮清晰性程式編寫首先應考慮清晰性，不要刻意追求技巧性，使程式顯得過於緊湊。例如，有一個用C語句編寫的程式段：

A[I]=A[I]＋A[T]；

A[T]=A[I]－A[T]；

A[I]=A[I]－A[T]；

此段程式可能不易看懂，有時還需用實際數據試驗一下。*

實際上，這段程式的功能就是交換A[I]和A[T]中的內容。目的是為了節省一個工作單元。如果改一下：

WORK=A[T]；

A[T]=A[I]；

A[I]=WORK；

就能讓讀者一目了然了。（3）程式要能直截了當地說明程式員的用意程式編寫得要簡單，寫清楚，直截了當地說明程式員的用意。例如，*

for(i=1;i<=n;i++)

for(j=1;j<=n;j++)

V[i][j]＝(i／j)*(j／i)

除法運算（／）在除數和被除數都是整型量時，其結果只取整數部分，而得到整型量。因此,當i＜j時,i/j=0;當j＜i

時,j/i=0。這樣得到的結果V[][]

是一個單位矩陣。寫成以下的形式，就能讓讀者直接瞭解程式編寫者的意圖。*

for(i＝1;i<=n;i++)

for(j＝1;j<=n;j++)

if(i==j)

V[i][j]＝1;

else

V[i][j]＝0;（4）

除非對效率有特殊要求,程式編寫要做到清晰第一，效率第二。不要為了追求效率而喪失了清晰性。程式效率的提高主要應通過選擇高效的演算法來實現。*（5）首先要保證程式正確,然後才要求提高速度。反過來說，在使程式高速運行時，首先要保證它是正確的。（6）避免使用臨時變數而使可讀性下降。

例如，有的程式員為了追求效率，往往喜歡把運算式A[I]+1/A[I]寫成

X＝A[I];Y＝X+1/X;

這樣將一句分成兩句寫，會產生意想不到的問題。

*（7）讓編譯程序做簡單的優化（8）盡可能使用庫函數（9）

避免不必要的轉移。同時如果能保持程式可讀性，則不必用

GOTO語句。例如,有一個求三個數中最小值的程式：Y<Z?small=Zsmall=Xsmall=Y

<<<X<Y?X<Z?*

if(X＜Y)goto30

if(Y＜Z)goto50

small＝Zgoto7030if(X＜Z）goto60

small＝Zgoto7050small＝Ygoto7060small＝X70continue*

程式只需編寫成：

small＝x;

if(y<small)small＝y;

if(z<small)small＝z;

所以程式應當簡單，不必過於深奧，避免使用GOTO語句繞來繞去。（10）儘量只採用三種基本的控制結構來編寫程式 除順序結構外，使用if-then-else來實現

選擇結構；使用do-until或do-while來實現迴圈結構。*

（11）

避免使用空的ELSE語句和IF…THENIF…的語句

這種結構容易使讀者產生誤解。例如，

if(char>='a’)

if(char<=’z’)

cout<<“Thisisaletter。”;

else

cout<<“Thisisnotaletter。”;

可能產生二義性問題。

*（12）

避免採用過於複雜的條件測試。（13）

儘量減少使用“否定”條件的條件語句。

例如，如果在程式中出現

if(!(char＜‘0’||char＞‘9’))……

改成

if(char>='0’&&char<='9’)……

不要让读者绕弯子想。（14）數據結構要有利於程式的簡化。*（15）盡可能用通俗易懂的偽碼來描述程式的流程，然後再翻譯成必須使用的語言。（16）要模組化，使模組功能盡可能單一化，模組間的耦合能夠清晰可見。（17）利用資訊隱蔽，確保每一個模組的獨立性。（18）從數據出發去構造程式。*（19）

不要修補不好的程式，要重新編寫。也不要一味地追求代碼的複用，要重新組織。（20）對太大的程式，要分塊編寫、測試，然後再集成。（21）對遞歸定義的數據結構儘量使用遞歸過程。*4.輸入和輸出輸入和輸出資訊是與用戶的使用直接相關的。輸入和輸出的方式和格式應當盡可能方便用戶的使用。一定要避免因設計不當給用戶帶來的麻煩。因此，在軟體需求分析階段和設計階段，就應基本確定輸入和輸出的風格。系統能否被用戶接受，有時就取決於輸入和輸出的風格。

*不論是批處理的輸入／輸出方式，還是互動式的輸入／輸出方式，在設計和編碼時都應考慮下列原則：對所有的輸入數據都要進行檢驗，識別錯誤的輸入，以保證每個數據的有效性；檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態資訊；使得輸入的步驟和操作盡可能簡單，並保持簡單的輸入格式；*

輸入數據時，應允許使用自由格式；應允許缺省值；輸入一批數據時,最好使用輸入結束標誌，而不要由用戶指定輸入數據數目；在互動式輸入輸入時，要在螢幕上使用提示符明確提示交互輸入的請求，指明可使用選擇項的種類和取值範圍。同時，在數據輸入的過程中和輸入結束時，也要在螢幕上給出狀態資訊；*

當程式設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句的要求的一致性；給所有的輸出加注解，並設計輸出報表格式。 輸入／輸出風格還受到許多其他因素的影響。如輸入／輸出設備（例如終端的類型，圖形設備，數位化轉換設備等）、用戶的熟練程度、以及通信環境等。

*5.程式效率

程式的效率是指程式的執行速度及程式所需佔用的記憶體的存儲空間。改進根源程式的效率的最有效手段是在詳細設計階段改進的演算法。優化語句結構可以改進效率，但是不會有很明顯的改進。*效率的準則效率是一個性能要求，應當在需求分析階段給出。軟體效率以需求為准，不應以人力所及為准。好的設計可以提高效率。程式的效率與程式的簡單性相關。一般說來，任何對效率無重要改善，且對程式的簡單性、可讀性和正確性不利的程式設計方法都是不可取的。*（1)程式執行時間根源程式的效率與詳細設計階段確定的演算法的效率直接有關。在詳細設計翻譯轉換成根源程式代碼後，演算法效率反映為程式的執行速度和存儲容量的要求。設計向程式轉換過程中的指導原則：在編程式前，盡可能化簡有關的算術運算式和邏輯運算式；仔細檢查演算法中的嵌套的迴圈，盡可能將某些語句或運算式移到迴圈外面；*

儘量避免使用多維數組；儘量避免使用指針和複雜的表；採用“快速”的算術運算；不要混淆數據類型，避免在運算式中出現類型混雜；儘量用整數算術運算式和布爾運算式；選用等效的高效率演算法；許多編譯程序具有“優化”功能，可以自動生成高效率的目標代碼。

*（2）記憶體效率在大中型電腦系統中，存儲限制不再是主要問題。在這種環境下，對記憶體採取基於操作系統的分頁功能的虛擬存儲管理。存儲效率與操作系統的分頁功能直接有關。採用結構化程式設計，將程式功能合理分塊，使每個模組或一組密切相關模組的程式體積大小與每頁的容量相匹配，可減少頁面調度，減少內外存交換。*在微型電腦系統中，記憶體的容量對軟體設計和編碼的制約很大。因此要選擇可生成較短目標代碼且存儲壓縮性能優良的編譯程序，有時需採用組合語言程式。提高記憶體效率的關鍵是程式的簡單性。*（3）輸入／輸出效率輸入／輸出可分為兩種類型：

面向人(操作員)的輸入／輸出面向設備的輸入／輸出如果操作員能夠十分方便、簡單地錄入輸入數據，或者能夠十分直觀、一目了然地瞭解輸出資訊，則可以說面向人的輸入／輸出是高效的。

*關於面向設備的輸入/輸出，可以提出一些提高輸入/輸出效率的指導原則：

輸入/輸出的請求應當最小化；對於所有的輸入/輸出操作，安排適當的緩衝區，以減少頻繁的資訊交換。對輔助存儲(例如磁片)，選擇盡可能簡單的，可接受的存取方法；對輔助存儲的輸入/輸出，應當成塊傳送；*對終端或印表機的輸入/輸出，應考慮設備特性，盡可能改善輸入/輸出的品質和速度；任何不易理解的，對改善輸入/輸出效果關係不大的措施都是不可取的；任何不易理解的所謂“超高效”的輸入/輸出是毫無價值的；*8.2程式結構複雜程度的度量

程式複雜性主要指模組內程式的複雜性。它直接關聯到軟體開發費用的多少，開發週期的長短和軟體內部錯誤的多少。程式複雜性度量的參數主要有：規模程式指令條數或根源程式行數；難度與程式運算元和操作符有關的度量；結構與程式分支數有關的度量；智能度演算法的難易程度。*代碼行度量法源代碼行數度量法基於兩個前提：程式複雜性隨著程式規模的增加不均衡地增長；

控制程式規模的方法最好是採用分而治之的辦法。將一個大程式分解成若干個簡單的可理解的程式段。方法的基本考慮是統計一個程式模組的源代碼行數目，並以源代碼行數做為程式複雜性的度量。*

設每行代碼的出錯率為每100行根源程式中可能有的錯誤數目。Thayer曾指出，程式出錯率的估算範圍是從0.04％～7％之間，即每100行根源程式中可能存在0.04～7個錯誤。他還指出，每行代碼的出錯率與根源程式行數之間不存在簡單的線性關係。

*Lipow指出，對於小程式，每行代碼出錯率為1.3％～1.8％；對於大程式，每行代碼的出錯率增加到2.7％～3.2％之間，這只是考慮了程式的可執行部分，沒有包括程式中的說明部分。Lipow及其他研究者得出一個結論：對於少於100個語句的小程式，源代碼行數與出錯率是線性相關的。隨著程式的增大，出錯率以非線性方式增長。*8.2.1McCabe方法

McCabe度量法，又稱環路複雜性度量，是一種基於程式控制流的複雜性度量方法。它基於一個程式模組的程式圖中環路的個數，因此計算它先要畫出程式圖。程式圖是退化的程式流程圖。流程圖中每個處理都退化成一個結點，流線變成連接不同結點的有向弧。*A開始BC輸入DEFGJH輸入K輸出L結束ABCDEFGJKLH程式流程圖程式圖*程式圖僅描述程式內部的控制流程，完全不表現對數據的具體操作，以及分支和迴圈的具體條件。計算環路複雜性的方法：在一個有向圖G中，環路的個數由以下公式給出：

V(G)＝m－n＋2

其中，V(G)是有向圖G中環路個數，m是圖G中弧數，n是圖G中結點數。Myers建議，對於複合判定，如

(A＝0)∩(C＝D)∪(X＝‘A’)

算做三個判定。*在例示中，結點數n＝11，弧數m＝12，則有

V(G)＝m－n＋2＝12－11＋2＝3.環路複雜度取決於程式控制結構的複雜度。當程式的分支數目或迴圈數目增加時其複雜度也增加。環路複雜度與程式中覆蓋的路徑條數有關。McCabe環路複雜度隱含的前提是：錯誤與程式的判定加上例行副程式的調用數目成正比。*McCabe建議，對於複雜度超過10的程式，應分成幾個小程式，以減少程式中的錯誤。Walsh用實例證實了這個建議的正確性。在McCabe複雜度為10的附近，存在出錯率的間斷躍變。這種度量的缺點是：

對於不同種類的控制流的複雜性不能區分；簡單IF語句與迴圈語句的複雜性同等看待；*

嵌套IF語句與簡單CASE語句的複雜性是一樣的；模組間接口當成一個簡單分支一樣處理；一個具有1000行的順序程式與一行語句的複雜性相同*8.2.2Halstead方法

Halstead軟體科學研究確定電腦軟體開發中的一些定量規律,它採用以下一組基本的度量值。這些度量值通常在程式產生之後得出，或者在設計完成之後估算出。

*程式長度(預測的Halstead長度)

令n1表示程式中不同運算符

(包括保留字)的個數，令n2表示程式中不同運算對象的個數，令

H

表示“程式長度”，則有

H=n1

log2n1+n2

log2n2

這裏，H是程式長度的預測值，它不等於程式中語句個數。

*在定義中，運算符包括：

算術運算符賦值符(=或:=)

邏輯運算符分界符(，或；或:)

關係運算符括弧運算符副程式調用符數組操作符迴圈操作符等。特別地，成對的運算符，例如

begin…end、if…then…else、for…to、

repeat…until、while…do、（…）

等都當做單一運算符。*

運算對象包括變數名和常數。實際的Halstead長度

設N1為程式中實際出現的運算符總個數，N2為程式中實際出現的運算對象總個數，N為實際的Halstead長度，則有

N=N1+N2程式的辭彙表

Halstead定義程式的辭彙表為不同的運算符種類數n1和不同的運算對象種類數n2的總和。若令n為程式的辭彙表，則有n=n1+n2*程式量程式量V可用下式得到

V=N×log2n

它表明了程式在辭彙上的複雜性。其最小值為

V*=(2+n2*)×log2(2+n2*)

這裏，2表明程式中至少有兩個運算符：賦值符

=和函數調用符

f()

，n2*表示輸入／輸出變數個數。*例如，用FORTRAN語言寫的交換排序例

SUBROUTINESORT(X,N)

DIMENSIONX(N)IF(N.LT.2)RETURN

DO20I=2,N

DO10J=1,I

IF(X(I).GE.X(J))GOTO10

SAVE=X(I)

X(I)=X(J)

X(J)=SAVE

10CONTINUE

20CONTINUE

END*運算符計數運算對象計數可執行語句結束7X6數組下標6I5=5J4IF()2N2DO222,2SAVE2程式結束111.LT.1n2=7N2=22.GE.1GOTO101n1=10N1=28*

對於上面的例子，利用n1，N1，n2，N2，可以計算得

H=10×log210+7×log27=52.87N=28+22=50V=(28+22)×log2(10+7)=204等效的組合語言程式的V＝328。這說明組合語言比FORTRAN語言需要更多的資訊量(以bit表示)。*

程式量比率(語言的抽象級別)

L=V*/V

或L=(2/n1)×(n2/N2)

它表明了一個程式的最緊湊形式的程式量與實際程式量之比，反映了程式的效率。其倒數

D=1/L

表明了實現演算法的困難程度。

*程式員工作量

E=V/L程式的潛在錯誤

Halstead度量可以用來預測程式中的錯誤。預測公式為

B=(N1+N2)×log2(n1+n2)/3000=V/3000

B为该程序的错误数。它表明程序中可能存在的差错B應與程式量V成正比。

*例如，一個程式對75個數據庫項共訪問1300次，對150個運算符共使用了1200次，那麼預測該程式的錯誤數B：

B=(1200+1300)×log2(75+150)/30006.5

即預測該程式中可能包含6～7個錯誤。*Halstead的重要結論程式的實際Halstead長度N可以由辭彙表n算出。即使程式還未編制完成，也能預先算出程式的實際Halstead長度N，雖然它沒有明確指出程式中到底有多少個語句。這個結論非常有用。經過多次驗證，預測的Halstead長度與實際的Halstead長度是非常接近的。

*Halstead度量的缺點沒有區別自己編的程式與別人編的程式。這是與實際經驗相違背的。這時應將外部調用乘上一個大於1的的常數Kf

(應在1～5之間，它與文檔資料的清晰度有關)。沒有考慮非執行語句。補救辦法：在統計n1、n2、N1、N2時，可以把非執行語句中出現的運算對象，運算符統計在內。*在允許混合運算的語言中，每種運算符與它的運算對象相關。如果一種語言有整型、實型、雙精度型三種不同類型的運算對象，則任何一種基本算術運算符(＋、－、×、／)實際上代表了=6種運算符。在計算時應考慮這種因數據類型而引起差異的情況。沒有把不同類型的運算對象，運算符與不同的錯誤發生率聯繫起來，而是把它們同等看待。例如，對簡單if語句與while語句就沒有區別。

*沒有注意調用的深度。Halstead公式應當對調用副程式的不同深度區別對待。在計算嵌套調用的運算符和運算對象時，應乘上一個調用深度因數。這樣可以增大嵌套調用時的錯誤預測率。忽視了嵌套結構(嵌套的迴圈語句、嵌套IF語句、括弧結構等)。一般地，運算符的嵌套序列，總比具有相同數量的運算符和運算對象的非嵌套序列要複雜得多。解決的辦法是對嵌套結果乘上一個嵌套因數。*8.3面向對象實現面向對象實現階段的主要任務：選擇合適的面向對象的編程語言與開發環境；基於選定的語言和開發環境編碼實現詳細設計中所得到的對象、演算法、公式和規則等；將編寫好的各個類代碼模組根據類的相互關係集成；對軟體進行測試和調試，完成各個部分和整個系統。*1.面向對象程式設計語言面向對象語言的技術特點（1）支持類與對象概念的機制（2）實現整體／部分結構的機制（3）實現一般／特殊結構的機制（4）對於實現屬性和服務的機制（5）類型檢查（6）類庫*（7）效率（8）持久保存對象（9）參數化類（10）開發環境面向對象語言的選擇

（1）可複用性（2）類庫和開發環境（3）其他因素

*（1）提高可重用性

1）提高方法的內聚

2）減小方法的規模

3）保持方法的一致性

4）把策略與實現分開

5）全面覆蓋

6)儘量不使用全局資訊

7）利用繼承機制2.程式設計風格*（2）提高可擴充性

1）封裝實現策略

2）不要用一個方