如何思考面向对象

在学习了面向对象的语言，比如Java、Python和Ruby之后，看起来每个人都觉得自己在进行面向对象的编码。但是如果你仔细审视一下代码，你就会发现还是无意识地使用了很多过程语句。



静态方法



静态方法是最天然的过程方法，它和面向对象没有一点关系。好吧，我已经听见质疑的尖叫了，那么，我就来给你解释一下为什么。首先我们可以达成一个共识，全局变量和全局状态是魔鬼。如果你觉得前面说的静态方法的话会没什么可争论的，那好，我认为静态方法就应该返回一个常量，因为没有全局状态量（时间和随机数，这些都是全局状态量，所以不能算进去的，对象必须有不同的实例，但是对象图的连线是一致的）。



这就意味着静态方法要做什么有价值的事情的话，就必须要有参数的传入了。但是那样的话，我又会啰嗦一句，这样的方法应该简单地属于其中的某一个参数。举例来说，Math.abs(-3) 应该写成-3.abs()。实际上，并不是说-3非得是一个对象，但是有的编译器可认可这件事情，比如Ruby。如果你有一堆参数的话，不妨选择一个对方法影响最大的参数来做这个方法的调用者。



给静态方法一个最公正的定义：工具方法。假使你想要按照骆驼命名法来将“my_workspace”转成“myWorkspace”，那么绝大多数开发者会完成一个类似这样的方法来解决这个问题：StringUtil.toCamelCase(“my_workspace”)。但是，还是那句话，我可以给String类定义一个方法，方法调用变成了这样：“my_workspace”.toCamelCase()。当然了，在Java里面我们无法随意扩展String这个类，但是很多面向对象的语言是允许我们做到这一点的。



最后，我有时候（一年有几次吧）会因为语言的局限被迫写静态方法，但是静态方法实在是很难做单元测试，所以我尽量不用它。我发现在大多数项目中，静态方法的使用是很难得到合理控制的。



实例方法



现在你摆脱了这些静态方法，可是你的代码还是面向过程的。面向对象要求行为和数据是放在一起的。所以如果一个人不去理解代码的实际意义，就可以评估出代码是做什么的，那么通常他是看了行为和数据之间的关系。


Java代码  收藏代码

    class Database { 
      // some fields declared here 
      boolean isDirty(Cache cache, Object obj) { 
        for (Object cachedObj : cache.getObjects) { 
          if (cachedObj.equals(obj)) 
            return false; 
        } 
        return true; 
      } 
    } 





这段代码的问题在于，方法完全可以定义成是静态的！而且这个方法放错位置了，因为你可以看到，方法内部并未和Database这个类的对象做交互，而是使用getObjects()来和cache做交互。我觉得这个方法应该放在类似于一个“Cache”的类里面。那样的话，Cache类就不需要这个getObjects()方法了，因为这个for循环可以放到Cache内部去，Cache的状态量可以在方法内直接获取到了。嘿，我们这样做，简化了代码（移动了一下方法的位置，删除了一些多余的方法），皆大欢喜，多好。



有意思的是，getter方法经常意味着，你把数据放到这个类的外面去处理了（译注：参见这篇文章）。换句话说，方法和数据没有放在一起。


Java代码  收藏代码

    class Authenticator { 
      Ldap ldap; 
      Cookie login(User user) { 
        if (user.isSuperUser()) { 
          if ( ldap.auth(user.getUser(), 
                 user.getPassword()) ) 
            return new Cookie(user.getActingAsUser()); 
        } else (user.isAgent) { 
            return new Cookie(user.getActingAsUser()); 
        } else { 
          if ( ldap.auth(user.getUser(), 
                 user.getPassword()) ) 
            return new Cookie(user.getUser()); 
        } 
        return null; 
      } 
    } 



我不知道这段代码写得好不好，但是我很确定它的login()方法很喜欢user对象，它和user的交互大过和它自己内部状态量的交互，现在它看起来就像一个无名的数据仓库。我再说一遍，它违背了方法要和数据放在一起的原则。我觉得方法应该放在一个和它自己交互最多的地方，在这里，就是User类的对象中。现在我改成这样：


Java代码  收藏代码

    class User { 
      String user; 
      String password; 
      boolean isAgent; 
      boolean isSuperUser; 
      String actingAsUser; 
     
      Cookie login(Ldap ldap) { 
        if (isSuperUser) { 
          if ( ldap.auth(user, password) ) 
            return new Cookie(actingAsUser); 
        } else (isAgent) { 
            return new Cookie(actingAsUser); 
        } else { 
          if ( ldap.auth(user, password) ) 
            return new Cookie(user); 
        } 
        return null; 
      } 
    } 



好，我们取得了一些进展，可以注意到那些getter方法不见了（这个例子最终是要让Authenticator类消失掉），但是还有一些问题存在，这就是一堆“if”分支。我觉得Authenticator里的if (user.isSuperUser())这个判断带来了冗余，这样会要求重构后的代码增加一个isSuperUser这样的状态量。我现在一见到这样的标志量，我就知道，这里可以用多态的方式来优化：



Java代码  收藏代码

    class User { 
      String user; 
      String password; 
     
      Cookie login(Ldap ldap) { 
        if ( ldap.auth(user, password) ) 
          return new Cookie(user); 
        return null; 
      } 
    } 
     
    class SuperUser extends User { 
      String actingAsUser; 
     
      Cookie login(Ldap ldap) { 
        if ( ldap.auth(user, password) ) 
          return new Cookie(actingAsUser); 
        return null; 
      } 
    } 
     
    class AgentUser extends User { 
      String actingAsUser; 
     
      Cookie login(Ldap ldap) { 
        return new Cookie(actingAsUser); 
      } 
    } 

现在我们利用了多态，每个不同的User对象知道怎么去login，并且我们很容易就可以扩展一个新的用户类型到系统中。还可以看到，那些用来控制给予User不同行为的标志位都消失了，那一堆if分支也消失了。



现在来看看这样的问题：User对象应该知道Ldap吗？实际这里存在有两个问题：

（1）User应该具备一个引用类型的属性Ldap吗？

（2）User应该在编译期就和Ldap建立依赖关系吗？



关于第一个问题，回答是：不。因为你可能想把user序列化到数据库中，但是却不想把Ldap序列化到数据库中。看这里。



关于第二个问题，这就比较复杂了。总的来说，回答取决于你是否打算在不同的工程中重用User对象，因为编译期依赖在强类型语言中是过渡性质的。我的经验是每个人都想写某天可以重用的代码，但是那一天从未到来，并且那么做的人会陷入代码的纠缠之中，所以在实际需要重用之前，不要太过考虑这件事情（开发一个可重用的库另说）。我持有这样一个观点，有很多人为“假如”付出了太多的代价，但是并没有从“假如”中获益，所以，不要太过担心User对Ldap的依赖问题。