静态工厂和构造函数都有一个限制：可选参数数量很大时，他们都不能很好地扩展。考虑一下这个例子：用一个类来表示袋装食品上的营养成分标签，这些标签有几个必选字段：每份的含量、每罐的份数、每份的卡路里；还有超过20个可选字段：总脂肪含量、饱和脂肪含量、转化脂肪含量、胆固醇含量、钠含量等等。大多数产品只有少数几个可选字段是非零值。
你将为这种类编写怎样的构造函数或者静态工厂呢？程序员习惯上会使用telescoping constructor模式，提供一个值包含必选参数的构造函数，以及一个包含一个可选参数的构造函数、一个包含二个可选参数的构造函数、等等，最后一个构造函数包含所有可选参数。【例】就像下面的示例那样，简单起见，我们只展示4个可选参数的情况。
// Telescoping constructor pattern - does not scale well!
public class NutritionFacts {
private final int servingSize; // (mL) required
private final int servings; // (per container) required
private final int calories; // optional
private final int fat; // (g) optional
private final int sodium; // (mg) optional
private final int carbohydrate; // (g) optional
public NutritionFacts(int servingSize, int servings) {
this(servingSize, servings, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories) {
this(servingSize, servings, calories, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat) {
this(servingSize, servings, calories, fat, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat, int sodium) {
this(servingSize, servings, calories, fat, sodium, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat, int sodium, int carbohydrate) {
this.servingSize = servingSize;
this.servings = servings;
this.calories = calories;
this.fat = fat;
this.sodium = sodium;
this.carbohydrate = carbohydrate;
}
}
当想要创建实例时，使用包含你想要设置的所有参数的最短的参数列表的那个构造函数：
NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);通常这种构造方法调用要求你传入一些你并不想设置的参数，但是不得不为这些参数传入一个值。在上例中，我们给参数fat传入了值0，因为只有6个参数，这看起来也还不算太糟，但是随着参数数目增长，很快就会无法控制。
简言之，telescoping constructor模式虽然可行，但是当参数过多时就很难编写客户端代码，而且更加难以阅读。读者会奇怪这些参数都表示什么含义，必须仔细地数着参数才能弄明白。一长串类型相同的参数会导致微妙的bug。如果客户端意外弄反了两个参数的顺序，编译器不会报错，但是程序在运行时会出现错误的行为（Item40）。
遇到多个构造函数参数的第二种方法是JavaBeans模式，先调用无参数的构造函数创建对象，然后调用setter方法设置每个必选参数以及感兴趣的那些可选参数的值。【例】：
// JavaBeans Pattern - allows inconsistency, mandates mutability
public class NutritionFacts {
// Parameters initialized to default values (if any)
private int servingSize = -1; // Required; no default value
private int servings = -1; // " " " "
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public NutritionFacts() { }
// Setters
public void setServingSize(int val) { servingSize = val; }
public void setServings(int val) { servings = val; }
public void setCalories(int val) { calories = val; }
public void setFat(int val) { fat = val; }
public void setSodium(int val) { sodium = val; }
public void setCarbohydrate(int val) { carbohydrate = val; }
} 这种模式没有telescoping constructor模式那种缺点。易于创建实例，而且产生的代码页易于阅读：NutritionFacts cocaCola = new NutritionFacts(); cocaCola.setServingSize(240); cocaCola.setServings(8); cocaCola.setCalories(100); cocaCola.setSodium(35); cocaCola.setCarbohydrate(27);不幸的是，JavaBeans模式自身有重大缺陷。由于构造过程分成了多个调用，在构建过程中JavaBean可能处于不一致状态。类不能通过检查构造函数参数的有效性来保证一致性。如果尝试使用处于不一致状态的对象，就会导致错误，而且产生这些错误的代码大相径庭，导致很难调试。相关的另一个缺点是，JavaBean模式阻止了把类变为“不可变”（Item15）的可能性，而且要求程序员付出额外努力来保证线程安全。
有一种办法可以降低这个缺点：当对象构建完成后，手工“冻结”该对象，并且不允许使用未冻结的对象。不过这种方法不灵便，在实践中很少使用。更重要的是，由于编译器不能确保程序员在使用对象前先调用其冻结方法，所以这种方法可能导致运行时错误。
幸运的是，还有第三种方法结合了telescoping constructor模式的安全性以及JavaBeans模式的可读性。这是Builder模式的一种形式。客户端并不直接构造需要的对象，而是先调用一个包含所有必选参数的构造函数（或静态工厂），得到一个builder object；然后，客户端在该builder object上调用类似setter的方法来设置各个感兴趣的可选参数；最后，客户端调用无参数的build方法生成对象（不可变对象）。——build相当于冻结方法
builder是所要构建的类的一个静态成员类（Item22）。【例】如下是它的示例：
//Builder Pattern
public class NutritionFacts{
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public static class Builder{
//必选参数
private final int servingSize;
private final int servings;
//可选参数
private final int calories = 0;
private final int fat = 0;
private final int carbohydrate = 0;
private final int sodium = 0;
//Builder构造函数设置所有必选参数
public Builder(int servingSize, int servings){
this.servingSize = servingSize;
this.servings = servings;
}
//Builder类setter方法设置可选参数
public Builder calories(int v){
this.calories = v;
return this;
}
public Builder fat(int v){
this.fat = v;
return this;
}
public Builder carbohydrate(int v){
this.carbohydrate = v;
return this;
}
public Builder sodium(int v){
this.sodium = v;
return this;
}
//builde()返回需要构建的对象
public NutritionFacts build(){
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder){
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate= builder.carbohydrate;
}
} 注意，NutritionFacts是不可变的（未提供setter方法），并且所有的参数值得默认值都放在一个地方。builder的setter方法返回builder自身，所以setter的调用可以链接起来。客户端代码就像下面这样：
NutritionFacts coca = new NutritionFacts.Builder(240,8) .calories(100).sodium(35).build();
这种客户端代码易于编写，而且更重要的是易于阅读。Builder模式模拟了Ada和Python中的具名可选方法（named optional parameters）。
web.xml配置:
struts.xml配置:
1 and 和where的滥用 用的时候 请多注意
下面的三段代码的效果肯定是不一样的
(1) select A.a1 ,B.b3
from A left join B
on A.a2=B.b2
where A.a3=1
and B.b3=2
先左关联后 在过滤 假如关联的结果里面B.b3=null 那么 你在where后面在加B.b3=2 那么结果中B.b3肯定是没有null的情况的
(2) select A.a1 ,B.b3
from A left join B
on A.a2=B.b2
and B.b3=2
where A.a3=1
关联前 先过掉B的b3=2的条件 然后再左关联起来 那么这个结果可能B.a3会有null的情况的
(3) select A.a1 ,B.b3
from A left join B
on A.a2=B.b2
and B.b3=2
and A.a3=1 关联前 先过掉B中的B3=2和A中的a3=1条件 然后再关联起来 那么这个结果可能B.b3会有null的情况的
所以大家在用where 和and 的时候 放的位置 请多注意了
2 用+进行左关联 缺陷 也许可以有解决方案 待后续
(1) select A.a1 ,B.b3
from A , B
where A.a2=B.b2(+)
and A.a3(+)=1
and B.b3(+)=2
这个 条件 应该是 和 1里面的(1)的情况一样
先左关联后 在过滤 假如关联的结果里面B.b3=null 那么 你在where后面在加B.b3=2 那么结果中B.b3肯定是没有null的情况的
也就是说 用+进行左关联没有用left join 灵活 待后续看是否有什么好的解决方案