《代码整洁之道》 之第十章 类

要点简介

• （我认为）本节除了实践意义，更重要的是一些理念上的东西,在代码中要有这种思想，是否完全照此处理，估计还是要看编码的情况
• 类最常规的组织方式
• 类的结构以及这样结构的原因
• 进一步的组织类的原则

一、常规组织方式-自定向下原则

1.1 变量

1. 从一组变量列表开始
2. 公共静态常量首先出现
3. 然后是私有静态变量和私有实体变量

1.2 公共函数

1. 公共函数位于变量列表之后
2. 某公共函数调用的私有工具函数紧随在其后面

二、短小的类

2.1 单一权责原则(SRP)-规模衡量原则

关于类的第一条规则是短小，其衡量方法是一个类应该只能有一个权责，同样的他也应该只有一个修改的理由。如代码段10.1里面的版本管理，应该可以再独立出一个类。演变为代码段10.2

代码段10.1
    public class SuperDashboard extends JFrame implements MetaDataUser {

        public Component getLastFocusedComponent()
        public void setLastFocused(Component lastFocused)
        public int getMajorVersionNumber()
        public int getMinorVersionNumber()
        public int getBuildNumber()
    }

代码段10.2
 public class Version {
        public int getMajorVersionNumber();
        public int getMinorVersionNumber();
        public int getBuildNumber();
    }

• 让软件能工作和让软件保持整洁，是两种截然不同的工作。更多地把精力放在前者也是正确的。但是后者其在编程行为中的重要程度等同于在程序中的重要程度。

• 每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者知道到哪儿能找到东西，并且在某个特定时间只需要理解直接有关的复杂性。反之，拥有巨大、多目的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难跋涉。

• 再强调一下：系统应该由许多短小的内不是少量区大的类组成。每一个小类封装一个权责，只有一个修改原因，并与少数其他类一起协同达成期望的系统行为

2.2 内聚

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

• 保持内聚就会形成很多短小的类，请参考书中代码清单10.5里面的例子

2.3 为修改而组织

我们期望通过对类的组织，降低修改带来的风险；
这里参考的原则是开放-封闭原则（OCP），类应当对扩展开放，对修改封闭。
但是需求改变，代码也会变，变化是肯定的，这就需要我们隔离修改。

如果我们构建一个应用依赖于外部的API如Portfolio类，代表投资组合的价值，则测试用例就会收到架子查询的连带影响。那么与其设计一个依赖于具体类，不如创建一个接口。这个接口呈现的是得到某只股票价格的抽象概念。隔离了询价的特定细节。比如价格计算方法，数据来源等。

代码段10.3
public interface StockExchange {
   Money currentPrice(String symbol};
}

代码段10.4
public class Portfolio {
    private StockExchange exchange;
    //这里依赖了抽象的接口
    public Portfolio(StockExchange exchange) {
        this.exchange = exchange;
        // ...
    }
}