add

Signed-off-by: maskleo <[email protected]>

Author: maskleo

Diff for: ch08/02_Use_Checked_Collections_to_Enforce_Security.md

@@ -0,0 +1,82 @@
+## 使用选中的集合来强化安全性
+
+请注意，通用类型提供的保证仅适用于没有未经检查的警告的情况。 这意味着泛型类型对于确保其他人编写的代码的安全性没有用处，因为您无法知道该代码是否在编译时引发未经检查的警告。
+
+假设我们有一个定义订单的类，并且定义了一个经过验证的订单：
+
+```java
+   class Order { ... }
+   class AuthenticatedOrder extends Order { ... }
+```
+
+接口指定订单的供应商和处理商。 在这里，供应商只需提供经过认证的订单，而处理器则处理各种订单：
+
+```java
+   interface OrderSupplier {
+     public void addOrders(List<AuthenticatedOrder> orders);
+   }
+   interface OrderProcessor {
+     public void processOrders(List<? extends Order> orders);
+   }
+```
+
+从涉及的类型中，您可能会认为以下代理保证只有经过验证的订单可以从供应商传递到处理器：
+
+```java
+   class NaiveBroker {
+     public void connect(OrderSupplier supplier, OrderProcessor processor) {
+       List<AuthenticatedOrder> orders =
+       new ArrayList<AuthenticatedOrder>();
+       supplier.addOrders(orders);
+       processor.processOrders(orders);
+     }
+   }
+```
+
+但是一个狡猾的供应商实际上可能会提供未经认证的订单：
+
+```java
+   class DeviousSupplier implements OrderSupplier {
+     public void addOrders(List<AuthenticatedOrder> orders) {
+       List raw = orders;
+       Order order = new Order(); // not authenticated
+       raw.add(order); // unchecked call
+     }
+   }
+```
+
+编译这个狡猾的供应商会发出一个未经检查的警告，但是经纪人无法知道这一点。
+
+无能可能导致与迂回一样多的问题。 编译时发出未经检查的警告的任何代码都可能导致类似的问题，可能仅仅是因为作者犯了一个错误。 特别是，如前一节所述，遗留代码可能会引发这样的问题。
+
+正确的解决方案是让经纪人将检查清单传递给供应商：
+
+```java
+   class WaryBroker {
+     public void connect(OrderSupplier supplier, OrderProcessor processor) {
+       List<AuthenticatedOrder> orders = new ArrayList<AuthenticatedOrder>();
+       supplier.addOrders(Collections.checkedList(orders, AuthenticatedOrder.class));
+       processor.processOrders(orders);
+     }
+   }
+```
+
+现在，如果供应商尝试将任何内容添加到非认证订单的列表中，则会引发类别强制异常。
+
+选中的集合不是实施安全性的唯一技术。 如果提供订单的接口返回一个列表而不是接受一个列表，那么代理可以使用前一节中的空循环技术来确保列表只包含经过授权的订单，然后才能通过它们。 也可以使用专业化，如下一节所述，创建一个特殊类型的列表，只能包含授权订单。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+