要点简介
- （我认为）本节除了实践意义，更重要的是一些理念上的东西,在代码中要有这种思想，是否完全照此处理，估计还是要看编码的情况
- 类最常规的组织方式
- 类的结构以及这样结构的原因
- 进一步的组织类的原则
一、常规组织方式-自定向下原则
1.1 变量
- 从一组变量列表开始
- 公共静态常量首先出现
- 然后是私有静态变量和私有实体变量
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;
// ...
}
}
