一 : 架构师必须了解的三大类软件设计模式（共22种设计模式）的使用说明和情

一、创建性模式

通过该类的子类来创建对象的。但是，这可能会限制在系统内创建对象的类型或数目

1、Abstract Factory 模式
在不指定具体类的情况下，为创建一些列相关或相互依赖的对象提供了接口。
提供了一个可以确定合适的具体类的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用Abstract Factory 模式：
系统独立于产品的创建、组成、表示。
系统配置成具有多个产品的系列。
相关产品对象系列是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。

2、Builder 模式
将复杂对象的构件与表示相分离，相同的构造过程可以创建不同的对象，通过只指定对象
的类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：

可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用Builder 模式：
算法独立于组成对象。
构造过程必须允许已构件对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。
优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用Factory Method 模式：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时添加或删除产品。
通过改变值指定新对象。
通过改变结构制定新对象。
减少子类的生成和使用。
可以用类动态地配置应用程序。
以下情况中，应该使用Prototype 模式：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的工厂类层次结构。
5、Singleton 模式
确保一个类只有一个实例，并且提供全局访问入口，确保使用这个实例所有的对象使用
相同的实例。
优点：

对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活。

二、结构性模式

机构性模式控制较大部分之间的关系。
它将以不同的方式影响应用程序。
允许在补充写代码或自定义代码的情况下创建系统。
具有增强的重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容
接口的类能够系统使用。
优点：
允许多个不兼容的对象进行交互和通信。
提高已有功能的重复使用性。
以下情况，应该使用Adapter 模式：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与不相关或未知类进行协作。
要在一个不同于已知对象接口的接口环境中使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge 模式
将一个复杂的组件分成两个独立的但又相关的继承层次结构：功能性抽象和内部实现。
优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。

以下情况中，应该使用Bridge 模式：
避免在抽象及其实现之间存在永久的绑定。
抽象及其实现可以使用子类进行扩展。
抽象的实现被改动不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由主要对象和符合对象组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性和可管理性的接口。
以下情况中，应该使用Composite 模式：
想要表示对象的整个或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类处于层次结构的过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用Decorator 模式：
在单个对象中动态并且透明地添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口提供了一个统一的接口。更容易使用子系统的高级接口。
优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。

屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后发送给能够处理这些请求的子系统。
以下情况中，应使用Facade 模式：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例所带来的开销。
优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用Flyweight 模式：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。

三、行为性模式

行为性模式影响系统的状态、行为流。
简化、优化并且提高应用程序的可维护性。
1、Chain of Responsibility 模式
在系统中建立一个链，在首先接收到它的级别处被处理，或者定位到可以处理它的对象。
优点：
降低了耦合度。
增加面向对象制定责任的灵活性。
类的集合可以作为一个整体。
以下情况中，应该使用Chain of Responsibility 模式：

多个对象可以处理一个请求，而其处理器却是未知的。
在不指定确切的请求接受对象的情况下，向几个对象中的一个发送请求。
动态地指定能够处理请求的对象集。
2、Command 模式
在对象中封装了请求。
优点：
将调用操作的对象与知道如何完成该操作的对象相分离。
更容易添加新指令，因为不用修改已有类。
以下情况中，应该使用Command 模式：
要通过执行的动作来参数化对象。
在不同的时间指定、排序、执行请求。
必须支持Undo、日志记录或事务。
3、Interpreter 模式
解释定义其语法表示的语言，提供了语句解释器。
优点：
容易修改并扩展语法。
更容易实现语法。
以下情况中，应该使用Interpreter 模式：
语言的语法比较简单。
效率并不是最主要的问题。
4、Iterator 模式
为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。
优点：
支持集合的不同遍历。
简化了集合的接口。
以下情况中，应该使用Iterator 模式：
不开放集合对象内部表示的前提下，访问集合对象内容。
支持集合对象的多重遍历。
为遍历集合中的不同结构提供了统一的接口。

5、Mediator 模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间
的松耦合度，还可以独立地改变其间的交互。
优点：
去除对象间的影响。
简化了对象间协议。
集中化了控制。
由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。
由于不再需要包含逻辑来处理组件间的通信，组件变得更加通用。
以下情况中，应该使用Mediator 模式：
对象集合需要以一个定义规范但复杂的方式进行通信。
6、Memento 模式
保持对象状态的“快照”（snapshot），对象可以在不向外界公开其内容的情况下返回到它
的最初状态。
优点：
保持封装的完整性。
简化了返回到初始状态所需的操作。
以下情况中，应该使用Memento 模式：
必须保存对象状态的快照，恢复状态。
7、Observer 模式
定义了对象间一到多的依赖关系，当对象改变状态时，将自动通知并更新它所有的依赖
对象。
优点：
抽象了主题与Observer 之间的耦合关系。
支持广播方式通信。
以下情况中，应该使用Observer 模式：
对一个对象的修改涉及对其他对象的修改，而且不知道有多少对象需要进行相应修改。
对象应该能够在不同假设对象标识的前提下通知其它对象。
8、State 模式

对象在内部状态变化时，变更其行为，并且修改其类。
优点：
针对不同状态来划分行为，使状态转换显式进行。
9、Strategy 模式
定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用，来修改应
用程序功能。
优点：
另一种子类化方法。
在类自身中定义了每一个行为，减少了条件语句。
更容易扩展模型。
以下情况中，应该使用Strategy 模式：
许多相关类只是在行为方面有所区别。
需要算法的不同变体。
算法使用客户端未知的数据。
10、Template Method 模式
不重写方法的前提下允许子类重载部分方法的方法。
将一些步骤由子类实现。
优点：代码重用的基础技术。
以下情况中，应该使用Template Method 模式：
一次实现算法的不变部分，子类实现算法的可变行为。
11、Visitor 模式
不改变操作元素的类的前提下定义一个新操作。
优点：
容易添加新操作。
集中相关排除不相关操作。
以下情况中，应该使用Visitor 模式：
包含许多具有不同接口的对象类，并且想要对这些依赖具体类的对象进行操作。
定义对象结构的类很少被修改，但想要在此结构上定义新的操作。

二 : 软件架构的目标

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标： 　　
·可靠性（Reliable）。软件系统对于用户的商业经营和［www.61k.com］管理来说极为重要，因此软件系统 必须非常可靠。 　　
·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。 　　
·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。 只有这样，才能适应用户的市场扩展得可能性。 　　
·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的 变化进行调整。 　　
·可扩展性（Extensible）。在新技术出现之际，1个软件系统应当允许导入新技术， 从而对现有系统进行功能和性能的扩展　　
·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。1个易于维护的系统可以有效地降低技术支持的花费 　　
·客户体验（Customer Experience）。软件系统必须易于使用。 　　
·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

三 : 威盛笔试(硬件架构设计)

刚才去参加VIA的笔试，这是我的第一次笔试经历，我应聘的是硬件架构设计部（Graphics/VideoAlgorithums Engineer/Graphics Architect）。liuqingwei也参加这次笔试，只是他应聘的是Software Engineer。各个部门的题目都不相同，所以这里我只贴一下我的题目

　　有六道大题，回答要求是英文的，由于题目是英文的，并且有很多问题我不了解，所以可能有表述不正确的地方

　　一、五个小题

　　1、似乎是关于3维曲线拟和的问题及数据的过滤

　　2、关于Win API中的OpenGL函数

　　3、说出固定小数表示和浮点小数表示的优缺点

　　4、说出显卡可以优化哪些MPEG中的计算

　　5、说出Bezier和B-Spline曲线的区别

　　我只做了5，其他的都不知道

　　二、写个函数判断一个数是不是2的次方。这个题目还算简单，可能是我作的最好的一道了

　　三、用c++写一个函数求三个输入中最大的一个，要求用template　（sigh，关于template已经忘记了）

　　四、题目告诉你IEEE 16和32浮点数表示的规范要求将-0.25分别用IEEE 16和32表示，并写一个c++函数将输入的IEEE 16表示转化为IEEE 32的表示。这道题应该也作的还可以，因为对IEEE的浮点数表示本来就知道一些

　　五、用c写一个函数f(x) = x * 0.5要求只能用整数操作，并且似乎对函数的调用有特别的要求。也就是说函数的输入参数和输出的格式需特别注意。这道题目有明显的错误，所以没有作。监考的是HR部门的，问了也是白问，呵呵

　　六、两道证明题，选作一题

　　1、关于一个2维向量关于另一个向量作镜面反射的

　　这道题很简单的，相信大部分人都知道。只是题目的表述很奇怪

　　2、关于3维空间中一个平面的变换问题

　　题目的表述有明显的问题，所以也没有作

　　总的感觉是，似乎比较注重位运算，还有就是c和c++的基本编程以及关于图象处理的基本知识，希望liuqingwei作的比我好

本文标题：软件架构设计目标-架构师必须了解的三大类软件设计模式（共22种设计模式）的使用说明和情
本文地址： http://www.61k.com/1126720.html