设计模式笔记（C++）
一、创建型
Factory：工厂
1、定义创建对象的接口，封装了对象的创建
2、使得具体化类的工作延迟到了子类中
3、Factory模式正如我在相应的文档中分析的是为一类对象提供创建接口或者延迟对象的创建到子类中实现。
AbstractFactory：抽象工厂
1、创建一组相关或者相互依赖的对象
2、AbstractFactory模式是为创建一组（有多类）相关或者依赖的对象提供创建接口
3、AbstractFactory模式通常都是使用Factory模式实现（ConcreateFactroy）
Singleton：单例
1、Singleton模式保证一个类仅有一个对象，并提供一个访问它的全局访问点。
2、全局变量不能防止实例化多个对象。
3、全局变量将使得对象在无论是否用到都要被创建。
Builder：创建者
1、Builder模式的意图是非常容易理解、间接的：将一个复杂对象的构建与它的表示分离，使用同样的构建过程可以创建不同的表示（在示例代码中可以通过传入不同的参数实现这一点）。Builder模式和AbstractFactory模式在功能上很相似，因为都是创建大的复杂的对象，它们的区别是：Builder模式强调的是一步步创建对象，并通过相同的创建过程可以获得不同的结果对象，一般来说Builder模式中对象不是直接返回的。而在AbstractFactory 模式中对象是直接返回的，AbstractFactory模式强调的是为创建多个相互依赖的对象提供一个同一的接口。
Prototype：原型
1、Prototype模式通过复制原型（Prototype）而获得新对象创建的功能，这里Prototype本身就是“对象工厂”（因为能够生产对象），实际上Prototype 模式和Builder模式、AbstractFactory模式都是通过一个类（对象实例）来专门负责对象的创建工作（工厂对象），它们之间的区别是：Builder模式重在复杂对象的一步步创建（并不直接返回对象），AbstractFactory模式重在产生多个相互依赖的对象，而Prototype模式重在从自身复制自己创建新类。
二、结构型
Bridge：桥梁
1、Bridge模式将抽象和实现分别独立实现
2、Bridge中设计模式中比较复杂和难理解的模式之一，也是OO开发与设计中经常会用到的模式之一。使用组合（委托）的方式将抽象和实现彻底地解耦，这样的好处是抽象和实现可以分别独立地变化，系统的耦合性也得到了很好的降低。
3、使用Bridge模式和使用带来问题方式的解决方案的根本区别在于是通过继承还是通过组合的方式去实现一个功能需求。
Adapter：适配器
1、Adapter模式的两种类别：类模式和对象模式
2、类模式Adapter中，我们通过private继承Adaptee获得实现继承的效果，而通过public继承Target获得接口继承的效果。
3、在Adapter模式的两种模式中，有一个很重要的概念就是接口继承和实现继承的区别和联系。接口继承和实现继承是面向对象领域的两个重要的概念，接口继承指的是通过继承，子类获得了父类的接口，而实现继承指的是通过继承子类获得父顺的实现（并不统共接口）
Decorator：装饰者
1、Decorator提供了一种给类增加职责的方法，不是通过继承实现，而是通过组合。
2、Decorator模式除了采用组合的方式取得了比采用继承方式更好的效果，Decorator模式还给设计带来一种“即用即付”的方式来添加职责。
Composite：组成、树
1、递归构建树状的组合结构
2、Composite模式通过和Decorator模式有着类似的结构图，但是Composite 模式旨在构造类，而Decorator模式重在不生成子类即可给对象添加职责。Decorator模式重在修饰，而Composite模式重在表示。
Flyweight：享元
1、
2、
Flyweight模式中有一个类似Factory模式的对象构造工厂FlyweightFactory，当客户程序员（Client）需要一个对象的时候就会向FlayweigthFactory发出请
求对象的消息GetFlyweigth（）消息，FlyweightFactory拥有一个管理、存储对象的“仓库”（或者叫对象池，vector实现），GetFlyweight（）消息会遍历对象池中的对象，如果已经存在则直接返回给Client，否则创建一个新的对象返回给Client。当然可能也有不想被共享的对象（例如结构图中的UnshareConcreateFlyweight），但不在本模式的讲解范围，故在实现中不给出。
Facade：外观
1、
2、
Facade模式在高层提供了一个统一的接口，解耦了系统。设计模式中还有另一种模式Mediator也和Facade有类似的地方。但是Mediator主要目的是对象间的访问的解耦。
Proxy：代理
1、Proxy模式最大的好处就是实现了逻辑和实现的彻底解耦。
2、虚代理（Virtual Proxy）
3、远程代理（Remoto Proxy）
4、保护代理（Protection Proxy）
5、智能指针（Smart Pointer）
三、行为
Template：模板
1、对于某一个业务逻辑（算法实现）在不同的对象中有不同的细节实现，但是逻辑（算法）的框架（或通用的应用算法）是相同的。Template提供了这种情况的一个实现框架。
2、Template模式是采用继承的方式实现这一点：将逻辑（算法）框架放在抽象基类中，并定义好细节接口，子类中细节。
3、Strategy（策略）模式解决的是和Template模式类似的问题，但是Strategy 模式是将逻辑（算法）封装到一个类中，并采取组合（委托）的方式解决这个问题。
4、Template模式是很简单模式，但是也应用很广的模式。如上面的分析稆实现中阐明的Template是采用继承方式实现算法的异构，其关键点就是通用算法封装在抽象基类中，并将不同的算法细节放到子类中实现。Template模式获得一种反向控制结构效果，这也是面向对象系统的分析和设计中一个原则DIP（依赖倒置：Dependency Inversion Principles）。其含义就是父类调用子类的操作（高层模块调用低层模块的操作），低层模块实现高层模块声明的接口。这样控制权在父类（高层模块），低层模块反而要依赖高层模块。
Template模式实际上就是利用面向对象中多态的概念实现算法实现细节和高层的接口的松耦合。可以看到Template模式采取的是继承方式实现这一点的，由于继承是一种强制约束性的条件，因此也给Template模式带来一些许多不方便的地方。
Strategy：策略
1、Strategy模式和Template模式要解决的问题是相同（类似）的，都是为了给业务逻辑（算法）具体实现和抽象接口之间的解耦。Strategy模式将逻辑（算法）封装到一个类（Context）里面，通过的方式将具体算法的实现在组合对象中实现，再通过委托的方式将抽象接口的实现委托给组合对象实现。State模式也有类似的功能。
2、Strategy模式和Template模式实际是实现一个抽象接口的两种方式：
继承和组合之间的区别。
3、继承：
优点：
（1）易于修改和扩展那些被利用的实现
缺点：
（1）破坏了封装性，继承中父类的实现细节暴露给子类了
（2）“白盒”复用
（3）当父类的实现更改时，其所有子类将不得不随之改变
（4）从父类继承而来的实现在运行期间不能改变（编译期间就已经确定了）4、组合
优点：
（1）“黑盒”复用，因为被包含对象的内部细节对外是不可见的
（2）封装性好
（3）实现和抽象的依赖性很小（组合对象和被组合对象之间的依赖性小）（4）可以在运行其它动态定义实现（通过一个指向相同类型的指针，典型的是抽象类的指针）
缺点：
（1）系统中对象过多
5、面向对象的设计中的有一条很重要的原则就是：优先使用（对象）组合，而非（类）继承（Favor Composition Over Inheritance）
6、Strategy模式和State模式也有相似之处，但是State模式注重的对象在不同的状态下不同的操作。两者之间的区别就是State模式中具体实现类中有一个指向Context的引用，而Strategy模式则没有。
State：状态
1、将State声明为Context的友元类（Friend Class），其作用是让State模式访问Context的protected接口ChangeState（）
2、State及其子类中的操作都将Context*传入作为参数，其主要目的是State 类可以通过这个指针调用Context中的方法（在本示例代码中没有体现）。这也是State模式和Strategy模式的最大区别所在。
3、State和Strategy
相同：
它们都有一个Context类，都是通过委托（组合）给一个具有多个派生类的多态基类实现Context的算法逻辑。
区别：
State模式中派生类持有指向Context对象的引用，并通过这个引用调用
Context中的方法，但在Strategy模式中就没有这种情况。因此可以说一个State 实例同样是Strategy模式的一个实例，反之却不成立。State模式主要是要适应对象对于状态改变时的不同处理策略的实现，而Strategy则主要是具体算法和实现接口的解耦（coupling），Strategy模式中并没有状态的概念（虽然很多时候有可以看作是状态的概念），并且更加不关心状态的改变。
Observer：观察者
1、Observer模式应该可以说是应用最多、影响最广的模式之一，因为Observer 的一个实例Model/View、Control（MVC）结构在系统开发架构设计中有着很重要的地位和意义，MVC实现了业务逻辑和表示层的解耦。个人也认为Observer模式是软件开发过程中必须要掌握和使用的模式之一。
2、Observer模式要解决的问题为：建立一个一（Subject）对多（Observer）的依赖关系，并且做到当“一”变化的时候，依赖这个“一”的多也能够同步改
变。
Memento：备忘
1、Memento模式的关键就是在不破坏封装的前提下，捕获并保存一个类的内部状态，这样就可以利用保存的状态实施恢复操作。
2、
Mediator：中介者
1、Mediator模式提供将对象间的交互和通讯封装在一个类中，各个对象间的通信不必显式去声明和引用，大大降低了系统的复杂性能。
2、Mediator模式还带来了系统对象间的松耦合
Command：命令
1、Command模式通过将请求封装到一个对象（Command）中，并将请求的接受者存放到具体的ConcreateCommand类中（Receiver）中，从而实现调用操作的对象和操作的具体实现者之间的解耦。
2、模板类的构造函数必须要实现，要不编译通过，连接不上，错误提示也不准确（模板类的函数指针）
Command模式结构中，将请求的接收者（处理者）放到Command的具体子类ConcreateCommand中，当请求到来时（Invoker发出Invoke消息激活Command对象），ConcreateCommand将处理请求交给Receiver对象进行处理。
Visitor：访问者
1、Visitor模式则提供了一个解决方案：将更新（变更）封装到一个类中（访问操作），并由待更改类提供一个接收接口，则可达到效果。
2、
创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor （抽象工厂） 提供一个创建一系列相关或互相依赖对象的接口，而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB
23种设计模式趣味讲解 对设计模式很有意思的诠释，呵呵，原作者不详。 创立型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，固然口味有所不同，但不管你带MM往麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类离开。花费者任何时候需要某种产品，只需向工厂恳求即可。花费者无须修正就可以接纳新产品。毛病是当产品修正时，工厂类也要做相应的修正。如：如何创立及如何向客户端供给。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同处所的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM 我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这必定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的天生过程分割开来，从而使一个建造过程天生具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变更，客户不必知道产品内部组成的细节。建造模式可以强迫履行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM往麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创立，而是将具体创立的工作交给子类往做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的串口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，必定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创立的对象的类型，然后用复制这个原型对象的方法创立出更多同类型的对象。原始模型模式容许动态的增加或减少产品类，产品类不需要非得有任何事先断定的等级结构，原始模型模式实用于任何的等级结构。毛病是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个美丽的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，
如何更改用户配置文件和程序设置的默认位置 文章编号: 322014 最后修改: 2006年4月20日 移动用户的Documents and Settings 文件夹 概要 本文介绍了如何移动用户的Documents and Settings 文件夹。 所有用户的配置文件信息均存储在“%系统驱动器%\Documents and Settings”文件夹中。如果尝试在Windows 中移动或重命名用户的Documents and Settings 文件夹，您将收到以下错误消息：Documents and Settings 是Windows 系统文件夹，Windows 需要它才能正常运行，因此不能移动或重命名。 注意：本文包含有关Microsoft 不支持的配置的信息。Microsoft 提供此信息仅供参考；Microsoft 不能保证此配置可以正常运行。 警告：Microsoft 强烈建议不要重命名任何系统文件夹。如果重命名系统文件夹，可能会导致系统故障或计算机性能不稳定。使用本文中的信息之前，请备份您的计算机。 回到顶端 移动用户的Documents and Settings 文件夹 警告：注册表编辑器使用不当可导致严重问题，可能需要重新安装操作系统。Microsoft 不能保证您可以解决因注册表编辑器使用不当而导致的问题。使用注册表编辑器需要您自担风险。 注意：此方法并不会重新定位重要的Windows 组件。此方法仅用于移动用户特定的数据。 1. 确定用户的配置文件路径。确定配置文件路径有两种方法。可以使用以下两种方法中的任一种（首选用户SID 方法）：? 用户SID 方法：a. 使用Windows Server Resource Kit 中的Getsid 工具获取SID。使用与以下示例类似的语法： getsid \\server1username \\server1username b. 获取SID 之后，使用Regedit.exe 或Regedt32.exe 在以下注册表项之下选择用户的SID： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList ? 用户路径设置方法：a. 以用户身份登录到计算机，然后在命令提示符处键入set。记下USERPROFILE 的设置，然后关闭命令提示符窗口。 b. 以计算机管理员的身份登录。 c. 使用注册表编辑器将USERPROFILE 设置添加到以下注册表项中： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList d. 单击注册表项，然后单击“编辑”菜单上的“查找”。 e. 在“查找”框中，键入USERPROFILE 设置的值，然后单击“查找下一个”。 2. 更改ProfilesDirectory 值以使用您希望在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList 注册表项中使用的新路径。 3. 退出注册表编辑器，然后以用户身份登录。在命令提示符处键入set，以确认路径已更改。
更改软件默认安装路径的方法 默认安装路径C:\Program Files的。一般安装软件默认都是安装这个，要不想安装在这个目录在安装的时候就要手动去必动路径。 你要是懒得改下面有几种一劳永逸的方法。 方法一：运行输入regedit打开注册表编辑器，展开注册表“HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows\ CurrentVersion”分支，在窗口的右侧区域找到名为“ProgramFilesDir”和“ProgramFilesPath”的键值，将其原键值“C:\Program Files”改为“D:\Program Files”，关闭注册表。 方法二：用DOS命令即可实现。 ①点击“开始”→“运行”。 ②输入“cmd”，回车。提示符后输入“set ProgramFiles=D:\Program Files”，回车即可。 方法三：下载默认路径修改器 改了后还是会有一些在安装文件在：CommonFilesDir 文件夹中。如这个文件夹里的软件文件你也想转动可以同样改下路径如改默认的：C:\Program Files\Common Files 为 D:\\Program Files\\Common Files。 附：把 Program Files 目录移动到非系统盘的方法 本文只讨论系统正常安装后的移动，另外一种方案是使用"unattend 无人值守"安装系统，可以自行搜索。 本文方案适用的系统为：Windows Server 2008，Vista 应该（可能）也有效。之前的系统也类似，可以参考《[系统优化] 用 Junction 自定义“顽固”系统文件夹的路径》。 第零步，确定系统是刚刚安装好的，这样比较不会出现意外，也更有效优化；确定是用 Administrator 登录。 第一步，复制 Program Files 目录，但不能直接用资源管理器复制，我们
Gof的23种设计模式 从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF提出这些模式的 年代更加久远（1995年）。在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。 O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。 L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响，这样可以保证我们使用“继承”并没有破坏父类。
I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。 D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。下面，我们快速回顾GoF的23种模式。工厂方法 意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。 适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。抽象工厂 意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。 适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的
总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 2、里氏代换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 5、迪米特法则（最少知道原则）（Demeter Principle） 为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 6、合成复用原则（Composite Reuse Principle） 原则是尽量使用合成/聚合的方式，而不是使用继承。 三、Java的23中设计模式 从这一块开始，我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析。 1、工厂方法模式（Factory Method） 工厂方法模式分为三种：
应用安装过程以及默认安装路径 分类： 一:安装过程 是类似或的文件格式。通过将文件直接传到模拟器或手机中执行即可安装。 应用安装有如下四种方式 1. 系统应用安装――开机时完成，没有安装界面 2. 网络下载应用安装――通过应用完成，没有安装界面 3. 工具安装――没有安装界面。 4. 第三方应用安装――通过卡里的文件安装，有安装界面，由应用处理安装及卸载过程的界面。 应用安装的流程及路径 应用安装涉及到如下几个目录： 系统自带的应用程序，无法删除 用户程序安装的目录，有删除权限。
安装时把文件复制到此目录 存放应用程序的数据 将中的文件安装到目录下(文件是虚拟机的可执行文件,其大小约为原始文件大小的四分之一) 安装过程：复制安装包到目录下，解压并扫描安装包，把文件(字节码)保存到目录，并目录下创建对应的应用数据目录。 卸载过程：删除安装过程中在上述三个目录下创建的文件及目录。 一、系统应用安装： 处理各种应用的安装，卸载，管理等工作，开机时由启动此服务 (源文件路径：\\\\\\\\) 服务启动的流程： 1. 首先扫描安装“\”目录下的包
1. (, | ); 2.第二步扫描安装“\”目录下的各个系统应用 (, ); 3.第三步扫描“\”目录，即用户安装的第三方应用 (, 0, ); 4.第四步扫描" \"目录，即安装保护的文件（目前没有遇到过此类的应用）。(,0, | ); 安装应用的过程 1(, , ) 遍历安装指定目录下的文件
2(, , , , ) 安装文件 3( , , , , , ) 通过解析安装包获取到安装包的信息结构4(, ); 实现文件复制的安装过程（源文件路径：\\\\） 二、从上下载应用：
几种常用的设计模式介绍 1. 设计模式的起源 最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander。在1970年他的《建筑的永恒之道》里描述了投计模式的发现，因为它已经存在了千百年之久，而现代才被通过大量的研究而被发现。 在《建筑的永恒之道》里这样描述：模式是一条由三个部分组成的通用规则：它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题解决方案的核心设计。 在他的另一本书《建筑模式语言》中提到了现在已经定义了253种模式。比如： 说明城市主要的结构：亚文化区的镶嵌、分散的工作点、城市的魅力、地方交通区 住宅团组：户型混合、公共性的程度、住宅团组、联排式住宅、丘状住宅、老人天地室内环境和室外环境、阴和阳总是一气呵成 针对住宅：夫妻的领域、儿童的领域、朝东的卧室、农家的厨房、私家的沿街露台、个人居室、起居空间的序列、多床卧室、浴室、大储藏室 针对办公室、车间和公共建筑物：灵活办公空间、共同进餐、共同小组、宾至如归、等候场所、小会议室、半私密办公室 尽管亚力山大的著作是针对建筑领域的，但他的观点实际上适用于所有的工程设计领域，其中也包括软件设计领域。“软件设计模式”，这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。目前主要有23种。 2. 软件设计模式的分类 2.1. 创建型 创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式（并不是23种设计模式之一）、工厂方法、抽象工厂模式、单例模式、生成器模式和原型模式。 2.2. 结构型 用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式。 2.3. 行为型 用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。
关于23种设计模式新解 创建型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你” builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的
细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的 MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创建，而是将 具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给 出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例 化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里 面就行了，这就是我的情话prototype了。（100块钱一份，你要 不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象 的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有 任何事先确定的等级结构，原始模型模式适用于任何的等级结构。 缺点是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，
android APK应用安装过程以及默认安装路径 分类： Android 一:安装过程 APK是类似Symbian Sis或Sisx的文件格式。通过将APK文件直接传到Android模拟器或Android手机中执行即可安装。 Android应用安装有如下四种方式 1. 系统应用安装――开机时完成，没有安装界面 2. 网络下载应用安装――通过market应用完成，没有安装界面 3. ADB工具安装――没有安装界面。 4. 第三方应用安装――通过SD卡里的APK文件安装，有安装界面，由packageinstaller.apk应用处理安装及卸载过程的界面。 应用安装的流程及路径 应用安装涉及到如下几个目录： system/app 系统自带的应用程序，无法删除 data/app 用户程序安装的目录，有删除权限。
安装时把apk文件复制到此目录 data/data 存放应用程序的数据 Data/dalvik-cache 将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件,其大小约为原始apk文件大小的四分之一) 安装过程：复制APK安装包到data/app目录下，解压并扫描安装包，把dex文件(Dalvik 字节码)保存到dalvik-cache目录，并data/data目录下创建对应的应用数据目录。 卸载过程：删除安装过程中在上述三个目录下创建的文件及目录。 一、系统应用安装： PackageManagerService处理各种应用的安装，卸载，管理等工作，开机时由systemServer 启动此服务 (源文件路径： android\frameworks\base\services\java\com\android\server\PackageManagerService.jav a) PackageManagerService服务启动的流程：
23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///
class MainApp { ///
1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory。工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM 到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好
我的C盘满了怎么设置系统默认的存储路径首先，修改软件的默认安装路径，修改后再安装任何软件都会自动安道你指定的位置。单击“开始”、“运行”-->“Regedit”找到“HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curren tVersion”，在右侧窗口中找到名为“ProgramFilesDir”和“ProgramFilesPath"的字符串，就是它记录了ProgramFiles的路径，双击把它们的数值由“%SystemDrive%\Pr ogram Files”修改为你所希望的安装路径如“D:\Program Files”，确定后退出注册表就可以了. 下回安装软件的默认路径即为："D:\Program Files"。 第二，更改我的文档路径: 在桌面“我的文档”上点右键，选择属性，在目标文件夹下面选择“移动我的文档的存放路径”，然后选择存放文档的文件夹位置即可。 第三，修改系统缓存文件所在的位置。win7方法如下：右键单击我的电脑，单击属性功能，点击左侧的高级系统设置，在弹出界面的高级选项卡中点击下边的环境变量功能中，更改上下两个窗口中temp和tmp的存放路径如D:\temp即可，这样以后的系统运行缓存文件就不会占用c盘空间了。 最后，删除c：\windows文件夹中以$符号开头的隐藏文件，这些文件占的空间非常大，是系统补丁安装后的备份文件，没有任何作用，可安全删除。 经过上边几步，你的系统就不会很臃肿了，我之前也遇到了你这样的问题，现在已经解决了，呵呵。不要相信有什么能够不重装
系统就扩大系统盘空间的软件，没有那样的软件，扩大系统磁盘必然影响系统文件存放的相对磁盘地址，不出系统问题才怪。
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
改变 Android 手机软件安装位置的解决办法 谷歌 Android 系统手机默认只能把软件安装在手机内存里,使本来就不大的手机内存显得捉襟见肘。如果你也是个手机软件狂人,喜欢尝试各种各样新奇有趣的软件,面对越来越少的手机内存空间,不得不对已经安装的软件痛下 **。你是否还在安装与卸载之间纠结? Follow Me!我们一起来给 Android 系统扩扩容,让“ 机器人” 也可以“ 大肚能容” ,免去存储空间不足的后顾之忧。 Tips :存储器分为随机存储器(RAM 和只读存储器(ROM 两种。手机 ROM 相当于 PC 上的硬盘, 用于存储手机操作系统和软件, 也叫 FLASH ROM, 决定手机存储空间的大小。手机 RAM 相当于 PC 的内存,其大小决定手机的运行速度。 要把大象装冰箱里总共分三步, 而 Android 系统中把软件安装到 SD 卡上, 比这还简单, 两步就够了: 一、存储卡分区 首先我们需要对手机 SD 卡进行分区, 分一个 FAT32分区和一个 Ext3分区, FAT32分区用于正常存储图片、音乐、视频等资料,而 Linux 格式的 Ext3分区就是用于扩容安装软件的分区。以笔者的 2G SD卡为例, FAT32分区 1.35GB , Ext3分区 494MB 。下载并安装 Acronis Disk Director Suite 软件。将手机 SD 卡装入读卡器并连接电脑,然后运行 Acronis Disk Director Suite软件。 1.FAT32分区。找到代表 SD 卡的磁盘分区,点击右键,选择“ 删除” 命令,删除已有分区。当成为“ 未分配” 分区时,点击右键,选择“ 创建分区” ,在弹出的对话框中,文件系统选择: FAT32,创建为“ 主分区” ,设置好分区大小 1.35GB ,点击确定按钮。 2. Ext3分区。在剩余的 494MB 分区上,点击右键,选择“ 创建分区” ,在弹出的对话框中, 文件系统选择:Ext3,创建为“ 主分区” ,设置好分区大小 494MB ,点击确定按钮。
创建型模式 1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂 请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖) 建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过 程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。 工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作 交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
修改Windows XP和Windows 7的C:\Program Files的目录 和默认目录 第一节 述 在Windows系统中，默认程序安装路径是“C:\Program Files”，要安装的软件多了会导致C盘臃肿不堪，但是每次安装程序的时候手动选择安装目录又觉得十分麻烦。关于修改Windows默认安装目录的文章网上有很多，不过都是针对XP系统的，很多使用WIN7系统的朋友直接照搬过来，结果运行Win7自带的一些程序或新安装程序时会直接报错,说找不到路径等。本文将指出修改WinXP和Win7的修改方法，供大家参考。 第二节 修改XP 2.1方法一：命令修改（x64上要调整一下文件夹即可） 2.1.1第1步：创建移动文件 使用记事本创建一个文件，如：移动文件.bat 里面内容如下： xcopy "C:\Program Files" "C:\PFXP\" /E /H /K /X /Y /C rmdir /s /q "C:\Program Files" mklink /J "C:\Program Files" "C:\PFXP" 2.1.2第2步：使用光盘或U盘启动电脑 使用“雨林木风 Ghost XP SP3 装机版 YN9.9 终结版”启动电脑后，双击执行上面的文件，该命令会将文件自动复制到你指定的目录。移动完毕后，重新
启动电脑。 2.1.3第3步：修改注册表 进入Windows系统，创建记事本文件，如：修改注册表.reg，内容如下： [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion] "CommonFilesDir"="C:\PFXP\Common Files" "ProgramFilesDir"="E:\PFXP" 然后双击执行。 2.1.4第4步：批量修改注册表文件 下载Regtkt V4.0，在程序里将C:\Program Files替换成C:\PFXP，替换完成后，重新启动电脑，此时，所以文件都关联到C:\PFXP下了。之后所有安装目录也到E:\PFXP下了。注：路径跟据需要变一下。 2.2方法二：手动修改 进入注册表： 【HKEY_LOCAL_MACHINE】\【SOFTWARE】\【Microsoft】\【Windows】\【CurrentVersion】\【ProgramFilesDir】
设计模式课程设计 题目：画图程序 学院：信息科学与技术学院 专业：软件工程 学号：20092384 姓名：陈志
1．需求分析 该系统是一个画图程序，我们要用设计模式的思想来设计系统结构，然后实现基本图形的绘制功能。 1.1 设计模式要求 至少在其中运用 6 种模式，其中涉及到的模式有装饰模式、策略模式、桥梁模式三种。 1.2 画图基本要求 能实现基本图形的绘制功能 1.3 画图高级要求 实现图形的操作（如选取、移动、放大、缩小、改变颜色、改变线形等）和持久化（利用文件或利用数据库）。 2.系统设计 首先，画图程序可以实现绘制圆形、矩形和按钮，这里可以将圆形、矩形和按钮看作三个不同的类，那么我们可以采用抽象工厂的方式来创建它们。对于画组合图，我们可以采用组合模式将二者结合起来。而对于图形颜色或者粗细的改变，我们可以使用外观模式。然后，我们可以使用原型模式来实现对于最后一个图形的复制。在系统中可以使用代理模式来实现显示图片。下面是对需要用到的设计模式进行的分析。 2.1 使用设计模式 2.1.1 桥梁模式 桥梁模式 , 结构型模式一种 .设计程序过程中 , 会经常使用到抽象类或者接口来完成抽象的过程。 继承或实现的类通过不同的实现方式来完成抽象类或接口的变化 , 也就是实现过程的变化 , 但可能会有这样的情况 , 抽象过程同样需要进行变化 , 也就是抽象类或者接口需要变化 , 这样就会造成原有的继承或实现关系复杂 , 关系混乱 .桥梁模式利用将抽象层和实现层进行解耦 , 使两者不再像继承或实现这样的较强的关系 , 从而使抽象和实现层更加独立的完成变化的过程 . 使系统更加清晰。 桥梁模式主要由抽象类、修正抽象类、实现类以及具体实现类组成 . 抽象类 , 制定接口 , 同时给出一个实现化的引用。 修正抽象类 , 扩展抽象类 , 修正或改变抽象类中指定的接口。 实现类 , 提供实现化角色的接口 , 但不进行具体实现过程 , 该接口不一定给出与抽象类相同的接口 , 只是提供实现的方式。 具体实现类 , 完成实现类中定义的实现接口的具体实现过程。 具体代码如下： package BridgePattern; import java.awt.Color;
23种设计模式的通俗理解【转】 1、FACTORY 工厂方法 追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER 抽象工厂 MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱 你”builder。（这一定比美军在伊拉克用的翻译机好卖）建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD 建造者模式 请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE 原型模式 跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、SINGLETON 单态模式 俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事) 单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。[b:9ceca65206]结构型模式[/b:9ceca65206] 6、ADAPTER 适配器模式 在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我) 适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，