设计模式-问题-享元模式+组合模式+适配器模式+桥接模式
享元模式
享元模式是什么我相信你很容易理解,但是什么时候你应该考虑使用享元模式呢?有没有想过?
系统中存在大量的相似对象
例如String,Integer,Long内部维护的缓存
需要缓冲池的场景
例如说线程池的维护
需要注意ThreadLocal如果用线程池,变量不记得回收可能出现问题
连接池的维护
细粒度的对象都具备较接近的外部状态,而且内部状态与环境无关,也就是说对象没有特定身份。
画出
StringTest.java
类中对应的内存布局。

组合模式
怎么理解客户端对单个对象和组合对象保持一致的方式处理
都是面向抽象编程,所有的根节点和子节点都有共同的抽象角色构建
所以操作方式都是相同的方式
组合模式透明方式是怎么违背最少知道原则的
组合模式透明方式因为是通过继承,所以子类其实也获得了很多本来自己所不需要关心的属性。
适配器模式
适配器一般是什么时候 用到(我们使用时候需要先知道当前代码的情况然后再重构也许需要使用设计模式)
适配器模式是一个补偿模式,或者说是一个“补救”模式,通常用来解决接口不相容的问题,在百分之百的完美设计中是不可能使用到的, 什么是百分之百的完美设计?
“千虑”而没有“一失”的设计,但是,再完美的设计也会遇到“需求”变更这个无法逃避的问题,,不管系统设计得多么完美,都无法逃避新业 务的发生,技术只是一个工具而已,是因为它推动了其他行业的进步和发展而具有了价值,通俗地说,技术是为业务服务的,因此业务在日新月异变化的同时,也对技术提出了同样的要求,在这种要求下,就需要 我们有一种或一些这样的补救模式诞生,使用这些补救模式可以保证我 们的系统在生命周期内能够稳定、可靠、健壮的运行,而适配器模式就 是这样的一个“救世主”,它在需求巨变、业务飞速而导致你极度郁闷、 烦躁、崩溃的时候横空出世,它通过把非本系统接口的对象包装成本系 统可以接受的对象,从而简化了系统大规模变更风险的存在。
桥接模式
- 问题
想一下桥接模式怎么不使用继承的情况下怎么把两个维度结合起来的呢,可以举个例子或者对于上述案例加以说明也行
在java当中除了继承就是组合和聚合了
如果通过继承
那么子类会持有很多父类的东西,并且很容易重写父类的方法,违背里氏替换原则
如果通过组合和聚合
子类想要拥有方法很简单,桥梁打过去,获得这个方法就行了
例如
image-20210106090526018 我们集团组要功能是赚钱,赚钱需要先生产然后销售
crop
当前是抽象类具体的生产产品,和销售交给旗下的子公司HouseCrop
卖房子的和IpodCorp
卖Ipod的来卖钱public class Client { public static void main(String[] args) { System.out.println("-------房地产公司是这样运行的------"); //先找到我的公司 HouseCorp houseCorp = new HouseCorp(); //看我怎么挣钱 houseCorp.makeMoney(); System.out.println("\n"); System.out.println("-------服装公司是这样运行的-------"); ClothesCorp clothesCorp = new ClothesCorp(); clothesCorp.makeMoney(); } }
很明显现在有一个问题,我们的工厂和具体的产品绑的太死了,比如说但是我们不想用抽象工厂那么可以通过桥接模式来解决,用组合来把他们构建起来
image-20210106091728955 可以让山寨的工厂也能生产房子和ipod其实就是通过桥梁模式让我们的具体公司能够和产品关联起来
我们平常写JDBC代码的时候有没有去琢磨一下这句代码
DriverManager.getConnection("jdbc:mysql://localhost:3306/ds0", "admin", "admin");
是怎么拿到mysqlConnection。image-20210106092730379
Last updated