effective java

注：本文轉載於http://www.cnblogs.com/xing901022/p/5854506.html，感謝xingoo！

effective java 經過函數來做爲策略

經過函數做爲策略有兩個要注意的地方：

• 使用接口做爲策略傳入
• 若是長期調用，應該設置爲靜態內部類，避免頻繁建立過多的匿名對象

下面舉個簡單的例子，針對Engineer類提供不一樣的策略作排序，好比按照年齡或者按照員工級別：

class Engineer{
   private String name;
   private int age;
   private int level;
   public Engineer(String name,int age,int level) {
       this.name = name;
       this.age = age;
       this.level = level;
   }
   public String getName() {
       return name;
   }
   public void setName(String name) {
       this.name = name;
   }
   public int getAge() {
       return age;
   }
   public void setAge(int age) {
       this.age = age;
   }
   public int getLevel() {
       return level;
   }
   public void setLevel(int level) {
       this.level = level;
   }
 }
public class Strategy {
   public static final Comparator<Engineer> AGE_ORDER = new AgeComparator();
   public static final Comparator<Engineer> LEVEL_ORDER = new LevelComparator();
   private static class AgeComparator implements Comparator<Engineer>{
       @Override
       public int compare(Engineer e1, Engineer e2) {
           return e1.getAge()-e2.getAge();
       }
   }
   private static class LevelComparator implements Comparator<Engineer>{
       @Override
       public int compare(Engineer e1, Engineer e2) {
           return e1.getLevel()-e2.getLevel();
       }
   }
   public static void main(String[] args) {
       List<Engineer> el = new ArrayList<>();
       el.add(new Engineer("zhangsan", 26, 3));
       el.add(new Engineer("lisi", 30, 2));
       el.add(new Engineer("wangwu", 28, 1));
       Collections.sort(el,AGE_ORDER);
       System.out.println(JSON.toJSON(el));
       Collections.sort(el,LEVEL_ORDER);
       System.out.println(JSON.toJSON(el));
   }
 }

在上面的例子中，採用靜態成員變量聲明，能夠在屢次使用的時候節省建立對象的成本。並且靜態成員在堆內存的分配上也更簡單，不會每次都建立新的對象。

在真實的場景中，是在某個請求方法裏面，返回一個List對象，須要對它按照日期排序。若是是普通的Collections.sort(list,new Comparator<xx>{})這種方式，會在每次返回結果的時候，都建立一個匿名類，很顯然會浪費很多內存空間，增長垃圾回收的壓力。使用靜態成員變量的方式，能夠減小這種沒必要要的浪費。

List<?>與List

因爲在1.5以前的版本,java是沒有泛型概念的。所以在引入泛型後，須要考慮到之前代碼的移植。

沒有泛型的時候，若是使用List，能夠往裏面插入任意類型的值。可是在取得時候，若是類型不對就有問題了:

List list = new ArrayList();
list.add(1);

String list0 = list.get(0);//出錯

爲了不這種問題，1.5引入泛型，這樣一套代碼能夠適用於多種類型；還能在編譯器就檢查類型是否一致。

除了這種List<E> xxx標準的泛型，java還提供了無限制性的泛型：

<?>意思是未知類型，就是不設上下限 <? extend Object>意思是繼承於Object的未知類型 <? super Object>意思是Object的祖先類型

因此，儘可能使用標準的格式，在某些狀況下已知的一些通配限制，還可使用_<?>號加以限制。

記得最開始本身寫代碼的時候，滿滿的都是黃色標記，師兄就糾正個人作法，讓我把這些警告全都去掉。其實隨時保證沒有警告的代碼，纔是最負責的作法。不論是本身屏蔽掉，仍是作相應的解決，都好過編譯的時候爆出一大堆警告好。

編譯器警告

Java是一門編譯型的語言，須要通過編譯，變成class字節碼才能執行。可是在編寫泛型相關的代碼時，老是會遇到一些警告。好比參數僅僅聲明爲Map，沒有聲明具體內部的內容等等。

在Eclipse中能夠經過加入_{@SuppressWarning}註解來忽略警告，可是不推薦這種作法。除非你對本身的代碼很是自信，保證不會出現其餘的類型，而致使ClassCastException。因此儘可能在寫代碼的時候不要產生警告，若是想要忽略，儘可能考慮清楚入口出口是否不會出現意外。

經常使用的就是_unckecked和_rawtypes，一個是不檢查內部變量，一個是不檢查參數類型。

warngings

all to suppress all warnings boxing to suppress warnings relative to boxing/unboxing operations cast to suppress warnings relative to cast operations dep-ann to suppress warnings relative to deprecated annotation deprecation to suppress warnings relative to deprecation fallthrough to suppress warnings relative to missing breaks in switch statements finally to suppress warnings relative to finally block that don’t return hiding to suppress warnings relative to locals that hide variable incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case) nls to suppress warnings relative to non-nls string literals null to suppress warnings relative to null analysis rawtypes to suppress warnings relative to un-specific types when using generics on class params restriction to suppress warnings relative to usage of discouraged or forbidden references serial to suppress warnings relative to missing serialVersionUID field for a serializable class static-access to suppress warnings relative to incorrect static access synthetic-access to suppress warnings relative to unoptimized access from inner classes unchecked to suppress warnings relative to unchecked operations unqualified-field-access to suppress warnings relative to field access unqualified unused to suppress warnings relative to unused code

什麼是同比和環比

作業務需求，仍是須要了解些業務知識才行。不管是電商環境，仍是傳統企業，環比和同比是最多見的數據分析手段，能夠經過對比明顯的看到當前業務的變化趨勢，有利於管理層即便作出調整，那麼什麼是環比，什麼是同比呢？

• 環比就是如今的統計週期和上一個統計週期比較。
• 同比是與歷史時期做比較。

舉個例子：

• 2016年4月和2016年的3月相比，就是環比
• 2016年的10月和2015年的10月相比，就是同比

太業務化的東西，就不說了，省得設計到什麼尷尬的信息。

睡覺時間到，養好精神，才能專一...