具体的这句话从什么地方获得，我已经无从考证了，但是想想我们现在使用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