你能做到几个呢？(思想接口依赖分层业务)

2.设计模式中提到的6大设计原则

A.单一职责原则：

从业务的角度规范模块或单元划分范围的界限，即业务模块的外在界限；

B.里式替换法则：

通俗的讲，就是面向对象（其实不仅仅限于面向对象）的继承，其概念是“凡是对象A出现的地方，都能被对象B替换”，满足这种情况，就应该设计成继承结构，即

B extends A.

C.ioc或DI法则：

即依赖注入或控制反转，大名鼎鼎的开源机构Spring，将这一思想体现的淋漓尽致，具体思路 就是具体依赖抽象，由“主动”的“拉”，转化为“被动”的“推”，且被推的目标在编译时是不确定的，在运行时动态绑定。
这里用到很重要的一个思想，“接口”编程，依赖关系传入接口，具体的实现在运行时指定，一般通过XML配置推入。

D.接口分离原则：

契约（接口定义的功能）并不是越多越好，功能越多，责任（具体的实现）代价也越大，因此从业务的角度加以划分接口要提供的最“干净”的功能，比如，对应美的观点，有丰腴，也有苗条，如果合并在一个接口中，虽然编码上没问题，但给人的感觉挺矛盾与怪异，这种情况下，显示拆分在2个接口比较合理。

E.迪米特法则：

看过电视剧的人，经常听到熟悉的台词：“A：为什么？”，“B：你知道的太多了…”.

如果说单一职责法则、接口分离法则是对对象内部的规范要求的话，那么，IOC、迪米特法则则是基于对象之间依赖性约束的相关规范，它与IOC 一样，出发点都是“解耦” 达到低耦合的目的，解耦是需要代价的，一般至少引入一个中间层，引入的中间层越多，与目标的耦合越低，这其实分层思想的一个典型应用，其实这里还有一个隐形原则，就是依赖的路线最好是单线（1:1），而不是树或网状对应关系（1：n,n:m）,举例，有老师、学生2个对象，老师与学生直接耦合，如果解耦，可以引入班长或课代表这个中间角色，这样就有3个角色了，这时，三者之间有如下几种依赖图：

老师———————->班长（或课代表）——————————>学生

A.单线依赖关系

B.非单线依赖关系

可以看到 b类型的依赖关系，老师不仅要依赖班长，还有依赖学生，产生多重 依赖，“知道的太多”，不是一个好的解耦方式，而A就是正确的迪米特法则的实现体现；

F.开闭法则：

这种主要是针对编码时的规范要求，即对新增方法开放，对已有的方法进行修改是关闭，也就是保留已经成熟的实现方法，如果需求有变动，通过增加新的方法，将影响度降低到最低，特别是新旧版本发布的时候，有些还在途未处理的业务，依旧需要沿用原有的业务逻辑。

这里的分层，是针对架构层次的分层，典型的WEB应用 一般都会进行分层，比如展示层、业务逻辑层、领域模型层、数据访问层，这就是典型的分层思想，这样的好处是 .方便软件的复用、维护，减少维护成本，也方便架构的伸缩、扩展性；SPRING MVC 也是典型分层系统的实现；

上面设计原则中的IOC原则以及提到，这里也是为了强调接口开发的好处，通过引入接口层，使模块或组件之间的依赖通过接口来耦合，不是具体的实现来耦合，这样做的好处有以下几种：

1.RPC调用，将接口与实现分类，方便客户端、服务端的隔离，对客户端而言，实现改变了，不影响客户端的编译；

2.通过接口依赖，实现解耦，方便业务拓展、变动引起的不变维护，将影响降到最低；

3.方便软件的重用，更好的结合设计模式中的具体模式嵌入。

常用的配置文件格式有property,xml等，其好处是配置做了改动后，不需要重新编译，重启应用即可生效（有些应用可以动态提取，不用重启应用），特别是容器管理配置的维护，真正达到“四两拨千斤”的效果，ibatis、mybatis的mapper思想就是

最好的体现，通过动态维护XML中的映射语句，到达动态访问业务数据的功能。

这里的分离是一个很广泛的思想，小到代码模块单元，大到服务、子系统，都含有分离的思想，包括配置都包含若干分离思想的应用，之所以如此，主要是分布环境、多人开发团队协作给软件开发驱动的必然结果，方便治理也好、方便维护也罢，总之其目的不一而足。

随着系统业务量的增加，数据量也会同步增长，对数据的提取与导出带来了性能上的压力，数据分页是十分有必要的，具体包括前台分页（js相关插件）、后台分页（数据库的分页或对查询出的结果集进行计算分页），这样会极大提高系统的性能。

对于复杂或交互量大的系统，往往需要与周边系统进行交互数据，一般需要通过RPC的方式进行调用，如果每包的数据量比较大，调用比较频繁，如果同步方式

处理，对系统的性能要求比较大，而采用异步方式，则极大改善性能，特别是对实时性不高的业务。