00 valueOf和“ ”+ 1拼接效率比较
答：字符串拼接的两个值，实则是通过创建第三个属性的创建StringBuilder然后通过其自带的append()方法，对两个数值进行拼接并赋给定义为StringBuilder的变量，最后将此变量通过toString来转换为字符串。而valueOf()方法则是直接调用其自带的toString方法进行转换。
01 方法中的方法体又称方法签名
02 TDD企业模式
测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。
Test-Drive-Development：即需求被转化成一系列明确的测试例，写代码使测试依次通过，最后重构使增量代码和存量代码和平共处，满足设计规则和原则，不断的迭代直至结束。
03 BDD：行为驱动开发
Behavior Driven Development:行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。主要是从用户的需求出发，强调系统行为。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。
04 ATDD：验收测试驱动开发
Acceptance Test Driven Development:TDD 只是开发人员的职责，通过单元测试用例来驱动功能代码的实现。在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员，强调如何实现系统以及如何检验。
05 多态的使用
存在的必要条件
- 需要有继承关系
- 需要有重写
- 需要有父类的引用指向子类。
当子类继承父类时，若方法签名一致，只需要修改其里面的对象，可以将此对象进行以方法的形式来新建。当子类继承时重写创建对象的方法即可替换对象，并在子类中实现以本类对象进行的方法操作。
//父类中
IParkingAndDriveable builderObject(ParkingLotImpl...parkingLots){
return new ParkingBoyImpl(parkingLots);
}
public void parking_boy_could_parking_one_car(){
ParkingLotImpl parkingLot = new ParkingLotImpl(1);
IParkingAndDriveable parkingBoy = builderObject(parkingLot);//此处用到。
assertThat(parkingBoy.parking(new Car())).isExactlyInstanceOf(Ticket.class);
}
子类中进行重写对象。即可达到替换对象目的。
@Override
IParkingAndDriveable builderObject(ParkingLotImpl... parkingLots) {
return new SmartParkingBoy(parkingLots);
}
06 测试总类
A。单元测试
- 是指对软件中的最小可测试单元进行检查和验证，测试方法：白盒测试
- 单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
B。集成测试
也叫组装测试或联合测试，测试方法：灰盒测试
-
在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
-
模块组装成系统的方式：一次性组装方式和增殖式组装方
-
一、一次性组装方式
先对模块分别进行测试，再把所有模块组装进行测试
缺点：发现错误不容易定位
-
二、增值式组装测试
先对一个个模块进行模块测试，然后将这些模块逐步组装成系统，分为两种方式：自顶向下的增殖方式和自底向上的增殖方式 。
-
C。系统测试
软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，
集成测试和系统测试之间的比较：
- 1、测试内容：集成测试是测试各个单元模块之间的接口，系统测试是测试整个系统的功能和性能；
- 2、测试角度：集成测试偏重于技术的角度进行测试，系统测试是偏重于业务的角度进行测试。
D。验收测试
-
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
-
不是对系统进行全覆盖测试，而是对核心业务流程进行测试；
-
验收测试包括alpha测试和beta测试，alpha测试是由开发者进行的软件测试，beta测试是由用户在脱离开发环境下进行的软件测试。
E。白盒测试
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序的所有逻辑路径进行测试，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试。白盒测试主要是想对程序模块进行检查。
F。黑盒测试
黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。
E、F区别
白盒测试主要用于检测软件编码过程中的错误；黑盒测试主要检测软件的每一个功能是否能够正常使用。软件的黑盒测试意味着测试要在软件的接口处进行；软件的白盒测试是对软件的过程性细节做细致的检查。
07 敏捷开发和瀑布
敏捷开发借助互联网浪潮开始流行起来，这也是2C的业务特点决定的，看过QQ和微信长大的人，这种体会特别深。互联网产品不可能一步规划到位，一般都是核心功能优先，比如微信，先是实现聊天功能，然后才是漂流瓶，钱包，小程序……
08 Java内存区域分布图
09 JVM知识讲解
10 java类加载机制和类加载器(ClassLoader)的详解
11 类的加载顺序介绍(ClassLoader)
初始化顺序依次是：（静态变量、静态初始化块）–>（变量、初始化块）–> 构造器；
如果有父类，则顺序是：父类static方法 –> 子类static方法 –> 父类构造方法- -> 子类构造方法
第一点，所有的类都会优先加载基类
第二点，静态成员的初始化优先
第三点，成员初始化后，才会执行构造方法
第四点，静态成员的初始化与静态块的执行，发生在类加载的时候。
第四点，类对象的创建以及静态块的访问，都会触发类的加载。
构造方法的调用顺序
- 首先会调用基类的构造方法
- 其次，调用成员的构造方法
- 最后，调用自己的构造方法
12 常见问题即名词解释
运行时数据区
程序计数器
栈
局部变量表
操作数栈
Java堆
方法区（Method Area）
关于字符串 + 号连接问题：
13 finalize关键字
finalize方法作用
finalize()方法是在每次执行GC操作之前时会调用的方法，可以用它做必要的清理工作。
它是在Object类中定义的，因此所有的类都继承了它。子类覆盖finalize()方法以整理系统资源或者执行其他清理工作。finalize()方法是在垃圾收集器删除对象之前对这个对象调用的。
14 垃圾收集器GC原理应用
15 DDD 领域驱动设计模式
16 包层结构说明
1.vo是封装有类属性的bean的集合,有的项目组用domain表示；
2.sql里面是各中sql语句，一般是final String，方便以后查询修改；
3.dao里面是数据访问的方法，也就是传统的增删改查方法；
4.service里面是业务逻辑处理类，这里根据用户传来的需求进行业务逻辑判断然后调用不同的dao层里不同实现类的不同方法，以实现业务；
5.delegate叫做代理层，有些小项目里这一层没有，用于简单处理用户请求，并调用不同的业务层方法；
6.web里就是那些Controller控制器，与界面进行交互的地方
这些分布只是一些行内默认习惯，并没有什么强制性，这种分层是为了防止侵入式开发，同时方便修改测试以及封装。
17 设计模式的六大原则
A.单一职责原则（Single Responsibility Principle）
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，
循单一职责原的优点有：
1.可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2.提高类的可读性，提高系统的可维护性；
3.变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
B.开闭原则(Open-Closed Principle, OCP)
一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展
问题由来：任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。因为变化，升级和维护等原因，如果需要对软件原有代码进行修改，可能会给旧代码引入错误，也有可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试，所以当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现使我们需要的。
C. 里氏替换原则(Liskov Substitution Principle, LSP)
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。
D. 接口隔离原则(Interface Segregation Principle, ISP)
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
E. 依赖倒置原则（Dependence Inversion Principle，DIP）
高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程。
依赖倒置原则的作用
（1）依赖倒置原则可以降低类间的耦合性。
（2）依赖倒置原则可以提高系统的稳定性。
（3）依赖倒置原则可以减少并行开发引起的风险。
（4）依赖倒置原则可以提高代码的可读性和可维护性。
依赖倒置原则的实现方法
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。
（1）每个类尽量提供接口或抽象类，或者两者都具备。
（2）变量的声明类型尽量是接口或者是抽象类。
（3）任何类都不应该从具体类派生。
（4）使用继承时尽量遵循里氏替换原则
F. 迪米特原则
一个软件实体应当尽可能少地与其他实体发生相互作用。只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多少复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息
浙公网安备 33010602011771号