Monthly Archives:: 四月 2010

最近几乎天天加班，周末依然加班，好久没有更新博客了，非常累。不过此累非彼类。 在现有的很多面向过程开发的代码中，对我这个涉世不深的玩家来说，简直就是灾难，或许很多代码连面向过程都算不上，连函数都没有包装。一个函数可能会超过500行代码，语义不名，名称更不名。我曾经试图改造这些代码，并非技术上不可行，而是实现需要太多的时间，一个不可能完成的任务。 让一个缺乏面向对象的团队掌握面向对象很困难的，也许是我智商低，当年我花了两个月才能意会什么是对象，什么是面向对象编程，到现在也不会言传。 如果不能转向到面向对象，那么我们先转成类吧，或许技术上更能解决一点。类的最基本功能就是封装，如果我们撇去面向对象的东西，那么类就是把具有相似性的东西做一个集合，外部在使用这些功能的时候不需要知道具体实现，只要给类中的方法确需要的参数值，如果非要理解成一堆具有相似属性函数的集合，那也是可以的，毕竟这个比一个文件中的几千行代码，连个function都没有的代码好得多。 如果我们想得到更好的类，需要遵循一些基本的原则， 其中之一就是类应该短小，短小并不是说不完整，这和很多人学C的时候，老师告诉我们，函数要尽可能短小一样，到底多短小的类算是合适呢？我觉得根本无法用代码行数来描述，这取决于这个类所完成的功能，比如你要封装一个操作文章的类，那么至少需要，增删改查四个函数，也许还有基于这四个函数的别名和封装，以及必要的公共属性。 第二个重要原则就是单一权责（SRP），这个原则要做到非常 不容易，因为比第一条更难衡量，一般认为，衡量单一权责的标准是：类或者模块应该有且只有一条加以修改的理由。SRP实际上能给出控制类长度的指导方针。简单的理解就是一个类只有一个功能，假如你修改博客标题或者设置的时候，都要改动文章类，显然违背了单一权责的原则。 第三个原则–内聚。类应该只有少量实体变量。类中的每个方法都应该操作一个或者多个这种变量。通常而言，方法操作的变量越多，就越内聚到类上，如果一个类中的米一个变量都被每个方法所使用，则该类具有最大的内聚性。通常，创建一个这样极大化的内聚类是非常不容易的，也是不可取的，因为类的内聚性过高也就意味着类中的方法和变量相互依赖，互相结合成一个逻辑的整体，当修改类中的变量或者方法时，可能影响或者需要修改其他的方法或者属性。一般认为，类的内聚应该保持在较高的位置，但不是最高的位置，这样有利于降低维护成本。 前面提到在我目前的项目中，我碰到很多超过500行代码的函数，假如把数字降低到300，那么符合标准的函数将会增加十倍以上，在一个面向对象的团队中，一个单纯函数或者方法超过100行几乎都是不可接受的，因为这意味着这个函数可能包含过多的权责。其实我们如果真的遵循类的内聚和单一权责的原则，就会导致很多短小的类的产生。 一般程序员在拆解过大的函数的时候实际上就是将原来的代码复制出来，放到新建的函数中去，然后把需要的参数传递过去，实际上导致超大函数的产生的动机常常是因为有很多变量在这个函数的中被使用到，看似这个函数似乎是一个整体，因为拆分会导致新建的函数参数很多。为啥他们不想用一下类呢，假如拆解函数导致需要传递很多的参数，那么这个函数其实就是一个类，需要传递的函数需要提升为实体变量，这样就可以将函数拆成很小的小块，这样看起来似乎丧失了内聚性，因为堆积了越来越多的只为允许少量函数共享而存在的实体变量。如果这些函数想要公司向某些变量，为什么不让它拥有自己的类呢？当类丧失了内聚性，就应该拆了它。所以，将大的函数拆分为小函数，旺旺也是将类拆分为多个小类的时机，程序会更加有组织，更为透明的结构。 实际上很多时候，当你完成所有的功能的时候，产品经理会跑过来跟你说，我们不能把这个功能改成这样，这样用户体验更好，很可能你需要改动很多的代码很逻辑，甚至数据结构，所以如果我们能在设计的类的时候，注意一下可能的需求改动，我们可以借助接口或者抽象类来隔离修改细节对原来代码产生的破坏性更改。