##工厂模式(factory pattern):
####意图
定义一个创建对象的接口。让其子类决定实例化那一个工程类,工厂模式将其创建过程延迟到子类中
####主要解决
主要解决接口选择问题。
####何时使用
在不同条件下创建不同实例。
####如何解决
让其子类实现工厂接口,返回的也是一个抽象的产品。
关键代码
创建过程在其子类中执行。
####优点
1,一个调用者创建一个对象。只要知道对象名旧可以 。
##工厂模式(factory pattern):
####意图
定义一个创建对象的接口。让其子类决定实例化那一个工程类,工厂模式将其创建过程延迟到子类中
####主要解决
主要解决接口选择问题。
####何时使用
在不同条件下创建不同实例。
####如何解决
让其子类实现工厂接口,返回的也是一个抽象的产品。
关键代码
创建过程在其子类中执行。
####优点
1,一个调用者创建一个对象。只要知道对象名旧可以 。
##适配器模式(Adapter Pattern)
####意图
当一个类的接口转换成客户希望的另外一个接口的适合,适配器模式使得原本由于接口不兼容不能一起工作的类可以在一起工作
####主要解决
在系统中常常要将一些现存的对象放到新环境中,而新环境接口是现存对象不能满足的
####何时使用
1:系统需要使用现有的类,但是这个类的接口不满足系统需要
2:想要建立一个可以重复使用的类,用于一些批次之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作,这些源类不一定有一致的即可
3:通过接口转换,将一个类插入到另一个类系中,(比如老虎和飞禽,现在多了一个能飞的老虎,在不增加实体需求下 增加一个适配器,里面包含虎对象,实现飞接口)
####如何解决
继承或者依赖
####关键代码
适配器继承或者依赖已经有的对象,实现想要的目标接口
####实例
1:美国电器110v 中国220v 需要一个适配器来转换
2:jdk1.1提供Enumeration接口 现在1.2中提供了iterator接口 ,想要使用1.2jdk 就要把一起系统的Rnumeration接口转换iterator接口
3:linux上运行windows程序
4:jvm就是一个类似适配器的一个虚拟机
####优点
1:可以让两个没有关联的类一起运行,
2:提高类的复用
3:增加类的透明
4:灵活
####缺点
1:过多使用适配器,让系统显得凌乱 ,不容易把握整体,比如明明调用的是a接口但是内部适配成b接口的实现,一个系统中出现太多这种情况会爆炸,如果不是很有必要不适用适配器,而是对系统重构
2:由于java只能继承一个类,所以最多只能适配一个适配类,而且目标类必须是抽象类
####使用场景
有动机的修改一个运行正常的系统接口
####注意
适配器不是详细设计时候设计的 而是解决在系统上线过程中出现问题
####总结:通过一个中间适配器类来增加已有类的功能,这个只是补救方式 最好的方式还是重构项目
####代码地址:https://github.com/xuxianyu/myGitHub/tree/master/DisignPattern/src/main/java/com/xxx/structural/adapter
##单例模式(Singleton Pattern)
####注意
1:单例类只能有一个实例
2:单例类必须自己创建自己唯一的实例
3:单例类必须给其他对象提供这个实例
####意图
保证一个类仅有一个实例。并提供一个访问它的全局访问点
####主要解决
一个全局使用的类频繁创建销毁
####何时使用
控制实例数目。节省系统资源
####如何解决
判断系统是否已经有这个单例。如果有返回、没有创建
####关键代码
构造函数私有化
####应用实例
1:一个党只有一个主席
2:多线程中对文件的处理必须是唯一的一个实例来进行。
3:设备管理器常常被设计为单例模式。比如一个电脑有两台打印机。在输出的适合不能两台打印同一个文件
####优点
1:内存中只有一个实例,减少内存开销,
2:避免对资源的多重占用
####缺点:
没有接口、不能继承。和单一职责冲突。
####使用场景
1:产生唯一序列号
2:计数器
3:创建比较耗费资源的对象比如io 与数据库链接等
####总结:共有 懒汉式线程不安全、懒汉式线程安全(加锁)、饿汉式、双捡锁、登记式、枚举这些方式来创建单例 其中饿汉式,双捡锁,登记式,枚举比较适合平常用。懒汉式要么不 安全 要么效率低下不建议使用
####代码地址:https://github.com/xuxianyu/myGitHub/tree/master/DisignPattern/src/main/java/com/xxx/create/singleton
##建造者模式(builder pattern)
####意图
将一个复杂构建与其标识相分离,使得同样构建过程构建出不一样的标识
####主要解决
在创建复杂对象过程中,通常是各个部分子对象用一定算法构建而成;由于需求变化,这个复杂对象各个部分经常面临剧烈变化,但是组合他们成为一个复杂算法是相对稳定的。
####何时使用
基本部件不变,但是组合经常变化(组合对象不定,算法固定)
####如何解决
变化部分和不变部分分离
####关键代码
1:建造者:创建和提供实例
2:导演:管理建造出来的实例依赖关系
####实例
肯德基,有汉堡、可乐、薯条等是不变对象,但是其中他们组合是经常变化的
####优点
1:建造者独立,容易扩展
2:便于细节风险控制
####缺点
1:产品必须有共通点,因此限制范围
2:内部变化复杂的化会出现很多建造类
####使用场景
1:需要生成复杂对象有复杂的内部结构
2:需要生成对象内部属性相互依赖
####注意事项
建造者模式更加关注零件装配的顺序
而工厂模式关注的是产品结果
####个人总结:在组合复杂对象的时候 可以采用建造者模式 这样只需要在构建类中区定义生成对象的依赖就可以了
####代码地址:https://github.com/xuxianyu/myGitHub/tree/master/DisignPattern/src/main/java/com/xxx/create/builder
##抽象工厂模式(Abstract Factory Pattern)
####意图
提供一个创建一系列相关或者互相依赖的对象接口,无需指定他们具体类
####主要解决
解决接口选择问题
####何时使用
系统产品多于一个产品族,而系统只消费其中某一族产品
####如何解决
在一个产品族中定义多个产品
####关键代码
在一个工厂里聚合多个同类产品
####实例
假设生产衣服 有商务男装、商务女装、时尚男装、时尚女装等等、都放在各自种类衣柜中。衣柜就承当抽象工厂的作用。其中衣柜中上衣、裤子 都是单独的产品
####优点
当一个产品族中多个对象被设计成一起工作的时候,它能保证客户端始终只使用其中一个产品族 不会乱套
####缺点
产品族扩展困难。要增加一个系列的一个产品 既要在抽象工厂里面加代码又要在具体里面加代码
####使用场景
1:qq换肤2:生成不同操作系统的程序
####注意事项
产品族难维护。等级好扩展
####个人总结:抽象工厂 用来生成工厂 然后来选择具体的产品
####代码地址:https://github.com/xuxianyu/myGitHub/tree/master/DisignPattern/src/main/java/com/xxx/create/abstractfactory
公司想切换到spring cloud上所以我找了本书看看 大致上知道了spring cloud的各部分组件 也算是用的比较熟练了
但是好记性不如烂笔头 所以写一波笔记 防止遗忘
####目录
在使用SpringBeanManager工具类的时候 发现 spring boot 是根据目录取扫描装配bean 的
由于我把 这个工具类放在com.ming.core.utils下 导致 这个加载顺序在一些初始化服务之后
看了一下相关资料
有四种解决方法
1 | <!--bean声明--> |
1 | @Component |
1 |
|
###actuator 是spring boot 提供的一个监控的工具
直接访问 相应端点(rest 接口)
端点分为三种:
####spring boot 打包成docker image 会更加方便使用
1:配置编译jar选项
2:配置maven docker 插件
3:上传到私服
4:自动化脚本
####配置编译jar
如果是继承spring boot 的pom 直接如下配置即可
1 | <plugin> |