《代码简洁之道》总结三之简洁的类

1、类的组织

类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。

公共函数应跟在变量列表之后。把由某个公共函数调用的私有工具函数紧随在该公共函数后面，更符合由顶向下的原则。

2、类应该短小

关于类的第一条规则是类应该短小。第二条规则是还要更短小。

函数通过计算代码行数衡量大小。对于类，通过计算权责来进行衡量。

类的名称应当描述其权责。如果某个类无法命名以精确的名称，这个类就太长了。类名越含混，该类越有可能拥有过多的权责。

单一权责原则

单一权责原则任务，类或模块应有且只有一条加以修改的理由。

有大量短小类的系统并不比有少量庞大类的系统拥有更多移动部件，其数量大致相等。

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

内聚

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

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

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

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

仅仅是将较大的函数切割为小函数，就将导致更多的类出现。如果一个有许多变量的大函数，把该函数中某一小部分拆解成单独的函数。不过，想要拆出来的代码使用了该函数声明中的4个变量，是否必须将这4个变量都作为参数传递到新函数中去？

没有必要，只要将这4个变量提升为类的实体变量，完全无需传递任何变量就能拆解代码了。很容易将函数拆分为小块。

但是这也意味着类丧失了内聚性，因为堆积了越来越多只为运行少量函数共享而存在的实体变量。如果有些函数想要共享某些变量，为什么不让它们拥有自己的类呢？当类丧失了内聚性，就拆分它。

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

3、为了修改而组织

在整洁的系统中，对类加以组织，以降低修改的风险。

如果类中出现了只与类的一小部分有关的私有方法行为，意味着存在改进空间。

类应该满足开放--闭合原则：类应当对扩展开放，对修改关闭。

隔离修改

具体类包含实现细节（代码），而抽象类则只呈现概念。依赖于具体细节的类，当细节改变时，就会有风险。我们可以借助接口和抽象类来隔离这些细节带来的影响。

public interface StockExchange{
    Money currentPrice(String symbol);
}

---------------------------------------

public Portfolio{
    private StockExchange exchange;
    public Portfolio(StockExchange exchange){
        this.exchange = exchange;
    }
    // ...
}

---------------------------------------

public class PortfolicTest{
    private FixedStockExchangeStub exchanges;
    private Portfolio portfolio;
    @Before
    protected void setUp() throws Exception{
        exchange = new FixedStockExchangeStub();
        exchange.fix("MSFT",100);
        portfolio = new portfolio(exchange);
    }
    
    @Test
    public void GivenFiveMSFTTotalShouldBe500() throws Exception {
        portfolio.add(5,"MSFT");
        Assert.assertEquals(500,portfolio.value();
    }
    
}

Portfolio类不再依赖于FixedStockExchangeStub类的实现细节，而是依赖于StockExchange接口。StockExchange接口呈现的是有关询问某只股票价格的抽象概念。这种抽象隔离了所有询价的特定细节，包括价格数据来自何处之类。

通过降低连接度，类就遵循了另一条设计原则，依赖倒置原则。