您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 咨询培训 > 快播科技设计模式培训第1期(C)
设计模式第一讲设计原则主讲:林金星•第一章单一职责原则•第二章接口隔离原则•第三章里氏代换原则•第四章依赖倒转原则•第五章迪米特法则•第六章开放封闭原则你能从电脑设计想到如何进行软件设计吗?第一章单一职责原则定义:应该有且只有一个原因引起类的变化.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。单一职责的好处:•1、类的复杂性降低,实现什么职责都有清晰明确的定义;•2、可读性提高了,复杂性降低了,可读性自然也就提高了;•3、可维护性提高了,可读性提高了,那当然可读性就提高了;•4、变更引起的风险降低,变更是必不可少的,如果一个接口的单一职责做的好,一个接口的修改只对相应的实现类有影响,对其他接口无影响,这对系统的扩展性、维护性都有很大的帮助classcShape{public:virtual~cShape();virtualvoidDraw()=0;/*绘制图形*/virtualdoubleGetArea()=0;/*获取面积*/};classcSquare:publiccShape{public:voidDraw();doubleGetArea();voidSetWidth(doubledWidth);doubleGetWidth();private:doublem_dWidth;};现在有两个不同的应用程序用到了类cSquare,一个是有关几何计算方面的,另一个是有关图形方面的。对于前者而说,程序从来不需要绘制图形;而对于后者来说,程序也从来不需要计算图形的面积。在上面这种情况下,我们的设计就违反了单一职责原则。下面是一个符合单一职责原则的设计。在这个设计中,把原来的类cShape分为两个类:cGeometricShape和cGraphicalShape,来分别承担几何和图形两方面的职责。同样,分别派生出GGeometricSquare和cGraphicalSquare。classcGeometricShape{public:virtual~cGeometricShape();virtualdoubleGetArea()=0;};classGGeometricSquare:publiccGeometricShape{public:doubleGetArea();voidSetWidth(doubledWidth);doubleGetWidth();private:doublem_dWidth;};classcGraphicalShape{public:virtual~cGraphicalShape();virtualvoidDraw()=0;};classcGraphicalSquare:publiccGraphicalShape{public:voidDraw();voidSetWidth(doubledWidth);doubleGetWidth();private:doublem_dWidth;};第二章接口隔离原则接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口,应该把胖接口中的方法分组,然后用多个接口代替它,每个接口服务于一个子模块。接口隔离原则是对接口进行规范约束,其包含以下四层含义:1.接口尽量要小这是接口隔离原则的核心定义,不出现臃肿的接口。classIWorker{public:virtualvoidwork()=0;virtualvoideat()=0;};classWorker:publicIWorker{public:voidwork(){//....working}voideat(){//....eatinginlaunchbreak}};工厂改进生产后,买进一批机器人,如果机器人也继承IWorker,将会出现接口臃肿的情况。因为机器人不需要实现eat方法。classIWorkable{public:virtualvoidwork()=0;};classIFeedable{public:virtualvoideat()=0;};classWorker:publicIWorkable,IFeedable{public:voidwork(){//....working}voideat(){//....eatinginlaunchbreak}};classRobot:publicIWorkable{public:voidwork(){//....working}}但是“小”是有限度的,首先就是不能违反单一职责原则。classIConnectionManager{public:virtualvoiddial(char*number)=0;virtualvoidhuangup()=0;};classIDataTransfer{public:virtualvoidchat()=0;virtualvoidanswer()=0;};classPhone{private:IConnectionManager&cm;IDataTransfer&dt;};2.接口要高内聚什么是高内聚?高内聚就是提高接口、类、模块的处理能力,减少对外的交互。具体到接口隔离原则就是,要求在接口中尽量少公布public方法,接口是对外的承诺,承诺越少对系统的开发越有利,变更的风险也就越少,同时也有利于降低成本。3.定制服务一个系统或系统内的模块之间必然会有耦合,有耦合就要有相互访问的接口,我们设计时就需要为各个访问者(也就客户端)定制服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口要采用定制服务。采用定制服务就必然有一个要求:只提供访问者需要的方法。4.接口设计是有限度的接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度增加,可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度,这个“度”如何来判断的呢?根据经验和常识判断,没有一个固化或可测量的标准。第三章里氏代换原则定义:所有引用基类的地方必须能透明地使用其子类的对象。只有满足以下2个条件的OO设计才可被认为是满足了LSP原则:1.不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。if(objtypeofClass1){dosomething}elseif(objtypeofClass2){dosomethingelse}2.子类应当可以替换父类并出现在父类能够出现的任何地方,或者说如果我们把代码中使用基类的地方用它的子类所代替,代码还能正常工作,其它行为不会发生变化。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了:1.类的继承原则:如果一个继承类的对象可能会在基类出现的地方出现运行错误,则该子类不应该从该基类继承,或者说,应该重新设计它们之间的关系。2.动作正确性保证:从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。classRectangle{public:doublegetHeight(){returnm_height;}voidsetHeight(doubleheight){m_height=height;}doublegetWidth(){returnm_width;}voidsetWidth(doublewidth){m_width=width;}private:doublem_width;doublem_height;};classSquare:publicRectangle{public:voidsetHeight(doubleheight){Rectangle::setHeight(height);Rectangle::setWidth(height);}voidsetWidth(doublewidth){Rectangle::setHeight(width);Rectangle::setWidth(width);}};voidmain(){Squarer;r.setWidth(5);r.setHeight(4);if(r.getWidth()*r.getHeight()!=20){throwexception!!!\n;}}包含以下四层含义:1、子类必须完全实现父类的方法;2、子类可以有自己的特性;3、覆写或者实现父类的方法时输入的参数可以被放大;4、覆写或者实现父类的方法时输出的结果可以被缩小;classIConnectionManager{public:virtualIConnectionManager*self()=0;};classConnectionManager:publicIConnectionManager{public:ConnectionManager*self(){returnthis;};};classHTTPConnectionManager:publicConnectionManager{public:HTTPConnectionManager*self(){coutHTTPConnectionManagerreturnself\n;returnthis;};};实现好处:使用里氏替换原则的目的是增强程序的健壮性,版本升级时也可以保持非常好的兼容性,即使增加子类,原有的子类还是可以继续运行,在实际应用中,每个子类对应不同的业务含义,使用父类作为参数,传递不同的子类则可以完成不同的业务逻辑。当然,要使用子类的“个性化”业务逻辑,必须创建子类的对象,不过采用里氏替换原则设计类时,应尽量避免子类的“个性化”。第四章依赖倒转原则定义:高层模块不应该依赖底层模块,两者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象;我们现在来看看依赖有几种,依赖也就是耦合,分为下面三种1.零耦合(NilCoupling)关系,两个类没有依赖关系,那就是零耦合.2.具体耦合(ConcreteCoupling)关系,两个具体的类之间有依赖关系,那么就是具体耦合关系,如果一个具体类直接引用另外一个具体类,就会发生这种关系.3.抽象耦合(AbstractCoupling)关系.这种关系发生在一个具体类和一个抽象类之间,这样就使必须发生关系的类之间保持最大的灵活性.classQQCar{public:voidPutIntoGear(){std::cout挂档;};voidStepOnAccelerator(){std::cout踩油门;}voidControlDirection(){std::cout打方向;}};classPerson{public:Person(){m_car=newQQCar();}voiddrive(){m_car-PutIntoGear();m_car-StepOnAccelerator();m_car-ControlDirection();}private:QQCar*m_car;};例子中QQCar和Person类发生了具体耦合,如果Person类要开BMW牌子的车时,就需要更改Person类的代码,造成维护的困难。修改如下:classICar{public:virtualvoidPutIntoGear()=0;virtualvoidStepOnAccelerator()=0;virtualvoidControlDirection()=0;};classQQCar:publicICar{public:voidPutIntoGear(){cout挂档;};voidStepOnAccelerator(){cout“踩油门”;}voidControlDirection(){cout打方向”;}};ClassBMWCar:publicICar{public:voidPutIntoGear(){cout挂档;};voidStepOnAccelerator(){cout“踩油门”;}vo
本文标题:快播科技设计模式培训第1期(C)
链接地址:https://www.777doc.com/doc-976968 .html