Java和Ceylon对象的构造和验证

澳门新葡亰网站注册 1

本文由码农网 –
civic5216原创翻译,转载请看清文末的转载要求,欢迎参与我们的付费投稿计划!

三十八、检查参数的有效性:

当变换Java代码为Ceylon代码时,有时候我会遇到一些Java类构造器混淆了验证与初始化的情形。让我们使用一个简单但是人为的代码例子来说明我想阐述的意思。

     
绝大多数方法和构造器对于传递给它们的参数值都会有些限制。比如,索引值必须大于等于0,且不能超过其最大值,对象不能为null等。这样就可以在导致错误的源头将错误捕获,从而避免了该错误被延续到今后的某一时刻再被引发,这样就是加大了错误追查的难度。就如同编译期能够报出的错误总比在运行时才发现要更好一些。事实上,我们不仅仅需要在函数的内部开始出进行这些通用的参数有效性检查,还需要在函数的文档中给予明确的说明,如在参数非法的情况下,会抛出那些异常,或导致函数返回哪些错误值等,见如下代码示例:

澳门新葡亰网站注册 1

 1     /**
 2      * Returns a BigInteger whose value is(this mod m). This method
 3      * differs from the remainder method in that it always returns a
 4      * non-negative BigInteger.
 5      * @param m the modulus, which must be positive.
 6      * @return this mod m.
 7      * @throws ArithmeticException if m is less than or equal to 0.
 8 */
 9      public BigInteger mod(BigInteger m) {
10          if (m.signum() <= 0)
11              throw new ArithmeticException("Modulus <= 0: " + m);
12          ... //Do the computation.
13      }

一些坏代码

考虑下面的Java类。(伙计,不要在家里写这样的代码)

public class Period {
    private final Date startDate;
    private final Date endDate;
    //returns null if the given String
    //does not represent a valid Date
    private Date parseDate(String date) {
       ...
    }
    public Period(String start, String end) {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public boolean isValid() {
        return startDate!=null && endDate!=null;
    }
    public Date getStartDate() {
        if (startDate==null) 
            throw new IllegalStateException();
        return startDate;
    }
    public Date getEndDate() {
        if (endDate==null)
            throw new IllegalStateException();
        return endDate;
    }
}

嘿,我之前已经警告过,它是人为的。但是,在实际Java代码中找个像这样的东西实际上并非不常见。

这里的问题在于,即使输入参数(在隐藏的parseDate()方法中)的验证失败了,我们还是会获得一个Period的实例。但是我们获取的那个Period不是一个“有效的”状态。严格地说,我的意思是什么呢?

好吧,假如一个对象不能有意义地响应公用操作时,我会说它处于一个非有效状态。在这个例子里,getStartDate()
和getEndDate()会抛出一个IllegalStateException异常,这就是我认为不是“有意义的”一种情况。

从另外一方面来看这个例子,在设计Period时,我们这儿出现了类型安全的失败。未检查的异常代表了类型系统中的一个“漏洞”。因此,一个更好的Period的类型安全的设计,会是一个不使用未检查的异常—在这个例子中意味着不抛出IllegalStateException异常。

(实际上,在真实代码中,我更有可能遇到一个getStartDate() 方法它不检查null ,在这个代码行之后就会导致一个NullPointerException异常,这就更加糟糕了。)

我们能够很容易地转换上面的Period类成为Ceylon形式的类:

shared class Period(String start, String end) {
    //returns null if the given String
    //does not represent a valid Date
    Date? parseDate(String date) => ... ;
    value maybeStartDate = parseDate(start);
    value maybeEndDate = parseDate(end);
    shared Boolean valid
        => maybeStartDate exists 
        && maybeEndDate exists;
    shared Date startDate {
        assert (exists maybeStartDate);
        return maybeStartDate;
    }
    shared Date endDate {
        assert (exists maybeEndDate);
        return maybeEndDate;
    }
}

澳门新葡亰网站注册,当然了,这段代码也会遇到与原始Java代码同样的问题。两个assert符号冲着我们大喊,在代码的类型安全中有一个问题。

      
是不是我们为所有的方法均需要做出这样的有效性检查呢?对于未被导出的方法,如包方法等,你可以控制这个方法将在哪些情况下被调用,因此这时可以使用断言来帮助进行参数的有效性检查,如:

使Java代码变得更好

Java里我们怎么改进这段代码呢?好吧,这儿就是一个例子关于Java饱受诟病的已检查异常会是一个非常合理的解决方法!我们可以稍微修改下Period来从它的构造器中抛出一个已检查的异常:

public class Period {
    private final Date startDate;
    private final Date endDate;
    //throws if the given String
    //does not represent a valid Date
    private Date parseDate(String date)
            throws DateFormatException {
       ...
    }
    public Period(String start, String end) 
            throws DateFormatException {
        startDate = parseDate(start);
        endDate = parseDate(end);
    }
    public Date getStartDate() {
        return startDate;
    }
    public Date getEndDate() {
        return endDate;
    }
}

现在,使用这个解决方案,我们就不会获取一个处于非有效状态的Period,实例化Period的代码会由编译器负责去处理无效输入的情形,它会捕获一个DateFormatException异常。

try {
    Period p = new Period(start, end);
    ...
}
catch (DateFormatException dfe) {
    ...
}

这是一个对已检查异常不错的、完美的、正确的使用,不幸的是我几乎很少看到Java代码像上面这样使用已检查异常。

1      private static void sort(long a[],int offset,int length) {
2          assert(a != null);
3          assert(offset >= 0 && offset <= a.length);
4          assert(length >= 0 && length <= a.length - offset);
5          ... //Do the computation
6      }

使Ceylon代码变得更好

那么Ceylon怎么样呢?Ceylon没有已检查异常,因而我们需要寻找一个不同的解决方式。典型地,在Java调用一个函数会抛出一个已检查异常的情形中,Ceylon会调用函数返回一个联合类型。因为,一个类的初始化不返回除了类自己外的任何类型,我们需要提取一些混合的初始化/验证的逻辑来使其成为一个工厂函数。

//returns DateFormatError if the given 
//String does not represent a valid Date
Date|DateFormatError parseDate(String date) => ... ;
shared Period|DateFormatError parsePeriod
        (String start, String end) {
    value startDate = parseDate(start);
    if (is DateFormatError startDate) {
        return startDate;
    }
    value endDate = parseDate(end);
    if (is DateFormatError endDate)  {
        return endDate;
    }
    return Period(startDate, endDate);
}
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

根据类型系统,调用者有义务去处理DateFormatError:

value p = parsePeriod(start, end);
if (is DateFormatError p) {
    ...
}
else {
    ...
}

或者,如果我们不关心给定日期格式的实际问题(这是有可能的,假定我们工作的初始化代码丢失了那个信息),我们可以使用Null而不是DateFormatError:

//returns null if the given String 
//does not represent a valid Date
Date? parseDate(String date) => ... ;
shared Period? parsePeriod(String start, String end)
    => if (exists startDate = parseDate(start), 
           exists endDate = parseDate(end))
       then Period(startDate, endDate)
       else null;
shared class Period(startDate, endDate) {
    shared Date startDate;
    shared Date endDate;
}

至少可以说,使用工厂函数的方法是优秀的,因为通常来说在验证逻辑和对象初始化之间它具有更好的隔离。这点在Ceylon中特别有用,在Ceylon中,编译器在对象初始化逻辑中添加了一些非常严厉的限制,以保证对象的所有领域仅被赋值一次。

      
和通用的检查方式不同,断言在其条件为真时,无论外部包得客户端如何使用它。断言都将抛出AssertionError。它们之间的另一个差异在于如果断言没有起到作用,即-ea命令行参数没有传递给java解释器,断言将不会有任何开销,这样我们就可以在调试期间加入该命令行参数,在发布时去掉该命令行选项,而我们的代码则不需要任何改动。
      
需要强调的是,对于有些函数的参数,其在当前函数内并不使用,而是留给该类其他函数内部使用的,比较明显的就是类的构造函数,构造函数中的很多参数都不一样用于构造器内,只是在构造的时候进行有些赋值操作,而这些参数的真正使用者是该类的其他函数,对于这种情况,我们就更需要在构造的时候进行参数的有效性检查,否则一旦将该问题释放到域函数的时候,再追查该问题的根源,将不得不付出更大的代价和更多的调试时间。
      
对该条目的说法确实存在着一种例外情况,在有些情况下有效性检查工作的开销是非常大的,或者根本不切实际,因为这些检查已经隐含在计算过程中完成了,如Collections.sort(List),容器中对象的所有比较操作均在该函数执行时完成,一旦比较操作失败将会抛出ClassCastException异常。因此对于sort来讲,如果我们提前做出有效性检查将是毫无意义的。
    
三十九、必要时进行保护性拷贝:

     
如果你的对象没有做很好的隔离,那么对于调用者而言,则有机会破坏该对象的内部约束条件,因此我们需要保护性的设计程序。该破坏行为一般由两种情况引起,首先就是恶心的破坏,再有就是调用者无意识的误用,这两种条件下均有可能给你的类带来一定的破坏性,见如下代码:

 1     public final class Period {
 2         private final Date start;
 3         private final Date end;
 4         public Period(Date start,Date end) {
 5             if (start.compareTo(end) > 0) {
 6                 throw new IllegalArgumentException(start + "After " + end);
 7             this.start = start;
 8             this.end = end;
 9         }
10         public Date start() {
11             return start;
12         }
13         public Date end() {
14             return end;
15         }
16     }

     
从表面上看,该类的实现确实对约束性的条件进行了验证,然而由于Date类本身是可变了,因此很容易违反这个约束,见如下代码:

1     public void testPeriod() {
2         Date start = new Date();
3         Date end = new Date();
4         Period p = new Period(start,end);
5         end.setYear(78);  //该修改将直接影响Period内部的end对象。
6     }

     
为了避免这样的攻击,我们需要对Period的构造函数进行相应的修改,即对每个可变参数进行保护性拷贝。

1     public Period(Date start,Date end) {
2         this.start = new Date(start.getTime());
3         this.end = new Date(end.getTime());
4         if (start.compareTo(end) > 0) {
5             throw new IllegalArgumentException(start + "After " + end);
6     }

     
需要说明的是,保护性拷贝是在坚持参数有效性之前进行的,并且有效性检查是针对拷贝之后的对象,而不是针对原始对象的。这主要是为了避免在this.start
= new Date(start.getTime())到if (start.compareTo(end) >
0)这个时间窗口内,参数start和end可能会被其他线程修改。
     
现在构造函数已经安全了,后面我们需要用同样的方式继续修改另外两个对象访问函数。

1     public Date start() {
2         return new Date(start.getTime());
3     }
4     public Date end() {
5         return new Date(end.getTime());
6     }

     
经过这一番修改之后,Period成为了不可变类,其内部的“周期的起始时间不能落后于结束时间”约束条件也不会再被破坏。
     
参数的保护性拷贝并不仅仅针对不可变类。每当编写方法或者构造器时,如果它要允许客户提供的对象进入到内部数据结构中,则有必要考虑一下,客户提供的对象进入到内部数据结构中,则有必要考虑一下,客户提供的对象是否有可能是可变的。如果是,就要考虑你的类是否能够容忍对象进入数据结构之后发生变化。如果答案是否定的,就必须对该对象进行保护性拷贝,并且让拷贝之后的对象而不是原始对象进入到数据结构中。例如,如果你正在考虑使用有客户提供的对象引用作为内部Set实例的元素,或者作为内部Map实例的键(Key),就应该意识到,如果这个对象在插入之后再被修改,Set或者Map的约束条件就会遭到破坏。
    
四十一、谨慎重载:

      见下面一个函数重载的例子:

 1     public class CollectionClassfier {
 2         public static String classify(Set<?> s) {
 3             return "Set";
 4         }
 5         public static String classify(List<?> l) {
 6             return "List";
 7         }
 8         public static String classify(Collection<?> c) {
 9             return "Unknown collection";
10         }
11         public static void main(String[] args) {
12             Collection<?>[] collections = {
13                 new HashSet<String>(),
14                 new ArrayList<BigInteger>(),
15                 new HashMap<String,String>().values()
16             };
17             for (Collection<?> c : collections)
18                 System.out.println(classify(c));
19         }
20     }

      这里你可能会期望程序打印出
      //Set
      //List
      //Unknown Collection
      然而实际上却不是这样,输出的结果是3个”Unknown
Collection”。为什么会是这样呢?因为函数重载后,需要调用哪个函数是在编译期决定的,这不同于多态的运行时动态绑定。针对此种情形,该条目给出了一个修正的方法,如下:

1     public static String classify(Collection<?> c) {
2         return c instanceof Set ? "Set" : c instanceof List 
3             ? "List" : "Unknown Collection";
4     }

     
和override不同,重载机制不会像override那样规范,并且每次都能得到期望的结果。因此在使用时需要非常谨慎,否则一旦出了问题,就会需要更多的时间去调试。该条目给出以下几种尽量不要使用重载的情形:
      1.    函数的参数中包含可变参数;
      2.  
 当函数参数数目相同时,你无法准确的确定哪一个方法该被调用时;
      3.    在Java 1.5 之后,需要对自动装箱机制保持警惕。
     
我们先简单说一下第二种情形。比如两个重载函数均有一个参数,其中一个是整型,另一个是Collection<?>,对于这种情况,int和Collection<?>之间没有任何关联,也无法在两者之间做任何的类型转换,否则将会抛出ClassCastException的异常,因此对于这种函数重载,我们是可以准确确定的。反之,如果两个参数分别是int和short,他们之间的差异就不是这么明显。
      对于第三种情形,该条目给出了一个非常典型的用例代码,如下:

 1     public class SetList {
 2         public static void main(String[] args) {
 3             Set<Integer> s = new TreeSet<Integer>();
 4             List<Integer> l = new ArrayList<Integer>();
 5             for (int i = -3; i < 3; ++i) {
 6                 s.add(i);
 7                 l.add(i);
 8             }
 9             for (int i = 0; i < 3; ++i) {
10                 s.remove(i);
11                 l.remove(i);
12             }
13             System.out.println(s + " " + l);
14         }
15     }