到这招聘需求系列会告一个尾声，接下来就都是笔试面试题了，在目前的公司博主不太开心，技术上成长的空间已经不高，终日为琐事所累，没有真正的大神去膜拜，看着身边的菜鸟们，我虽然菜但是比他们强+上进的自信我还是有的。这个文章的主题就是设计模式！
熟悉java设计原则、设计模式
设计模式的中心思想就是OO思想，OO思想的四个好处可以用活字印刷的例子来说，可维护，可扩展，可复用，灵活性强。
设计原则包括JAVA自身的设计原则和针对设计模式的设计原则，
设计模式的设计原则：
1单一职责，一个类就干一个事，或者说对一个类而言，仅有一个引起她变化的原因。
2里氏替换，针对父子类关系的，直白说就是子类能够替换系统中所有的父类，因为这时候说明了父类真正被复用了。
3依赖倒置，说白了就是针对接口编程，而不是针对实现编程。
4接口隔离，跟1很像，别混杂了
5迪米特法则，说白了你管好自己就行，也别把自己暴露出去，也就是结构上，每一个类都尽可能降低成员对自己的访问权限，才有了那么多private，强调类与类之间的松耦合，只有松耦合了，才以后被修改，对其他相关的类影响才会最小。
6开闭原则，对扩展开放对修改关闭。
http://blog.csdn.net/jiafu1115/article/details/6713830 这是更复杂的有15条，
一 类的设计原则
1 依赖倒置原则－Dependency Inversion Principle (DIP)
2 里氏替换原则－Liskov Substitution Principle (LSP)
3 接口分隔原则－Interface Segregation Principle (ISP)
4 单一职责原则－Single Responsibility Principle (SRP)
5 开闭原则－The Open-Closed Principle (OCP)
二 包的设计原则
6 重用发布等价原则－Release ReuseEquivalency Principle (REP)
7 无环依赖原则－The AcyclicDependencies Principle (ADP)
8 稳定依赖原则－The StableDependencies Principle (SDP)
9 稳定抽象等价原则－The StableAbstractions Principle (SAP)
10 共同封闭原则－The CommonClosure Principle (CCP)
11 全部重用原则－The Common Reuse Principle (CRP)
三 扩展原则
12 迪米特法则 －Least Knowledge Principle (LKP)
13 黑盒原则－ BBP(Black Box Principle)
14 缺省抽象原则 －DAP(Default Abstraction Principle)
15 接口设计原则 －IDP(Interface Design Principle)
16 不要构造具体的超类原则 －DCSP(Don't Concrete SupperclassPrinciple)
设计模式：
设计模式分23种加一个简单工厂模式，大体分为3类，创建型，解决创建对象的问题，结构型解决类与类，对象与对象之间关系，行为性，增加协作效率。
创建型：0简单工厂simple factory 1工厂方法 factory method2抽象工厂abstract factory3创建者模式builder4原型模式prototype5单例模式singleton
结构型：6外观模式facade7适配器模式adapter8代理模式proxy9装饰模式decorator10桥模式bridge11组合模式composite12享元模式flyweight
行为型：13模板方法template method14观察者observer15状态state16策略strategy17职责链chain of responsibility18命令command19访问者visitor20调停者mediator21备忘录memento22迭代器iterator23解释器interpreter
明天开始挨个分析不过明天要上线，还有就是考的时候会让你花UML图。
创建型：
0简单工厂simple factory
简单工厂模式，就是用一个工厂创建所有需要的类，也就意味着一个工厂跟多个接口依赖，又叫静态工厂方法模式，顾名思义用一个静态工厂创建对象。
缺点自然是扩展麻烦，而且不能被继承。
1工厂方法 factory method
比上面的简单工厂多了个分类，一个工厂方法只负责一种产品的创建，所有的工厂继承自一个公用的工厂接口，实际使用中找到需要的工厂实现去调用。优点是扩展性好了很多，便于修改。
2抽象工厂abstract factory
工厂方法是一对一的创建，而抽象工厂就是针对多个产品结构创建，一次创建多个不同的产品对象。又回到了静态工厂处，一个工厂对应多个产品。但是与静态工厂的差距又很大。这就是OO的妙处。
3创建者模式builder
抽象工厂实现了一次生产多个不同的产品，但是当需要组装的时候，这个组装的功能如果放在抽象工厂又违反了单一职责的原则，当组装放在客户端时，如果产品的组装不复杂没问题，如果组装复杂，这时就需要一种设计模式针对这种级别比较大的产品。这时你要发现，创建和组装是两步，又不能违反单一职责原则所以组装类是单独的，那么把工厂类传入到组装类不就可以了么？没错，这就是创建者模式。
4原型模式prototype
很常见，比如画板里定义好的图形，你拿过来进行扩展，这就是原型模式，既然是复制出来了一份，就要实现cloneable接口。由于JAVA是引用传递，所以还有深度克隆和浅克隆之分。
5单例模式singleton
面试常问，也很常见，比如log4j，多考虑多线程下的单例模式，懒汉饿汉是基本的，然后是如何在多线程下实现，可以考虑用静态内部类，因为静态内部类只会加载一次。
结构型：
6外观模式facade
特别常见，现在系统用的分布式，用的RPC就是把一个业务系统的功能通过facade暴露出一部分供外部调用，从而降低耦合度。主要是一个抽象类，抽象外观实现。
7适配器模式adapter
可以叫他转换头模式，就是把USB转为MINIUSB的感觉。JAVA的IO中很常用，你传入来的流要能被其他接口所识别，强调了对接口的转换。
所以有适配器，调用适配器的对象和被适配的对象。
8代理模式proxy
又是非常常见的，顾名思义专业的事情找专业的人干，把类传入代理类，代理类会在类的执行前后进行处理。你没猜错，这就是AOP的思想，而且JDK1.3后就有了动态代理类，该类必须实现INVACATIONHANDLER接口，把要执行的类放进去BIND获取返回的代理对象，执行时就可以看到效果了。
9装饰模式decorator
OO思想中继承是有地位的，又是没地位的，当使用继承进行扩展的时候非常麻烦时，就需要装饰模式了，装饰类和要执行的类使用同一个接口，创建装饰类时把要执行的类扔进去，这样调用的时候就可以随意加东西了。
被装饰者和装饰器抽象类实现同一个接口，使用时把被装饰者传入装饰器对象。传入后调用父类构造把该被装饰者对象记为最新的状态。
10桥模式bridge
汽车有品牌有型号，当品牌和型号交叉的时候，如果用多重继承，那就真的是误入歧途了，桥模式就是将抽象与实现解耦，使用时，继承一次再用组合来一次就实现了，不明白？多重继承拆分成继承加组合，效果远比多重继承好。
11组合模式composite
组合模式，用于树形结构，多级菜单，你总不能又一级一级继承下去吧？所以组合模式就是把整体和部分进行分离，需要三部分，
1component 组件，指的是组合的组件，你没看错，叶就是实现了这个组件，这个组件也就是那个抽象类
2composite组合本身。用其实现对叶的增删等，你可以把他当做节点，一个节点会有多个叶，一个节点又会属于另一个节点，就这样实现了树形结构。
但是，当某时对象的数量很多，或者占用的空间又很大，这时候每创建一个对象都会引起很大的内存开销，就需要下面的享元模式，也叫蝇量模式。
叶与枝实现相同的接口，枝要能增删枝。
12享元模式flyweight
不过享元模式既然叫享元，这个享字不要忽略了，就是共享的意思，共享的是什么？自然是那么多的对象了。其实享元模式也是处理树形结构，也是为了不用继承，既然也是处理树形，其实跟组合模式差不多，但是他会创建大量不重复的对象，既然是创建对象，自然需要我们的工厂模式了，然后已经创建或者新创建的对象，说白了享元模式就是避免了相同对象的重复创建，减少了后期维护的难度，差不多的东西一样有一个就够了。
行为型：
13模板方法template method
就是定义一个骨架让子类去实现，那么问题来了，这个骨架要求一个调用过程和必须有调用的实现，用接口满足不了，只能用抽象类。
14观察者observer
就是对象间一种一对多的依赖，当一个对象变化时，要通知所有跟他有依赖的对象。
那么就需要1一个观察者2一堆接收通知并更新的人
根据OO原则这些人肯定是继承一个借口的，观察者中接收这个接口的对象，当状态发生改变时，调用所有接口对象的更新方法。同样这个观察者也可以通过继承抽象每个观察者对应一种状态的人，再进一步扩展把所有的观察者统一管理，用一个SUBJECT类，增删观察者并且在状态改变时调用所有观察者的更新方法。
观察者模式，又叫订阅/发布模式，SUBSCRIBE/PUBLISH.
这里观察者和被观察者的解耦，就是通过被观察者并不知道具体的观察者，只知道所有的观察者都是一个抽象的实现。
例子就是前台盯着老板，负责通知后面偷懒的员工。。。
观察者，就是在执行某个操作的人，也就是需要被通知的人。
需要一个SUBJECT类，作为抽象通知者，把所有对观察者的对象引用保存一起，可增删观察者。
由通知者通知观察者执行自身的更新操作。
使用中观察者必须要知道通知者，里面含有通知者，创建观察者时就把通知者传入进去了。
1创建通知者
2创建观察者，并且同时把通知者传入观察者
3改变通知者状态，触发通知者通知操作
4所有观察者改变。
15状态state
每种状态都放在不同的类里，将执行对象本身传入初始状态类，初始状态类执行完处理状态更新，把执行对象内的状态改变了，这就是组合的威力啊，你中有我，我中有你。
16策略strategy
策略模式可以说是对模板方法模式的扩展，模板方法模式的问题是一个类干了太多事情，自然也就违反了单一职责原则。
模板方法模式是定义了一个算法让子类去实现。
策略模式也是定义了一个算法，但是他自己实现了，里面都是抽象的调用，而具体调用哪个实现的，需要在执行前把实现传进这个算法的实体中，再调用算法。你没看错，这里又避免了继承，OO到底多讨厌继承啊。。。
17职责链chain of responsibility
再一次顾名思义，即使根据职责划分和事情的严重程度，将事情送到该负责他的类中。那么这些负责的就要组成一个责任链依次传递。
可以拿医生的例子说，医生分很多科，病人的来到一个医生面前，医生判断自己能不能治，
那么问题来了，一个医生只知道病人不行该交给下一个，但是下一个能不能搞定他也不知道，后果就是实际使用过程中可能病人要一路看到末尾，很是蛋疼。
18命令command
拿饭店举例，顾客找服务员点菜，服务员记菜单，拿着菜单让厨师做，从而让顾客和厨师解耦，这个菜单就是命令，一个顾客可以有多个命令然后集中调用一次。那么每个命令的执行人比如命令做菜的厨师，就要在命令类里体现，这又是一个组合的关系，命令包含被命令的人，顾客包含命令，顾客调用命令，命令命令厨师。而且这个命令是可以撤销和记录日志的。以及对请求排队。
实际使用中STRUTS的ACTION即使一个命令类，在MVC框架里，通过命令层实现C和M的解耦。
这又是一个抽象类的使用，命令本身是一个抽象类，里面包含了被命令者，比如教练发出命令，球员执行
球员类，命令抽象类，命令具体实现由多种，进攻命令防守命令，和教练类发出命令。
关键命令模式不光是解耦了，还能轻松实现回放命令和撤销命令的功能，因为回放时命令的对象和动作是要结合起来的，不用命令模式没这么轻松。而命令模式中的命令类就包括了命令和被命令者，实现很轻松。
19访问者visitor
这个模式。。。。很复杂，会有一个单独的访问者类来定义对每个物品的操作，还会在每个物品里定义一个方法用来表示这些物品可以被访问。
拿超市举例，超市的每个商品，都有一个方法供访问者访问，访问者访问后将这个商品传回访问者中进行访问。这个访问者中的访问就是可以自己定义了想访问商品的啥都行了，就是获取了商品的权限。那么当商品被加到购物车后，购物车调用结算方法把商品集合传过去，结算方法通过把访问者塞到商品中，访问者调用自身的行为把要获取的每个商品想要的属性返回给结算方法，结算方法根据这个得到最后的结果。这里需要注意结算方法并不是直接通过访问者类得到的结果而是通过将访问者类传入商品得到的结果。
这里的关键就是所有的商品都会在接受传进来的访问者对象后执行访问者对象的方法并且把自身传过去供调用，那么这时访问者内部务必区分传进来的对象执行不同的操作。
这样返回不同的结果给购物车也就是把访问者传给被访问者方法的对象。
20调停者mediator
又叫中介者模式，一个类要调用另一个类的方法，不直接调用，而是通过第三方，中介者封装的是对象间的相互调用，使其不能显示调用，从而松耦合，并且可以独立的改变他们之间的交互。
比如联合国就是中介者，国与国之间要交互的时候，不要直接联系，通过联合国传达，所以可以看到调停者也就是中介者中是需要包含要交互的两个对象的，在创建国对象时就要把中介者传进去了，这样国家发生行为的时候已经通过中介者发生了，并且在调用中介者方法时把自己传进去作为FROM，中介者中的另一个对象自然就是TO了。
21备忘录memento
有点绕，备忘录就是一个保存另一个类内部状态复制的对象，这样以后就可以用该对象恢复原来的状态。
前提是一定在不破坏封装的情况下，就是外部要对对象内部了解最少的情况下，捕获对象的状态，并且在对象的外面保存，然后还可以恢复。这就像打游戏的游戏存档。
实际使用中要保存状态的对象内部有一个备忘录类，当外部获取该对象备忘录实例时，返回一个包含对象当前状态的备忘录实例，当使用备忘录实例恢复对象状态时将备忘录实例扔到对象中，对象自动读取备忘录实例中的状态实现恢复。
22迭代器iterator
JAVA集合类的迭代器，分离了集合对象的遍历行为，抽象出一个迭代器类来负责，又可以不暴露内部结构，又可以让外部透明的访问内部数据。迭代器模式是为容器而存在的，因此他仅适用于对容器的访问。
可以看出关键点有几个 1不关心集合内部的实现。你是树啊，链表啊数组啊都无所谓我不知道也不关心2是多种遍历方式前后上下啥的
说迭代器必须依赖容器就是因为要容器去创建迭代器。
23解释器interpreter
顾名思义，翻译机，实际不常用，了解即可，但是解释型语言可不光一个解释器模式就能搞定的，复杂着呢。
http://blog.csdn.net/bwwlpnn/article/details/7421628
所有设计模式的UML图，看这个就够了，一定要看啊，面试时候会让你现场画的。
0 0
