u011463470的博客

1.泛型的继承包括：普通泛型的继承，抽象泛型的继承，接口的继承    注：其实他们的继承方式都一样，对于泛型的继承我们只要记住一些规则就可以了    ①：泛型的继承分为保留继承和不保留继承。           a.保留继承又分为部分保留和全部保留====》子类也一定是泛型           b.不保留又分为具体类型继承，和不具体类型继承（相当于类型擦除，类似于Object类型）

简单工厂模式的思想源于Java中的接口。Java中接口市一中特殊的抽象类，跟一般的抽象类相比，接口里面的所有方法都是抽象方法，接口里面的所有属性都是常量。也就是说，接口里面只有方法定义，而不会有任何方法实现。        （1） 接口的作用         通常用接口来实现类的外观，也就是实现类的行为定义，用来约束实现类的行为。接口就相当于一份契约，根据外部应用需要的功能，约定了

//管理配置信息(便于项目和配置文件的解耦)public class Configuration{       //驱动类      private String driver;      //数据库的连接url      private String url;      //数据库的用户名     private String user;     //数据库的密码

简介：一个代理类可以代理多个被委托者（或被代理者），因此一个代理类具体代理哪个真是主题角色，是由场景类决定的。当然，最简单的情况就是一个主题类一个代理类。这是最简介的代理模式，在通常情况下，一个接口之需要一个代理类就可以了，具体代理哪个实现类由高层模块来决定，也就是在代理类的构造器中传递被代理者。       静态代理：在程序运行前就已经存在在代理类的字节码文件，代理类和委托类的关系在

在日常工作或交流中，经常会讨论一些关于sql调优的问题，然后总结了下，下面我们主要是从软件方面进行分析，希望对你有帮助：        引导语：我曾有一种感觉，不管何种调优方式，索引是最根本的方法，是一切优化手法的内功，所以一下我们将讨论一些和索引相关的调优方式。        索引可以新建、删除、重建。        注：下面介绍的调优手段只是一些常规条件下的优化手法，具体的优化效果

简单工厂的本质是：选择实现。        注意简单工厂的重点在选择，实现是已经做好的。就算实现在简单，也要由具体的实现类来实现，而不是在简单工厂里面来实现。简单工厂的目的在于为客户端来选择相应的实现，从而是的客户端与实现之间解耦，这样一来，具体实现发生了变化时，就不用变动客户端了，这个变化会被简单工厂吸收和屏蔽掉。        工厂模式的本质：在简单工厂的基础上完善了OCP原则

内存调优的目的：对于JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数，重点是减少Full GC的次数，因为它会对整个堆进行整理，导致Full GC一般由以下几种情况：  ①：年老代空间不足  ②：Permanet Generation空间不足  ③：统计得到的GC后晋升到年老代的平均大小大于年老代剩余空间  ④：System.gc()被显示调用

作用：此模式能够在不必改变原类文件和使用继承的情况下，动态扩展一个对象的功能。装饰模式是通过创建一个包装对象来实现的，也就是用装饰来包裹真实的对象。        好处：        一：比继承更灵活        从为对象添加功能的角度来看，装饰模式比继承来得更灵活，继承是静态的，而且一旦继承，是所有子类都有同样的功能。而装饰模式则把功能分离到每个装饰器中，然后通过对象组合

//根据配置信息，维持连接对象的管理（增加连接外对象）public class DBManager{      //连接池对象     private static DBConnPool pool;     private static Logger logger = Logger.getLogger(DBManager.class);     //配置信息     p

一：泛型就是一种泛化类型，泛型可以让我们在开发过程中觉得更加安全更加省心，同时也可以让类型更加人性化和更加丰富。eg：List list = new ArrayList();//等价于List list = new ArrayList()，在java1.7之后也可以写成List list = new ArrayList二：对于list我们可以往里面添加任意的数据类型，但是当我们取数据想要取

抽象就抽象类和接口 ，细节即具体实现类       核心思想：要依赖与抽象，不要依赖与具体的实现，它的意思就是在应用程序中，所有的类如果使用或依赖与其他的类，则都应该依赖于这些其他类的抽象类，而不是这些其他类的具体实现类，它的本质就是通过抽象使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。（针对接口编程）        依赖注入原则如下三点说明：       

单一职责的核心思想就是：系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成：       目的：高内聚，低耦合       单一职责也就是单一变化原因。       需要注意的一点就是：当实际情况中的职责确实发生了变化，应用该原则才是具有意义的。如果一个类组合了多个职责，但这些职责在实际情况中根本不会发生变化，那就完全没有必要提前费尽心机去应用这个原则

场景1（不使用桥接模式的情况下）：商城系统中常见的商品分类，以电脑为例，如何良好的处理商品分类销售的问题？？        一般解决方法是：用多继承结构的方式层层继承。        但是由此会引发已写问题：        ①：扩展性问题（类个数的快速增长）        ②：违反单一职责原则        场景2（使用桥接模式的情况下）：商场系统中常见的商品分类，以电脑为类，

适配器模式(Adapter)，在我们的生活中，这种类似的场景随处可见，比如你想充电，但是你只有一个两个插头的充电头，但是这个插座却是有三个插头的，此时你会需要一个三个插头的适配器，而这个三个插头的适配器上有一个两个插头的的插孔。此时你就可以使用你自己的充电头充电了。        适配器(Adapter)模式的作用：将一个类的接口装换成客户希望的另外一个接口。Adapter模式使得原来

其实这两种架构在原则上确实相当近似，但仍有不同之处。在围绕这服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。这两者之间最关键的区别在与微服务更专注于以自治的方式产生价值。        对于微服务，我们可以这么理解：经过分离的组件可以各自拥有独立的生命周期，独立部署（Docker），并且按需进行扩展。不仅如此，这种方式也打破了组件之间的技术依赖，这就允许每个服