1、面向对象设计，封装，继承，多态
封住 不要无脑的把属性get set，要封装具体的业务方法，把想要输出给外围的属性 和 方法进行暴露
2、常量类，按照业务将一个大儿全的类 分割为多个业务常量类
3、工具类，与业务无关的方法才能抽出来当作工具类
4、什么时候使用抽象类，就是为了解决代码复用的问题
5、什么时候使用接口，就是为了解决非代码复用的问题，而是解决抽象的问题
6、继承的问题：继承层次过深，继承关系过于复杂会影响到代码的可读性和可维护性
7、贫血模型：像mvc三层模型中，Model中只包含数据结构，不包含业务逻辑，业务逻辑都在service中。
8、充血模型：Model中包含数据结构，和当前这个model对应的各种业务方法，service接口依然存在，支持负责与数据库层次打交道，事务，其它模块调用等
9、微服务加速了领域驱动模型（DDD）的发展，基于贫血模型的传统开发模式 重service 轻BO。基于充血模式的DDD开发模式，轻Service 重BO。
10、如何设计一个鉴权模块？
OOA，OOD，OOP
OOA，通过url+appid+密码 进行访问，服务端做验证
url+appid+token（appid+时间戳+密码）+时间戳
OOP
URL，AuthToken，SecretStore 分解出三个类。根据不同的业务能力，拆分到不同的类中
11、类之间的关系：继承，实现，聚合，组合
12、程序开发的原则 SOLID
单一职责 SRP:一个类只负责做一件事情，不要将不同的业务逻辑都混在一个类中
开关原则 OCP：软件实体（类，方法）应该“对外扩展，对修改关闭”，通俗一点就是：添加一个新的能力的时候应该是新增代码，尽量不修改原有的代码。最常用的设计模式 装饰，策略，模版，责任链
里氏代换：子对象能够替换程序中父对象和出现的任何地方，并且保证原程序的逻辑行为不变以及正确性不被破坏。里氏代换与多态的区别：多态是一种代码实现的方式，里氏代换是一种原则，用来指导继承关系中子类该如何设计的思路，保证在替换父类的时候，不改变原有程序不被破坏。
父类定义了函数，那子类可以改变函数的内部实现逻辑，但是不能改变函数原有的约定，这个约定包括 函数声明要实现的能力，对输入 输出 异常约定，甚至包括注释中锁罗列的任何特殊说明
接口隔离：客户端不应该被强迫依赖它不需要的接口，尽量将不同业务的做接口隔离
控制反转规则（IOC）：框架提供一个可以扩展的代码骨架，用来组装对象，管理整个执行流程，开发者利用框架的时候，只需要在指定的扩展点上开大，就可以利用框架来驱动整体流程的执行。
控制：指的是对程序执行流程的控制，反转：在使用框架之前是开发者控制程序的执行，使用框架之后，整个程序的执行流程是框架来控制的。
依赖注入DI：一句话 不通过new的方式在类内部进行创建依赖的对象，而是将依赖的类对象在外部创建好之后，通过构造方法，函数参数等方式给类使用。
依赖注入框架：guice，spring，picocontainer。butterfly container ，我们通过依赖注入框架的扩展点，简单配置一些所需要的类及其类之间的依赖关系，就可以由框架自动创建对象，管理对象的生命周期
依赖反转原则：高模块不要依赖低模块，高模块和低模块之间应该通过抽象来相互依赖，初次之后，抽象不要依赖具体的是实现细节，具体的实现细节依赖抽象。
tomcat是运行web容器的，我们编写的应该程序运行在tomcat容器中，便可以被tomcat容器调用执行。tomcat就是高模块，web程序就是低模块，tomcat 和 应用程序之间没有直接的依赖关系，这二者都是依赖同一个抽象，就是servlet规范，servlet规范不依赖具体的tomcat容器金额应用程序实现细节，而tomcat和应用程序依赖servlet规则
KISS原则：尽量保持简单，代码的可读性和可维护性是重要的指标
不要使用同事不懂的技术来实现
不重复造轮子，要善于使用已有的工具类库
不过度优化
YAGNI ：程序的扩展性可以预留好，但是不需要的不要写，不要做过度设计
DRY原则：不要写重复代码
迪米特法则：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。
如何设计一个业务系统？
1、合理的将功能规划到不同的模块
2、设计模块与模块之间的交互关系
一种 同步接口调用，另一种就是通过消息通信
3、设计模块的接口、数据库、业务模型
针对3更加具体一些原则：
（分层设计，分层代码复用性，分层隔离变化作用，分层隔离关注点，分层提高代码的可测试性，分层能应对系统的复杂性）