个人独立博客http://www.acb0y.cn/

依赖倒转原则<br />     抽象不应该依赖细节，细节应该依赖于抽象。换句话就是说，针对接口编程，不要针对实现编程。<br />     A:高层模块不应该依赖底层模块，两个都应该依赖抽象。B:抽象不应该依赖细节。细节应该依赖抽象。<br />     里氏代换原则：一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件内部，把父类全部替换成子类程序的行为是不会发生改变的，简单地说，子类必须能够替换掉它们的父类型。<br />     只有当父类

抽象工厂模式<br />      抽象工厂模式（Abstract Factory）提高一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。<br />      AbstractProductA和AbstractProductB是两个抽象产品，之所以为抽象，是因为它们都有可能有两种不同的实现。<br />     AbstractFactory是一个抽象工厂接口，它里面应该包含所有的产品创建的抽象方法。而ConcreteFactory1和ConcreteFactory2就是具体的工厂了。<br

适配器模式<br />     适配器模式（Apater）将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。<br />     适配器模式主要解决什么问题呢？<br />     答：简单地说，就是需要的东西就在面前，但却不能使用，而短时间又无法改造它，于是我们就想办法适配它。<br />     系统的数据和行为都正确，但接口不符合时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用

迭代器模式<br />       迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中各个元素，而不是暴露该对象的内部表示。<br />     一个聚集对象，而且不管这些对象是什么都需要遍历的时候，你就应该考虑用迭代器模式。你需要对聚集有多种方式遍历时，可以考虑用迭代器模式。为遍历不同的聚集结构提供如开始，下一个，是否结束，当前哪一项等统一的接口。<br />UML图如下：<br /><br />C++实现代码如下：<br />/* Author: ACb0y Date: 2010

备忘录模式<br />    备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。<br />     Originator（发起人）：负责创建一个备忘录Memento，用以记录当前时刻它的内部状态，并可以使用备忘录恢复内部状态。Originator可根据需要决定Memento存储Originator的那些内部状态。<br />      Memento（备忘录）：负责存储Originator对象内部状态，并可防

组合模式<br />   组合模式(Composite)将对象组合成树形结构已表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 <br />UML图如下：<br /><br />C++代码实现如下：<br />/* Autohr： ACb0y Date：2010年12月20日16:37:17 Model：Composite（组合模式） */ #include <iostream> #include <string> #include <vecto

单例模式<br />       单例模式(Singleton)，保证一个类仅有一个实例，并提供一个访问它的全局访问点。<br />通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。<br />UML图如下：<br /><br />C++代码实现如下：<br />/* Author: ACb0y Date: 2010年12月21日11:10:16

合成/聚合复用原则      合成/聚合复用原则（CARP），尽量使用合成/聚合，不要使用类继承。     合成（Composition，也有翻译成组合）和聚合（Aggregation），都是关联的特殊种类。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成（组合）是一种强的“拥有”关系，体现了严格的部分与整体的关系，部分和整体的生命周期是一样的。     例如下面UML 描述：    优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类

桥接模式<br />      桥接模式(Bridge)，将抽象部分与它的实现部分分离，使它们都可以独立地变化。<br />什么叫抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。<br />      由于实现的方式多种，桥接模式的核心意图就是把这些实现独立出来，让它们各自地变化。这样就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。<br />     实现系统可能要多角度分类，每一种分类都有可能变化，那么就把这种多角

在Unix/Linux下模拟双机热备（客户端自适应方式）     最近突然对双机热备的切换的过程产生了浓厚的兴趣。晚上动手写了份代码模拟了，双机切换的过程。该模拟方式是通过客户端自适应的方式来实现。当一个客户端发现链接的服务器关闭之后，便链接备用服务器。具体描述如下：

状态模式<br />      状态模式(State)，当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。<br />状态模式主要解决的是当控制一个对象的状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。<br />UML图如下：<br /><br />C++代码实现如下：<br />/* Author: ACb0y Date: 2010年12月18日21:33:26 Model: State（状态模式）

<br />观察者模式<br />      观察者模式又叫做发布-订阅(Publish/Subscribe)模式。<br />观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。<br /> <br />UML图如下：<br />C++实现代码如下：<br />/* Author: ACb0y Date: 2010-12-17 Model: Observer */ #include <io

代理模式    代理模式(Proxy)，为其他对象提供一种代理以控制对这个对象的访问。Subject类定义了RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy。UML图如下：C++实现代码如下：/* Author: ACb0y Date: 2010年12月15日18:32:26 Model: Decorator（装饰模式） */ #include #include using namespace std; //抽

简单工厂VS工厂方法<br />     简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于一个客服端来说，去除了于具体产品的依赖，但是如果要加一个新的类来完成新的功能，我们是一定需要给运算工厂类的方法里加"case"的分支条件的，而这就修改了原来的类，从而违背了开放-封闭原则。<br />    对于变化的需求，工厂方法只需要增加相关的类和相应的工厂类就可以了，这样整个工厂和产品体系其实都没有修改的变化，而只是扩展了变化，这就完全符合了开放-封闭原则。<b

开放-封闭原则<br />     软件设计的实体（类、模块、函数等等）应该可以扩展，但是不可以修改。就是说对于扩展是开放的，(open for extension)， 对于更改是封闭的(closed for modification)<br />     无论是模块是多么的‘封闭’，都会存在一些无法对之封闭的变化，既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化进行封闭做出选择。作为一名优秀的软件设计者，要能预测出最有可能发生的变化种类，然后构造抽象来隔离哪些变化。<br />     变化

策略模式     策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。策略模式的结构图如下：策略模式剖析：     策略模式是一种定义一系列算法的方法，从概念上看，所有这些算法完成都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少各种算法类与使用算法类之间的耦合。策略模式的Strategy类层次为Context定义了一系列可供重用的算法或行为。继承有助于抽象出这些算法的公共功能。      策略模式的优点是简化了单元测试，因为每个算法

装饰模式     动态地给一个对象添加一些额外的职责，就增加工能来说，装饰模式比生成子类更为灵活。Component是定义一个对象接口，可以这些对象动态添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator存在的。至于ConcreteDecorator就是具体的装饰对象起到给Component添加职责的功能。UM

/* */ #include using namespace std; class LeiFeng { public: virtual void Sweep() { cout

模板方法模式<br />    定义了一个操作中的算法的骨架，而将一些步骤延迟到了子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。<br />     当我们要完成在某一细节层次一致的一个过程或一系列步骤，但某个别步骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法来处理。<br /> <br />UML图如下：<br /><br /> <br />C++实现代码如下：<br /> <br />/* Author: ACb0y Date: 2010年12月16

外观模式<br />      为了系统中一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。<br /> <br />UML图如下：<br /><br /> <br />C++代码实现如下：<br /> <br />/* Author: ACb0y Date: 2010年12月16日12:29:59 Model: Facade（外观模式） */ #include <iostream> using namespace std; class

单一职责原则(SRP)<br />      就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏性。<br />      软件设计真正要做到的许多内容，就是发现职责并把职责相互分离。<br />      如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

一起来学POSIX thread 之 综合应用——线程池 1、为什么需要线程池？ 部分应用程序需要执行很多细小的任务，对于每个任务都创建一个线程来完成，任务完成后销毁线程，而这就会产生一个问题：当执行的任务所需要的时间T1小于等于创建线程时间T2和销毁线程时间T3总和时即T1 ，应用处理任务的响应能力会大大减弱，从而影响了应用程序性能，为了解决这类问题，线程池技术提供了很好的解决方案。