微服务技术栈

装饰者模式是指在不改变原有对象的基础之上，将功能附加到对 象上，提供了比继承更有弹性的替代方案（扩展原有对象的功能），属于结构型模式，为对象扩展一些额外的职责。比如给房子装修就可以当作是一个装饰者模式，装饰者在代码程序中适用于以下场景： 用于扩展一个类的功能或给一个类添加附加职责；动态的给一个对象添加功能，这些功能可以再动态的撤销。装饰者模式在项目中经常用到，不仅仅是框架中，就连Jdk API中也有用到，我们以JDK API 中的一个装饰者模式为例讲述装饰者模式。在 JDK 中体现最明显的类就是 IO

观察者模式是一种对象行为模式。它定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。在观察者模式中，主题是通知的发布者，它发出通知时并不需要知道谁是它的观察者，可以有任意数目的观察者订阅并接收通知。观察者模式（Observer）完美的将观察者和被观察的对象分离开。（百度百科）。我们使用JDK提供的API来实现一个观察者模式，学生向老师提问问题，然后通知老师有学生提问，这个案例里面，老师属于观察者，需要实现Observer接口。学生属于被观察者，需要继承

模板方法模式定义了一个算法的步骤，并允许子类别为一个或多个步骤提供其实践方式。让子类别在不改变算法架构的情况下，重新定义算法中的某些步骤。它适应的场景有：一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现；各子类中公共的行为被提取出来并集中到一个公共的父类中，从而避免代码重复。（百度百科），看到定义或许会很迷糊，我们可以通过例子说明，其实模板模式的一个典型的应用就是Spring的JdbcTemplate，这是一个经典的模板模式，我们就以Spring的JdbcTemplate为例子介绍模板模式，

策略模式（Strategy Pattern）是指定义了算法家族并分别封装起让它们之间可以互相替换，此模式使得算法的变化不会影响使用算法的用户。一般策略模式由三部分组成：抽象策略角色： 策略类，通常由一个接口或者抽象类实现；具体策略角色：包装了相关的算法和行为；环境角色：持有一个策略类的引用，最终给客户端调用。假如我们出去旅游，可以选择坐高铁，坐火车，汽车，飞机，还可以自驾游，这几种交通方式就可以当成是一种策略。我们可以根据自己的实际情况选择对应的策略出行。首先我们先定义一个出行策略：public

委派模式不属于 GOF23 种设计模式中。委派模式（Delegate Pattern）的基本作用就是负责任务的调用和任务分配,跟代理模式很像,但是代理模式注重过程，而委派模式注重结果。在Spring中有很多地方使用到委派模式，比如：DispatcherServlet根据不同的URL进行转发；BeanDefinitionParserDelegate 根据不同类型委派不同的逻辑解析BeanDefinition等。委派模式在现实中也经常发生，比如一个软件开发公司，有产品经理，项目经理，开发人员。产品经理做好产

单例模式也是创建型模式的一种，在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中，应用该模式的一个类只有一个实例，而且自行实例化并且向整个系统提供这个实例。该类构造方法为私有，并 =提供一个全局访问点，比如公开一个getInstance()方法获取单个实例。单例模式在现实生活中应用也非常广泛。例如：ServletContext、 ServletContextConfig ;在 Spring 框架应用中的 ApplicationContext;数据库的连接池等。一般来说单例的创建有饿汉式

工厂模式是开发过程中最常见的设计模式之一，我们平时使用的框架中，比如：Spring，MyBatis等都涉及到到了工厂模式。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，封装了对象的具体创建方式，在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。工厂模式分为简单工厂模式，工厂方法模式和抽象工厂模式，其中简单工厂模式不属于GOF23种设计模式之一。简单工厂模式：简单工厂模式也叫静态工厂方法模式，它不属于23种设计模式之一。它内部使用静

迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。（百度百科）迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则

接口隔离原则就是客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。（百度百科概念）。看着可能比较懵逼。简单的说就是应该使用多个接口，而不是一个包含所有方法的接口。举个例子：在单一职责原则和开闭原则里我们分别创建了WeChatMsgHandler和WeChatE

单一职责（Simple Responsibility Pinciple，SRP）又称单一功能原则,它规定一个类应该只有一个发生变化的原因。所谓职责是指类变化的原因，如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。假设我们有一个类负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在两个导致类变更的原因。接下来，我们看一下代码示例，在开闭原则一节，我们创建接口WeChatMsgHandler以达到扩展而不修改已存在的代码，实

开闭原则（Open-Closed Principle）是指一个软件实体（类，模块和函数）应该对扩展开放，对修改关闭。它是针对扩展和修改两个行为的原则。它强调用抽象构建框架，用实现扩展细节，用以提高系统的可复用性和可维护性，该原则是让在增加新功能的同时尽量不修改已有代码。几乎任何一款优秀的框架都使用了开闭原则，比如Spring，我们使用Spring的时候不需要修改Spring源代码，就可以集成很多其他框架，增加功能。这里我们使用项目中的微信公众号的消息接收为案例，我们在开发微信公众号时，可以接收微信服务器

最近在设计一个新的平台（原来的平台代码都是一坨一坨的，每添加一个功能点，都会引出一堆的问题，恨不得在一个类里面讲所有功能实现，从不考虑代码的可读性，可维护性，可扩展性。）现在想要设计一个可扩展的在线平台，因此不得不拾起设计原则与设计模式这些东西，在此做一些记录，并且会使用项目中的案例或者优秀开源项目中的案例。关于设计原则和设计模式，我想很多软件开发者都多少的了解一点，但是又了解的不是那么深入，看完就懂，过段时间就忘。它看起来是有用的，但是很多时候又觉得没什么用。据我所知道的大多数项目都是一次性开发，就是