三天配置之接口设计及框架设计

接口，什么是接口！   java语言层面 我们想到的是 interface，abstract class   跳出语言层面，我们能想到什么呢，协议，规范！

一个东西，最有价值的就是它的接口！  我们的web项目，UI(user interface)，客户看到的和关心的这是UI,根本不管你底层用了多么牛叉的技术！

UI提供了什么接口呢，它提供了很多链接，很多页面给我们！   如果有一个链接，是程序员不想给普通用户使用的 ，但是忽然有一天一个黑客忽然发现这里有一个链接，诶，看起来很好玩的耶，是管理员的界面，而且还不需要登录！  那么这个界面 也成为了接口！  从这个层面讲  接口就是我能看见的，能使用的!

所以从能否使用，能否看见来定义接口，我们怎么去定义java界的接口呢，  显然我们想到了  修饰符  那到底什么修饰的才是接口呢！ public  这个毋庸置疑了，  private呢，在一个类里面，一个private方法是可以被其他方法调用的，  protected 呢    还有个package local (什么都不写)  这个是不是呢！？

我们想想这4个修饰符的意思，public ，private 这2个就不解释了，protected这个是 同包或者子类可访问， package local呢 是同包可以访问，  public,private  修饰的是class 而protected 跟 package local 修饰的是 package  所以说package 跟 class 同样重要！

我们平时写项目，一个class显然是不可能完成一个功能的，所以我们需要用package 一个功能块一个package   所以接口已package来划分（也就是已功能划分）  那么显然public 跟protected 都是接口了！  但是二者还是有区别的！ public 是可以被直接使用的 是 api  而 protected 是需要继承才能使用的  是 spi （serveice provide interface） ！

如果我们设计一个接口  应该考虑哪些问题呢，  需求（输入，输出），安全性，代码的复用性，代码的可维护性，安全性,可行性，可用性，异常，可测试性等，但是其实可以归结为2类，一类为 可用性， 一类为 可行性！ 

异常是一个重要可用性方面的问题！  (三天培训之异常 里面讲了 异常的处理)

可测试性呢 就是 需要接口能够很一目了然，一看接口就知道这个接口要干嘛，需要什么，返回什么，做了一件什么事情！

接口是协议， 那么协议就是双方进行商定的！

假设现在有个  Item 商品类 有字段  名称，价格，提供商，id  现在要根据属性来进行组合查询，  这个接口怎么设计呢！

我们很容易第一个想到的是 传递一个 Map 过去 ！  这个方法很不推荐，待会会说为什么！   我们的 删 传递一个id ，增，改，都是传递一个Item 对象就ok了，

那我们能不能设计的跟前面的接口一样呢？

有人说传递 对象 Item 过去，这其实也有无法实现的地方，比如说 我要查询价格在某个区间的呢？ 

那该怎么办呢？  我们可以定义一个  ItemQuery 对象  传递这个对象就ok了，在里面写设置方法！

有人说这个跟Map 有啥区别啊？  区别大着呢？  Map 你可能会写错了  key，而且value 的类型 就是object 可能会输错，  为什么有泛型 就是为了防止  classcastexception，

而且Map 需要文档说明，不然谁都不知道你要什么    但是用ItemQuery对象 就不会有这个问题了！  有人说Map 易于扩展， Map添加个字段 需要改文档，需要改调用地方的代码 其实一样！

有人又有疑问了，  对象能解决 复杂的多表查询吗？  比如我要查询  TradeRecord  交易记录，有 交易时间，交易价格，交易数量，商品属性，显然要进行多表关联，

其实可以 有个  TradeRecordQuery对象 ，里面可以包含一个属性  ItemQuery　这样就解决了问题了！

最后一点  系统架构，  接口的作用就是隐藏实现，为什么要隐藏实现，因为要进行责任的分割！

这个js 显然需要知道 业务的，因为js做的是什么  做的是验证，验证显然需要知道业务意义的，action 知道业务吗？  这个先不管，我们看service  service 显然需要知道业务的！而dao呢  这个显然是不需要的！ 如果action 知道业务，那么要service做什么呢？ （这里解惑了我以前迷糊很久的问题，以前写代码  也很疑惑很多时候 action 跟service 搞在一起了，分层很不清晰，甚至action 做了 dao的事情！）

所以说分工一定要明确，懂业务的就是js　跟service  ! 我们讲异常的时候 有个 叫做 使用者是知道业务的， 是不是矛盾呢，其实因为js懂业务，所以action也就懂业务了！ action其实就相当于一个传话筒的功能！

这次培训讲了3小时，讲了很多东西，实在无法表达！ 呵呵，只能这样浅显的说一下了！ 

反正呢，接口的设计一定要  看名字就知道它的意思！  然后呢  框架的设计 要 分工详细，责任分割详细！ 

框架的设计 有2个主流 一个是 KISS 原则  Keep It Simple, Stupid

另外一个是： SOLID原则！