设计模式

设计模式，是对很多已有问题的常规处理方式。大多数材料记录了23种设计模式，但是要记在脑海里需要一定时间的代码练习和理解。我在学习《Java设计模式及应用案例》这本书时，将部分设计模式的代码实现进行了整理并放在Github上，如有需要点击该链接
Github-DesignMode

我喜欢将设计模式按照目的分为三类：

创建型模式（5种）：

工厂方法模式(Factory Method Pattern)
抽象工厂模式(Abstract Factory Pattern)
单例模式(Singleton Pattern)
建造者模式(Builder Pattern)
原型模式(Prototype Pattern)

结构性模式（7种）

适配器模式(Adapter Pattern)
装饰者模式(Decorator Pattern)
代理模式(Proxy Pattern）
外观模式(Facade Pattern)
桥接模式(Bridge Pattern)
组合模式(Composite Pattern)
享元模式(Flyweight Pattern)

行为型模式（11种）

策略模式(Strategy Pattern）
模板方法模式(Template Method Pattern）
观察者模式(Observer Pattern)
迭代器模式(Iterator Pattern)
责任链模式(Chain of Responsibility Pattern)
命令模式(Command Pattern)
备忘录模式(Memento Pattern)
状态模式(State Pattern)
访问者模式(Visitor Pattern)
中介者模式(Mediator Pattern)
解释器模式(Interpreter Pattern)

设计模式六大原则

1. 开闭原则
   开闭原则具有两个特性，其一是对扩展是开放的，其二是对于更改是封闭的。这样做的好处是对代码可维护、可扩展、可复用、灵活性好。同时还可以保证以前代码的正确性，因为我们并没有修改代码，所以可以保证开发人员能够专注于将设计放在新扩展的代码上。
   主要是对关键步骤进行抽象化---封装。例如setXXX 或者 getXXX

2. 里氏替换原则
   这个主要是一个软件实体如果使用一个父类的话，那么一定适用于父类的子类。而且它觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类替换成它的子类。程序的行为是没有变化。
   通俗的来说：子类是可以扩展父类的功能，但是不能改变父类原有的功能。

3. 依赖倒转原则
   高层模块不依赖底层模块，二者都要依赖其抽象；抽象不应该依赖细节，细节也应该依赖抽象。说白了就是面向接口编程。因为相对于细节来说，抽象的东西要稳定很多。以抽象搭建起来的架构比细节搭建起来的架构要稳定的多。
   通俗的来说，面向抽象编程，而不是面向细节编程
   举个例子来说，一个团队，有需求组，开发组，测试组。而开发组和测试组面对同样的需求，做自己响应的工作。而不是测试组按照开发组的理解需求去做测试用例。也就是说开发组和测试组是直接面向需求组工作的

4. 接口隔离原则
   使用多个专门的接口，比使用一个单一的接口要好。因为在设计中，依赖几个专用的接口要比依赖一个单一的接口更加灵活。
   通俗的来讲：细化多个接口，不要建立臃肿的接口
   一个接口就好比一个剧本中的角色，而这个角色在一个舞台上的表演相当于接口的实现。因此，一个接口相当于代表一个角色，而不是多个角色。如果系统涉及多个角色的话，那么每一个角色都应当由一个特定的接口代表。
   这里与单一职责的区别在于，单一职责原则注重的是职责，约束类，其次才是接口和方法；而接口隔离原则注重的是对接口依赖的隔离，约束接口，主要针对抽象、针对整体框架的搭建。

5. 最少知道原则
   这里强调的是类之间的松耦性，类之间的耦合性越弱，越有利于复用。一个处于低耦合的类被修改，不会对有关系的类造成影响。也就是说，信息的隐藏促进了软件的复用。
   通俗的来讲：就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类，无论逻辑多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，不对外泄露任何信息
   而我们常说的低耦合、高内聚正是由这个原则去完成的。总之一句话，一个对象应该对其他对象保持最少的了解。

6. 单一职责原则
   在软件编程中，我们不希望修改了一个功能导致其他的功能出现问题。而避免这个问题的方法便是遵循单一职责原则。
   通俗的来讲：一个类负责一项职责，应该仅有一个引起它变化的原因
   单一职责原则的优点可以提高类的可读性，提高系统的可维护性，变更引起的风险降低。这个原则并非只是在面向对象编程思想所特有，只要是模块化的程序设计，都需要遵循这个原则。