软件设计五大原则.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 放下这个争论，我们先将SetWidth和SetHeight改作虚函数看看 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); }; void Square::setWidth(double w){ Rectangle::setWidth(w); Rectangle::setHeight(w); }; void Square::setHeight(double h){ Rectangle::setWidth(h); Rectangle::setHeight(h); }; 看起来， 很不错！ 真正的问题： void g(Rectangle r){ r.setWidth(5); r.setHeight(4); assert(r.Area()==20); } 函数g不能操作Square的实例，Square不能替换Rectangle，所以违反了LSP LSP告诉我们： 孤立的看，我们无法判断模型的有效性 ——考虑一个设计是否恰当时，不能孤立的看待并判断，应该从此设计的使用者所作出的假设来审视它！ 事先的推测是困难的，我们采用敏捷的思想 ?推迟这个判断——“一个模型是否违反LSP”。直到出现问题的时候我们才解决它。 更加深入的思索： 这个看似明显正确的模型怎么会出错呢？ “正方形是一种长方形”——地球人都知道 错在哪里？ 对不是g函数的编写者而言，正方形可以是长方形，但是对g函数的编写者而言，Square绝对不是Rectangle！！ OOD中对象之间是否存在IS-A关系，应该从行为的角度来看待。 ?而行为可以依赖客户程序做出合理的假设。 基于契约（和约）的设计——DBC（Deign by Contract） “合理的假设”使人郁闷。 ——我怎么知道是否合理呢？？ 使用DBC，类的编写者需要显示的规定针对该类的契约。客户代码的编写者可以通过契约获悉行为的依赖方式。 契约通过为每一个方法规定前置条件（preconditions）和后置条件（postconditions）来指定的。要使一个方法执行，前置条件一定要为真（对客户的要求）；函数执行后要保证后置条件为真（对函数编写者的要求）。 基于契约（和约）的设计——DBC（Deign by Contract）（续） 例如： 在上面的例子中，Rectangle::SetWidth(double w)的后置条件可以看作是： assert((itsWidth==w) (itsHeight==old.itsHeight)); 基类和派生类在前置条件和后置条件上的关系是： 如果在派生类中重新申明了基类中已有的成员函数，这个函数只能使用相等或更弱的前置条件来替换原有的前置条件；并且，只能使用相等或更强的后置条件来替换原有的后置条件。 ?派生类必须接受基类已经接受的一切；并且，派生类不能违反基类已经确定的规则。 在一些语言中明确的支持契约，例如Eiffel，你申明它们，运行时系统会自动的检查。在Jave和C＋＋标准中尚未支持，我们必须自己考虑。 4. 依赖倒置原则（DIP） 陈述： 高层模块不应该依赖于低层模块。二者应该依赖于抽象。 抽象不应该依赖于细节。细节应该依赖于抽象。 分析： 所谓“倒置”是相对于传统的开发方法（例如结构化方法）中总是倾向于让高层模块依赖于低层模块而言的软件结构而言的。 高层包含应用程序的策略和业务模型，而低层包含更多的实现细节，平台相关细节等。高层依赖低层将导致： 难以复用。通常改变一个软硬件平台将导致一些具体的实现发生变化，如果高层依赖低层，这种变化将导致逐层的更改。 难以维护。低层通常是易变的。 层次化： “……所有良构的OO体系结构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。” ——Booch 对上述论述可能存在两种不同