軟件工程面向?qū)ο蟮脑O(shè)計原則資料

1、面向?qū)ο蟮脑O(shè)計原則和設(shè)計模式北京化工大學(xué)計算機系袁國棟面向?qū)ο蟮脑O(shè)計原則一個好的系統(tǒng)設(shè)計應(yīng)該包括至少三個性質(zhì)：可擴展性，和插入性和靈活 性。面 向?qū)ο笤O(shè)計的原則開閉原則（open-closed principle ocp 一個軟件實體應(yīng)該對擴展開放，對 修改關(guān)閉。模塊設(shè)計時，使得該模塊可以在不被修改的前提下被擴展。也即就當可以在不必修改源代碼的情況下改變這個模塊的行為不能修改而可以擴展是不允許更改系統(tǒng)的抽象層，而允許擴展的是系統(tǒng)的實現(xiàn)層 如何做到既不修改，又可以擴展?抽象化讓模塊依賴于一個固定的抽象體，這樣它就是不可以修改的；同時，通 過這個抽象體派生，就可以擴展此模塊的行為功能。這樣設(shè)計的程

2、序只通過 增加代碼來變化而不是通過更改現(xiàn)有代碼來變化。ocp實part以上函數(shù)的工作是在制訂的電腦部件數(shù)組中計算各個部件價格的總和。若是一個基類或接口且使用了多態(tài)，則該類可很容易地來適應(yīng)新類型的部 件，而不必對其進行修改。其將符合ocp但是在計算總價格時，若財務(wù)部頒布主板和內(nèi) 存應(yīng)使用額外費用，則將如何去做列的代碼是如何來做的呢?每當計價策略發(fā)生改變, 我們就必須修改part的每個子類采用一個pricepolicy類，通過對其進行繼承以提供不同的計價策略；所做 的就是將問題推遲到另一個類中，將“變化”封裝在pricepolicy類里面；但 是使用該解決方案，可通過改變part對象，在運行期間動

3、態(tài)地來設(shè)定計價的 策略。單一職責原則(srp: the single responsibility principle就一個類而言，應(yīng)該僅有一個引起它變化的原因，如果你能想到多于一個 的動機 去改變一個類，那么這個類就具有多于一個的職責.應(yīng)該把多于的職責 分離出去，分別再創(chuàng)建一些類來完成每一個職責.系統(tǒng)中的每一個對象都應(yīng)該 只有一個單獨的職責，而任何對象所關(guān)注的就是自身職責的完成實例dbmanager類對數(shù)據(jù)庫的操作和用戶權(quán)限的判別封裝在一個類中實現(xiàn)public void add(if (getpermission(m_id = canaddconsole.writeline(管理員可以增加數(shù)

4、據(jù)。權(quán)限判斷的職責、數(shù)據(jù)庫操作的職責被無理的實現(xiàn)在一個類中，權(quán)限的規(guī) 則變化和數(shù)據(jù)庫操作的規(guī)則變化，都有可能引起dbmanager修改當前代碼。 按照單一職責原則，一個類應(yīng)該只有一個引起它改變的原因。所以我們選擇以合適的方式來重構(gòu)有缺陷的設(shè)計，在此顯 然可以通過實現(xiàn)一個proxy模式來解決職責交叉的問題public class dbmanager jdbaction private string m_id=string.empty;public dbmanager(stringid m_id=id; idbaction members public class dbmanagerproxy j

5、dbaction private idbaction dbmanager;public dbmanagerproxy(idbactiondbaction dbmanager =dbaction; public string getpermission(stringid return string.empty; idbaction members public class dbciient static void main(stringargs idbaction dbmanager =newdbmana gerproxy(newdbmanager(hcanadd;dbmanager.add;一

6、個軟件實體如果使用的是一個基類的話那么一定適用于其子類，而 且它察覺不出基類對象和子類對象的區(qū)別。也就是說，在軟件里面，把基 類都替換成它的子類，程序的行為沒有變化。lsp是繼承復(fù)用的基石, 只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能 真正被復(fù)用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。長方形和正 方形實例dependency inversion principle高層模塊不應(yīng)該依賴于低層模塊，二者都應(yīng)該依賴于抽象抽象不應(yīng)該依賴于 細節(jié),細節(jié)應(yīng)該依賴于抽象高層模塊包含了一個應(yīng)該程序中的重要的策略選擇 和業(yè)務(wù)模型，正是這些高層模塊才使得其所有的應(yīng)用程序區(qū)別于其他，如果高

7、層依賴于低層,那么對低層模塊的改動就會直接影響到高層模塊，從而迫使它們 依次做出改動缺點：耦合太緊密，light發(fā)生變化將影響toggleswitch怎么辦?將light作成abstract ,然后具體類繼承自light優(yōu)點:toggleswitch依賴于抽象類light ,具有更高的穩(wěn)定性，而bulblight 與 tubelight 繼承自light,可以根據(jù)”開放一封閉”原則進行擴展。只要light不發(fā)生變化，bulblight與tubelight的變化就不會波及 toggleswitch。如果用togglesw讓ch控制一臺電視就很困難了。總不能讓tv繼承自light 吧任何變量都不應(yīng)

8、該持有一個指向具體類的指針或者引用任何類都不應(yīng)該從具 體類派生（始于抽象，來自具體任何方法都不應(yīng)該覆寫它的任何基類中的已經(jīng) 實現(xiàn)了的方法定義客戶端不應(yīng)該依賴它不需要的接口類間的依賴關(guān)系應(yīng)該建立在最小的接口上一句話：建立單一接口，不要建立臃腫龐大的接口。再通俗一點講：接口盡 量細化，同時接口中的方法盡量少。提供給每個模塊的都應(yīng)該是單一接口，提 供給幾個模塊就應(yīng)該有幾個接口，而不是建立一個龐大的臃腫的接口，容納所 有的客戶端訪問?！皻W火ti有a接口要盡重這是接口隔離原則的核心定義，不出現(xiàn)臃腫的接口( fat interface),但是 “小”是有限度的，首先就是不能違反單一職責原則。根據(jù)接口隔離原

9、則拆分接口時，首先必須滿足單一職責原則 接口要高內(nèi)聚高內(nèi)聚就是要提高接口類 模塊的處理能力，減少對外的交互。具體到接 口隔離原則就是，要求在接口中盡量少公布public方法，接口是對外的承諾， 承諾地越少對系統(tǒng)開發(fā)越有利，變更的風險也就越少，同時也有利于降低成 本o定制服務(wù)定制服務(wù)就是單獨為一個個體提供優(yōu)良的服務(wù)。接口的設(shè)計粒度越小，系統(tǒng) 越靈活，這是不爭的事實。但是，靈活的同時也帶來了結(jié)構(gòu)的復(fù)雜化，開發(fā)難 度增力口，可維護性降低，這不是一個項目或產(chǎn)品所期望看到的，所以接口設(shè)計 一定要注意適度，這個度只能根據(jù)經(jīng)驗和常識判斷，沒有一個固化或可測量的 標準接口設(shè)計是有限度的迪米特原則一個軟件實體應(yīng)當盡可能少的其他實體發(fā)生相互作用。模塊之間的交互要少 這樣做的結(jié)果是當系統(tǒng)的功能需要擴展時，會相對更容易地做到對修改的關(guān)閉。一個對象應(yīng)當對其他對象有盡可能少的了解。迪米特原則的具體操作 優(yōu)先考慮將一個類設(shè)置成不變類。不變類易于設(shè)計 實現(xiàn)