軟件技術(shù)方案設計原則

軟件技術(shù)方案設計原則

　　軟件開(kāi)發(fā)是一項高強度的腦力勞動(dòng)過(guò)程，到目前為止尚沒(méi)有辦法使軟件開(kāi)發(fā)完全機械化，只能靠人腦去設計，也無(wú)法保證一個(gè)軟件完全沒(méi)有錯誤。同硬件產(chǎn)品相比，一方面是同功能的軟件產(chǎn)品不再需要一個(gè)生產(chǎn)過(guò)程，只需要拷貝就行了，而硬件產(chǎn)品卻需要重復生產(chǎn);另一方面，軟件產(chǎn)品功能需求的變化遠比硬件產(chǎn)品多。這就造成軟件產(chǎn)品和硬件產(chǎn)品在成型之后面臨的問(wèn)題是不同的，軟件產(chǎn)品主要是應付用戶(hù)功能需求的變化和擴展，硬件產(chǎn)品主要著(zhù)眼于如何大規模地生產(chǎn)。硬件產(chǎn)品的大規模生產(chǎn)可以交給機器去執行，而軟件產(chǎn)品的需求變化還是要靠人腦去完成。以下是軟件技術(shù)方案設計原則，歡迎閱讀。

　　如何快速開(kāi)發(fā)出符合用戶(hù)功能需求的軟件，如何保證開(kāi)發(fā)出的軟件盡可能少地出現錯誤，如何使開(kāi)發(fā)出的軟件能夠容易地適應用戶(hù)功能需求的變化和擴展，是所有軟件開(kāi)發(fā)人員追求的目標;我想，也正是為了實(shí)現上述目標，才有了軟件設計原則和設計模式。

　　軟件開(kāi)發(fā)是起始于面向過(guò)程的，為什么會(huì )這樣呢?我想是因為面向過(guò)程地解決問(wèn)題更直接，軟件本身就是一個(gè)解決問(wèn)題的過(guò)程;面向過(guò)程的最大問(wèn)題就是不容易把問(wèn)題進(jìn)行分解，再大的問(wèn)題都要在一個(gè)過(guò)程里面解決，從第一步直到最后一步;最多是把一個(gè)大過(guò)程分解成幾個(gè)順序執行的小過(guò)程，很考驗人的邏輯推理能力，開(kāi)發(fā)出的軟件不容易維護、重用和擴展。面象對象的方法沒(méi)那么直接，需要有一個(gè)抽象的過(guò)程，要把問(wèn)題抽象成一個(gè)個(gè)對象，每個(gè)對象解決一個(gè)小問(wèn)題，不同對象的組合就可解決不同的大問(wèn)題;而且把對象跟日常的事物聯(lián)系起來(lái)，產(chǎn)生了屬性、事件、方法這樣的概念，增加了對象的直觀(guān)性。

　　設計原則和設計模式都是針對面向對象的設計方法而提出來(lái)的，如果在軟件開(kāi)發(fā)中還完全采用面向過(guò)程的方法，是無(wú)所謂設計原則和設計模式的。在軟件開(kāi)發(fā)中，面向過(guò)程是起步，是基礎，沒(méi)什么好研究的了;面向對象才是深入，是王道，需要不斷地去總結方法;下面的軟件設計都是指面向對象的設計方法。

　　根據前人總結的經(jīng)驗，在軟件開(kāi)發(fā)中，遵循一定的設計原則，靈活地采用一些設計模式，可以提高軟件的易維護性、可擴展性以及重用的機率。關(guān)于這方面最權威的著(zhù)作恐怕就是Robert C. Martin寫(xiě)的敏捷軟件開(kāi)發(fā)一書(shū)了;關(guān)于這本書(shū)，個(gè)人閱讀的理解如下：

　　一、設計原則，該書(shū)提出了如下設計原則：

　　1、單一職責原則(SRP)：一個(gè)類(lèi)只實(shí)現一個(gè)功能;換一種說(shuō)法，一個(gè)類(lèi)只能有一個(gè)引起它變化的原因;在軟件工程中有一個(gè)要求，叫做高內聚;一個(gè)類(lèi)只實(shí)現一個(gè)功能，無(wú)凝內聚度是最高的了;這一原則可以使一個(gè)類(lèi)更好地被重用;當然，“一個(gè)功能”是相對的，在某種情況下，MODEM功能是一個(gè)單一功能，而在另一種情況下，可能就要把MODEM功能再分解成多個(gè)小功能;

　　2、開(kāi)放封閉原則(OCP)：開(kāi)放是指一個(gè)類(lèi)能夠擴展功能，封閉是指這個(gè)類(lèi)對于功能修改是封閉的，也就是說(shuō)不能修改其已有的代碼和功能;要實(shí)現這一目標，關(guān)鍵是抽象;在客戶(hù)類(lèi)中只使用抽象基類(lèi)，在應用中子類(lèi)繼承基類(lèi)，并按實(shí)際需要擴展基類(lèi)的功能;按更通俗的說(shuō)法就是：接口不能改變，功能可以擴展;

　　3、子類(lèi)替換原則(LSP)：就是一個(gè)子類(lèi)在任何情況下，都能替換掉它的基類(lèi);這是面向對象設計方法中實(shí)現繼承和多態(tài)必須遵循的一條基本原則，顯然也是開(kāi)放封閉原則能夠實(shí)現的基礎;如何實(shí)現這一原則呢?那就是子類(lèi)必須要有比基類(lèi)相同或更弱的前置條件，相同或更強的后置條件;前置條件就是調用一個(gè)方法之前必須滿(mǎn)足的條件，后置條件就是一個(gè)方法執行之滿(mǎn)足的條件;為了更清楚地說(shuō)明這一個(gè)問(wèn)題，見(jiàn)下面的函數表達式：

　　Y = F(X);

　　F是一個(gè)函數，X是一個(gè)整型的輸入參數，Y是一個(gè)整型的返回值，如果F要求X>0，返回值Y>1，則X>0和Y>1就分別是F的前置條件和后置條件;如果F是基類(lèi)A中的一個(gè)函數，B是A的一個(gè)子類(lèi)，并擴展了F的功能，則B類(lèi)中F的前置條件必須跟A類(lèi)中的相同或更弱，也就B類(lèi)中的F必須至少能接受X>0，如果能同時(shí)接收X<=0的條件更好，但不能要求X>1，這是一個(gè)X>0更強的條件;B類(lèi)中的F必須保證返回值Y>1，當然如果能保證Y>10更好，但不能使返回值Y<=1，這樣就不滿(mǎn)足A類(lèi)中F返回值Y>1的條件;不滿(mǎn)足子類(lèi)替換原則最直接的后果就是使應用程序產(chǎn)生BUG;必須說(shuō)明的是，在實(shí)際中是很難完全遵循子類(lèi)替換原則的，必須作合理的假設，在這個(gè)假設的前提下遵循子類(lèi)替換原則，這就是所謂契約設計;

　　4、依賴(lài)倒置原則(DIP)：就是上層模塊不能依賴(lài)于下層模塊，兩者都應該依賴(lài)抽象;抽象不能依賴(lài)細節，細節應該依賴(lài)于抽象;對這一原則要靈活看待，因為這一原則和當前開(kāi)發(fā)中常用組件開(kāi)發(fā)方式看起來(lái)是相矛盾的;首先明確定義一下上層模塊和下層模塊，所謂上層模塊是調用別人的模塊，也可稱(chēng)之為客戶(hù)模塊，下層模塊是被別人調用的模塊，也可稱(chēng)之為服務(wù)模塊;顯然這是一個(gè)相對的概念，因為一個(gè)模塊很可能同時(shí)即調用別的模塊，又被另外的模塊調用;依賴(lài)倒置原則告訴我們客戶(hù)模塊和服務(wù)模塊不能互相依賴(lài)，而只能依賴(lài)于一個(gè)抽象的基類(lèi);另外這個(gè)抽象基類(lèi)的接口是由客戶(hù)模塊決定，而不是由服務(wù)模塊決定;也就是說(shuō)客戶(hù)模塊需要什么，服務(wù)模塊就提供什么，而不是服務(wù)模塊提供什么，客戶(hù)模塊就使用什么;這頗有點(diǎn)當前企業(yè)信奉的一個(gè)原則：客戶(hù)就是上帝，客戶(hù)需要什么，我們就提供什么;而我們當前常用的組件編程中，每一個(gè)組件都是一個(gè)被別人調用的具體類(lèi)，顯然是屬于細節和服務(wù)模塊，我們調用組件，實(shí)際上就依賴(lài)了這些組件的模塊;根據依賴(lài)倒置原則是不是就不能調用這些組件呢?當然不能這么呆板，在設計中還有另一條原則，穩定依賴(lài)是沒(méi)有害處的;說(shuō)到底，這些組件也是根據客戶(hù)需求制定出來(lái)的，只不過(guò)是已經(jīng)固化了的需求;而且這些組件經(jīng)過(guò)了嚴密測試，是穩定的，依賴(lài)它們沒(méi)有害處;依賴(lài)倒置原則是針對我們自己的設計來(lái)說(shuō)的;當然，如果我們自己設計的某一個(gè)服務(wù)類(lèi)經(jīng)過(guò)了嚴格的測試和大量的使用，都已經(jīng)驗證沒(méi)有問(wèn)題，也可以作為一個(gè)通用的組件，別人可以調用它，依賴(lài)它，沒(méi)有問(wèn)題;

　　5、接口隔離原則(ISP)：這一原則好象是單一職責原則的升級版，接口隔離原則強調的是當一個(gè)服務(wù)類(lèi)需要被即有共同功能需求又有不同功能需求的客戶(hù)類(lèi)使用時(shí)，不能在服務(wù)類(lèi)中加進(jìn)它的客戶(hù)不需要的方法，比如在服務(wù)類(lèi)A的客戶(hù)中， B類(lèi)客戶(hù)需要F方法，而C類(lèi)客戶(hù)則不需要F方法，這時(shí)不能簡(jiǎn)單地把F方法加到服務(wù)類(lèi)A中以滿(mǎn)足B類(lèi)客戶(hù)的需求，而應分離接口;比如另設計一個(gè)服務(wù)類(lèi)D，其中包含F方法，并把共用的功能委托給A實(shí)現，這樣B客戶(hù)可以使用D，而C客戶(hù)繼續使用A;對這一原則我有所保留的是：如果F方法對C類(lèi)沒(méi)有影響，直接加到A類(lèi)中也無(wú)防，而且這種情況是很普遍;

　　6、共同封閉原則：這是針對包的;一個(gè)包對應用一個(gè)程序文件，包含一到多個(gè)類(lèi)，這些類(lèi)具有共同的封閉性，要么是都不能修改，要么是只能由同一原因引起修改;

　　7、共同重用原則：也是針對包的;不同類(lèi)的通用性也是不一樣的，通用性最高的就是在所有項目中都可使用，比如我們用到的集成開(kāi)發(fā)工具中的組件;有些類(lèi)可能包含些行業(yè)特征，只能這一行業(yè)類(lèi)的軟件中使用，有些類(lèi)包含了某一個(gè)項目的特征，就可能在該項目中使用;但是一個(gè)包中的所有類(lèi)的通用性都應該是一樣的，這樣才能保證包的重用度最大化;

　　二、設計模式，該書(shū)列出了以下常用的設計模式;

　　1、策略模式(STRATEGY)：在一個(gè)擁有通用算法的具體類(lèi)中，把一些調用的方法委托給一個(gè)接口類(lèi)實(shí)現，通過(guò)接口的不同實(shí)現，擴展不同的功能;策略模式能夠重用通用具體類(lèi)，又易于擴展功能;

　　2、工廠(chǎng)模式(FACTORY)：在一個(gè)工廠(chǎng)類(lèi)中，傳入不同的參數，可生成不同的類(lèi)(相同的接口，不同的實(shí)現);工廠(chǎng)模式易于擴展功能;

　　3、封裝模式(FAADE)：對一個(gè)具有復雜接口的類(lèi)(或API函數)進(jìn)行封裝，并提供幾個(gè)簡(jiǎn)單的接口供外部調用;封裝模式可以隔離復雜的接口，并使其使用變得簡(jiǎn)單;

　　4、命令模式(COMMAND)：上層模塊要操作一組COMMAND對象，這些COMMAND對象都具有同樣的方法(不同的實(shí)現)，上層模塊在操作COMMAND對象時(shí)，只需要調用它們的方法，而不用關(guān)心方法的實(shí)現;在某些情況下，這種模式會(huì )極大地簡(jiǎn)化系統;

　　5、組合模式(COMPOSITE)：當A調用B，一對一的關(guān)系，需要改變?yōu)锳調用多個(gè)B(或B的子類(lèi)對象)時(shí)，不更改A的代碼(比如在A(yíng)中創(chuàng )建一個(gè)B或B的子類(lèi)對象的列表，再依次從列表中取出對象調用)，而是從B繼續一個(gè)子類(lèi)C，在C類(lèi)中創(chuàng )建B或B的子類(lèi)對象的列表，重寫(xiě)C類(lèi)中相應的方法為依次調用列表中對象的方法，從而用A和C一對一的關(guān)系代替A和B之間一對多的關(guān)系，并保持A的代碼不用更改;

　　6、觀(guān)察者模式(OBSERVER)：在被觀(guān)察者中提供注冊接口(Register)用于注冊觀(guān)察者，所有注冊的觀(guān)察者都放入一個(gè)列表中，在觀(guān)察者中提供觀(guān)察接口(Update)，用于接收被觀(guān)察者發(fā)出的通知;當被觀(guān)察者發(fā)生變化時(shí)，依次調用列表中的觀(guān)察者的觀(guān)察接口(Update)，觀(guān)察者在觀(guān)察接口(Update)中，對感興趣的被觀(guān)察者變化進(jìn)行處理;

　　7、代理模式(PROXY)：主要用于代理數據庫操作，可以實(shí)現數據庫操作和業(yè)務(wù)操作的代碼分離;實(shí)現模式如下：

　　應用程序調用一個(gè)接口A(yíng)，B和C都實(shí)現A中的所有接口，其中B是知曉數據庫的代現，利用一個(gè)數據庫類(lèi)D進(jìn)行數據庫操作，然后委托相應的方法給C;代理模式使用不多，主要是在B類(lèi)中把方法再委托給C，在大多數情況下都沒(méi)有必要;

　　8、適配器模式(ADAPTER)：在一個(gè)穩定的架構中，增加一個(gè)外部組件，但該組件的接口不符合架構的規范，這時(shí)就可創(chuàng )建一個(gè)適配器類(lèi)對外部組件進(jìn)行封裝，適配器的接口符合架構的規范(這樣才能納入架構)，相應的方法委托給外部組件實(shí)現;這樣就可把外部組件納入到已有的架構中;另外，也可能是需要提供一個(gè)具有不同接口的組件給另外的客戶(hù)端使用，同時(shí)又要把該組合件的功能納入到已有的架構中，通過(guò)一個(gè)適配器把組件納入架構，另外的客戶(hù)端直接使用組件;

　　最后說(shuō)明：使用設計模式是有代價(jià)的，可能需要增加新的類(lèi)，編寫(xiě)額外的代碼，增加復雜度;優(yōu)勢就是，可以使系統更適應于功能需求的變化，包括功能修改和擴展，隔離變化等;可以提高代碼的重用率;所以對于設計模式，不能生搬硬套，而應是順勢而為。

【軟件技術(shù)方案設計原則】相關(guān)文章：

技術(shù)方案設計原則04-25

軟件技術(shù)專(zhuān)業(yè)自我評價(jià)07-05

選股票的原則07-04

MBA的面試原則07-01

股票成交原則07-02

股票的成交原則07-02

春分養生原則07-12

立冬養生原則07-05

面試的原則解析07-13

堅持HR的原則07-09