设计模式6大原则
目录
敏捷软件开发宣言 (2)
原则 (2)
极限编程实践 (2)
避免设计的臭味 (2)
设计原则 (3)
包和组件的设计原则 (3)
里氏替换原则（Liskov Substitution Principle） (9)
依赖倒置原则（Dependence Inversion Principle） (11)
接口隔离原则（Interface Segregation Principle） (14)
迪米特法则（Law Of Demeter） (21)
开闭原则（Open Close Principle） (26)
敏捷软件开发宣言
我们正通过亲身实践以及帮助他人实践，揭示更好的软件开发方法
通过这项工作，我们认为：
人和交互重于过程和工具
可以工作的软件重于面面俱到的文档
客户合作重于合同谈判
随时应对变化重于遵循计划
虽然右项也有其价值，但我们认为左项更加重要。
原则
1.我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2.我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。
3.经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
5.围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。
7.可以工作的软件是进度主要的度量标准。
8.敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。
9.对卓越技术和良好设计的不断追求有助于提高敏捷性。
10.简单——尽量减少工作量的艺术是至关重要的。
11.最好的架构、需求和设计都源于自我组织的团队。
12.每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。
极限编程实践
完整团队用户故事短交付周期验收测试结对编码测试驱动开发
集体所有权持续集成可持续的开发速度开放的工作空间计划游戏
简单设计重构隐喻
避免设计的臭味
僵化性（rigidity）——设计难以改变。
?脆弱性（fragility）——设计易于遭到破坏。
?顽固性（immobility）——设计难以重用。
?粘滞性（viscosity）——难以做正确的事情。
?不必要的复杂性（needless complexity）——过分设计。
?不必要的重复（needless repetition）——滥用鼠标进行复制、黏贴。
?晦涩性（opacity）——混乱的表达。
设计原则
?单一职责原则（SRP）：一个类应该只有一个发生变化的原因。
?开放封闭原则（OCP）：软件实体应该对扩展开放，对修改关闭。
?Liskov替换原则（LSP）：子类型（subtype）必须能够替换掉它的基类型（base type）。
?依赖倒置原则（DIP）：a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。b.
抽象不应该依赖于细节。细节应该依赖于抽象。
?接口隔离原则（ISP）：不应该强迫客户程序依赖并未使用的方法。
?DRY：Don’t repeat yourself Principle。通过抽取公共部分放置在一个地方避免代码重复。
?封装变化（Encapsulate what varies）。
?面向接口编程而不是实现（Code to an interface rather than to an implementation）。
?优先使用组合而非继承（Favour Composition Over Inheritance）。
包和组件的设计原则
?重用-发布等价原则（Reuse-Release Equivalence Principle, REP）：重用的粒度就是发布的粒度。
?共同重用原则（Common-Reuse Principle, CRP）：一个组件中的所有类应该是共同重用的。如果重用了组件中的一个类，那么就要重用组件中的所有类。
?共同封闭原则（Common-Closure Principle, CCP）：组件中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的组件产生影响，则对该组件中的所有类产生影响，二对于其他组件则不造成任何影响。
?无环依赖原则（Acycle-Dependencies Principle, ADP）：在组件的依赖关系图中不允许存在环。
?稳定依赖原则（Stable-Dependencies Principle, SDP）：朝着稳定的方向进行依赖。
?稳定抽象原则（Stable-Abstraction Principle, SAP）：组件的抽象程度应该与其稳定程度一致。
七种敏捷开发的方法敏捷开发包括一系列的方法，主流的有如下七种：
XP
XP（极限编程）的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
FDD
FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。
ASD
ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDM
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUP
RUP其实是个过程的框架，它可以包容许多不同类型的过程，
Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。
单一职责原则（Single Responsibility Principle）
定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T 时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。
比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。
举例说明，用一个类描述动物呼吸这个场景：
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}
}
public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
}
}
运行结果：
牛呼吸空气
羊呼吸空气
猪呼吸空气
程序上线后，发现问题了，并不是所有的动物都呼吸空气的，比如鱼就是呼吸水的。修改时如果遵循单一职责原则，需要将Animal类细分为陆生动物类Terrestrial，水生动物Aquatic，代码如下：
class Terrestrial{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}
}
class Aquatic{
public void breathe(String animal){
System.out.println(animal+"呼吸水");
}
}
public class Client{
public static void main(String[] args){
Terrestrial terrestrial = new Terrestrial();
terrestrial.breathe("牛");
terrestrial.breathe("羊");
terrestrial.breathe("猪");
Aquatic aquatic = new Aquatic();
aquatic.breathe("鱼");
}
}
运行结果：
牛呼吸空气
羊呼吸空气
猪呼吸空气
鱼呼吸水
我们会发现如果这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代码如下：
class Animal{
public void breathe(String animal){
if("鱼".equals(animal)){
System.out.println(animal+"呼吸水");
}else{
System.out.println(animal+"呼吸空气");
}
}
}
public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe("鱼");
}
}
可以看到，这种修改方式要简单的多。但是却存在着隐患：有一天需要将鱼分为呼吸淡水的鱼和呼吸海水的鱼，则又需要修改Animal类的breathe方法，而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险，也许某一天你会发现程序运行的结果变为“牛呼吸水”了。这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但隐患却是最大的。还有一种修改方式：
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}
public void breathe2(String animal){
System.out.println(animal+"呼吸水");
}
}
public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe2("鱼");
}
}
可以看到，这种修改方式没有改动原来的方法，而是在类中新加了一个方法，这样虽然也违背了单一职责原则，但在方法级别上却是符合单一职责原则的，因为它并没有动原来方法的代码。这三种方式各有优缺点，那么在实际编程中，采用哪一中呢？其实这真的比较难说，需要根据实际情况来确定。我的原则是：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
例如本文所举的这个例子，它太简单了，它只有一个方法，所以，无论是在代码级别上违反单一职责原则，还是在方法级别上违反，都不会造成太大的影响。实际应用中的类都要复杂的多，一旦发生职责扩散而需要修改类时，除非这个类本身非常简单，否则还是遵循单一职责原则的好。
遵循单一职责原的优点有：
λ可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
λ提高类的可读性，提高系统的可维护性；λ变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都需要遵循这一重要原则。
里氏替换原则（Liskov Substitution Principle）
肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。
定义1：如果对每一个类型为T1的对象o1，都有类型为T2 的对象o2，使得以T1定义的所有程序P 在所有的对象o1 都代换成o2 时，程序P 的行为没有发生变化，那么类型T2 是类型T1 的子类型。定义2：所有引用基类的地方必须能透明地使用其子类的对象。
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
举例说明继承的风险，我们需要完成一个两数相减的功能，由类A来负责。
class A{
public int func1(int a, int b){
return a-b;
}
}
public class Client{
public static void main(String[] args){
A a = new A();
System.out.println("100-50="+a.func1(100, 50));
System.out.println("100-80="+a.func1(100, 80));
}
}
运行结果：
100-50=50
100-80=20
后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：
λ两数相减。
λ两数相加，然后再加100。
由于类A已经实现了第一个功能，所以类B继承类A后，只需要再完成第二个功能就可以了，代码如下：
class B extends A{
public int func1(int a, int b){
return a+b;
}
public int func2(int a, int b){
return func1(a,b)+100;
}
}
public class Client{
public static void main(String[] args){
B b = new B();
System.out.println("100-50="+b.func1(100, 50));
System.out.println("100-80="+b.func1(100, 80));
System.out.println("100+20+100="+b.func2(100, 20));
}
}
类B完成后，运行结果：
100-50=150
100-80=180
100+20+100=220
我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能出现了错误。在本例中，引用基类A完成的功能，换成子类B之后，发生了异常。在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
看上去很不可思议，因为我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑的好好的。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？
后果就是：你写的代码出问题的几率将会大大增加。
依赖倒置原则（Dependence Inversion Principle）
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C 发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖倒置原则的中心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：
class Book{
public String getContent(){
return"很久很久以前有一个阿拉伯的故事……";
}
}
class Mother{
public void narrate(Book book){
System.out.println("妈妈开始讲故事");
System.out.println(book.getContent());
}
}
public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
}
}
运行结果
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
运行良好，假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事。class Newspaper{
public String getContent(){
return"林书豪38+7领导尼克斯击败湖人……";
}
}
这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。
我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物。
interface IReader{
public String getContent();
}
Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：
class Newspaper implements IReader {
public String getContent(){
return"林书豪17+9助尼克斯击败老鹰……";
}
}
class Book implements IReader{
public String getContent(){
return"很久很久以前有一个阿拉伯的故事……";
}
}
class Mother{
public void narrate(IReader reader){
System.out.println("妈妈开始讲故事");
System.out.println(reader.getContent());
}
}
public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
mother.narrate(new Newspaper());
}
}
运行结果
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……
这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
采用依赖倒置原则给多人并行开发带来了极大的便利，比如上例中，原本Mother类与Book
类直接耦合时，Mother类必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序则可以同时开工，互不影响，因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的TDD 开发模式就是依赖倒置原则最成功的应用。
传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。
在实际编程中，我们一般需要做到如下3点：
低层模块尽量都要有抽象类或接口，或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则。
总之，依赖倒置原则就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
接口隔离原则（Interface Segregation Principle）
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
举例来说明接口隔离原则：
（图1 未遵循接口隔离原则的设计）
这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。对类图不熟悉的可以参照程序代码来理解，代码如下：
interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}
class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}
class B implements I{
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
//对于类A来说，method4和method5不是必需的，但是由于接口A中有这两个方法，
//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。public void method4() {}
public void method5() {}
}
class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}
class D implements I{
public void method1() {
System.out.println("类D实现接口I的方法1");
}
//对于类C来说，method2和method3不是必需的，但是由于接口A中有这两个方法，
//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。public void method2() {}
public void method3() {}
public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}
public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D()); }
}
可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如图2所示：
（图2 遵循接口隔离原则的设计）
照例贴出程序的代码，供不熟悉类图的朋友参考：
interface I1 {
public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
public void method5();
}
class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}
class B implements I1, I2{
public void method1() {
System.out.println("类B实现接口I1的方法1");
Java23种设计模式6大原则总结
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
问卷设计六大原则
问卷设计六大原则 问卷调查是目前调查业中所广泛采用的调查方式——即由调查机构根据调查目的设计各类调查问卷，然后采取抽样的方式(随机抽样或整群抽样)确定调查样本，通过调查员对样本的访问，完成事先设计的调查项目，最后，由统计分析得出调查结果的一种方式。它严格遵循的是概率与统计原理，因而，调查方式具有较强的科学性，同时也便于操作。这一方式对调查结果的影响，除了样本选择、调查员素质、统计手段等因素外，问卷设计水平是其中的一个前提性条件。而问卷设计的好坏很大程度上又与设计制度(原则)有关! 一、合理性。合理性指的是问卷必须紧密与调查主题相关。违背了这样一点，再漂亮或精美的问卷都是无益的。而所谓问卷体现调查主题其实质是在问卷设计之初要找出与“调查主题相关的要素”! 如：“调查某化妆品的用户消费感受”——这里并没有一个现成的选择要素的法则。但从问题出发，特别是结合一定的行业经验与商业知识，要素是能够被寻找出来的：一是使用者(可认定为购买者)。包括她(他)的基本情况(自然状况：如性别、年龄、皮肤性质等)；使用化妆品的情况(是否使用过该化妆品、周期、使用化妆品的日常习惯等)；二是购买力和购买欲。包括她(他)的社会状况收入水平、受教育程度、职业等)；化妆品消费特点(品牌、包装、价位、产品外观等)；使用该化妆品的效果(评价。问题应具有一定的多样性、但又限制在某个范围内，如Ⅰ．价格；Ⅱ．使用效果；Ⅲ．心理满足，等)；三是产品本身。包括对包装与商标的评价、广告等促销手段的影响力、与市场上同类产品的横向比较、等……应该说，具有了这样几个要素对于调查主题的结果是有直接帮助的。被访问者也相对容易了解调查员的意图，从而予以配合。 二、一般性。即问题的设置是否具有普遍意义。 应该说，这是问卷设计的一个基本要求，但我们仍然能够在问卷中发现这类带有一定常识性的错误。这一错误不仅不利于调查成果的整理分析，而且会使调查委托方轻视调查者的水平。如搞一个“居民广告接受度”的调查： 问题：你通常选择哪一种广告媒体： 答案：a、报纸；b、电视；c、杂志；d、广播；e、其它 而如果答案是另一种形式： a、报纸； b、车票； c、电视； d、墙幕广告； e、汽球； f、大巴士； g、广告衫； h、…… 如果我们的统计指标没有那么细(或根本没必要)，那我们就犯了一个“特殊性”的错误，从而导致某些问题的回答实际上是对调查无助的! 在一般性的问卷技巧中，需要注意的是：不能犯问题内容上的错误。如： 问题：你拥有哪一种信用卡? 答案：a、长城卡；b、牡丹卡；c、龙卡；d、维萨卡；e、金穗卡； ——其中“d”的设置是错误的，应该避免。 三、逻辑性。问卷的设计要有整体感，这种整体感即是问题与问题之间要具有逻辑性，独立的问题本身也不能出现逻辑上的谬误。从而使问卷成为一个相对完善的小系统。如： 问题： Ⅰ、你通常每日读几份报纸? a、不读报； b、1份； c、2份； d、3份以上； Ⅱ、你通常用多长时间读报? a、10分钟以内； b、半小时左右； c、1小时； d、1小时以上； Ⅲ、你经常读的是下面哪类(或几类)报纸? a、×市晚报； b、×省日报； c、人民日报； d、参考消息； e、中央广播电视报； f、足球…… 在以上的几个问题中，由于问题设置紧密相关，因而能够获得比较完整的信息。调查对象也会感到问题集中、提问有章法。相反，假如问题是发散的、带有意识流痕迹的，问卷就会给人以随意性而不是严谨性的感觉。那么，将市场调查作为经营决策的一个科学过程的企业就会对调查失去信心! 因此，逻辑性的要求即是与问卷的条理性、程序性分不开的。已经看到，在一个综合性的问卷中，调查者将差异较大的问卷分块设置，从而保证了每个“分块”的问题都密切相关。 四、明确性。所谓明确性，事实上是问题设置的规范性。这一原则具体是指：命题是否准确?提问是
设计模式考试复习题
一、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) 理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。 应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
广告海报设计的6大原则
广告海报设计的6大原则 导语：无规矩不成方圆，凡事都应该遵守原则，我们都知道广告对于我们很重要，广告海报设计的好可以为企业带来良好的效益，如今的社会是遵循优胜劣汰的生存法则，所以我们要增加自己的竞争力，更好的发展自己，因此宣传就很重要，然而广告海报设计在宣传上能起到很好的作用，下面就由小编为大家介绍一下广告海报设计的6大原则，希望对大家有所帮助！ 一、冲击性原则。 在令人眼花缭乱的各种广告中，要想迅速吸引人们的视线，在广告公司创意海报就必须把提升视觉张力放在首位。照片是广告中常用的视觉内容，将摄影艺术与电脑后期制作充分结合，拓展了广告公司创意海报的视野与表现手法，产生了强烈的视觉冲击力，给观众留下了深刻的印象。 二、包蕴性原则。 吸引人们眼球的是形式，打动人心的是内容。独特醒目的形式必须蕴含耐人思索的深邃内容，才拥有吸引人一看再看的魅力。这就要求广告公司创意广告海报设计时不能停留在表层，而要使“本质”通过“表象”显现出来，这样才能有效地挖掘读者内心深处的渴望。 三、新奇性原则。
新奇是广告作品引人注目的奥秘所在，也是一条不可忽视的广告创意规律。有了新奇，才能使广告公司创意海报波澜起伏，奇峰突起，引人入胜；有了新奇，才能使广告公司创意海报主题得到深化、升华。 四、应合理规划。 每一份广告海报设计的版面规划是否科学与规范也影响广告海报设计的广告效果的一个非常重要的条件。科学的对版面进行规划能够给大家造成一种比较好的视觉效果。 五、需构思要巧妙。 产品的构思往往决定着一个产品能否得到大家的喜欢。对于一份构思比较巧妙的广告海报设计来说，无疑是会吸引大家关注的目光的，也是能够得到人们认可的一个非常重要的条件。 六、内容要全面充分。 因为广告海报设计最重要的一个要素就是广告宣传，所以，在设计广告海报设计的时候，应尽可能的把有关广告宣传的信息较好的融入到广告海报设计的中。
教育游戏中游戏任务设计的原则与方法
教育游戏中游戏任务设计的原则与方法 [摘要]本文主要阐述了教育游戏中游戏任务设计的原则，即根据教学目标的类型层次、不同领域的课程知识、游戏者的认知水平以及游戏任务本身的结构四方面进行游戏任务设计，并说明了游戏任务实现的方法，以获得游戏教育性与游戏性的平衡统一。 ［关键词］教育游戏；游戏任务；设计；原则；方法 在教育游戏中，玩家具有游戏者和学习者双重身份。游戏的任务设计和教学中的教学目标分析有相似之处，但两者不是等同关系。游戏任务是教学目标与教学内容的外部表现形式，教学目标与教学内容是游戏的本质,游戏中的任务和目标来源于教与学目标及内容的确定。因此，首先需明确分析游戏者需要获得的经验知识是哪些，游戏者使用该游戏软件后需形成的思想和表现的行为，然后分析当前状态与目标状态之间的差距，最后确定是否能使用游戏的形式加以实现。假如游戏是可行的方式，下一步开始设计合适的游戏任务和目标。游戏任务是从游戏者的角度出发，而游戏目标则是从游戏的设计者视角出发，即学习目标。这些目标隐含在任务中，游戏者完成任务意味在达到游戏设计师预设的学习目标。 一、游戏任务设计的原则 1．根据教学目标的类型层次设计形式恰当的游戏任务 在设计游戏时，首先需要考虑的是教学目标的类型和层次。根据不同的教学内容，教学目标可分解成言语信息、智慧技能、心智运动技能和态度技能。 言语信息需要学习者给出特定问题的特定答案，即能说出、能列出或能描述出某样东西，一般属于记忆性知识。目前多数游戏任务设计针对于这种内容，目的仅在于帮助学习者更好地记住某种信息。如果游戏软件仅仅停留在此种水平，学习者的学习方式极有可能变成机械式的学习，如果过度使用就会抑制儿童的想象力。这也是目前设计教育游戏需要跳出的困境。 智慧技能需要学习者形成概念、运用规则和解决问题。其中，问题可以分为良构问题和劣构问题。我们可以根据“梅克——斯维克问题类型连续体理论”进行分析。该理论把问题解决按照该问题所需的创造性程度来划分等级，分别从教师和学生两个点出发，将问题、问题解决的方法和问题的答案三个方面分成五个维度，见下表：
POP的制作基本要点
POP的制作基本要点 一、POP的定义 在国际贸易中POP的意思是:产品证明 Proof of Product 也就是货物证明ＰＯＰ(Point Of Purchase)本来是指商业销售中的一种店头促销工具，其型式不拘，但以摆设在店头的展示物为主，如吊牌、海报、小贴纸、大招牌、实物模型、旗帜等等，都是林立在ＰＯＰ的范围内。ＰＯＰ的中文名字又名「店头陈设」。 二、POP手绘海报的兴起 近年来，由于日本引进店头展示的行销观，店家们开始重视门面的包装，而店面上出现大量以纸张绘图告知消费者讯息的海报出现，也许是大量印刷的或是手工绘制的，形成一波流行的潮流。而之中最令人侧目的是手绘POP的兴起。 早期由十分简单，不重视美观仅在乎告知讯息的文字POP，到最近演变出的一波手绘POP 文化，大量的图案及素材活泼地呈现在海报纸上，色彩丰富吸引人的目光，手绘POP是近年来的一项艺术。而除了在商业上应用之外，校园内也逐潮流行起海报绘制的工作，举凡社团活动、学会宣传、校际活动周知，无不利用最简单的工具来绘制出五花十色的海报。而手绘海报也由最初的「大字报」时期变型成为文图并茂的「图文看板」。 三、POP手绘海报常使用的工具 绘制一张精美的POP海报，可以利用以下的工具来混合搭配，不限定一定要利用某一种特定的工具，这些都是完成一张POP手绘海报的基本工具，可以在美术行或是书店中买到： 一、彩色笔：分角头及圆头二种笔头。 二、麦克笔：分角头及圆头二种笔头，又分酒精、水性、油性三种溶液的麦克笔。 三、粉、蜡笔。 四、粉彩笔。 五、色铅笔、素描铅笔。 六、水彩、广告颜料、圆或平的水彩笔。 七、毛笔、墨汁、色丹。 八、笔刀、美工刀、割圆器、造型剪刀、剪刀。 九、双面胶、口红胶、透明胶带、纸胶带、胶水、照片胶、台湾黏胶。 十、切割板、切割钢尺（三十公分、七十公分、一百公分各一）、小尺、波浪尺、软尺。
六西格玛设计的8个基本原则
https://www.360docs.net/doc/9c3124840.html,/ 六西格玛设计的8个基本原则 简单地讲，六西格玛设计是为了满足顾客的要求和期望，并可为顾客带来价值和服务。六西格玛设计同传统设计一样，一些基本原则应该满足。否则，并非是一个成功的六西格玛设计项目。 1、性能指标适合要求的原则 每一种新产品或服务，性能指标必须达到顾客要求，这也是最低要求。新产品或服务的规格应该是清晰的，而且是可测量的。 2、实用性和舒适性的原则 每一种新产品或服务，要实用性和舒适性相结合，能使顾客满意，新产品设计要新颖，要符合美学原则。 3、创新性和超前性原则 每一种新的发明创造，能起到一种推动社会进步的作用。优秀的六西格玛设计师，是人类文明的开拓者。设计的项目具有创新精神和超前意识，为顾客带来新的愉悦，为社会创造价值，为人类作出贡献。 4、工艺性和可制造性原则 每一种新产品或服务设计出来，要能够形成商品，并快速投放市场，应该具有好的工艺性或可制造性。无论是加工或组装，工艺性能要满足制造要求，且夹具及辅料要最省，通用零部件要省，标准化程度要高。 5、可靠性原则 每一种新产品或服务设计出来，新产品要有一定的可靠度，满足顾客的预期使用寿命，为顾客真正带来价值。 6、可维修性原则 每一种新产品设计出来，在保障使用的前提下，可维修性也要提出来。尽量模块化、标准化、通用化，拆卸维修方便，提高产品的使用寿命，超越顾客的期望。 7、成本效益原则 每一种新产品的设计都要考虑成本与效益的问题，找到一个顾客与提供商的成本与效益的最佳平衡点。六西格玛设计师要系统考虑，全面统筹，给顾客带来价值的同时，要考虑给股东或社会带来价值。 8、安全性原则 每一种新产品或服务投放市场，应该是安全地满足顾客的要求和期望，六西格玛设计师要充分考虑设计的稳健性，提供必要的裕量。防止失效，防止给人类和社会造成灾难。这样的例子是不胜枚举的。往往是由于设计师的疏忽而酿成大祸。六西格玛设计师是人类灵魂的工程师，社会的进步，人类的发展，他们的作用是功不可没的。安全性要始终牢记于心，一种新产品或服务，要为社会带来福音。
设计模式试卷
设计模式期中考试试题 一：单项选择（共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) 可学习性 (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.可见性 可见性原则是指用户了解系统所有功能和组件，包括各种可用功能和使用后的系统反馈。 可见性原则规定所有的用户必须能够获知系统所有的功能和过程。在复杂的应用程序中完全实现可见性可能会导致用户界面难以使用。 刺激强度 我们首先感觉到的是刺激的强度，然后才是行为的含义。换言之，在理解某个事物之前就已经感知到它的颜色、形状和尺寸了。 模式 可见性原则与后文中提到的渐进原则、简洁性原则联合作用。 仅使用可见性原则而不考虑渐进将会导致视觉上的超负荷。界面设计中很容易使系统中的所有功能都可见，但是它使得用户所有精力都放在了辨析系统的功能而不是认真学习用户交互界面，同时不能够按照要求进行交互并按照新的任务要求更新界面。
海报设计基本知识
海报设计 海报（Poster）又称“招贴”。是一种在户外如马路、码头、车站、机场、运动场或其他公共场所张贴的速看广告。由于海报的幅度比一般报纸广告或杂志广告大，从原处都可以吸引大家的主义，因此在宣传媒介中占有很重要的位置。 海报的范围很广，举凡是商品展览、书展、音乐会、戏剧、运动会、时装表演、电影、旅游、慈善、或其他专题性的事物，都可以透过海报做广告宣传。 海报的目的当然是要吸引观众去看。在设计海报之前，我们要想一想如何去传达我们要表达的内容。如何使观众停下来细读海报的内文呢？ 最有效的方法是“新颖”两个字。一般人的心理都是好奇的，只有新鲜、奇异、或刺激的事物才能引起观众的注意。因此，设计海报的首要工作就“造形”。在本质上，海报上的图案是属于装饰性艺术，惟有解决了“造形”才能作其他构图设计。 要设计一幅成功的海报，还需要注意几项基本原则： 那就是主题、构图、色彩和字体。 主题即内容。一幅海报，不论是以图案或摄影作表达，
一定要配合事物的内容，不同性质的海报要配合不同内容的画面。假如是一幅宣传机器或重工业的海报，很明确，便需要配合粗壮的图案和标题。假如是关于芭蕾舞或其他轻巧的事物，它的画面便需要配上柔和细致的描写。比方我们设计一幅有关音乐会的海报，我们可以用下列的方法去处理：一是主题的造型，从音乐，我们可以联想到音符，各种中西乐器的形状，或是流水、海水、云、雪、线条的跳动。假如是属于敲击乐器，又可以联想到一些柔和雅淡的色彩衬托着细致的线条和字体。有关色彩方面，假如是暖灯、暖气机等冬天用品，很明显要采用红色或黄色等暖色，给予人们一种温暖的感觉。相反地，假如是属于冷气机、风扇或冰箱等夏天用品，我们便采用青色、绿色、或青紫色等冷色，给予人们一种清新凉快的感觉。海报上的色彩配合，一般是将图案和标题的面色与底色配合，产生良好的对比效果。 海报设计的六大原则 美国是广告的王国，海报在广告上扮演了重要的角色。根据美国名海报设计家所倡导的海报制作六大原则是： (1)单纯：形象和色彩必须简单明了（也就是简洁性）。 (2)统一：海报的造型与色彩必须和谐，要具有统一的协调效果。 (3)均衡：整个画面须要具有魄力感与均衡效果。 (4)销售重点：海报的构成要素必须化繁为简，尽量挑选重点
设计模式大作业
设计模式大作业 (总分：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
任务型教学设计原则
英语阅读教学的任务设计原则 曹杨中学魏岭 一、关于活动任务设计，新《课程标准》提出了多条建议： 1、活动要有明确的目的并具有可操作性； 2、活动要以学生的生活经验和兴趣为出发点，内容和方式要尽量真实； 3、活动要有利于学生学习英语知识、发展语言技能，从而提高实际语言能力； 4、活动应积极促进英语学科其他学科间的相互渗透和联系，使学生的思维和想象力、审美情趣和艺术感受、协作和创新精神等综合素质得到发展； 5、活动要能促使学生获取、处理和使用信息，用英语与他人交流，发展用英语解决实际问题的能力； 6、活动不应该仅限于课堂教学，要延伸课堂之外的学习和生活中。 英语课堂教学由教师、学生、语言学习材料和媒体等基本要素构成，教学是一种有计划、有目的、有组织的活动过程。为此，我们有必要对高中英语阅读课的“任务教学模式”的设计原则进行探讨。 所谓任务型教学就是一种以具体的任务为学习的动力或动机，以完成任务的过程为学习的过程，一是一种展示任务成果的方式来体现教学成就的一种教学方式。 二、高中英语阅读课的“任务教学模式”的设计应遵循以下几个原则： 1、学生主体性原则 实施任务教学，首先应扮好演好师生各自的角色，教师应扮演助学者、任务的组织者和完成任务的监管者；学生是交际者和任务的完成者，其主要任务是沟通（传递与接受）信息，能自由地在教师的引导下，通过对话、交流等学习活动，在完成任务的过程中掌握新知识，并能将所学的语言融会贯通，进而扩展到自己的现实生活中去，为此课堂教学要做到以下几点： （1）以学生为主体，在学习内容上更强调学生的参与性。“任务型教学”的任务设计，实际上是指学生的学习任务设计，因此，学生的主体性参与不仅关系到知识目标的达成，更重要的是涉及到学生能力的全面发展。 （2）“以学生为主体”在学习形式上更强调互动性。既有师生互动，也有生生互动，
i园林竖向设计的原则与任务
i园林竖向设计的原则与任务
园林竖向设计的原则与任务 其主要涉及的事物有：竖向设计的一般原则以及竖向设计的基本步骤，竖向设计的任务及其目的 园林竖向设计应与园林绿地总体规划同时进行。在设计中，必须处理好自然地形和园林建筑工程中各单项工程（如园路、工程管线、园桥、构筑物、建筑等）之间的空间关系，做到园林工程经济合理、环境质量舒适良好、风景景观优美动人。这是园林竖向设计的基本工程目标所在，而不仅仅是安排若干竖向标高数字以及使土方平衡的问题。 一、园林竖向设计的一般原则 竖向设计是直接塑造园林立面形象的重要工作。其设计质量的好坏，设计所定各项技术经济指标的高低，设计的艺术水平如何，都将对园林建设的全局造成影响。因此，在设计中除了要反复比较、深入研究、审慎落笔之外，还要遵循以下几方面的设计原则。 1．功能优先，造景并重 进行竖向设计时，首先要考虑使园林地形的起伏高低变化能够适应各种功能设施的需要。对建筑、场地等的用地，要设计为平地地形；对水体用地，要调整好水底标高、水面标高和岸边标高；对园路用地，
则依山随势，灵活掌握，只控制好最大纵坡、最小排水坡度等关键的地形要素。在此基础上，同时注重地形的造景作用，尽量使地形变化适合造景需要。 2．利用为主，改造为辅 对原有的自然地形、地势、地貌要深入分析，能够利用的就尽量利用；做到尽量不动或少动原有地形与现状植被，以便更好地体现原有乡土风貌和地方的环境特色。在结合园林各种设施的功能需要、工程投资和景观要求等多方面综合因素的基础上，采取必要的措施，进行局部的、小范围的地形改造 3．因地制宜，顺应自然 造园应因地制宜，宜平地处不要设计为坡地，不宜种植处也不要设计为林地。地形设计要顺应自然，自成天趣。景物的安排、空间的处理、意境的表达都要力求依山就势，高低起伏，前后错落，疏密有致，灵活自由。就低挖池，就高堆山，使园林地形合乎自然山水规律，达到“虽由人作，宛自天开”的境界。同时，也要使园林建筑与自然地形紧密结合，浑然一体，仿佛天然生就，难寻人为痕迹。 4．就地取材，就近施工
商业空间设计的6大原则
商业空间设计最终的目的有且只有一个 那就是让消费者迈入店铺门槛，并引导他们消费更多 这也是众多零售商想尽办法想要达到的目的 他们通过播放音乐或采用诱人的气味充满整个售卖场所等等的方式 去赢得顾客的关注与消费。 而对于商业空间设计公司来说 从最初的店面的规划，到实施，再到最后的交付 其设计的诀窍是了解消费者，设计出符合消费者喜好的室内环境 这才是商业空间设计真正的艺术所在。 下面的六种商业空间设计艺术将改变零售环境： 1.引人注目的视觉营销 商业空间设计中的橱窗所带来的视觉营销力是不容小觑的。引人注目的视觉营销可以吸引购物者的注意力，并鼓励他们走进商店消费。 橱窗是所有零售店的眼睛，透过这双眼睛，可以向顾客讲述商店的故事。这个故事的每一个细节，都有可能走进顾客的心里，牵动顾客将步代迈入商店内。通常来说，橱窗的展示核心在于店铺的核心商品。
2.减慢客户的购物过程 现代消费者非常忙碌，并且倾向于匆忙购物。商业空间设计的工作是减缓 这段购物过程并增加顾客在商店的停留时间。一种方法是在入口处放置一个醒 目的大型显示屏。 客户将很快知道他们是否喜欢他们所看到的内容，并将关键产品放在商店 前面可以帮助他们做出这个决定。通过一些动线的设计，零售商可以鼓励顾客 进一步进入商店的最深层。 3.动线引导顾客的购物路径 在进行商业空间设计时，零售商应该清楚的知道，他们规划的顾客动线， 应清楚地了解，哪些产品放在什么位置会有利于引导顾客走入商店的最深层， 接触更多深层的商，品，最终获得最多的消费。 一些零售商没有合理的动线设计，没有高效的将顾客带入他们想去的地方，只是单纯的引导顾客进入走道而没有考虑去设计出一条能增加停留时间、利于 销售的动线。 而商业空间设计中的动线设计原则，是设计出一条理想的客户购物路线. 4.引导顾客到商店右侧
软件设计模式目标原则
软件设计模式目标原则 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、面向对象设计模式：描述了面向对象设计过程中，特定场景下，类与相互通信的对象之间常见的组织关系。
设计集团管控模式的六条原则
设计集团管控模式的六条原则 某市政工程有限公司成立于1993年，并于2001年在原公司基础上组建成立了X建设集团，经过短短十多年的发展，已经形成了一个以工程建设为核心，以地产开发为补充，以对外投资为支撑的集团公司，经营范围涵盖市政道桥、建筑安装、地产开发、材料生产、汽车销售、传媒教育、商贸物流、园区开发等多个领域。然而面对业务规模扩张、业务领域不断多元化、以及业务跨地域发展所带来的挑战，集团管理出现了多种“并发症”：集团总部定位不明确，对下属公司的管理仍然沿用原来的部门和分公司管理模式，管理效率低下；下属分子公司达到30多家，由于缺少具体分析，使用“一刀切”的管控模式，有的不该管的管得过死，有的该管的却又放得过宽；集团层面的管理输出能力不足，想发挥集团协同效应却缺乏足够的资源；缺乏管控的手段和科学的评估和监控手段……。 集团化是企业成长发展到一定阶段之后的必然选择，然而在长大的过程也免不了伴随着这些成长的烦恼。因此集团管控也就成了企业集团化绕不开的话题。 一、什么是集团管控模式 所谓企业集团的管控模式，是指集团对下属企业基于集分权程度不同而形成的管控策略，其具体体现在通过管控部门的设置、管控流程设计以及集团文化的传播来影响下属经营单位的战略、营销、财务、经营运作等方面的内容。集团管控模式的选择，说到底就是对集团集权与分权的度的把握，通过集权与分权的有机结合，实现整个集团各层级权、责、利的平衡。 二、集团管控的三种基本模式 企业集团对下属企业的管控模式，按照总部的集、分权程度不同可以划分为“操作管控型”、“战略管控型”和“财务管控型”三种基本管控模式。
操作管控型操作管控型的管控模式是高度集权的管控模式，强调过程控制是这种管控模式的鲜明特点。集团总部从战略规划制定到实施几乎什么都管，集团总部的各种职能管理非常深入，如人事管理不仅负责全集团的人事制度政策的制定，而且负责管理各下属公司二级管理团队及业务骨干人员的选拔、任聘。在实行这种管理模式的集团中各下属企业业务相关性高。为了保证总部能够正确决策并能应付解决各种问题，总部职能部门的人员会很多，规模会很庞大。在全球工业化开始的初期阶段，许多老牌全球性集团公司选择此种集团管控模式，以力保其全球随需而变的战略实施。操作管控型主要适用于以下情况：产权关系紧密度高，总部为投资中心和利润中心，而下属企业只是成本中心。 战略管控型战略管控型的管控模式是集权与分权相结合的一种管控模式，强调程序控制是这种管控模式的突出特点。集团总部负责整体的战略规划，下属企业同时也制定本业务单元的战略规划。在实行这种管控模式的集团中，集团总部的规模并不大，各下属企业业务的相关性也较高。运用这种管理模式的典型公司有英国石油、壳牌石油、飞利浦等。目前世界上大多数集团公司都采用或正在转向这种管控模式。战略管控型主要适用于以下情况：各下属企业业务相关性较高，产权关系紧密度较高，下属企业的业务运作比较成熟，对集团总部影响较大等。 财务管控型财务管控型的管控模式是最为分权的管控模式，强调结果控制是这种管控模式的突出特点。在实行这种管控模式的集团中，各下属企业业务的相关性可以很小。集团总部只负责集团的财务管理、资产运营、投资决策和实施监控等，以及对外部企业的收购、兼并工作。下属企业负责完成集团规定的财务目标。许多以收购、兼并为主要目标，且行业涉猎复杂的集团公司采用此类模式。GE公司也是采用这种管理模式，这种模式可以形象地表述为“有头脑，没有手脚。”财务管