C++设计模式和设计原则.doc

《C++设计模式和设计原则.doc》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、单一职责原则SRP·定义就一个类而言，应该仅有一个引起它变化的原因。变化是指具体类的改变，如一个moden类具有连接管理和数据通讯的功能，那么这个类就有连接管理和数据通讯这两个变化方向，此时就违背了“单一职责的原则”。·关于“单一职责”“单一职责”也就是“单一变化原因”。“职责”也就是引起类变化的原因。“单一职责原则”是面向对象设计的第一个基本原则，它可能是最简单的也可能是最难运用的一个原则！通常，一个类的“职责”越多，导致其变化的因素也就越多。因为每个职责都可能是一个变化的轴线。这与我们在设计类时所采用的方法有关系。一般情况下，我们在设计一个类的时候会把与该类

2、有关操作都组合到这个类中，这样做的后果就有可能将多个职责“耦合”到了一块，当这个类的某个职责发生变化时，很难避免类的其它部分不受影响，这最终导致程序的“脆弱”和“僵硬”。解决这种问题的方法就是“分耦”，将不同的职责分别进行封装，不要将其组合在一个类中，使这个类只有一个可能会引起它变化的原因。这样做将会使你的程序易于修改和维护。但这个过程可能是很困难的，因为我们不总是能轻易知道那些职责会发生变化，那些职责应该被提取出来。所以，你的程序可能会有一个演化的过程，从中得出这些会发生的职责并进行另外的封装。需要注意的一点就是当实标情况中的职责确实发生了变化，应用该原则才是

3、有意义的。如果一个类组合了多个职责，但这些职责在实际情况中根本不会发生变化，那完全没有必要提前费尽心机去应用这个原则。总结： SRP好处： 消除耦合，减小因需求变化引起代码僵化性臭味 注意点： 1.一个合理的类，应该仅有一个引起它变化的原因，即单一职责； 2.在没有变化征兆的情况下应用SRP或其他原则是不明智的； 3.在需求实际发生变化时就应该应用SRP等原则来重构代码； 4.使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码； 4.如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用Facade或Proxy模式对代码重构； 实例： 违

4、反SRP原则代码:modem接口明显具有两个职责：连接管理和数据通讯； classModem{   publicvoiddial(stringpno);   publicvoidhangup();   publicvoidsend(charc);   publicvoidrecv();} 此时应该把的modem的两个职责分到两个类中 classDataChannel{   publicvoidsend(charc);   publicvoidrecv();} classConnection{   publicvoiddial(stringpno);   publ

5、icvoidhangup();}新的modem类：classmodem{//构造      publicmodem()      {            datachannel=newDataChannel();            con=newConnection();      }//字段   privateDataChannel datachannel;    private Connection con;//操作    publicvoiddial(stringpno)      {            datachannel.dial();  

6、    }   publicvoidhangup()      .......    publicvoidsend(charc)      .......   publicvoidrecv()      .......}  一、什么是开放封闭原则    开放封闭原则(Open-ClosedPrinciple)：一个软件实体应当对扩展开放，则修改关闭。    在设计一个模块时，应当使得这个模块可以在不被修改的前提下被扩展。也就是说，应当可以在不必修改源代码的情况下修改这个模块的行为。    设计的目的便在于面对需求的改变而保持系统的相对稳定，从而使得系统可以很容易

7、的从一个版本升级到另一个版本。二、怎样做到开放封闭原则    实际上，绝对封闭的系统是不存在的。无论模块是怎么封闭，到最后，总还是有一些无法封闭的变化。而我们的思路就是：既然不能做到完全封闭，那我们就应该对那些变化封闭，那些变化隔离做出选择。我们做出选择，然后将那些无法封闭的变化抽象出来，进行隔离，允许扩展，尽可能的减少系统的开发。当系统变化来临时，我们要及时的做出反应。    我们并不害怕改变的到来。当变化到来时，我们首先需要做的不是修改代码，而是尽可能的将变化抽象出来进行隔离，然后进行扩展。面对需求的变化，对程序的修改应该是尽可能通过添加代码来实现，而不是通

8、过修改代码来实现。