軟件設(shè)計(jì)的五大原則(編輯修改稿)
2024-09-11 23:47 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 urn Precedes(s)。 } private: static char* typeOrderTable[]。 }。 char* Shape::typeOrderTable[] = { typeid(Circle).name(), typeid(Square).name(), 0 }。 bool Shape::Precedes(const Shapeamp。 s) const{ const char* thisType = typeid(*this).name()。 const char* argType = typeid(s).name()。 bool done = false。 int thisOrd = 1。 int argOrd = 1。 for (int i=0。 !done。 i++){ const char* tableEntry = typeOrderTable[i]。 if (tableEntry != 0){ if (strcmp(tableEntry, thisType) == 0) thisOrd = i。 if (strcmp(tableEntry, argType) == 0) argOrd = i。 if ((argOrd 0) amp。amp。 (thisOrd 0)) done = true。 } else // table entry == 0 done = true。 } return thisOrd argOrd。 } ? 通過上述方法，我們成功地做到了一般情況下 DrawAllShapes函數(shù)對(duì)于順序問題的封閉，也使得每個(gè) Shape派生類對(duì)于新的 Shape派生類的創(chuàng)建者或者給予類型的 Shape對(duì)象排序規(guī)則的改變是封閉的。 ? 對(duì)于不同的 Shapes的繪制順序的變化不封閉的唯一部分就是表本身。可以把表放置在一個(gè)單獨(dú)的模塊中，和所有其他模塊隔離，因此對(duì)于表的改動(dòng)不會(huì)影響其他任何模塊。 – 事實(shí)上在 C＋＋中我們可以在鏈接時(shí)選擇要使用的表。 3. LisKov替換原則（ LSP） ? 陳述： – 子類型（ Subtype）必須能夠替換他們的基類型 (Basetype) Barbara Liskov對(duì)原則的陳述： 若對(duì)每個(gè)類型 S的對(duì)象 o1,都存在一個(gè)類型 T的對(duì)象 o2，使得在所有針對(duì) T編寫的程序 P中，用 o1替換 o2后，程序 P的行為功能不變，則 S是 T的子類型。 ? 分析： – 違法這個(gè)職責(zé)將導(dǎo)致程序的 脆弱 性和對(duì) OCP的違反 例如：基類 Base，派生類 Derived，派生類實(shí)例 d,函數(shù) f(Base* p)。 ? f(amp。d) 會(huì)導(dǎo)致錯(cuò)誤 顯然 D對(duì)于 f是脆弱的。 ? 如果我們?cè)噲D編寫一些測(cè)試，以保證把 d傳給 f時(shí)可以使 f具有正確的行為。那么這個(gè)測(cè)試違反了 OCP——因?yàn)?f無法對(duì) Base的所有派生類都是封閉的 ? 示例 1： struct Point{double x,y。}。 struct shape{ enum ShapeType{square,circle} itsType。 shape(ShapeType t):itsType(t){ } }。 struct Circle:public Shape{ Circle():Shape(circle){ }。 void Draw()const。 Point itsCenter。 double itsRadius。 }。 struct Square:public Shape{ Square():Shape(square){ }。 void Draw()const。 Point itsTopLeft。 double itsSide。 }。 void DrawShape(const Shapeamp。 s){ if(==Shape::square) static_castconst Squareamp。(s).Draw()。 else if (==Shape::circle) static_castconst Circleamp。(s).Draw()。 } 顯然， DrawShape違反了 OCP， 為什么？ 因?yàn)?Circle和 Square違反了 LSP ? 示例 2：一次更加奇妙的違規(guī) class Rectangle{ Point topLeft。 doulbe width。 double height。 public: void setWidth(double w){width=w。} void setHeight(double h){height=h。} double getWidth() const{return width。} double getHeight() const{return height。} }。 class Square:public Rectangle{ public: void setWidth(double w)。 void setHeight(double h)。 }。 void Square::setWidth(double w){ Rectangle::setWidth(w)。 Rectangle::setHeight(w)。 }。 void Square::setHeight(double h){ Rectangle::setWidth(h)。 Rectangle::setHeight(h)。 }。 R e c ta n g leS q u a r e– 問題的第一步分析： ? 看下面這個(gè)函數(shù) void f(Rectangleamp。 r){ (32)。 } 問題： 顯然，當(dāng)我們將一個(gè) Square的實(shí)例傳給 f時(shí)，將可能導(dǎo)致其 height與width不等，破壞了其完整性 ——違反了 LSP 要改正上述問題，很簡(jiǎn)單，我們只要將 SetWidth和 SetHeight兩個(gè)函數(shù)設(shè)置成virtual函數(shù)即可 ——添加派生類需要修改基類，通常意味著設(shè)計(jì)上的缺陷 但是并非所有人都同意上述的分析 反方：真正的設(shè)計(jì)缺陷是忘記把 SetWidth和 SetHeight兩個(gè)函數(shù)作為 virtual函數(shù) 正方：設(shè)置長(zhǎng)方形的長(zhǎng)寬是非?；镜牟僮?，不是預(yù)見到有正方形這樣的派生類，怎么會(huì)想到要將其設(shè)成虛函數(shù)？ – 放下這個(gè)爭(zhēng)論，我們先將 SetWidth和 SetHeight改作虛函數(shù)看看 class Rectangle{ Point topLeft。 doulbe width。 double height。 public: virtual void setWidth(double w){width=w。} virtual void setHeight(double h){height=h。} double getWidth() const{return width。} double getHeight() const{return height。} }。 class Square:public Rectangle{ public: void setWidth(double w)。 void setHeight(double h)。
黨政相關(guān)相關(guān)推薦
鄂ICP備17016276號(hào)-1