设计模式之总结与回顾
设计模式之总结与回顾(1)
2013-05-27 12:59 李胜攀博客园我要评论(0)字号：T | T
就Java语言体系来说，GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。GoF表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE，.Net等技术也无关！
AD：2013大数据全球技术峰会课程PPT下载
从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）需要创建的对象有复杂的内部结构；2）对象的属性之间相互依赖，创建时前后顺序需要指定。
?原型
意图：用原型实例指定创建对象的种类，并通过复制原型实例得到对象。
适用场合：1）系统不关心对象创建的细节；2）要实例化的对象的类型是动态加载的；
3）类在运行过程中的状态是有限的。
?适配器
意图：将一个类的接口转换成用户希望的另一个接口。
适用场合：系统需要使用现有类的功能，但接口不匹配
?装饰
意图：动态的为对象添加额外职责
适用场合：1）需要添加对象职责；2）这些职责可以动态添加或者取消；3）添加的职责很多，从而不能用继承实现。
?桥接器
意图：将抽象部分与实现部分分离，从而使得它们可以独立变化
适用场合：1）系统需要在组件的抽象化角色与具体化角色之间增加更多的灵活；2）角色的任何变化都不应该影响客户端；3）组件有多个抽象化角色和具体化角色
?享元
意图：运用共享技术支持大量细粒度的对象
适用场合：1）系统中有大量对象；2）这些对象占据大量内存；3）对象中的状态可以很好的区分为外部和内部；4）可以按照内部状态将对象分为不同的组；5）对系统来讲，同一个组内的对象是不可分辨的
?门面
意图：为系统的一组接口提供一个一致的界面
适用场合：1）为一个复杂的接口提供一个简单界面；2）保持不同子系统的独立性；3）在分层设计中，定义每一层的入口
?合成
意图：将对象组装成树状结构以表示“部分-整体”的关系
适用场合：1）系统中的对象之间是“部分-整体”的关系；2）用户不关心“部分”与“整体”之间的区别
?代理
意图：为其他对象提供一种代理以控制对该对象的访问
适用场合：对象无法直接访问（远程代理）
?职责链
意图：对目标对象实施一系列的操作，并且不希望调用双方和操作之间有耦合关系
适用场合：1）输入对象需要经过一系列处理；2）这些处理需要在运行时指定；3）需要向多个操作发送处理请求；4）这些处理的顺序是可变的
?命令
意图：对一类对象公共操作的抽象
适用场合：1）调用者同时和多个执行对象交互；2）需要控制调用本身的生命周期；3）调用可以取消
?观察者
意图：定义对象之间一种“一对多”的关系，当一个对象发生改变时，所有和它有依赖关系的对象都会得到通知
适用场合：1）抽象模型有两部分，其中一部分依赖于另一部分；2）一个对象的改变会导致其他很多对象发生改变；3）对象之间是松耦合
?访问者
意图：对一组不同类型的元素进行处理
适用场合：1）一个类型需要依赖于多个不同接口的类型；2）需要经常为一个结构相对稳定的对象添加新操作；3）需要用一个独立的类型来组织一批不相干的操作，使用它的类型可以根据应用需要进行定制
?模板
意图：定义一个操作步骤的方法骨架，而将其中一些细节的实现放到子类中
适用场合：1）可以抽取方法骨架；2）控制子类的行为，只需要实现特定细节
?策略
意图：对算法族进行封装
适用场合：1）完成某项业务有多个算法；2）算法可提取公共接口
?解释器
意图：应用或对象与用户狡猾时，采取最具实效性的方式完成
适用场合：1）针对对象的操作有规律可循；2）在执行过程中，对效率要求不高，但对灵活性要求很高
?迭代
意图：提供一种方法，来顺序访问集合中的所有元素
适用场合：1）访问一个聚合对象的内容，而不必暴露其内部实现；2）支持对聚合对象的多种遍历方式；3）为遍历不同的聚合对象提供一致的接口
?中介者
意图：避免大量对象之间的紧耦合
适用场合：1）有大量对象彼此依赖（M：N）；2）某个类型要依赖于很多其他类型?备忘录
意图：希望备份或者恢复复杂对象的部分属性
适用场合：1）对象的属性比较多，但需要备份恢复的属性比较少；2）对象的状态是支持恢复的
?状态
意图：管理对象的多个状态
适用场合：1）对象的行为依赖于当前状态；2）业务处理过程存在多个分支，而且分支会越来越多
上面是对GoF23中模式的快速回顾，其中的理解未必很深刻很到位。对设计模式的学习是没有止境的，而且它也只是面向对象分析与设计的冰山一偶
设计模式之总结与回顾(2)
2013-05-27 12:59 李胜攀博客园我要评论(0)字号：T | T
就Java语言体系来说，GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。GoF表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE，.Net等技术也无关！
AD：2013大数据全球技术峰会课程PPT下载
设计模式之创建型模式
GoF的设计模式一共23个，可以分为3大类：创建型、结构型和行为型，这篇文章主要讨论创建型。
创建型的设计模式包括：简单工厂（Simple Factory）、工厂方法（Factory Method）、抽象工厂（Abstract Factory）、单例（Singleton）、构造者（Builder）和原型（Prototype），我们分别来讨论。
我们首先来看工厂系列的3个设计模式，它们都主要是针对软件设计中的“开放-封闭”原则，即程序应该对扩展开放，对修改封闭。特别是当我们的程序采用XML+反射的方式来创建对象时，工厂模式的威力就完全展现出来了，这时我们可以通过维护配置文件的方式，来控制程序的逻辑。
1）简单工厂，当我们的程序在实例化对象时，如果输入条件不一样，产生的对象也不一样，那么我们可以考虑使用简单工厂对不同的实例进行统一封装， UML结构如下：
优点：封装了具体对象的实例化过程，Client端和具体对象解耦，同时ProductManager可以作成静态类或者Singleton对象，然后可以使用HashMap缓存具体对象（前提是对象没有时间依赖性），降低创建对象的次数。
缺点：当增添一种新类型的对象时，需要修改Productmanager的代码（如果不采用XML）
2）工厂方法，它是针对简单工厂的改进版，添加了对ProductManager的抽象，UML结构如下：
优点：结构更加灵活，对于某种类型的对象来说，会有一个特定的对象工厂指向它，这样当我们需要添加一种新类型的产品时，只需要添加两个类，一个是具体产品类，一个是新产品的工厂类。这样更加灵活。
缺点：结构开始变得复杂，而且最终还是需要Client端来确定究竟使用哪一个Factory（当然这个信息可以保存在上下文或者配置文件中）。
3）抽象工厂，这个是最复杂的工厂模式，它用来生成一个产品线上的所有产品，我们假设一个产品线上包括多个产品，不同的产品线上的产品个数是一样的，这样我们需要一个针对产品线的抽象，并且很显然不同产品线上的产品是不可能混到一起的。对应的UML结构图如下：
上图表明，一个产品线上的产品由IProduct1和IProduct2组成，客户端在获取产品时，这两个产品应该是同时返回的，因此对于IProductManager来说，它需要同时生成这两个对象。
优点：对创建产品家族的行为高度抽象，添加一个产品线的逻辑比较清晰。
缺点：当我们对产品线上的产品进行增加和删除时，对应的操作比较麻烦，所有的产品工厂都需要进行修改。
4）单例，这是比较好理解的一个模式，从字面上说，就是程序在运行的过程中，希望在任意时刻，都只保留某个对象的唯一实例。对应的UML结构图如下：
单例的实现方式一般包括几步：1）私有的指向自身的字段；2）私有构造函数；3）公开对私有字段进行实例化的方法。也有几种针对具体语言进行的改善，例如针对多线程采用double lock 机制，采用常量方式定义私有字段、使用内嵌类来实例化字段等。
我们也可以对单例进行一些适当的扩展，例如我们将对象的个数由1个变为N个，这就成了对象池。
通常工厂模式中会使用到单例模式，特别是对于简单工厂来说。
5）构造者，对于一些复杂对象来说，它可以分成多个不同的部分，在实例化时，不同部分之间实例化的顺序，有时会有严格的限制，这时我们就可以使用构造者模式了。对应的UML结构图如下：
我们定义了IBuilder接口来实例化对应的不同部分，同时有一个方法来返回对象的实例。而Constructor类的Construct方法会按照业务逻辑依次调用实例化部分对象的方法，即BuildPartA、BuildPartB，这里的调用顺序，完全由业务逻辑来控制，最后可以调用 GetProduct 方法取得完整的对象实例。
我们有时也会对上图进行修改，例如将GetProduct放到Constructor中，或者将Construct方法放入到GetProduct（取消Constructor）中。即使有这些变形，但是基本的思想是不变的。
6）原型，我们在程序运行过程中，当需要有新的实例对象时，有时并不希望是从头创建一个对象，而是希望新的实例的状态和某个已存在的实例保持一致，这就是原型模式发挥作用的地方。对应的UML结构图如下：
在.NET中，已经定义了IClonable接口来实现原型模式。需要注意在实现时，会有深拷贝和浅拷贝的区别，深拷贝会同时拷贝堆栈和堆上的内容，而浅拷贝只会拷贝堆栈上的内容。
设计模式之总结与回顾(3)
2013-05-27 12:59 李胜攀博客园我要评论(0)字号：T | T
就Java语言体系来说，GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。GoF表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE，.Net等技术也无关！
AD：2013大数据全球技术峰会课程PPT下载
设计模式之结构型模式
在这部分里，我们关注GoF里面的结构型模式，它主要是用于描述如何将类组合在一起去构成更大的结构。结构型模式包括适配器（Adapter）、装饰（Decorator）、桥接器（Bridge）、享元（FlyWeight）、门面（Facade）、合成（Composite）以及代理（Proxy）模式。
下面我们对上面提到的模式分别进行描述。
1）适配器（Adapter）。当我们已经开发出一个模块，有一套清晰的接口，并且模块正在被某个功能使用（意味着模块接口改变的可能性不高），这是如果有另外一个功能也需要使用这个模块的功能，但是对应的是一套完全不同的接口，这时适配器就可以发挥作用了。
适配器模式分为两种，一种是对象适配器，一种是类适配器，对象适配器的UML图如下：
这里Adaptee1和Adaptee2指两套不同的子系统，它们作为Adapter的属性存在，可以使用IoC的方式指定。
类适配器的UML图如下：
同样是两个不同的子系统，但是这里我们创建了2个Adapter类来分别指向两个子系统。在这里我们可以在Client和ITarget之间，设置一个Adapter 工厂，来根据业务需求创建不同的Adpater实例。
2）装饰（Decorator），假如我们已经开发了一套功能，然后根据需求，需要增加一些子功能，而且这些子功能是比较分散比较时可以增删的，这时如果直接修改接口，那么会造成接口功能复杂并且不稳定，针对这种情况，我们可以使用装饰模式。对应的UML图如下：
上图中，ConcreteComponent已经实现了Component的基本功能，对于一些附加的功能，如果放在ConcreteComponent中不合适的话，我们可以像ConcreteDecoratorA一样，创建一个基于Decorator的类，通过SetComponent方法将核心功能和辅助功能串在一起。
有时，为了简单，我们也可以把ConcreteDecorator直接挂在Concretecomponent下面。
3）桥接器（Bridge），面向对象提倡的几个最佳实践包括：1）封装变化；2）面向接口编程；3）组合优于继承；4）类的职责尽量单一。桥接器完美的体现了这些，通过创建型模式，我们可以很好地达到面向接口编程的目标，也就是说我们在程序中各变量的声明类型是接口类型或者抽象类，而具体的实现类型则由不同的设计模式使用不同方式指定。这在接口或者抽象类基本稳定的情况下，是很好地，但当接口需要发生变化时，我们如何去处理？可以看看桥接器的UML图：
通过这个图，我们可以看出，Implementor接口的变化，对于Client来说，基本是没有影响的。Abstraction会持有Implementor的一个实例。
4）享元（FlyWeight），当我们系统中需要使用大量的小对象，但我们又不希望将所有的小对象都创建出来时，可以考虑使用享元模式，它会抽取小对象中的公共部分，将其封装为基类，然后针对不同条件创建小对象，同时在对象池中维护这些小对象，客户在需要使用小对象时，首先在对象池中
查找，如果存在，直接返回。对于小对象中“个性”的部分，由调用小对象的客户端进行维护。对应的UML图如下：
除了上述的简单享元，还存在一种复合享元，对应的UML图如下：
图中，CompositeConcreteComponent是不共享的，但是它里面包含很多简单的享元，这些享元是共享的，我们可以把它想象成一个特殊的“享元工厂”。
通常提到享元，最常见的例子就是文本编辑器中的26个字母，在.NET中，字符串常量也使用了享元模式。
在享元模式中，我们通常会将FlyWeightFactory设计为单例模式，否则享元就没有意义了。
5）门面（Facade），如果我们的程序需要深入调用某个模块的内部，但我们又不想和模块过紧耦合，这时可以考虑使用门面模式，来对外部封装内部子系统的实现。简单的门面可能和代理在某种程度上很相似。
门面模式没有固定的UML图，它是根据客户端的实际需求以及子系统内部的接口来确定的。
6）合成（Composite），当我们的对象结构中存在“父子”关系时，可以考虑使用合成模式。它分为两种，一种是安全型的合成模式，UML图如下：
这种类型的合成模式，对于Component的增、删、改，都在Composite 中维护，Leaf根本不知道这些操作。另一种是透明型的合成模式，UML图如下：
这种类型的合成模式，自上而下所有的Component都会有增、删、改的操作，只不过对于Leaf来说，这些操作时没有意义的。
7）代理（Proxy），在编写程序时，有时我们希望使用某个对象或者模块的功能，但是因为种种原因，我们不能直接访问，这时就可以考虑使用代理，对应的UML图如下：
需要注意的是，在这里RealSubject只有一个，如果有多个，那么就是Adapter了。另外，代理也可以加入自己的一些逻辑处理，例如PreExecute 和PostExecute。如果这里有多个Proxy，那么就是Decorator了。
上面就是对结构型设计模式的快速浏览，其中有很多UML图看上去很相似，但深入去思考，每个模式的出发点、所要解决的问题是不一样的。
设计模式之总结与回顾(4)
2013-05-27 12:59 李胜攀博客园我要评论(0)字号：T | T
就Java语言体系来说，GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。GoF表面上好像也是一种具体的"技术"，而且新的设计模式不断在出现，设计模式自有其自己的发展轨道，而这些好像和J2EE，.Net等技术也无关！
AD：2013大数据全球技术峰会课程PPT下载
设计模式之行为型模式
在这部分里，我们关注GoF设计模式中的行为型模式，它是用来在不同对象之间划分职责和算法的抽象，行为模式不仅涉及到类和对象，还涉及到类与对象之间如何进行关联。
行为型模式包括：职责链（Chain of Responsibility）、命令（Command）、解释器（Interperter）、迭代（Iterator）、中介者（Mediator）、备忘录（Memento）、观察者（Observer）、状态（State）、策略（Strategy）、模板（Template）和访问者（Visitor）。我们主要讨论其中的一部分模式，后续会有其他补充。
1）职责链（Chain of Responsibility），如果完成一项业务，需要很多步相关操作，但是如果将这些操作完全封装到一个类或者方法里面，又违背了单一职责的原则。这时我们可以考虑使用职责链模式，对应的UML图如下：
我们可以创建很多个Handler的实现类，并通过设置Successor来将这些Handler“串”在一起。那么如何触发所有的Handler呢？这里和Decorator 有点儿类似，我们可以通过调用 Successor.HandlerRequest来实现。这样用户只需要关心最开始的Handler，而不必关心后面都还有哪些其他的Handler。
2）命令（Command），命令模式将发出命令和执行命令很好的区分开来，当我们执行某项业务时，客户端只需要构造一个请求，而不必关心业务实现的具体细节，即构造请求和业务实现是独立的。对应的UML图如下：
从图中，我们可以看到，当Client端需要执行某项业务时，它需要构造一个Invoker对象，它负责发出请求，会生成一个Command对象。同时我们看到有一个Receiver对象，它是用来实现具体业务的，我们在ConcreteCommand 中，会引用这个对象，来完成具体业务。
3）观察者（Observer），当我们的系统中，存在一个业务A，有其他多个业务都需要关注业务A，当它的状态发生变化时，其他业务都需要做出相应操作，这时我们可以使用观察者模式。观察者模式也称作订阅模式，它会定义一个“主题”（业务A），一个抽象的“订阅者”以及很多具体的“订阅者”（其他业务），在“主题”中，会保留所有“订阅者”的引用，同时可以对“订阅者”进行添加或者删除，当“主题”的状态发生变化时，它会主动“通知”所有“订阅者”，从而“订阅者”可以做出相应的操作。对应的UML图如下：
我们可以看到ConcreteSubject中保留了多个Subscriber的引用（Subscribers），在NotifySubscriber方法中，它会依次调用每个Subscriber的Update方法，从而更新“订阅者”的状态。
4）访问者（Visitor），当我们有一个对象集合，集合中的元素类型是不一样的，但类型是相对固定的，例如只有3种不同的类型，但是可能有30个元素。如果我们希望对集合中的所有元素进行某种操作，从接口的角度来看，
由于类型不一致，我们很难通过一个统一的接口来遍历集合元素并对其进行操作。这时我们可以考虑使用访问者模式，它将获取某个元素和对元素进行操作进行了分离。对应的UML图如下：
这里我们假设集合中只包括了2中不同的类型，ObjectBuilder就是上面提到的集合，它包含多个不同的IElement元素，业务的核心实现是在VisitorA 和VisitorB中，对于Element1的Accept 方法来说，它只是调用
visitor.VisitElement1方法。
5）模板（Template），继承是面向对象的一大核心，而模板方法就是对继承的完美体现。对于某项业务来说，我们可以根据通用的流程，设计其方法骨架，针对不清晰或者不明确的地方，以抽象方法的方式来处理，然后根据不同的子业务，创建不同的子类，在子类中，实现那些抽象方法。对应的UML 图如下：
可以看出，对于子类来说，它是不需要重写Operate方法的，而只需要实现父类的抽象方法。对于客户端来说，当它实例化某个子类后，可以直接调用Operate方法来完成某项业务。
6）策略（Strategy），当我们的系统中，针对某项业务有多个算法时，如何对这些算法进行管理，我们可以考虑使用策略模式，它主要是针对一组可以提取相同接口的算法进行管理。对应的UML图如下：
这里需要注意的是，Strategy类并不知道应该使用哪个具体的子类，这应该由Client指定。
7）解释器（Interperter），如果我们的系统中有些特定的问题反复出现，我们想要对这些问题进行抽象，那应该如何做？试想一下，当我们写完代码后，是如何进行编译的？无论对C#还是 Java，它们的编译器都会读取我们所写的每一行代码，并作出相应的解释。我们可以部分认为，编译器中存储了任何组合的语句，类似于C中的 typedef。解释器做的就是类似的事情，它将具有通用性的问题进行抽取，对其解决方案进行综合处理。对应的UML 图如下：
一般的执行过程是这样的，Client读取Context中的信息，根据某种原则将其划分成多个部分，针对每一部分，构造相应的解释器，并将Context信息传入解释器中进行处理。这里的问题是Client必须要清楚 Context细节和具体解释器中间的关联。我们可以在Client和Interpreter之间构造一个“解释器工厂”，用来根据Context生成相应的解释器实例，同样，如果解释器的执行过程和数据无关，我们可以为“解释器工厂”上追加“单例”模式，构造一个解释器池。这些都是可以根据需求做的进一步的优化。
8）迭代（Iterator），前文提到的访问者（Visitor）模式，针对的是存储在一起的不同类型的对象集合，如何进行遍历处理，那么针对存储在一起的
相同类型的对象集合，我们应该如何进行遍历呢？迭代模式可以帮我们做到，对应的UML图如下：
在C#和Java中，我们都已经在语言层级上实现了迭代，例如C#中的foreach，同时.NET来设计了两个接口来实现迭代：IEnumerator和IEnumerable。
9）中介者（Mediator），如果我们的系统中有多个对象，彼此之间都有联系，那这是一个对象之间耦合很高的系统，我们应该如何优化呢？我们可以建立一个知道所有对象的“对象”，在它内部维护其他对象之间的关联，这就是中介者模式，对应的UML图如下：
这里，Mediator是知道所有IPerson的“底细”的，Client 可以直接与Mediator联系，而不必关心具体的是PersonA还是PersonB，同样，对于PersonA和PersonB来说，它们之间也没有直接联系，当两者需要通信时，之金额使用Mediator的Send方法。
这个模式不好的地方在于：1）所有的IPerson类型都要有 Mediator引用，这样才能和其他的Person通信；2）Mediator需要维护所有Person的实例，这样它才能做出正确的判断，将消息发给对应的Person，但当Person子类过多时，Mediator就变的较难维护，这时，我们可以创建一套关于产生Person 实例的“工厂”，会减轻 Mediator的负担。
10）备忘录（Memento），当我们的系统中存在这样一种对象，它的属性很多，在某些情况下，它的一部分属性是需要进行备份和恢复的，那应该如何做？谈到备份和恢复，我们立刻想到可以使用原型模式，但那是针对所有属性的，备忘录模式可以很好地解决这里的问题，对应的UML图如下：
在这里，我们希望Originator的State2、State3是可以备份和恢复的，其他属性是无关的。我们可以在希望备份Originator的地方，调用Creatememento方法，在希望恢复Originator部分属性的地方，调用RestoreMemento方法，同时MementoManager对Memento进行管理。
11）状态（State），当我们的系统中的对象，需要根据传入的不同参数，进行不同的处理，而且传入参数的种类特别多，这时在方法内部会产生大量的if语句，来确定方法的执行分支。那么如何消除这些if语句呢？状态模式可以帮我们做到，对应的UML图如下：
这里，Client只与Context关联，在Context内部，会维护不同状态之间的跳转，简单来说，就是在HandleRequest内部判断传入的state值，如果符合业务逻辑，那么直接调用state的 HandleRequest方法；如果不符合，那么修改state值，然后调用相应state的HandleRequest方法。
原文链接：https://www.wendangku.net/doc/7d10332131.html,/wing011203/archive/2013/05/02/3055299.html
【编辑推荐】
1.Java设计模式之：创建者模式
2.Java设计模式之：适配器模式
3.关于Java 23种设计模式的有趣见解
4.王垠：解密“设计模式”
大型活动总结与反思
大型活动总结与反思 大型活动总结与反思一总结—“我与它共享爱”文艺晚会 20xx年5月27日晚，成功举办了“我与他共享爱”关注校园流浪动物文艺晚会。这次晚会的想法来源于慰灵碑。借助我们的专业知识，致力于志愿服务公益性的活动，生命平等，关爱生命，善待生命，丰富校园文化，创建绿色家园，实现人与动物和谐共处。提高大学生道德和社会责任。表达崇尚生命的理念，表达对生命的尊重与珍爱。促使大家养成爱护动物，关注动物福利的科研素养。也呼吁从事实验动物学习和工作的单位和个人，能够要怀有感恩的心情，尊重和善待实验动物。以晚会的形式让更多人知道动物对人类的贡献，呼吁大家学会感恩，尊重生命，提升社会道德。影响和带动更多的人关注流浪动物，加入我们的队伍。 一前期准备：活动前20天就开始准备。人人网等赞助的争取，演出人员的邀请及筛选工作。主持人的培训，要出道具的准备等等。但是有一项工作没有完成的很好。即演出服装的准备工作。因为摄影楼老板出差。迟迟不能借到，以至于直到活动当天的上午才借到！所以大家以后办活动一定要注意这个问题。尤其是借外面的东西。不要再发生我们类似的问题。 二活动现场：活动总体流程能够平稳地进行下来。但
中间出现了一些问题值得大家借鉴： 1.由于是我们协会第一次办晚会。所以当天活动的人员安排不够明确。有的人有好几项任务。但是有的人没有分配到多少任务。就导致了有的人忙的晕头转向，而有的人却很清闲！ 2.通知没到位。演员在彩排时没有按时到达现场进行彩排。导致一开始的彩排工作停滞。不过后来干事及时通知到位。算是弥补了这个错误。 3.现场的道具没有事先确定！比如话筒，话筒架，电吉他等一些要出的道具没有事先到科技报告厅确认。最后发现科技报告厅的师傅也没有带过来。并却话筒架还有几个坏的。只好临时再去借！浪费了不少时间！下次的活动我们一定会注意这些问题！ 三活动后期：及时将借来的物品归还，带着干事总结活动的优缺点。 通过这次活动，对于我们协会成员来说。又学到了不少东西。比如举办晚会的经验。演出人员的邀请，节目的准备和审查。现场演出的工作。这是我们之前没有的。这将为我们下一次办类似的活动提供了丰富的经验。对于观众。呼吁大家正确对待小动物，传播“生命平等、珍爱生命、尊重生命”这一理念顺应了人们爱护动物的心理，同时为人们抒发动物情结提供了平台。符合珍爱生命，尊重生命的人文精
软件设计师23种设计模式总结
创建型结构型行为型 类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
程序员个人工作计划
2015程序员个人工作学习计划 程序员个人工作学习计划 新的一年，一切事物充满了活力与生机。新生活意味着新开始，新开始意味着新的挑战。作为即将毕业跨入社会的大学生，我将在这学校生活和社会生活相交织的一年，努力适应变化，迎接新的挑战。 一、工作方面 作为公司的新员工，首先要与同事们相互熟悉，不说认识所有人，至少要认识大部分同事，与大家和睦相处，互相帮助。 分配的工作任务要积极及时的完成，作为新员工，分配到的任务肯定是非重点，繁琐的基础性的事，但是即使是这样，也不能松懈，敷衍了事，基础中才能学到真本事，对待这样的任务更要认真仔细。做好了这样的事，才有可能获得信任和肯定，被任命重要的任务，才能成长起来。 二、学习方面 最为初出校园的新人，必然有很多在实际开发中常用而我却从没有接触过的东西，学校教授的只是基础，进了公司，仍然不能停下学习的步伐。 首先最重要的一点就是在学习过程中有了问题就得及时解决。我的步骤一般是先自己思考问题的答案，自己无法解决则到网络上寻求答案，网上也无法找到可靠的答案则询问周围的同事帮忙解决。认真听他们的讲解，牢牢记住分析问题的思路和方法，以便下次遇到时能尽量自己就能解决问题。 14年需要学习的东西有很多，作为从事web应用开发的的程序员，首先mvc规范必然是要熟练掌握的，这是学校中只是简单提到的东西。首先通过李刚的《轻量级javaee企业应用实战》，对ssh这样的一个mvc思想的架构有一个初步宽泛的了解，()然后在分别对struts，spring，hibernate进行深入了解。根据网上资料，国内较好的struts方面的书是孙卫琴的《精通struts：基于mvc的javaweb设计与开发》，在大体学习了ssh后，就从这本书开始细致的学习这方面的知识，然后是林信良的《spring技术手册》和《prospring中文版》，最后是夏昕的《深入浅出hibernate》。 其次，设计模式的学习也是成为一个好的程序员，甚至是编程艺术家的必经之路。首先看完程杰的《大话设计模式》，对设计模式有一个初步的认识，然后再看gof的《设计模式：可复用面向对象软件的基础》， ericfreeman&elisabethfreemanwithkathysierra&bertbates的《headfirstdesignpatterns》，joshuakerievsky的《重构与模式》等等书籍。要成为一个好的java程序员，还有很长的路要走，只是看些肯定是不够的，最重要的还是实践经验，希望2015年能让向前迈出一大步。篇二：程序员的2015年9个计划 程序员的2015年9个计划 制定新年计划是我们最喜欢做的事情之一，我们总是会在年底的时候对新的一年有一个很好的计划，但后来就把它们都抛到脑后了，直到最后全部忘记。也许，我们的计划总是过于宏伟，很多事情都是做不到的，甚至显得遥不可及。但是，今年一定会有所不同，这篇文章就是专为程序员准备的九大新年计划，供各位程序员参考。 1. 学习一门新的不同风格的编程语言 这是很需要的一件事，因为如果你只了解一种语言，它就会局限你解决问题的能力和你的职业发展。所以在新的一年，你应该花些时间学习一门新的语言，体验不同的编程风格，并学以致用。 2. 提高你的已有技能 3. 活动你的手指，但不是在键盘上
上半年工作总结与反思
上半年工作总结与反思 上半年工作总结与反思 上半年以来，派出所在分局党委、xx乡党委、政府的正确领导下，结合科学发展观，以春季严打攻势、三大战役以及大走访开门评警活动为上半年工作要点，摸索出一条适合本地实际的治安防控体系以及在热情服务群众上走出一条和谐警民关系和维护一方治安稳定放在突出位置，确保了辖区安全、稳定，现将xx 派出所今年上半年的工作情况作总结如下： 一、以科技手段推动工作、以信息应用提高效能的工作思路，积极推进大走访开门评警全面协调的开展，开创公安群众工作满意工程 (一)、评进千家万户，让开门评警火起来，实现评议范围与密度的双扩大 自从年初大走访开门评警工作开展以来，xx派出所以大造声势、人人皆知、全民参与为目标，积极回应人民群众新期待，满足人民群众新要求，不断丰富走评形式，创新工作方法，限度听取评议，了解民意，高密度、多角度、全方位的宣传大走访开门评警活动，迅速掀起了大走访开门评警的新热潮。 1、创新评议模式。工作中，派出所在采取走访座谈、电话随访、上门走访等传统形式征求意见建议的基础上，大胆探索创新联系群众的新载体和新渠道，搭建了一个集qq警务室、新浪和腾讯微博、博客于一体的网络平台，吸引了社会各界群体的广泛参与和积极评议，探索出了一条网络1+n式评警模式(即：1个网络平台联系n个群众)，拉近了警民距离、促进了社会和谐，有效提升了开门评警活动实效，受到辖区群众的一致好评，先后征求群众意见建议25条。截止目前，派出所新浪微薄粉丝已达17936人，新浪博客访问量6230人次，民警小缪的会客厅腾讯微博听众达6966人，位居全市基层所队前列。 2、活化宣传形式。工作中，派出所自筹资金，安装了led警务公开显示屏并通过调试正式对外宣传，成为我区第一家拥有同步led电子宣传屏的农村基层派出所。该led屏24小时滚动公开开门评警宣传标语，不间断播放治安防控宣传语、警务、便民措施、办事指南、警情通报、窗口户籍*领证情况。同时，派出所网上警务室、微博、博客地址也公布在屏幕上，不仅增强了警务工作的透明度，而且方便了办事群众，拉近了警民关系，受到了辖区群众的高度评价和普遍欢迎。
活动反思、总结
**********“活动反思” 一：策划环节 太过依赖于模板，没有完全重新写一个策划，以致对策划内容不能了熟于心。没有完全掌握策划应有的内容、环节；策划太过形式主义，对于策划中的一些安排没有深思熟虑，没有准备应急方案，策划实际操作性不强，使得活动没有能够按照策划正常进行；制作时间略仓促，没有认真审核，也没有认真请教分管主席和老部长的意见，不明白的地方没有及时提出；活动环节内容毁容衔接安排欠妥，没有严格把关，进行排练。 二：活动安排 （一）：活动物品问题 1.海报：海报准备时间短；海报内容选定太过仓促不够认真；海报制作太过粗略，没有贴保鲜膜，使其在活动开始前就有所损坏。 2.ppt：ppt制作仓促没有新意，制作不够精细，花费时间少，出题也没有认真审核直接复制粘贴，使得题目出现纰漏，甚至ppt中的题目都未能认真看完一遍，导致活动中出现了重复题目和答案有异议的问题；没有做备用、应急题目的ppt。 3.教室布置：（1）装饰物品没有及时备齐，活动当天下午才去现买的，浪费了不少时间，以后注意提前至少一天备好。（2）布置方案不够详尽，不完善。后半段教室布置只是简单仓促的随意装饰，没有取得太好的效果，也未能及时通知分管主席来督促、建议（3）人员安排不到位，没有做出详尽的计划；通知布置教室时间略晚，一些委员也未能按时到场，不能掌握一些委员的动向。这些都使得教室布置浪费了很多时间。 4.奖状：未能提前备好奖状以至于比赛结束后奖状不能及时下发，使得颁奖环节未能正常进行。以后类似活动提前备好奖状并盖章。 （二）：活动的宣传通知问题 1.部门内部通知：部长未能将活动内容和细节对委员进行详细讲解，委员对于不明白的地方也未能及时提问反馈，交流有脱节，使得委员对活动环节和一些
Java设计模式学习心得
Java设计模式之心得 UML 1.案例图:系统角色和使用案例和它们之间的关系 2.类图: 类图中的关系 1.一般化关系：继承,接口 2.关联关系：类与类之间的联系Driver中的Car 3.聚合关系：整体与个体之间的关系 4.合成关系：强关联，整体包含部分，整体代表部分的生命周期，不能共享 5.依赖关系：类与类之间的连接，如Person包含Car和House 3.时序图： 每个步骤的流程图 4.状态图：一系列对象的内部状态及状态变化和转移 5.合作图：相互关系图 6.构建图：部署的软件构件之间的关系 7.活动图： 8.部署图： 面向对象的设计原则： 1.设计目标：可扩展性、可维护性、可插入性、可复用性 2.设计原则：开闭原则、里氏替换原则、依赖倒转原则、接口隔离原则、组合\聚合复用原则、迪米特法则 开闭原则：
OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。 一句话：“Closed for Modification;Open for Extension”——“对变更关闭；对扩展开放”。开闭原则其实没什么好讲的，我将其归结为一个高层次的设计总则。OCP的动机很简单：软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。 重要的步骤： 1.抽象化 2.对可变性的封装原则 里氏替换原则： 1.分析对象时必须明确是Is-a还是Has-a的关系,任何基类适应的地方，子类一定适用依赖倒转原则： 要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。 接口隔离原则： 使用多个专门的接口比使用单一的总接口要好。广义的接口：一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此一个接口应当简单的代表一个角色，而不是一个角色。，如果系统设计多个角色的话，则应当每一个角色都由一个特定的接口代表。狭义的接口（Interface）:接口隔离原则讲的就是同一个角色提供宽、窄不同的接口，以对付不同的客户端。 组合\聚合复用原则： 要尽量使用组合/聚合，而不是使用继承来达到目的 原因： 继承复用的缺点：静态复用 什么使用使用继承：a.满足is-a的关系，而不是has-a的关系 b.满足lsp原则 优点：a.简洁 b.父类修改某个方法，子类能获得 迪米特法则： 一个对象或模块应该和其它对象和模块尽量少的通信（高内聚），涉及的模式有：门面模式，调停者模式，前端控制器模式，业务代表模式，dao模式
设计模式心得体会
设计模式心得体会 7月初的一个周末，准确的说应该是7月1号周六，在网上看到一本《大话设计模式》的书，而且看到很多很好的评论，于是乎，下载了电子书看看，一下子看了几章之后，对设计模式有了个了解，于是继续上网搜些其他资料，进一步了解设计模式。。。最终结论：设计模式是个好东西，具体怎么好，一两句话是无法概括的，也是从那天起，我就决定学习设计模式，于是就看《大话设计模式》，至七月十多号，大概看了一百多页后，感觉有点难，有点看不下去的感觉，于是上网找其他的好方法，无意间发现了李建忠老师的《c#设计模式纵横谈》系列讲座，微软的web cast课程，主要讲解gof的23个设计模式，每个一讲，加上一头一尾，共25讲，试听了一节课后，感觉很有用，于是就抽时间去边听课边看书，并在我的博客里写下笔记，依赖加深印象，二来可以督促我的进度。。。 三个月以来，总算把设计模式学完一遍了，原计划是两个月学完（一星期三个模式），由于。。。计划两个月学完实际花了三个月，感触多多，收获多多——对c#语言有了更进一步的认识，对oo的思想有了更全面的了解。。。 下一步在设计模式方面的计划：巩固并运用设计模式，巩固：把《大话设计模式》，《设计模式》，《设计模式——可
复用的面向对象基础》，《敏捷软件开发：原则、模式与实践》这些书再结合起来系统的看一看，当然还会去买一些我手头上没有的关于设计模式的书；运用：部门前几天也提倡用c#来改版vb程序，我想这是一个很好的平台，正好有机会把理论的东西在实际中应用，理论加实际——唯一的学习方法。。。 下面对各个模式再简单总结一下： 1、创建型模式： singleton：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了singleton之外，其他创建型模式解决的都是 new 所带来的耦合关系。 abstract factory：创建一系列相互依赖对象，并能在运行时改变系列。 factory method：创建单个对象，在abstract factory 有使用到。 prototype：通过拷贝原型来创建新的对象。 factory method，abstract factory, builder都需要一个额外的工厂类来负责实例化“一边对象”，而prototype 则是通过原型（一个特殊的工厂类）来克隆“易变对象”。 如果遇到“易变类”，起初的设计通常从factory method 开始，当遇到更多的复杂变化时，再考虑重构为其他三种工
幼儿园的活动总结与反思
幼儿园的活动总结与反思 导读：本文幼儿园的活动总结与反思，仅供参考，如果觉得很不错，欢迎点评和分享。 幼儿园活动总结与反思1 迎着6月明媚的阳光，我园全体师生怀着愉快的心情，迎来了又一个“六一”国际儿童节。 六月一日上午，幼儿园里人头涌涌，欢声笑语不断，孩子和他们的爸爸妈妈在这里度过了快乐的节日时光。现将我班六一活动总结如下： 一、亲子表演其乐融融 在表演亲子呼拉圈过程中孩子与家长之间充满了愉快的情绪。欢声笑语此起彼伏，充满了整个班级。 二、亲子做操展示风采 今年的六一活动都是围绕着“亲子互动”为主题编排的，家长和孩子们在室外做徒手操时没有一个家长因为害羞而畏缩，无论老少个个都是充满了激情，口号响亮，整个活动在愉快的气氛下结束了。 活动后每个孩子都得到了奖品，活动虽然结束了但孩子们留下的笑声还荡漾在空中，整个幼儿园似乎也变得更加明媚和朝气蓬勃了。 不足：在联系家长志愿者帮助录像时，琬琪的爸爸因为是买的新摄像机，而不太会使用所以把录像录成一段一段的，可是在结束后家长马上联系了专业的人员将这些视频剪接到一起还刻录成光盘。
幼儿园活动总结与反思2 今年我园的“六一”活动，是一系列丰富多彩的活动，活动的开展比较成功，幼儿也获得了对“六一”儿童节较深的印象。总结起来，此次活动有以下的特点和可取之处以及存在的不足： 一、活动特点和可取之处： 1、围绕幼儿语言发展、幼儿动手能力、合作与交往能力的培养来设计，有幼儿故事剧表演、小能人比赛、巧手儿比赛、巧嘴儿比赛、结对子游园。这些活动基本上体现了我园今年的培养目标。 2、全园幼儿都有较多展示自我、体验学习、合作与交往的机会，如：幼儿故事剧表演、小能人比赛、巧手儿比赛、结对子游园等活动，全体幼儿都有参与的机会。 3、能早出方案，提示大家将一些活动、能力的训练融合到一个学期中去进行，也有助于我园的培养目标的实现。 4、锻炼了班级老师之间的协作能力。 5、从幼儿参加小能人比赛来看，幼儿对物品的摆放和整理能力已得到了一定的培养，各班幼儿基本上能按物品原来的摆放位置较迅速的进行整理。 6、幼儿游园以结对子的形式进行是可行的，有助于幼儿之间交往能力的培养和责任意识的培养，我们发现，有的幼儿自始至终都能与自己找到的朋友一起参加游园，部分家长也很支持、配合这项活动的开展。 7、较好地利用了电视新闻的宣传，本次活动我园进行了两次电
大话设计模式读书笔记
第一章简单工厂模式 1、代码规范性 A、变量命名规范化 B、if语句逻辑清晰，单向分支逻辑判断应该避免使用重复的if判断 C、异常情况判断 2、面向对象编程 (1)面向对象编程优点：A、可维护B、可复用C、可扩展D、灵活性好 (2)通过封装、继承、多态将程序耦合性降低，使用设计模式使程序更加灵活，易改，易复用 3、业务封装(将业务逻辑与界面逻辑分开) (1) 低耦合：高保密，高易维护性。 (2) 简单工厂模式 以下为C#代码： Public class OperationFactory { Public static Operation CreateOperate(string operate) { Operation oper = null; Switch (operate) { Case “+”: oper = new OperationAdd(); Break; Case “-”: Oper = new OperationSub(); Break; Case “*”: Oper = new OperationMul(); Break; Case “/”: Oper = new OperationDiv(); Break; } Return Oper; } }
(3) UML类图 *注：1、“动物”代表类 2、类分三层：第一层显示类的名称，如是抽象类，用斜体表示； 第二层是类的特性，即字段和属性； 第三层是类的操作，即方法和行为； 3、“+”表示public，“-”表示private，“#”表示protected 4、接口图顶部有<
自我总结与反思
自我总结与反思 自我反思总结 按照大队《反思日制度的通知》精神，我把本人工作实际与《通知》要求相比，对照查看内容，发现存在一些具体问题，并从自己内心深处反思如下： １、政治理论学习不够。实事求是的说，我还是比较爱学习的，但是近几年来，自己学习不如从前那样刻苦了。存在实用主义倾向，一是学习上不够勤奋。总觉得自己接受快，要用时学习随时来得及、跟得上。二是深入思考不够。自己平时学习，属浅层次的理解、记忆，没有认真思考，没有从深层次上去理解和把握，并加以指导实际工作。三是用理论指导实践不够。平时学习之后，不善于用所学的理论观点和方法去指导推动工作。 ２、对为民服务的观念理解不深、不透。做好本职工作，为群众办好事、办实事，正确处理各种利益关系是实现宗旨观的最基本形式。总的说，在思想的认识上、行动的自觉性上有差距。有时觉得在实际工作中，在具体行动上难以准确把握，没有完全做好与工作实践的紧密结合。 ３、思维方式不够科学。一是认识问题有偏颇。对政治形势研究较少，敏锐性不强，总觉得了解全面局势、掌握外界动态，制定方针政策是上级的事、领导的事，自己是执行者，只要把上级的精神不折不扣的贯彻执行就行了，缺乏
大局意识和忧患意识。这种思想是不对的，片面的，说明自己的不成熟。 所以在今后的工作、学习、生活过程中我要弥补现在存在的不足之处，完善自我： 首先，要进一步加强政治业务学习，提高自身素质。坚持理论联系实际，实事求是，解放思想。加强自身思想改造，与时俱进，开拓创新，强化为民服务观念，使自己的一言一行都体现出城管执法人员的形象。 其次，要进一步解放思想，适应工作需求。用新的思维去发现、解决工作中遇到的各种问题，因此，在今后的工作中，将以学习为载体，注意思想的解放，观念的创新，不断创新工作思路和方式方法，以适应工作的需求。 最后，要加强自身建设，严格要求，自我加压。始终保持积极向上、昂扬奋进的精神状态，自重自省、自警自励，在工作中自觉地服从、服务于大局，自觉地把自己的工作同全局联系起来，坚持高标准、严要求，努力做好本职工作。 2016年9月30日 个人反思自我总结 今天是XX年4月27日，我们进行了关于“反思总结自我、共建和谐团队”总结的会议，我是小组长所以我是组织者，我安排陈欢欢做会议记录，会议在中午十二点半正式开始了：
活动总结与反思
活动总结与反思 最近发表了一篇名为《活动总结与反思》的范文，觉得有用就收藏了，希望大家能有所收获。篇一：对于团日活动的总结和反思 对于团日活动的总结和反思 关于团日活动，我感觉首先要做出一个总体的定位：这是一次完整，顺利进行的活动，但是就其预期目标，活动进行，后期总结，规模影响各方面而言，可以说是一次失败的活动。作为一个策划者和参与者，从整体和个人部分做出反思，从主观和客观得到教训。从整体而言 没有足够的准备，考虑不周全。例如，就会场会发生的紧急情况没有提出合理建议，甚至没有想到。就物资（桌椅，板凳，帐篷）的解决没有充分的考虑。前松后紧，时间不充裕。协调沟通太差，工作分成几组，的确有利于提高效率，但是也同时割裂了各部分的联系，协调。导致人人只忙自己的事，忘了我们是一个整体。 活动进行和结束后，整体很懒散，怎么说呢。就是对工作没有积极性现场的物资，垃圾都没有自觉的打扫。 个人部分：负责视频，和一个小组，现场参与。 工作粗糙，如在节目彩排的时间，人员还没有到位。于内，它反（转载于在点网活动总结与反思）映出我的组织能力有待加强。这种现象，是很值得反思。通知，在活动中，要充分调动参与人员积极性，在活动参与时的通知，在拍摄视频时的通知都不够，没有切实将活动具体的各方面细节通知到位，导致参与人员不够积极，甚至签到后就离场了。 条理性，整体性。在负责拍视频过程中，虽然我们开了一小时多的会但是，没有及时和其他人联系，后期制作没有具体参与。拍摄过程不够条理，致使视频
质量差。而且没有顾及到一些边边角角，例如设备的准备，人员通知时不够具体。 工作态度工作方法。没有顾全大局，仅仅局限于自己的一小部分，没有为整个团队着想，在工作方法上还有缺陷，例如对拍摄人员的安排。还有最重要的一点就是态度真的不够，虽然说能力很重要，但是积极的态度是必不可少的。 就后期和个人参与来看。没有充分调动社团的积极性，主要由于活动通知不到位和不够有吸引力，社团反响不算太好。思想汇报专题而且个人积极性不够，没有完全投入到整个活动中，没有为其他队友考虑分忧。活动现场懒散，现场秩序混乱。 在工作初期，对工作认识不够，缺乏全局观念，对活动缺少了解和分析，对工作定位认识不足。从而对工作的最优流程认识不够，逻辑能力欠缺，结构性思维缺乏。 认识：这次活动由于客观可用时间的关系准备得有点仓促，还有就是可能我们都是第一次接触这种要自己组织来举办的大型活动，都没有什么工作经历。但我相信，只要我们继续坚持自我教育和自我完善，一定能取的更大的进步。在这一活动中，虽不战果累累但却也有一定的成绩，不惊天动地却也实实在在。相信在未来的工作中，我们将做得更好，将会取得更加优异的成绩。我也将一如既往的保持这份热情，希望大家可以一起努力，一起学习，一起进步。最后，我想说我在组织部学到了很多东西，提高了自己，希望会不断进步，一直到最后。 篇二：工作总结和反思 工作总结和反思 根据公司董事长在管理干部会议上的讲话，结合经营形势和转型的实际情况，落实培育积极进取、勇于奉献、智慧创新的管理，提升管理水平，通过组织管辅人员对各自的工作进行反思，深挖自身工作中的问题，现反思如下：
模式总结
设计模式总结 一、创建型模式 简单工厂 简单工厂最大优点在于工厂类中包含了必要的逻辑判断（switch），根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。 工厂方法 工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 工厂方法模式实现时，客户端要觉定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在时修改客户端。 抽象工厂 抽象工程模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类。 原型模式 原型模式（Prototype）,用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。（拷贝对象的引用地址《浅表副本》）。.NET在System命名空间中提供了ICloneable接口（里面唯一的方法Clone()）,只要实现这个接口就可以完成原型模式。 建造者模式 建造者模式（Builder）,将一个复杂对象的构造过程与它的表示分离，使得同样的构造过程可以创建不同的表示。
如果使用建造者模式，那么用户就只需建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。——抽象不应该依赖细节，细节应该依赖于抽象。建造者模式主要用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。 单例模式 单例模式（Singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。 二、行为型模式 观察者模式 观察者模式（Observer），定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生改变时，会通知所有观察者对象，使它们能自动更新自己。 当一个对象的改变需要同时改变其他对象的时候，而且他不知道具体有多少对象有待改变，应该考虑使用观察者模式。观察者模式所做的工作其实就是在解除耦合，让耦合的双方都依赖于抽象，而不依赖于具体，从而使得各自的变化都不会影响另一边的变化。 模板方法模式 模板方法模式（TemplateMethod），定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构可重复定义该算法的某些特定的步骤。 模板方法模式是通过把不变行为搬移到超类，去除子类中德重复代码来体现它的优势。模板方法模式就是提供了一个很好的代码复用平台。 状态模式 状态模式（State），当一个对象的内在状态发生改变时允许改变其行为，这个对象看起来像是改变了其类。
android之大话设计模式
笔者在《如何成为Android高手》一文和视频中曾提出，成为一名真正的Android高手必须掌握和遵循的一些准则：1，学会懒惰 2，精通Android体系架构、MVC、常见的设计模式、控制反转（IoC） 3，编写可重用、可扩展、可维护、灵活性高的代码 4，高效的编写高效的代码 5，学会至少一门服务器端开发技术 上面的几条准则非常明确的指出：熟练掌握设计模式以及设计模式相关的内容是在成为Android高手的道路上必修的课程。 Android号称是首个为移动终端打造的真正开放和完整的移动软件。作为一个气象万千的平台，设计原则、设计模式、IoC以及相关思想的应用是是导致Android之所以能够取得今日的Android的成功的核心因素之一。 为了让国内的Android爱好者们从浩如烟海的设计模式相关的系列书籍和文档中解脱出来，本着一种方便国内Android 开发者更好、更快、更轻松的对Android的设计原则、设计模式、IoC(控制反转)理解和掌握的心态，国士工作室成员在百忙之中编写了《Android之大话设计模式》一书，该书涵盖了6中设计原则、主要的设计模式、UML建模语言和StarUML建模工具的使用等，主要内容如下： ?前言(已发布) ?针对接口编程---问世间情为何物直教人生死相许(已发布) ?单一职责原则乔峰VS慕容复(已发布) ?开放封闭原则孙悟空任弼马温一职(已发布) ?里氏代换原则法海捉拿白蛇新解(已发布) ?迪米特法则慈禧太后为何不和陌生人说话(已发布) ?合成聚合复用原则刘邦VS韩信（已发布） ?简单工厂模式一见钟情的代价（已发布） ?工厂方法法模式让麦当劳的汉堡适合不同MM的不同口味（已发布） ?抽象工厂模式MM的生日 ?单例模式你是我的唯一 ?原型模式肉麻情话 ?建造者模式让我们同居吧！ ?装饰模式见MM的家长 ?外观模式MM也迷恋炒股？ ?享元模式短信可以这样发 ?适配器模式笔记本电脑的适配器 ?代理模式QQ聊天机器人 ?桥接模式最重要的是要有一颗让MM快乐的心 ?组合模式MM的生日礼物 ?模板方法模式人的一生应该这样度过 ?观察者模式GG在MM身边有两个妹妹 ?状态模式在一天的不同时间要给MM发不通的短信 ?策略模式帮助MM选择商场打折策略 ?职责链模式帮助MM选择商场打折策略 ?统一建模语言UML简介和StarUML使用 本着开放、分享、交流的原则，现免费开放该书，希望能够为推动国内Android的发展贡献力量。
班主任工作总结和反思
班主任工作总结和反思篇一：班主任工作总结和反思 班 主 任 工 作 总 结 和 反 思 新源二中高二(16)班： 年1月16日 缪岫兰 XX 班主任工作总结和反思 新源二中缪岫兰
忙碌的一学期工作已经结束了，回顾一学期来的工作更多的是缺憾和不完美，总是感觉到有很多该做的工作没有完成好，很多好的想法没有得到贯彻和实施，尽管做了大量的工作也付出了大量的精力，但是班级总是还存在着这样或者那样的毛病，总是感觉到头痛医头脚痛医脚，没有一个十分系统的规划和刚要。现将本学期的工作总结如下：一．建立良好的班集体; 新学期开始，班级的一切都是新的，万事开头难，好的开始是成功的一半。在开学初的工作中，自己重点抓了班集体的工作。在开学的第一天，自己充分利用学生都想有一个好的印象的心里，鼓动学生自己发言，谈谈他们对初中生活的展望，对新的班级体的预期和对自己在新班集体中的角色定位。通过学生们的发扬自己从中挑选适合班级工作的带头人，并且鼓励他们好好表现，为接下来的班级干部竞选奠定了基础。同时也通过学生的发言，从另一面了解了学生，为新学期的工作的开展铺平了道路。在第一天的会上也阐述了自己在班级管理上的核心思想，让学生尽快了解自己，尽快做好与学生的交流和沟通，为接下来的班级工作奠定了良好的基础。 开学伊始，各项工作十分的繁杂，但是自己还是充分的利用头一个月不上早自习的时间，对学生进行行为习惯教
育。根据学校的要求背诵弟子规，小学生守则，小学生日常行为规范。对学生进行日常行为规范的教育，利用学生刚到初中，积极上进的心理，通过各种各样的竞赛 等形式开展学习、卫生、文娱等竞赛活动，更好的贯彻学校的要求。以此约束学生的行为，养成良好的行为习惯。 充分利用班会时间，对学生进行思想教育，本学期教育的重点是安全、学习品德教育。由于学生刚刚入校一年，集体主义还不够成熟，同学之间的关系不够协调，个人主义思想严重，自觉性差。学生时常会打小报告，学生心里没有形成良好的集体主义思想，班集体的凝聚力和向心力没有形成。于是利用班会时间，召开主题班会进行思想教育。展开集体主义教育，调动学生的积极性，让学生自己发现班级的问题，并自己进行沟通，并通过大家的讨论进行解决。 二．班级的日常管理; 班级的事情很多，本学期的工作也很繁忙，为了减轻自己工作的压力，在本学期的班级工作中，采取分层承包的工作思路。现在班级确立四个组长，全班同学分成四个小组，从卫生，纪律，到学习都分到四个小组中。组长是组内的最高行政长官，统管组内的一切工作，对班主任负责。组内设纪律卫生学习等各个部门，进行任务的细化分类。各组之间展开竞争，从早上的作业的收取，每天的卡片的成绩，课堂
上半年工作总结与反思
上半年工作总结与反思 总结的深度等于成长的速度，等于发展的速度。写好工作总结，帮你更快成长。《个人上半年工作总结》是小编为大家准备的，希望对大家有帮助。 上半年工作总结与反思 上半年以来，派出所在分局党委、xx乡党委、政府的正确领导下，结合科学发展观，以春季严打攻势、三大战役以及大走访开门评警活动为上半年工作要点，摸索出一条适合本地实际的治安防控体系以及在热情服务群众上走出一条和谐警民关系和维护一方治安稳定放在突出位置，确保了辖区安全、稳定，现将xx派出所今年上半年的工作情况作总结如下： 一、以科技手段推动工作、以信息应用提高效能的工作思路，积极推进大走访开门评警全面协调的开展，开创公安群众工作满意工程 (一)、评进千家万户，让开门评警火起来，实现评议范围与密度的双扩大 自从年初大走访开门评警工作开展以来，xx派出所以大造声势、人人皆知、全民参与为目标，积极回应人民群众新期待，满足人民群众新要求，不断丰富走评形式，创新工作方法，限度听取评议，了解民意，高密度、多角度、全方位的宣传大走访开门评警活动，迅速掀起了大走访开门评警的新热潮。 1、创新评议模式。工作中，派出所在采取走访座谈、电话随访、上门走访等传统形式征求意见建议的基础上，大胆探索创新联系群众的新载体和新渠道，搭建了一个集qq警务室、新浪和腾讯微博、博客于一体的网络平台，吸引了社会各界群体的广泛参与和积极评议，探索出了一条网络1+n式评警模式(即：1个网络平台联系n个群众)，拉近了警民距离、促进了社会和谐，有效提升了开门评警活动实效，受到辖区群众的一致好评，先后征求群众意见建议25条。截止目前，派出所新浪微薄粉丝已达17936人，新浪博客访问量6230人次，民警小缪的会客厅腾讯微博听众达6966人，位居全市基层所队前列。 2、活化宣传形式。工作中，派出所自筹资金，安装了led警务公开显示屏并通过调试正式对外宣传，成为我区第一家拥有同步led电子宣传屏的农村基层派出所。
学习总结：学习总结与反思
学习总结:学习总结与反思 我们进行学习总结时,反思是少不了的,下面来看看的看法 1、完成学习计划、安排好学习时间 学习的目的就是要有实效.我根据培训学习日程安排,制定了学习计划,几乎每天都安排了一定的学习时间和内容,把学习、作业、交流、讨论互相穿插,保证足够的时间与空间,获取最大的学习效益.我 用课余时间和双休日完成了多项课程的学习,在学习中,我还做了大 量的学习笔记,注重突出重点,突破难点,能够根据网上提供的一些案 例发表自己的见解,探索更有效的方式与途径.每次学习之后,积极思考,认真完成了网上作业,达到了预期的学习效果.在学习研修的过程中,我坚持每天进行网上学习,认真观看各个专家的视频录象,通过学习,解决了我在实际教学中遇到的很多疑难问题,使自己在师德修养、教育理念、教学方法、等各方面有了很大的提升,驾驭课堂、把握教材、交流沟通、教学设计、班级管理、教学反思的技能也有了很大 的提高,同时更新了教育理论,丰富了教学经验,开阔了视野,充实了 自己.虽然能够学习的时间必须得从一点一滴的积累,这样也更加珍 惜这次学习机会.我通过课程视频聆听了专家的专题讲座;通过课程 文本加深了对专题的理解;通过课程作业反思了以往和展望即将启动 的教学改革. 2、努力做到管用 学习的过程是一次知识积累与运用、创造的过程,因此要会学、 善用.我每次听专家讲座后,总要有一个思考,即如何将这些优秀的、 先进的教育教学经验及典型的案例带进自己的课堂,有针对性的运用 到自己的教育教学实践中,从而收到事半功倍的效果,缩短同发达地 区学校教学上的差距.通过实践对理论、经验的检验,寻找这些方式 方法上的不同点、相同点与衔接点,完善自己的课堂教学方法,提升 自身的课堂教学艺术.我刻苦钻研计算机知识,结合教材所需,将一些 抽象的教材内容通过多媒体技术具体化、形象化,并创设出身临其境
机器人兴趣小组活动总结与反思
机器人兴趣小组活动总结与反思 时间过的真快，转眼就又到年底了，经过了一学期机器人活动小组的教学，感觉大家的收获还是很大的。 这学期的机器人活动兴趣班主要是由四、五年级的学生所组成的。对于四年级的学生来讲，学习操作机器人还是有些困难，难能可贵的是，这帮孩子很听话，很好学，很乐学，进步令人欣慰。 要想操控好机器人必须具备三个条件，一是要有好的遥控操作基础，能够熟练地操控遥控器；二是要对机器人的结构比较熟悉和了解；三是还要有理解程序能力与善于动手维修的能力。本来以为四年级的学生在这些方面都比较陌生，可是令我意外的是，每当讲解过后，他们也能知晓一二，并且兴趣很浓厚。于是，我在接下来的培训活动中间，着意对四年级孩子们多倾斜了点，希望他们早日成长。 这次与孩子们一起开展机器人兴趣活动，没有像以前那样先教孩子们一个个熟悉机器人软件的使用，也没有谈太多的理论知识。因为总结以前的经验，我发现这些对于小学阶段的的孩子们都不太适合，在他们这个好奇心强、持续性短的年龄阶段，他们习惯的就是见识真实的、能看的见、摸得着的机器人，并且有机会能很快自己动手做出来，亲自操控它。根据孩子们的这种年龄和知识特点，我选择了这样的教学方法，那就是不直接讲解程序的设计与程序的意图，而是在一次次简单的机器人操作中让孩子们来感知程序的存在和重要性，并想知道程序到底是怎么样来帮助人实现自己的意图，让机器人按照自己的意图行动和完成任
务的。用任务驱动式的教学方法来引导孩子们参与机器人活动，激发兴趣，保持兴趣。 经过这学期的学习活动，孩子们从刚开始时自己头脑中想象的、不具体的机器人开始，到现在都已经掌握了操控机器人的方法与知识。如对机器人结构的了解，对遥控器与机器人运动方式的掌握，对竞赛规则的学习，对竞赛实战的模拟。还有个别孩子表现很是突出，在数百人的观摩现场都能游刃有余的操控机器人进行比赛，真是很棒的。 当然，活动小组也有些准备不充分、考虑欠周到的地方，比如，刚开始时，时间定在周二、周三、周四中午，但是由于后来我要参与学校的青年夜校学习，又不得不改在了周三和周五的中午，看到现在孩子们的表现，又自责刚开始时对四年的孩子们估计过低，不过，两位高年级的老队员表现很不错，为活动小组的开展做了不少的贡献，看着孩子们一天天的成长起来，为这些聪明的孩子感到骄傲的同时，也感觉到自己肩膀上的担子的分量日益加重，在接下来的一学期里我将继续努力准备与组织好孩子们参与和学习机器人的活动，同时也要积极更新自己的知识与技能，与孩子们一起成长。
设计模式学习总结
设计模式学习总结 引子 刚开始学习设计模式的时候.感到这些模式真的非常抽象。今年下半年以来.随着我们组工作重点的转移.以及我在小组中角色的变化.我开始有条件提出自己对新系统的设计想法。在设计过程中.我发现了很多设计模式的用处.也确实应用了很多设计模式.这让我越来越感到设计模式的重要性.因此我写了这十余篇专门介绍设计模式的文章.作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》（有趣的是.梅宏一再在组会上强调应该译成重用）中介绍了一共23种设计模式.我一共写了19个设计模式（其中三个和在一篇文章中）.余下四个.考虑到该模式的应用范围我就没有介绍。在写这些文章时.其中的很多例子都是我在实践中提炼出来的.当然也有很大一部分是《设计模式》中的例子。不过.这四个人（四人团）生活的年代里现在已经很远了.所以它们的例子也很古老。 让我们更加设计模式 设计模式是个好东西.它给出了很多设计中的技巧与思路.对于很多优秀的设计.它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的.而是他们搜集了其他人优秀的设计.加以整理出来的.他们不是这些模式的创造者.仅仅是整理者。 应用设计模式会给我们带来很多好处：软件将变得更加灵活.模块之间的耦合度将会降低.效率会提升.开销会减少。更重要的.设计模式就好像美声唱法中的花腔.让你的设计更加漂亮。总的来说.设计模式似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了.在现在很多的图形界面框架都使用了MVC模式.大量跌代器模式的应用.彻底改变了我们对集合的操作方式。不仅如此.应用了设计模式的设计.往往被看成为优秀的设计。这是因为.这些设计模式都是久经考验的。 模式不是模型 在学习和使用设计模式的时候.往往出现一个非常严重的误区.那就是设计模式必须严格地遵守.不能修改。但是设计模式不是设计模型.并非一成不变。正相反.设计模式中最核心的要素并非设计的结构.而是设计的思想。只有掌握住设计模式的核心思想.才能正确、灵活的应用设计模式.否则再怎么使用设计模式.也不过是生搬硬套。