軟件設(shè)計的五大原則-wenkub
2022-09-12 23:47:07 本頁面
【正文】 rawAllShapes(VectorShape*amp。 class Square:public Shape{ public: virtual void Draw() const。 case circle: sDrawCircle()。in。 }。 }。 }。 ?OCP原則其實是要求我們清晰的區(qū)分策略和策略的具體實現(xiàn)形式。 public: void ServerFunc()。 } }。 2. 開放封閉原則（ OCP） – 例子 1（續(xù)） 修改后的設(shè)計 class client{ ClientInterfaceamp。 s。 class server1{ int serverData。 } }。 見下頁程序 2. 開放封閉原則（ OCP） – 例子 1（續(xù)） class client{ serveramp。 public: void ServerFunc()。 public: client(serveramp。 例如： E m p l o y e e+ C a l c u l a t e P a y+ S t o r eP e r s i s t e n c e S u b s y s t e m 業(yè)務(wù)規(guī)則經(jīng)常變化，而持久化方法卻一般不變。 但是我們注意到，對于應(yīng)用的其它部分，通過接口的分離我們已經(jīng)實現(xiàn)了職責(zé)的分離。 ? 連接和通信同時變化 這種情況下，不必將職責(zé)分開。 }。 – 修改后的設(shè)計如下： C o m p u t a t i o n a l G e o m e t r y A p p l i c a t i o nG r a p h i c a l A p p l i c a t i o nG e o m e t r i c R e c t a n g l e+ a r e a ( ) : d o u b l eR e c t a n g l e+ d r a w ( )G U IModem類（可能）有兩個職責(zé)： 1. 撥號 2. 通信 ? 示例 2： 一個 Modem的接口： Class Modem{ public: virtual void dail(char* pno)=0。軟件設(shè)計中的 5大原則 1. 單一職責(zé)原則（ SRP） ? 陳述： – 就一個類而言，應(yīng)該只有一個導(dǎo)致其變化的原因 ? 分析： – 一個職責(zé)就是一個變化的軸線 – 一個類如果承擔(dān)的職責(zé)過多，就等于將這些職責(zé)耦合在一起。 virtual void hangup( ) =0。 – 什么是職責(zé)？ 職責(zé)是 “ 變化的原因 ” 。反而分離可能導(dǎo)致 “ 不必要的復(fù)雜性 ”的臭味 刻舟求劍是錯誤的。 ModemImplementation已經(jīng)不被其它任何程序所依賴。將這兩個職責(zé)耦合在一起，將導(dǎo)致每次因為業(yè)務(wù)規(guī)則變化調(diào)整Employee類時，所有持久化部分的代碼也要跟著變化 2. 開放封閉原則（ OCP） ? 陳述： – 軟件實體（類、模塊、函數(shù)等）應(yīng)該是可以擴展的，同時還可以是不必修改的，更確切的說，函數(shù)實體應(yīng)該： （ 1）對擴展是開放的 當(dāng)應(yīng)用的需求變化時，我們可以對模塊進行擴展，使其具有滿足改變的新的行為 ——即，我們可以改變模塊的功能 （ 2）對更改是封閉的 對模塊進行擴展時，不必改動已有的源代碼或二進制代碼。 SER):s(SER) {} void useServer(){ ()。 }。 s。 class server{ int serverData。 public: void ServerFunc()。 public: client(serveramp。 ci。 class ClientInterface{ virtual void ServerFunc()=0。 }。允許 擴展具體的實現(xiàn)形式（開放），同時將這種擴展與策略隔離開來，使 其對上層的策略透明（封閉）。 struct Circle{ ShapeType itsType。 struct Square{ ShapeType itsType。 typedef struct Shape * ShapePointer。i++){ struct Shape* s=list[i]。 break。 }。 list){ vectorShape*::iterator i。 } – 例子 2（續(xù)） ? 再看這些批判 再加入 “ 三角形 ” 將變得十分簡單： – 僵化的 增加 Triangle會導(dǎo)致 Shape、 Square、 Circle以及 DrawAllShapes的重新編譯和部署 – 脆弱的 因為存在大量的既難以查找又難以理解的 Switch和 If語句，修改稍有不慎，程序就會莫明其妙的出錯 – 牢固的 想在一個程序中復(fù)用 DrawAllShapes，都必須帶上 Circle、 Square，即使那個程序不需要他們 ? 謊言： – 上述代碼并不完全封閉 ——“如果我們希望正方形在所有圓之前繪制 ” 會怎么樣？ ——對繪圖的順序無法實現(xiàn)封閉 ?更糟糕的是，剛才的設(shè)計反而成為了實現(xiàn) “ 正方形在所有圓之前繪制 ” 功能的障礙。 bool operatorconst Shapeamp。} } void DrawAllShapes(vectorShape*amp。 for(i=()。 s) const{ if (dynamic_castSquare*(s)) return true。 virtual bool Precedes(const Shapeamp。 } private: static char* typeOrderTable[]。 s) const{ const char* thisType = typeid(*this).name()。 int argOrd = 1。 if (tableEntry != 0){ if (strcmp(tableEntry, thisType) == 0) thisOrd = i。 (thisOrd 0)) done = true。 ? 對于不同的 Shapes的繪制順序的變化不封閉的唯一部分就是表本身。 ? 分析： – 違法這個職責(zé)將導(dǎo)致程序的 脆弱 性和對 OCP的違反 例如：基類 Base，派生類 Derived，派生類實例 d,函數(shù) f(Base* p)。那么這個測試違反了 OCP——因為 f無法對 Base的所有派生類都是封閉的 ? 示例 1： struct Point{double x,y。 struct Circle:public Shape{ Circle():Shape(circle){ }。 }。 double itsSide。(s).Draw()。 doulbe width。} double getWidth() const{return width。 void setHeight(double h)。 }。 R e c ta n g leS q u a r e– 問題的第一步分析： ? 看下面這個函數(shù) void f(
黨政相關(guān)相關(guān)推薦
鄂ICP備17016276號-1