爲何說private方法是有罪的

       具體的這句話從什麼地方得到，我已經無從考證了，可是想一想咱們如今使用private的場景，你慢慢的就會發現，private的方法，大多數都是copy代碼，固然我只是說大多數，還有就是大多數private方法其實是設計的不太合理的遺留物。我先說兩個我應用的場景，第一種場景與設計沒有關係，只是與維護系統有關係。

 

       第一種場景：維護系統，擴展系統

       不知道你們有沒有這種場景，須要維護或者擴展一個系統，這個時候，你只能經過繼承某個類來作事情，不能經過修改source來達到目的，而這個時候，你會發現，你真正須要修改的，或者言之，替換的只是一個小小的方法，你只要override這個小方法就能夠，而這個時候，很不幸的是，他是一個private方法，你能怎麼辦呢？只能找到更大範圍的方法來進行override，而後把其它不相關的方法在copy到本身的類裏面，只有這樣才能達到目的。

 

       第二種場景，設計角度，這個是我真正想說的地方。

       你們寫代碼的時候，不少時候，會遵循Refactor裏面的一些原則，會把不少代碼抽成不少小的方法，而這些小的方法每每會是private的方法，這些private方法，大致上能夠分爲兩類，一類是Util方法，一類是業務方法。

       先說第一種Util方法，不少時候，大多數是判斷時間是否合理，String是否爲空，字符是否夠長等等，諸如此類的方法，就是與業務一點關係都沒有的，這種方法，我想不用我說什麼了，你本身應該明白，爲何這些是可恥的了吧，或者有罪了吧。由於這些Util方法不少地方都會用到的，不止這一個地方，這些方法若是是private的話，你會在這個項目裏面不少地方都看到相似的private方法，你們都是copy來，copy去，DRY原則不用重複了。

 

        再說第二種業務方法的，這類我也分爲兩種，A是業務邏輯在錯誤地方，B是模板方法中的流程方法。

         A業務邏輯在錯誤地方

         舉個小例子：

          有個業務邏輯判斷是否能夠賣煙給這我的，一個判斷邏輯就是是否18歲

          

private boolean isCanSale(Person person) {
　　if (person.getAge() < 18) {
    　　return false;
　　}
　　return true;
}

       可是慢慢的你會發現，不少地方都須要這個業務邏輯，好比是否能夠賣酒給這我的，一樣也是如此。那麼這個時候，其實就是這個方法邏輯，放錯了地方，應該屬於Person的屬性。

   

public boolean isAdult() {
　　if (this.getAge() < 18) {
    　　return false;
　　}
　　return true;
}

  在別的地方就會調用person.isAdult()，就能夠了。固然在深刻的講，是否爲成年人，這個其實仍是與地方的法律有關係的，因此後面可能還會把這個方法挪到另外的地方去。

 

     B 模板方法中的流程方法

     就是在模板類中，有不少流程的方法，這些方法寫成了private，例如我以前的例子

   

public abstract class FatherTemplate  {
  public void doProcess() {
    a();
    b();
    c();
  }
    
  private void a() {
     // doSomething();
   };
 
   private void void b(); 

   private void void c();
 }

 這種方法，在未來就會遇到我說的第一種狀況，就是對於擴展和使用會出現不少問題，同時這個地方變成框架中的一部分的時候，也會遇到第一種狀況，對於擴展不是很友好。固然若是說，個人方法，永遠不會擴展，那麼你也會發現，這裏面的方法，也會逐步的挪到其它的類裏面。----沒有繼承使用，那麼就會變成其它類裏面的公開方法，這個是個人判斷。

   private的第一原則，就是永遠不要private