宁静致远

SRP  单一职责原则        就一个类而言，应该仅有一个引起它变化的原因。OCP  开放——封闭原则       软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。LSP  Liskov替换原则       子类型必须能够替换掉它们的基类型。DIP  依赖倒置原则       抽象不应该依赖于细节。细节应该依赖于抽象。ISP  接口隔离原则  

第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易地阅读并理解它。一个无法进行沟通的模块也是拙劣的，同样需要对它进行修正。 

 　　在上一节中，我们设计了一个过滤器的抽象类，并且在客户代码中通过抽象，很好地利用了类的接口。瞧，抽象是多么地强大，多态是多么强大！天是蓝的，水是清的，生活真是美好啊（Copy某位大师的口吻^_^）。　　但是，不要高兴太早，问题来了。现在，我们有一个新的需求：　　为了提供更好的扩展性，要求每个过滤器除了提供一套默认规则之外，还要允许客户（即系统的使用者）可以根据需要对规则进行扩充，当然，

　　上一节，我们引入了一个不大不小的变更，然而不经思考的编码却给我们带来了不少麻烦。万不得以，只能重构。Class Filter{public: Filter(RuleReader *ruleReader); virtual ~Filter(); void InitRules(); virtual void CheckRequest(str

　　最近一段时间，笔者设计了一款过滤器插件，用以对某系统的用户请求进行过滤，本系列文章即记载了整个过滤器插件开发过程中的一些面向对象设计的小事，一方面见证笔者对面向对象设计的一次探索，另一方面也是记录下来供大家一起学习和讨探。　　在本系列文章中，您将会看到我们是如何从最初的过滤器类的抽象，利用面向对象原则、设计模式等，一步一步将我们的项目重构成为最终看起来还比较“优雅”的样子。由于我们这里只讨