第6章行为模式（一）
本章目标
了解什么是命令模式
掌握命令模式的应用
了解什么是观察者模式
掌握观察者模式的应用
本章单词：
command_______________________ action________________________
transaction___________________ invoker_______________________
receiver______________________ observer______________________
6.1 命令模式（Command）
6.1.1 概念
1、名称
命令（Command）模式属于对象的行为模式【GOF95】。命令模式又称为行动（Action）模式或交易（Transaction）模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。
每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
2、结构
命令模式不是新的发明，在美猴王大闹天宫之前就有了。那时玉帝命令太白金星召美猴王上天："金星径入(水帘洞)当中，面南立定道：'我是西方太白金星，奉玉帝招安圣旨，下界请你上大，拜受仙录。'"玉帝是系统的客户端，太白金星是命令的发出者，猴王是命令的接收者，圣旨就是命令。玉帝的这一道命令就是要求猴王到上界报到。玉帝只管发出命令，而不管命令是怎样传达到美猴王的。太白金星负责将圣旨传到，可是美猴王怎么执行圣旨、何时执行圣旨是美猴王自己的事。果不然，个久美猴王就大闹了天宫。这个模拟系统的设计如图6-1所示。
图6-1 模拟结构
命令模式的类图如图6-2所示。
图6-2 命令模式结构图
3、意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。这里所谓的“不同的请求”也既意味着请求可能发生的变化，是一个可能扩展的功能点。
4、适用性
抽象出待执行的动作以参数化某对象，适用过程语言中的回调函数表达这种参数化的机制。
所谓的回调函数指函数先在某处注册，而他将在稍后的某个需要的时候被调用。Command模式是回调机制的一个面向对象的替代品。
在不同的时刻指定、排列和执行的请求。
支持取消操作。
支持修改日志，这样当系统崩溃时这些修改可以被从新作一遍。
用构建在原语操作上的高层操作构造一个系统。这样一种结构支持事务的信息系统中很常见。
5、个角色
客户（Client）角色：创建了一个具体命令(ConcreteCommand)对象并确定其接收者。
命令（Command）角色：声明了一个给所有具体命令类的抽象接口。这是一个抽象角色。
具体命令（ConcreteCommand）角色：定义一个接受者和行为之间的弱耦合；实现Execute()方法，负责调用接收考的相应操作。Execute()方法通常叫做执方法。
请求者（Invoker）角色：负责调用命令对象执行请求，相关的方法叫做行动方法。
接收者（Receiver）角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，
实施和执行请求的方法叫做行动方法。
6.1.2 作用
有时必须向一个对象提交请求，但是并不知道关于被请求的操作或者请求的接受者的任何信息。命令模式通过将请求本身变成一个对象来使工具箱对象可向未指定的应用对象提出请求，这个对象可以被存储并像其他的对象一样被传递，这一个模式的关键是抽象的Command类，它定义了一个执行操作的接口，其最简单的形式是一个抽象的Execute操作，具体的Command子类将接收者作为其一个实例变量，并实现Execute操作,制定接收者采取的动作，而接收者有执行该请求所需的具体信息。
6.1.3 适用范围
在下面的情况下应当考虑使用命令模式：
使用命令模式作为“CallBack”在面向对象系统中的替代。“CallBack”讲的便是先将一个函数登记上，然后在以后调用此函数。
需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。
系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令效果。
如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。
一个系统需要支持交易(Transaction)。一个交易结构封装了一组数据更新命令。使用命令模式来实现交易结构可以使系统增加新的交易类型。
6.1.4 实现
下面是一个简单命令模式的实现代码。
接收者角色：
命令角色：
调用者角色：
客户端角色：
执行结果如图6-3所示。
图6-3 运行结果
上面的代码似乎显的很多余，本来可以使用更简单的实现，代码如下：
看多简洁，如果是像上边如此简单的需求，这个才应该是我们的选择，但是有些情况下这样的写法不能解决的，或者说解决起来不好，所以引入命令模式。如以下情况：我们须要Client和Receiver同时开发，而且在开发过程中分别须要不停重购，改名。
如果我们要求Redo，Undo等功能。
我们须要命令不按照调用执行，而是按照执行时的情况排序，执行。
开发后期，我们发现必须要log哪些方法执行了，如何在尽量少更改代码的情况下实现，并且渐少重复代码。
在上边的情况下，我们的接受者有很多，不止一个。
解决办法：
情况一：我们可以定义一个接口，让Receiver实现这个接口,Client按照接口调用。
情况二：我们可以让Receiver记住一些状态，例如执行前的自己的状态，用来undo，但自己记录自己的状态实现起来比较混乱，一般都是一个累记录另一个类的状态。
情况三：很难实现。
情况四：我们须要在每个Action，前后加上log
情况五：相对好实现，但是再加上这个，是否感觉最终的实现很混乱呢好，我们再来看看命令模式，在命令模式中，我们增加一些过渡的类，这些类就是上边的命名接口和命令实现，这样就很好的解决了情况一，情况二。我们再加入一个Invoker，这样情况三和情况四就比较好解决了。
如下加入Log和排序后的Invoker：
客户端代码如下：
该实例的最终结构如图6-4所示。
图6-4 结构图
6.1.5 优缺点
1、优点
命令模式使新的命令很容易地被加入到系统里。
允许接收请求的一方决定是否要否决（Veto）请求。
能较容易地设计-个命令队列。
可以容易地实现对请求的Undo和Redo。
在需要的情况下，可以较容易地将命令记入日志。
命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
命令类与其他任何别的类一样，可以修改和推广。
你可以把命令对象聚合在一起，合成为合成命令。比如宏命令便是合成命令的例子。合成命
令是合成模式的应用。
由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。
2、缺点
使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。
6.2 观察者模式（Observer）
6.2.1 概念
1、名称
观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其它的对象做出相应的改变。做到这一点的设计方案有很多，但是为了使系统能够易于复用，应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用，但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致，保证高度的协作（Collaboration）。观察者模式是满足这一要求的各种设计方案中最重要的一种。
2、结构
观察者模式的类图如图6-5所示。
图6-5 观察者模式结构
3、意图
观察者模式属于行为型模式，其意图是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
4、适用性
在以下的任一情况下可以使用观察者模式：
当一个抽象模型有两个方面，其中一个方面依赖于另一方面。将这二者封装在独立的对象中可以使他们各自独立地改变和复用。
当对一个对象的改变需要同时改变其它对象，而不知道具体由多少对象有待改变。
当一个对象必须通知其他对象，而它又不能假定其他对象是谁，换言之，你不希望这些对象是紧密耦合的。
5、角色
观察者模式的实现里有下面这些角色：
抽象主题（Subject）角色：主题角色把所有对观察考对象的引用保存在一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，主题角色又叫做抽象被观察者（Observable）角色，一般用一个抽象类或者一个接口实现。
抽象观察者（Observer）角色：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者角色一般用一个抽象类或者一个接口实现。在这个示意性的实现中，更新接口只包含一个方法（即Update()方法），这个方法叫做更新方法。
具体主题（ConcreteSubject）角色：将有关状态存入具体现察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者角色（Concrete Observable）。具体主题角色通常用一个具体子类实现。
具体观察者（ConcreteObserver）角色：存储与主题的状态自恰的状态。具体现察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。如果需要，具体现察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现。
从具体主题角色指向抽象观察者角色的合成关系，代表具体主题对象可以有任意多个对抽象观察者对象的引用。之所以使用抽象观察者而不是具体观察者，意味着主题对象不需要知道引用了哪些ConcreteObserver类型，而只知道抽象Observer类型。这就使得具体主题对象可以动态地维护一系列的对观察者对象的引用，并在需要的时候调用每一个观察者共有的Update()
方法。这种做法叫做“针对抽象编程”。
6.2.2 作用
屏蔽线程间的通信机制：例如两个线程之间，主线程可以作为观察者，执行线程是被观察者。
彼此之间只知道对方存在，但不知道之间通信的细节。
消除硬编码：如果没有Observer模式，则只能采用回调的模式，或者在代码中显示地调用观察者。
优化异常机制：特别适合在异常发生时向顶层监控，减少try-catch代码量。
6.2.3 实现
老师有电话号码，学生需要知道老师的电话号码以便于在合时的时候拨打，在这样的组合中，老师就是一个被观察者（Subject），学生就是需要知道信息的观察者，当老师的电话号码发生改变时，学生得到通知，并更新相应的电话记录。整体的结构如图6-6所示。
图6-6 结构图
观察者接口Observer代码如下：
被观察者接口Subject代码如下：
被观察者实现类Teacher代码如下：
观察者实现类Student代码如下：
测试类Test代码如下：
运行结果如图6-7所示。
图6-7 运行结果
6.2.4 优缺点
Observer模式的优点是实现了表示层和数据逻辑层的分离，并定义了稳定的更新消息传递机制，类别清晰，并抽象了更新接口，使得可以有各种各样不同的表示层（观察者）。
但是其缺点是每个外观对象必须继承这个抽像出来的接口类，这样就造成了一些不方便，比如有一个别人写的外观对象，并没有继承该抽象类，或者接口不对，我们又希望不修改该类直接使用它。虽然可以再应用Adapter模式来一定程度上解决这个问题，但是会造成更加复杂烦琐的设计，增加出错几率。
1、优点
观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体现察者聚集，每一个具体现察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。
2、缺点
如果一个被观察者对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察考模式时要特别注意这一点。
如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。
虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
软件设计模式（Java版）习题 第1章软件设计模式基础 1.1 软件设计模式概述 1.2 UML中的类图 1.3 面向对象的设计原则 一、名词解释 1.一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展 一个系统的行为。 2.一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。 3.在软件中如果能够使用基类对象，那么一定能够使用其子类对象。 4.是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结， 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 二、单选择题 1.( A ) 2.（ A ） 3. ( A ) 4. ( D ) 5. ( D ) 6．( A ) 7. ( D ) 8.（ D ） 9.（ D ） 10.（ E ） 11.( C ) 12．（ C ） 13. ( A ) 三、多选择题 1．( A、B、C、D ) 2. ( A、B ) 3．( A、D ) 4．( A、B、C、D ) 四、填空题 1．依赖倒转、迪米特法则、单一职责 2．模式名字、目的、问题、解决方案、效果、实例代码 3．超类、子类 4．开闭 5．用户 6．依赖倒转 7．组合/聚合 8．结构型、行为型 9.依赖倒转 10.开闭 11.需求收集是否正确、体系结构的构建是否合理、测试是否完全 12．人与人之间的交流 13．接口 14．名称、目的、解决方案 15．对象组合、类继承
16．对象组合 17．对象组合、类继承 18．抽象类的指针 五、简答题 1.答：设计模式按类型分为以下三类： 1）创建型设计模式：以灵活的方式创建对象集合，用于管理对象的创建。 2）结构型设计模式：将己有的代码集成到新的面向对象设计中，用于处理类或对象的组合。 3）行为型设计模式：用于描述对类或对象怎样交互和怎样分配职责。 2.答：设计模式的主要优点如下： 1）设计模式融合了众多专家的经验，并以一种标准的形式供广大开发人员所用，它提供了一套通用的设计词汇和一种通用的语言以方便开发人员之间沟通和交 流，使得设计方案更加通俗易懂。 2）设计模式使人们可以更加简单方便地复用成功的设计和体系结构，将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式使得重用成功的设计更加容易，并避免那些导致不可重用的设计方案。 3）设计模式使得设计方案更加灵活，且易于修改。 4）设计模式的使用将提高软件系统的开发效率和软件质量，且在一定程度上节约设计成本。 5）设计模式有助于初学者更深入地理解面向对象思想，一方面可以帮助初学者更加方便地阅读和学习现有类库与其他系统中的源代码，另一方面还可以提高软件的设计水平和代码质量。 3.答：设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效 果、实例代码和相关设计模式，其中的关键元素包括模式名称、问题、解决方案和效果。 4.答：正确使用设计模式具有以下优点： ⑴可以提高程序员的思维能力、编程能力和设计能力。 ⑵使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从 而缩短软件的开发周期。 ⑶使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。 5.答：根据类与类之间的耦合度从弱到强排列，UML中的类图有以下几种关系：依赖关 系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。
1.Factory Method模式和Abstract Factory模式的区别在哪？一般哪些情况下适合用前者，哪些情况下适合用后者？ 1）不同之处主要在于： 应用环境不同：FM中创建者的职责并不仅限于创建对象，而AF通常只有创建对象这一职责。 实现方式不同：FM是实现继承，抽象类实现大部分操作，通常仅将对象的创建工作延迟到子类来完成；AF是接口继承，抽象类通常不实现任何功能，仅仅定义一系列接口，子类实现抽象类定义的接口。Factory Method模式与Abstract Factory模式的区别 2） 在这些情况下使用Factory Method: 当一个类不知道它所必须创建的对象的类的时候； 当一个类希望由它的子类来指定它所创建的对象的时候； 当类将创建对象的职责委托给多个帮助子类中的某一个，并且程序员希望将哪一个帮助子类是代理者这一信息局部化的时候。 在这些情况下使用Abstract Factory: 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。 当你要强调一系列相关的产品对象的设计以便进行联合使用时。 当你提供一个产品类库，而只想显示它们的接口而不是实现时。 2.解释Java中clone()方法和https://www.doczj.com/doc/aa10857662.html,ng.Cloneable接口的关系，如果想要实现深拷贝可以有哪些方法？ 1）cloneable接口中的一个方法是clone方法，实现cloneable接口必须实现接口中包含的clone 方法。如果在没有实现Cloneable 接口的实例上调用Object的clone方法，则会导致抛出CloneNotSupportedException 异常。 2）实现深拷贝的方法： 实现ICloneable接口，自定义拷贝功能； 通过反射实现； 序列化/反序列化类实现。 3. https://www.doczj.com/doc/aa10857662.html,ng.Math类和https://www.doczj.com/doc/aa10857662.html,ng.StrictMath类是否是单例模式？ 都不是单例模式。 原因： 这两个类均有一个私有的构造函数。但是这仅仅是单例模式的必要条件，而不是充分条件。根据单例模式的三个特性可以看出，无论是Math 还是StrictMath 都没有为外界提供任何自身的实例。实际上，这两个类都是被设计来提供静态工厂方法和常量的，因此从来就不需要它们的实例，这才是它们的构造子是私有的原因。 4. 如何保证单例模式中单例的线程安全？请列举两种或以上方法。 1）将类的构造函数设计为私有的，并提供一个public static方法，返回这个对象的指针。若这个函数返回的是null，则可以创建一个对象；否则不能创建新的对象。另外，由于多线
一、1. 设计模式一般用来解决什么样的问题： A.同一问题的不同表相 2. 下列属于面向对象基本原则的是： C.里氏代换 3. Open-Close原则的含义是一个软件实体：A.应当对扩展开放，对修改关闭. 4. 当我们想创建一个具体的对象而又不希望指定具体的类时，使用（A）模式。A.创建型 5. 要依赖于抽象不要依赖于具体。即针对接口编程不要针对实现编程：（D）依赖倒转原则 6. 依据设计模式思想,程序开发中应优先使用的是( A )关系实现复用。A, 委派 7. 设计模式的两大主题是( D ) D.系统复用与系统扩展 8. 单体模式中,两个基本要点(AB)和单体类自己提供单例A .构造函数私有 B.唯一实例 9. 下列模式中,属于行为模式的是( B ) B观察者 10. “不要和陌生人说话”是( D )原则的通俗表述 D.迪米特 1. 软件体系结构是指一个系统的有目的的设计和规划，这个设计规划既不描述活动，也不描述系统怎样开发，它只描述系统的组成元素及其相互的交互协作。 2．一个UML模型只描述了一个系统要做什么，它并没告诉我们系统是怎么做。 3．接口是可以在整个模型中反复使用的一组行为，是一个没有属性而只有方法的类。 4．多重性指的是，某个类有多个对象可以和另一个类的一对象关联。 5．当一个类的对象可以充当多种角色时，自身关联就可能发生。 6．在泛化关系中，子类可以替代父类。后前者出现的可以相同地方。反过来却不成立。 7．最通常的依赖关系是一个类操作的形构中用到了另一个类的定义。 8．组成是强类型的聚集，因为聚集中的每个部分体只能属于一个整体。 9．实现的符号和继承的符号有相似之处，两者的唯一差别是实现关系用虚线表示，继承关系用实线表示。 10. 设计模式中应优先使用对象组合而不是类继承。 1.适配器模式属于创建型模式结构型（ F ） 2.在设计模式中，“效果”只是指“原因和结果”（ T ） 3.设计模式使代码编制不能真正工程化（ T ） 4.面向对象语言编程中的异常处理，可以理解为责任链模式（T ） 5.反模式就是反对在软件开发过程中使用设计模式分析：反模式用来解决问题的带有共性的不良方法（F ） 1.什么是设计模式？设计模式目标是什么？ 答：设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解，保证代码可靠性。 2.设计模式中一般都遵循的原则有什么？ 答：开闭原则、根据场景进行设计原则、优先组合原则、包容变化原则 3.“Gang of Four”针对“创建优秀面向对象设计”建议了哪些策略？ 答：针对接口编程、优先使用对象组合而不是类继承，找到并封装变化点。 4.面向对象系统中功能复用的两种最常用技术是什么？ 答：类继承和对象组合，类继承允许你根据其他类的实现来定义一个类的实现。父类的内部细节对子类可见。 类继承是在编译时刻静态定义的，且可直接使用，类继承可以较方便地改变被复用的实现。对象组合是类继承之外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。 5.只根据抽象类中定义的接口来操纵对象有什么好处？ 答：1) 客户无须知道他们使用对象的特定类型，只须对象有客户所期望的接口。 2) 客户无须知道他们使用的对象是用什么类来实现的，他们只须知道定义接口的抽象类。 五、应用题（分值15） 公司架构：经理、工程师、技师和后勤人员都是公司的雇员，经理管理工程师、技师和后勤人员。高层经理领导较低级别的经理。典型层次图如下：可以使用哪种设计模式实现公司的层级关系？并说明为什么？ 组合模式，第一，其公司关系架构为树形结构；第二，其表示了部分-整体关系（自己扩展）
设计模式六大设计原则 单一职责原则(Single Responsibility Principle-SRP) 理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。 应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！开放封闭原则(open closed principle-OCP) 理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。 里氏替换原则(liskov substitution principle -LSP) 理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。 应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的public 方法供外界调用。 最少知识原则(last knowledge principle-LKP) 理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。 应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。 接口隔离原则(Interface Segregation Principle - ISP) 理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。 应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。 依赖倒置原则(Dependence Inversion Principle – DIP) 理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。 应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
摘要： 随着软件系统规模和复杂性的增加, 人们对软件的可靠性和生产效率也提出了更高的要求, 软件重用在当前比以往任何时候都显得重要. 设计模式是系统设计阶段的软件重用, 使得那些具有良好性能的设计方案可以在相似环境下被再次复用. 设计模式以文档的形式把面向对象的软件设计经验记录下来, 并予以系统的命名、解释和评价, 使开发人员在进行系统的设计与开发时, 可以使用别人的成功经验而不必为普通的、重复的问题重新设计解决方案,使设计者更容易理解其设计思路,能为自己的问题找到更合适的解决办法,帮助设计者更快更好地完成系统设计. 1.设计模式简介 设计模式是针对面向对象系统中重复出现的设计问题，提出一个通用的设计方案，并予以系统化的命名和动机解释。它描述了问题，提出了解决方案，并指出在什么条件下使用该方案以及其效果。该解决方案是解决该问题的一组精心安排的通用的类和对象，再经过定制和实现就可用来解决特定的上下文中的问题。简单来说，设计模式就是一个常用的方案。在我们的开发过程中经常会遇到一些相同或相近的问题，如果每次都寻找一个相应的解决办法&那么就会增加开发时间，降低开发效率。为了节省时间&提高开发效率&就需要提供一些解决类似问题的，在应用中被证明可行的方案设计模式。所以一个设计模式就是描述了一个被证明可行的方案，这些方案可以重用，有良好的伸缩性。一般而言，一个设计模式有四个要素： 1.模式名称 2.问题。 3.解决方案。 4.效果。 2.设计模式的分类 根据两条准则对模式进行分类,范围准则和目的准则。 范围准则,即指定设计模式主要是用于类还是用于对象。设计模式据此可分 为: (1)类设计模式:处理类和子类之间的关系,这些关系通过继承建立,是静态的,在编译时刻便确定下来了。 (2)对象设计模式:处理对象间的关系,这些关系在运行时刻是可以变化的,更具动态性。从某种意义上来说,几乎所有设计模式都使用继承机制,所以“类设计模式”只指那些集中于处理类间关系的设计模式,而大部分设计模式都属于对象设计模式的范畴。 目的准则,即设计模式是用来完成什么工作的。设计模式据此可分为: (l)创建型设计模式:与类或对象的创建有关; (2)结构型设计模式:处理类或对象的组合; (3)行为型设计模式:对类或对象怎样交互和怎样分配职责进行 描述。 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 3.设计模式的六大原则 1.单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引
实验3 创建型设计模式实验 实验学时： 2 每组人数： 1 实验类型： 3 （1：基础性2：综合性3：设计性4：研究性） 实验要求： 1 （1：必修2：选修3：其它） 实验类别： 3 （1：基础2：专业基础3：专业4：其它） 一、实验目的 1．熟练使用面向对象设计原则对系统进行重构； 2．熟练使用PowerDesigner和任意一种面向对象编程语言实现几种常见的创建型设计模式，包括简单工厂模式、工厂方法模式、抽象工厂模式和单例模式，理解每一种设计模式的模式动机，掌握模式结构，学习如何使用代码实现这些模式。 二、实验内容 1．在某图形库API中提供了多种矢量图模板，用户可以基于这些矢量图创建不同的显示图形，图形库设计人员设计的初始类图如下所示： Circle + + + + +init () setColor () fill () setSize () display () ... : void : void : void : void : void Triangle + + + + + init () setColor () fill () setSize () display () ... : void : void : void : void : void Rectangle + + + + + init () setColor () fill () setSize () display () ... : void : void : void : void : void Client 在该图形库中，每个图形类（如Circle、Triangle等）的init()方法用于初始化所创建的图形，setColor()方法用于给图形设置边框颜色，fill()方法用于给图形设置填充颜色，setSize()方法用于设置图形的大小，display()方法用于显示图形。 客户类(Client)在使用该图形库时发现存在如下问题： ①由于在创建窗口时每次只需要使用图形库中的一种图形，因此在更换图形时需要修改客户类源代码；
设计模式期中考试试题 一：单项选择（共20道，每道2分） 1、设计模式一般用来解决什么样的问题( ) A.同一问题的不同表相B不同问题的同一表相 C.不同问题的不同表相 D.以上都不是 2、下列属于面向对象基本原则的是( ) A.继承 B.封装 C.里氏代换D都不是 3、Open-Close原则的含义是一个软件实体( ) A.应当对扩展开放，对修改关闭. B.应当对修改开放，对扩展关闭 C.应当对继承开放，对修改关闭 D.以上都不对 4、当我们想创建一个具体的对象而又不希望指定具体的类时，可以使用（）模式。 A.创建型 B.结构型C行为型D.以上都可以 5、要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程,是( )的表述 A.开-闭原则 B.接口隔离原则 C.里氏代换原则 D.依赖倒转原则 6、设计模式的两大主题是( ) A.系统的维护与开发 B 对象组合与类的继承 C.系统架构与系统开发 D.系统复用与系统扩展 7、“不要和陌生人说话” 是( )原则的通俗表述 A.接口隔离 B.里氏代换 C.依赖倒转 D.迪米特：一个对象应对其他对象尽可能少的了解 8、构造者的的退化模式是通过合并（）角色完成退化的。 A.抽象产品B产品C创建者D使用者 9、以下关于简单工厂模式叙述错误的是（） A 它属于GoF23种设计模式 B 它是最简单的设计模式之一 C 它是学习其他创建型模式的基础 D 它只需要记住一个简单的参数即可获得所需对象的实例 E 它类中的方法通常为静态方法 F 它返回的类都有一个公共的父类和公共的方法 10、对象适配器模式是（）原则的典型应用。 A.合成聚合复用原则 B.里式代换原则 C.依赖倒转原则 D.迪米特法则 D.以上表述全部错误。 11.对于依赖倒转的表述错误的是（） A.依赖于抽象而不依赖于具体，也就是针对接口编程。 B.依赖倒转的接口并非语法意义上的接口，而是，一个类对其他对象进行调用时，所知道的方法集合。 C.从选项B的角度论述，一个对象可以有多个接口。 D.实现了同一接口的对象，可以在运行期间，顺利地进行替换。而且不必知道所示用的对象是那个实现类的实例。 E.此题没有正确答案。 12. 现有5个产品族，分布于3各不同的产品等级结构，只要指明一个产品所处的产品族以及它所在的等级结构，就可以唯一地确认这个产品。那么使用抽象工厂方法模式只需要提供
1、设计模式一般用来解决什么样的问题( a) A.同一问题的不同表相 B不同问题的同一表相 C.不同问题的不同表相 D.以上都不是 2、下列属于面向对象基本原则的是( c ) A.继承 B.封装 C.里氏代换 D都不是 3、Open-Close原则的含义是一个软件实体( a ) A.应当对扩展开放，对修改关闭. B.应当对修改开放，对扩展关闭 C.应当对继承开放，对修改关闭 D.以上都不对 4、当我们想创建一个具体的对象而又不希望指定具体的类时，可以使用（ a ）模式。 A.创建型 B.结构型 C行为型 D.以上都可以 5、要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程,是( d )的表述 A.开-闭原则 B.接口隔离原则 C.里氏代换原则 D.依赖倒转原则 6、依据设计模式思想,程序开发中应优先使用的是( a )关系实现复用。 A, 委派 B.继承 C创建 D.以上都不对 复用方式：继承和组合聚合（组合委派） 7、设计模式的两大主题是( d ) A.系统的维护与开发 B 对象组合与类的继承 C.系统架构与系统开发 D.系统复用与系统扩展 8、单例模式中,两个基本要点( a b )和单子类自己提供单例 A .构造函数私有 B.唯一实例 C.静态工厂方法 D.以上都不对 9、下列模式中,属于行为模式的是( b ) A.工厂模式 B观察者 C适配器以上都是 10、“不要和陌生人说话” 是( d )原则的通俗表述 A.接口隔离 B.里氏代换 C.依赖倒转 D.迪米特：一个对象应对其他对象尽可能少的了解 11、构造者的的退化模式是通过合并（ c ）角色完成退化的。 A.抽象产品 B产品 C创建者 D使用者 12、单子（单例，单态）模式类图结构如下： 下列论述中，关于”0..1”表述的不正确的是( d ) A.1表示,一个单例类中,最多可以有一个实例. B.”0..1”表示单例类中有不多于一个的实例 C.0表示单例类中可以没有任何实例 D.0表示单例类可以提供其他非自身的实例 13、对象适配器模式是（ a ）原则的典型应用。 A.合成聚合复用原则 B.里式代换原则 C.依赖倒转原则 D.迪米特法则 14、静态工厂的核心角色是（a） A.抽象产品 B.具体产品 C.静态工厂 D.消费者 15、下列关于静态工厂与工厂方法表述错误的是：（ a ） A.两者都满足开闭原则：静态工厂以if else方式创建对象，增加需求的时候会修改源代码 B.静态工厂对具体产品的创建类别和创建时机的判断是混和在一起的，这点在工厂
可用性设计原则 文档修改记录
启发式评估原则 (1) 可学习性 (3) 1.可见性 (3) 刺激强度 (3) 模式 (3) 反馈 (4) 识别 (4) 定位 (4) 2.可预见性 (4) 一致性和正确性 (4) 惯例 (5) 熟悉度 (5) 布局 (5) 模式 (6) 3.映射与启示性 (6) 4.真实性 (6) 5.帮助性 (7) 有效性 (7) 1.效用 (7) 用户控制原则 (8) 操作与目标相符原则 (8) 正确的功能与复杂度平衡原则 (8) 2.容错性（安全性） (9) 避免出错原则 (10) 错误恢复原则 (10) 用户控制和自由——清楚的标识退出 (10) 3.稳定性 (11) 高效性（效率） (11) 4.简洁性 (11) 去除界面冗余元素原则 (11) 80/20原则 (11) 满意度原则 (12) 渐进原则 (12) 合理约束原则 (12) 5.快捷性 (12) 6.可记忆性 (13) 7.灵活性 (13) 满意度 (13)
概述 1.可用性定义 ISO9241/11中的可用性定义是：特定用户在特定的使用环境下，使用某个产品达到特定目标的有效性、效率和满意度的大小。 2.相关术语描述 使用环境——用户、目标、任务、设备（硬件、软件和原料）、以及使用产品的物理环境和社会环境。 用户——与产品进行交互的人。 目标——一个预期的结果。 产品——在设备中，需要被详细说明或评估其可用性的一部分。 有效性——用户完成特定任务和达到特定目标时所具有的正确和完整程度； 效率——用户完成任务的正确和完整程度与所使用资源（如时间）之间的比率； 满意度——用户在使用产品过程中所感受到的主观满意和接受程度。 可学习性 3.可见性 可见性原则是指用户了解系统所有功能和组件，包括各种可用功能和使用后的系统反馈。 可见性原则规定所有的用户必须能够获知系统所有的功能和过程。在复杂的应用程序中完全实现可见性可能会导致用户界面难以使用。 刺激强度 我们首先感觉到的是刺激的强度，然后才是行为的含义。换言之，在理解某个事物之前就已经感知到它的颜色、形状和尺寸了。 模式 可见性原则与后文中提到的渐进原则、简洁性原则联合作用。 仅使用可见性原则而不考虑渐进将会导致视觉上的超负荷。界面设计中很容易使系统中的所有功能都可见，但是它使得用户所有精力都放在了辨析系统的功能而不是认真学习用户交互界面，同时不能够按照要求进行交互并按照新的任务要求更新界面。
设计模式大作业 (总分：20分) 问题1. 请简述什么是里氏代换原则？ (5分) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。严格表述如下：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这个定义比较拗口且难以理解，因此我们一般使用它的另一个通俗版定义：所有引用基类的地方必须能透明的使用其子类的对象。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。 问题2. 阅读以下代码，并回答问题：(7分) public class MyOrderedCollection { protected List
软件设计模式目标原则 Revised by BLUE on the afternoon of December 12,2020.
软件设计模式、目标、原则 软件设计模式 一、设计目标： ⑴、软件设计目标：正确性、健壮性、灵活性、可重用性、高效性 1、正确性：也就是满足应用程序的需求。 2、健壮性：是指软件对于规范要求以外的输入情况的处理能力。也就是说，在异常情况下，软件能够正常运行的能力。 3、灵活性：就是可以允许代码修改平稳地发生，而不会波及到很多其他的模块。 4、可重用性：也就是重复使用的意思。 5、高效性：一般指两个方面，一是执行效率，二是存储效率。 ⑵、良好设计的特征：可扩展性、灵活性、可插入性 1、可扩展性：新功能容易加入，而且不会影响已有功能，即不“僵硬” 2、灵活性：修改一个地方，不会影响其他，即不“脆弱” 3、可插入性：用一个容易替换另一个类，只要它们实现相同接口即可，即低“黏度” ⑶、面向对象的三大特征：继承性、封装性、多态性 1、继承性：特殊类的对象具有其一般类的对象的全部属性和行为，即称特殊类对一般类的继承。 2、封装性：把对象的属性和行为组合成为一个独立的单位或部件，并尽可能隐蔽对象的内 部细节，而只保留必要的对外接口，使之与外部发生联系。 3、多态性：是指不同类型的对象接收相同的消息时，产生不同的行为 二、设计原则：
⑴、软件设计原则：单一职责原则、开闭原则、里氏替换原则、接口 分离原则、依赖倒置原则 1、单一职责原则（SRP）：一个类应该有且只有一个改变的理由，它要求“一个设计元素只做一件事”。 2、开闭原则（OCP）：不修改原有类就能扩展一个类的行为。也就是说，一个软件实体应当对扩展开放，对修改关闭。 3、里氏替换原则（LSP）：子类能替换其超类（is-a 关系），也就是说子类型（subtype）必须能替换其基类型（base type）。 4、接口分离原则（ISP）：使用多个专门的接口比使用单一的总接口更好；换言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口之上的；不应该强迫客户程序依赖于它们不用的接口 5、依赖倒置原则（DIP）：要依赖于抽象，不要依赖于具体：也就是说，抽象不应当依赖 于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程。 三、设计模式： ⑴、软件设计模式的定义： 1、模式：是做事的一种方法，也即是实现某个目标的途径，或者技术。 2、设计模式：描述了软件设计过程中某一类常见问题的一般性的解决方案 3、设计模式：是类的联合体以及与之相伴的算法，这些算法能够实现共同的设计目标。设计模式表达了一种思想而不仅仅是固定的类联合体，相伴的算法表示模式的基本操作。 ⑵、面向对象设计模式的定义： 1、面向对象设计模式：描述了面向对象设计过程中，特定场景下，类与相互通信的对象之间常见的组织关系。
设计模式主要分三个类型:创建型、结构型和行为型。 其中创建型有： 一、Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点 二、Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。 三、Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。 四、Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示。 五、Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。 行为型有： 六、Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。 七、Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。 八、Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。 九、Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。 十、State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。 十一、Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户。 十二、China of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系 十三、Mediator，中介者模式：用一个中介对象封装一些列的对象交互。 十四、Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。 十五、Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 十六、Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 结构型有： 十七、Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite使得用户对单个对象和组合对象的使用具有一致性。 十八、Facade，外观模式：为子系统中的一组接口提供一致的界面，fa?ade 提供了一高层接口，这个接口使得子系统更容易使用。 十九、Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问
设计集团管控模式的六条原则 某市政工程有限公司成立于1993年，并于2001年在原公司基础上组建成立了X建设集团，经过短短十多年的发展，已经形成了一个以工程建设为核心，以地产开发为补充，以对外投资为支撑的集团公司，经营范围涵盖市政道桥、建筑安装、地产开发、材料生产、汽车销售、传媒教育、商贸物流、园区开发等多个领域。然而面对业务规模扩张、业务领域不断多元化、以及业务跨地域发展所带来的挑战，集团管理出现了多种“并发症”：集团总部定位不明确，对下属公司的管理仍然沿用原来的部门和分公司管理模式，管理效率低下；下属分子公司达到30多家，由于缺少具体分析，使用“一刀切”的管控模式，有的不该管的管得过死，有的该管的却又放得过宽；集团层面的管理输出能力不足，想发挥集团协同效应却缺乏足够的资源；缺乏管控的手段和科学的评估和监控手段……。 集团化是企业成长发展到一定阶段之后的必然选择，然而在长大的过程也免不了伴随着这些成长的烦恼。因此集团管控也就成了企业集团化绕不开的话题。 一、什么是集团管控模式 所谓企业集团的管控模式，是指集团对下属企业基于集分权程度不同而形成的管控策略，其具体体现在通过管控部门的设置、管控流程设计以及集团文化的传播来影响下属经营单位的战略、营销、财务、经营运作等方面的内容。集团管控模式的选择，说到底就是对集团集权与分权的度的把握，通过集权与分权的有机结合，实现整个集团各层级权、责、利的平衡。 二、集团管控的三种基本模式 企业集团对下属企业的管控模式，按照总部的集、分权程度不同可以划分为“操作管控型”、“战略管控型”和“财务管控型”三种基本管控模式。
操作管控型操作管控型的管控模式是高度集权的管控模式，强调过程控制是这种管控模式的鲜明特点。集团总部从战略规划制定到实施几乎什么都管，集团总部的各种职能管理非常深入，如人事管理不仅负责全集团的人事制度政策的制定，而且负责管理各下属公司二级管理团队及业务骨干人员的选拔、任聘。在实行这种管理模式的集团中各下属企业业务相关性高。为了保证总部能够正确决策并能应付解决各种问题，总部职能部门的人员会很多，规模会很庞大。在全球工业化开始的初期阶段，许多老牌全球性集团公司选择此种集团管控模式，以力保其全球随需而变的战略实施。操作管控型主要适用于以下情况：产权关系紧密度高，总部为投资中心和利润中心，而下属企业只是成本中心。 战略管控型战略管控型的管控模式是集权与分权相结合的一种管控模式，强调程序控制是这种管控模式的突出特点。集团总部负责整体的战略规划，下属企业同时也制定本业务单元的战略规划。在实行这种管控模式的集团中，集团总部的规模并不大，各下属企业业务的相关性也较高。运用这种管理模式的典型公司有英国石油、壳牌石油、飞利浦等。目前世界上大多数集团公司都采用或正在转向这种管控模式。战略管控型主要适用于以下情况：各下属企业业务相关性较高，产权关系紧密度较高，下属企业的业务运作比较成熟，对集团总部影响较大等。 财务管控型财务管控型的管控模式是最为分权的管控模式，强调结果控制是这种管控模式的突出特点。在实行这种管控模式的集团中，各下属企业业务的相关性可以很小。集团总部只负责集团的财务管理、资产运营、投资决策和实施监控等，以及对外部企业的收购、兼并工作。下属企业负责完成集团规定的财务目标。许多以收购、兼并为主要目标，且行业涉猎复杂的集团公司采用此类模式。GE公司也是采用这种管理模式，这种模式可以形象地表述为“有头脑，没有手脚。”财务管
设计模式的原则与策略 1、开闭原则（open-closed principle, OCP） 模块、方法和类应该对扩展开放，对修改封闭。 完全遵守开闭原则几乎是不可能的，但是它可以作为一个目标，指引正确的方向。代码越遵守这一原则，以后适应新（而且可能是无法预测的）需求就越轻松。 2、依赖倒置原则（dependency inversion principle, DIP） ?高层模块不应该依赖于低层模块。高层模块和低层模块都应该依赖抽象。?抽象不应该依赖于细节。细节应该依赖于抽象。 Christopher Alexander 称此为“复杂化”——一种从最简单（概念性）的层次开始，然后逐渐添加细节和特征，随着逐步深化，设计也渐趋复杂的过程。复杂化的依赖倒置是使用设计模式的中心基础原则。 这一原则隐含着使用对象和被使用对象之间只能在概念层次存在耦合，而非实现层次，这与《设计模式》一书中所建议的应该“按接口设计”可以说是英雄所见略同。 3、里氏代换原则（LSP）
子类型必须能够替换掉它们的父类型。 一个从基类派生的类应该支持基类的所有行为。→ （只要有可能）让使用对象无法知道是否存在派生类。实践中，这意味着子类型不应该在基类型的公开接口中添加新的公开方法。这还意味着，基类型必须是所建模的概念的完整规格说明。 （这和目前所理解的子类的扩展的作用相悖，实践中可能会遇到困难，所以以前一直知道这个原则，但却放弃遵循。其实是理解得不对，看下面这个例子就知道以后应该怎么做了。 但是，“子类型不应该在基类型的公开接口中添加新的公开方法”，这一点似乎很少能做得到。） 例 问题：一个鸟类，一个企鹅类，如果鸟是可以飞的，企鹅不会飞，那么企鹅是鸟吗？企鹅可以继承鸟这个类吗？ 回答：鸟会飞，企鹅不会飞，尽管在生物学分类上，企鹅是一种鸟，但在编程世界里，企鹅不能继承“鸟类”，因为企鹅不能支持“鸟类”的飞这个动作。 4、封装变化原则 不让一个类封装两个要变化的事物，除非这些变化明确地耦合在一起。 5、单一职责原则（SRP） 就一个类而言，应该仅有一个引起它变化的原因。
实验5 结构型和行为型设计模式实验 实验学时： 2 每组人数： 1 实验类型： 3 （1：基础性2：综合性3：设计性4：研究性） 实验要求： 1 （1：必修2：选修3：其它） 实验类别： 3 （1：基础2：专业基础3：专业4：其它） 一、实验目的 熟练使用PowerDesigner和任意一种面向对象编程语言实现几种常见的结构型和行为型设计模式，包括代理模式、职责链模式和命令模式，理解每一种设计模式的模式动机，掌握模式结构，学习如何使用代码实现这些模式。 二、实验内容 1. 在某应用软件中需要记录业务方法的调用日志，在不修改现有业务类的基础上为每一个类提供一个日志记录代理类，在代理类中输出日志，例如在业务方法method()调用之前输出“方法method()被调用，调用时间为2014-11-5 10:10:10”，调用之后如果没有抛异常则输出“方法method()调用成功”，否则输出“方法method()调用失败”。在代理类中调用真实业务类的业务方法，使用代理模式设计该日志记录模块的结构，绘制类图并编程模拟实现。 2. 某软件公司承接了某信息咨询公司的收费商务信息查询系统的开发任务，该系统的基本需求如下： (1) 在进行商务信息查询之前用户需要通过身份验证，只有合法用户才能够使用该查询系统； (2) 在进行商务信息查询时系统需要记录查询日志，以便根据查询次数收取查询费用。 该软件公司开发人员已完成了商务信息查询模块的开发任务，现希望能够以一种松耦合的方式向原有系统增加身份验证和日志记录功能，客户端代码可以无区别地对待原始的商务信息查询模块和增加新功能之后的商务信息查询模块，而且可能在将来还要在该信息查询模块中增加一些新的功能。 试使用代理模式设计并编程模拟实现该收费商务信息查询系统。【提示：使用保护代理和智能引用代理】 3. 某企业的SCM(Supply Chain Management，供应链管理)系统中包含一个采购审批子系统。该企业的采购审批是分级进行的，即根据采购金额的不同由不同层次的主管人员来审批，主任可以审批5万元以下（不包括5万元）的采购单，副董事长可以审批5万元至10万元（不包括10万元）的采购单，董事长可以审批10万元至50万元（不包括50万元）的采购单，50万元及以上的采购单就需要开董事会讨论决定。如下图所示：