8 接口字段
接口的字段都自動 static final ，是以成為了建立一組常量的友善工具。
在 Java 5 之前，這是産生與 C 或 C++ 中的 enum (枚舉類型) 具有相同效果的唯一方式。是以你可能在 Java 5 之前的代碼中看到
自 Java 5 開始，我們有了更加強大和靈活的關鍵字 enum，那麼在接口中定義常量組就顯得沒什麼意義了。然而當你閱讀遺留的代碼時，在很多場合你還會碰到這種舊的習慣用法。
8.1 初始化接口中的字段
接口中定義的字段不能是“空 final”，但是可以用非常量表達式初始化。
因為字段是 static 的，是以它們在類第一次被加載時初始化，這發生在任何字段首次被通路時。
這些字段不是接口的一部分，它們的值被存儲在接口的靜态存儲區域中。
9 接口嵌套
接口可以嵌套在類或其他接口中。
在類中嵌套接口就像非嵌套接口一樣，具有 public 或包通路權限的可見性。
作為一種新添加的方式，接口也可以是 private 的，例如 A.D（同樣的文法同時适用于嵌套接口和嵌套類）。
但 private 嵌套接口有什麼好處呢？
你可能猜測它隻是被用來實作一個 private 内部類，實作 private 接口是一種可以強制該接口中的方法定義不會添加任何類型資訊（即不可以向上轉型）的方式。
接口中的元素必須是 public 的——是以嵌套在另一個接口中的接口自動就是 public 的
不能指明為 private
當實作某個接口時，并不需要實作嵌套在其内部的接口。
同時，private 接口不能在定義它的類之外被實作。
添加這些特性的最初原因看起來像是出于對嚴格的文法一緻性的考慮，但是我通常認為，一旦你了解了某種特性，就總能找到其用武之地。
10 接口和工廠方法模式
接口是多實作的途徑，而生成符合某個接口的對象的典型方式是工廠方法設計模式。
不同于直接調用構造器，隻需調用工廠對象中的建立方法就能生成對象的實作——理論上，通過這種方式可以将接口與實作的代碼完全分離，使得可以透明地将某個實作替換為另一個實作。
如果沒有工廠方法，代碼就必須在某處指定将要建立的 Service 的确切類型，進而調用恰當的構造器。
為什麼要添加額外的間接層呢？一個常見的原因是建立架構。
11 總結
認為接口是好的選擇，進而使用接口不用具體類，這具有誘惑性。幾乎任何時候，建立類都可以替代為建立一個接口和一個工廠。
很多人都掉進了這個陷阱，隻要有可能就建立接口和工廠。這種邏輯看起來像是可能會使用不同的實作，是以總是添加這種抽象性。這變成了一種過早的設計優化。
任何抽象性都應該是由真正的需求驅動的。當有必要時才應該使用接口進行重構，而不是到處添加額外的間接層，進而帶來額外的複雜性。這種複雜性非常顯著，如果你讓某人去處理這種複雜性，隻是因為你意識到“以防萬一”而添加新接口，而沒有其他具有說服力的原因——好吧，如果我碰上了這種設計，就會質疑此人所作的所有其他設計了。
恰當的原則
優先使用類而不是接口。從類開始，如果使用接口的必要性變得很明确，那麼就重構。
接口是一個偉大的工具，但它們容易被濫用。
往期推薦
程式員删庫跑路?教你打造高可用的MySQL
從JVM 源碼看init和clinit到底什麼差別
使用SpringCloud三年,才知道@EnableEurekaServer注解到底有什麼用
Netty源碼面試解析實戰（一）- 引導篇
http://mp.weixin.qq.com/s?__biz=MzUzNTY5MzA3MQ%3D%3D&chksm=fa80d67bcdf75f6dbb88642a1d56a315568a4dd6468482a9df448a88bf048b5f10c2bf00987e&idx=1&mid=2247484443&scene=21&sn=20db2cdcc0cfe47d98ee56ba1faf5680#wechat_redirect