Clean Code读书笔记 3--类

1. 单一职责原则

像函数一样，类应该尽量短小

每一个类应该有且仅有一条加以修改的理由。

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

2.内聚

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

极大化的内聚不太可能，我们希望内聚性保持在较高位置。内聚性高，意味着类中的方法和变量互相依赖，互相结合成为一个整体。

//这是一个很好的内聚的例子
public class Stack {
  private int topOfStack = 0;
  List<int> elements = new LinkedList<int>();
  public int size(){
     return topOfStack;
  }
   public void push(int element) {
     topOfStack++;
     elements.add(element);
  }
   public int pop() {
     if(topOfStack != 0 ) {
        int element  = elements[topOfStack];
        elements.remove(topOfStack);
        topOfStack--;
        return element;
     }
  }
}

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

举例

4. 隔离修改，开闭原则

举例,没有遵守开闭原则的类设计（配置加载器，假设有从多种文件类型加载配置的需求）

这样的设计如果要再增加一个文件类型/或者修改任一文件类型的加载逻辑的支持，那么必须修改ConfigurationLoader类，违反了单一职责原则。

 增收开闭原则的类设计应该是

这样的话，要新增一个文件类型支持，只需新建一个子类。如果要修改一个文件类型的加载逻辑，也只需要修改一个类。

5. 依赖倒置

我们应该尽量避免依赖具体实现，而是应该依赖接口。

 这样的设计不具有灵活性，ConsoleLogger是一个具体的实现。如果我想要将系统的Log全部替换为输出到文件，那么所有耦合的地方都需要修改。

好的设计应该是依赖接口，而不是依赖实现。像如下这样