小说Java接口传参数

　　这段时间做了一些接口开发，web、service、dao三层架构，分别打jar包。随着使用的增加，发现一个问题。常常一个功能开发好了以后，客户又来了新的需求。新需求建立在老的实现上，这时候就常常需要对老的接口进行变更。虽然说接口通常是为了某个特定目的的设计，尽量不要变化，但实际上可以朝着这个目标努力，但是不变却很难做到。

　　在这种三层架构分别打包的情况下，就要尽量考虑少变动，尽可能减少变更可能带来的影响。之前的接口传参一般两种方式，对象或者直接参数，如下

public interface sayHelloA(String personName);

public interface sayHelloB(Person person);

class Person{
   String personName ;
   ... ...
}

　　对于sayHelloA，简单直接，实现起来也方便；sayHelloB却要先建立一个Person类，会更麻烦一点。通常，如果参数多，或者本身就是BO，那肯定直接用对象了。但是如果参数少点，比如三个参数，这种情况下，一般都会觉得直接传参数，简单明了，也懒得去写参数对象了。这时候假设我的接口已经设计并实现并交付客户使用了，某天客户说，我要对不同性别的人说不同的话！ 好吧，参数变了，加一个性别参数，如下

public interface sayHelloA(String person, String sex);

public interface sayHelloB(Person person);

class Person{
   String personName ;
   String  sex ;
  ... ...
}

　　发现去别了吗？如果以后还有需求更改的话，那接口可能还得继续改。如果使用方式sayHelloA且是dao层的接口，那估计郁闷了，上面调用的web、service都得跟着改。但是如果采用sayHelloB这种方式的话，那接口基本不用动，只需要给这个Person增加属性就好了，变动相对来说要少很多。

　 　 同样的，表间关联，如果是一对多的关系，可以建立独立的关联表，也可以在多表中存放单表主键，分别如下

tableA(id, colA1, colA2);
tableB(id, colB1, colB2, idA);

tableA(id, colA1, colA2);
tableB(id, colB1, colB2);
tableRelationAB(id, idA, idB);

 　 实际上说白了，单独用一个表来维护关联关系，这样可以处理任何的关联（1:1,1:n,m:n），但是如果不这样做，那就是确定的1：n关系。一旦这种对应关系发生变更，编程了多对多，在这种情况下，表结构就必须重建，依赖于老关联关系的所有应用接口都要变更。这个就是麻烦的根源，当然并不是什么都要这样，具体视实际情况而定