• 面向对象编程(OOP)和函数式编程(FP)的思考


    最近看过不少 JavaScript 的类(实际是嵌套 function),自己也写了一些,发现一个值得思考的问题。

    有的作者可能为了提高一点性能,喜欢有事没事把方法里面的某个变量做成类的字段(attribute)。而实际上,这些变量往往作用域在单个方法内一样工作的很好,就是说从逻辑上讲,是不需要在几个方法之间分享这些变量的。比如:

    function SomeClass(){
        
    var a;
        
    var b;
        
    function Foo(){
            a 
    = 3;
            b 
    = 4;
            
    // 
        }
        
    function Bar(){
            a 
    = 5;
            b 
    = 6;
            
    //
        }
    }

    这样做我认为带来的后果就是增加了不必要的状态信息,如果类似于 Foo, Bar 这样的方法一多起来,则会增加无意中修改字段信息(破坏状态)导致出错的可能性。我阅读这样的代码的时候是很担心的。我宁愿写成这样:

    function SomeClass(){
        
    function Foo(){
            
    var a = 3;
            
    var b = 4;
            
    // 
        }
        
    function Bar(){
            
    var a = 5;
            
    var b = 6;
            
    //
        }
    }

    函数式编程(FP)中一个思想是,函数调用应该没有“副作用”,就是不能依赖于状态,也没法修改状态。这样做的一个好处是每个函数都很容易理解,可读性好。而我们平时用面向对象编程(OOP)用多了,会有一个感觉,有时候看别人的代码真的很不容易理解,特别在没有注释的情况下。经过了重构等技术处理后,一个核心方法你看下去,其中的真实执行步骤可能会分散到无数个分支,其中又有若干对对象状态的依赖,和方法之间的协作等复杂关系,这就导致程序很难理解。

    这么说的目的倒不是否定 OOP, 追捧 FP. 我是觉得可以用这个思想来指导一点我们对类的设计方法。若非必要,不要往类里面塞太多本不该属于它的字段,在不违背 DRY 原则的前提下,尽量限制变量的作用域到一个比较小的范围。这样也许能写出更易理解的程序。

  • 相关阅读:
    javascript中this使用规律
    call和apply的作用和不同
    SVN的标准目录结构:trunk、branches、tags
    SVN 多人修改,如何管理 关于版本的问题
    公司考勤系统项目设计
    CDI Features
    Java Design Pattern
    公司考勤系统设计文件
    spring( history Design Philosophy )
    JSON/xml
  • 原文地址:https://www.cnblogs.com/RChen/p/829755.html
Copyright © 2020-2023  润新知