【代码整洁之道】第十章:类

第十章 类

  要将注意力放到代码组织的更高层面,才能得到更整洁的代码。

 

10.1   类的组织

  遵循标准的 Java 约定,类应该从一组变量列表开始。先是公共静态变量,然后是私有静态变量,以及私有实体变量。很少会有公共变量。

  公共函数应跟在变量列表之后,公共函数调用的私有工具函数紧随在该公有函数后面。这符合自顶向下原则。

  

 

10.2   类应该短小

在设计类时,第一条规则就是类应该短小

  对于函数,通过计算代码行数来衡量大小。对于类,采用不同的衡量方法,计算权责。

  类的名称应当描述其权责。实际上,命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称,这个类就太长了。类名越含混,该类越偶可能拥有过多权责。

 

10.2.1    单一权责原则

单一权责原则(SRP)认为,类或模块应有且只有一条加以修改的理由。

  系统应该由许多短小的类组成,而不是少量巨大的类组成。每个小类封装一个权责,只有一个修改的原因,并与少量其他类一起协同,从而达成期望的系统行为。

 

10.2.2    内聚

  类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言,方法操作的变量越多,就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性。

  一般来说,创建这种极大化内聚类是既不可取也不可能的;另一方面,我们希望内聚性保持在较高位置。内聚性高,意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。

  保持函数和参数列表短小的策略,有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时,往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中,让新的类更为内聚。

 

10.2.3    保持内聚性就会得到许多短小的类

  当类丧失了内聚性,就拆分它!

  将大函数拆分成许多小函数,往往也是将类拆分为多个小类的时机。程序会更加有组织,也会拥有更为透明的结构。

  重构后的程序更长的原因:其一,重构后的程序采用了更长、更有描述性的变量名。其二,重构后的程序将函数和类声明当作是给代码添加注释的一种手段。其三,我们采用了空格和格式技巧让程序更可读。

 

10.3   为了修改而组织

  开放-闭合原则(OCP):类应当对扩展开放,对修改封闭。

  依赖倒置原则(DIP),类应当依赖于抽象,而不是依赖于具体细节。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值