目录及笔记链接

序

丹麦谚语：小处诚实非小事。

建筑师路德维希：神在细节之中。

日本的 5S 哲学：

1. 整理　（整理、せいり）
   组织，分类，排序，如恰当地命名。

2. 整顿　（整頓、せいとん）
   整齐，系统化。

美国谚语：物皆有其位，物尽归其位（A place for everything, and everything in its place）。

3. 清楚　（清楚、せいそ）
   整洁；清秀，秀丽。

谚语：整洁近乎虔诚（Cleanliness is next to godliness）。

4. 清洁（清潔、せいけつ）
   干净；纯洁，纯正。

5. 身美（しつけ）
   纲纪；纪律；自律，在实践中贯彻规程并乐于改进。

谚语：守小节者不亏大节（He who is faithful in little is faithful in much）。

谚语：及时一针省九针（A stitch in time saves nine）。

谚语：日事日毕（Don't put off until tomorrow what you can do today）。

谚语：防病好过治病（An ounce of prevention is worth a pound of cure）。

第1章 整洁代码

1.2 糟糕的代码

20世纪80年代末，有家公司写了个流行的杀手应用。后来该软件的发布周期越来越长，缺陷总是不能修复，崩溃几率越来越大。

20年后一位雇员说：当时他们赶着推出产品，代码写得乱七八糟。特性越加越多，代码也越来越烂，最后再也没法管理这些代码了。

糟糕的代码毁掉了这家公司。

我们都曾瞟一眼自己亲手造成的混乱，并决定弃之不顾、走向明天。
我们都曾看到自己的烂程序居然能运行，然后断言这总比什么都没有要强。
我们都曾说过有朝一日再回头清理。

勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）。

1.3 混乱的代价

随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降时，管理层就只有一件事可做了：增加更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们不清楚什么样的修改符合设计意图，什么样的修改违背设计意图。团队中的每个人都背负着提升生产力的可怕压力，他们制造更多的混乱，驱动生产力向零端不断下降。

1.3.1 华丽新设计

开发团队难以忍受旧系统的混乱，要求重新设计一套看上去很美的新系统。
在新系统完成的时候，这个故事会重演。

1.3.2 态度

因进度和需求的压力而对代码质量做出妥协，这不是专业程序员应有的态度。

1.3.4 整洁代码的艺术

整洁代码很像是绘画。能分辨一幅画是好是坏并不表示懂得绘画。能分辨整洁代码和肮脏代码也不意味着会写整洁代码！

1.3.5 什么是整洁代码

Bjarne Stroustrup（C++语言发明者）：
我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

Grady Booch（Object Oriented Analysis and Design with Applications 作者）
整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

1.4 思想流派

任何门派都并非绝对正确。

1.5 我们是作者

作者有责任与读者做良好沟通。要想轻松写代码，需先让代码易读。

1.6 童子军军规

童子军军规：让营地比你来时更干净。

光把代码写好是不够的，必须时时保持代码整洁。

1.8 小结

艺术书并不保证你读过之后能成为艺术家，只能告诉你其他艺术家用过的工具、技术和思维过程。

第2章 有意义的命名

2.2 名副其实

一旦发现有更好的名称，就换掉旧的。

如果名称需要注释来补充，那就不算是名副其实。

糟糕的命名-例1

int d;  // 消逝的时间，以日计

有意义的命名-示例1

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

糟糕的命名-示例2

public List<int[]> getThem(){
  List<int[]> list1 = new ArrayList<int[]>();
  for (int[] x : theList)
    if (x[0] == 4)
      list1.add(x);
  return list1;
}

有意义的命名-示例2

public List<Cell> getFlaggedCells(){
  List<Cell> flaggedCells = new ArrayList<Cell>();
  for (Cell cell : gameBoard)
    if (cell.isFlagged())
      flaggedCells.add(cell);
  return flaggedCells ;
}

2.3 避免误导

避免与类型名称或专有名称混淆导致误导。

避免使用易混淆的字母与数字，如字母 l 与数字 1，字母 O 与数字 0。

2.4 做有意义的区分

避免使用废话做无意义的区分。

无意义的区分-示例1

public static void copyChars(char a1[], char a2[]){
  for (int i = 0; i < a1.length; i++){
    a2[i] = a1[i];
  }
}

有意义的区分-示例1

public static void copyChars(char source[], char destination[]){
  for (int i = 0; i < source.length; i++){
    destination[i] = source[i];
  }
}

无意义的区分-示例2

class Prodect { }
class ProdectInfo { }
class ProdectData { }

无意义的区分-示例3

getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();

2.5 使用读得出来的名称

读不出来的名称示例

class DtaRcrd102{
  private Date genymdhms;
  private Date modymdhms;
  private final String pszqint = "102";
}

读得出来的名称示例

class Customer{
  private Date generationTimestamp;
  private Date modificationTimestamp;
  private final String recordId = "102";
}

2.6 使用可搜索的名称

名称长短应与其作用域大小相对应。

糟糕代码示例

for (int j = 0; j < 34; j++){
  s += (t[j] * 4) / 5;
}

整洁代码示例

int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j = 0; j < NUMBER_OF_TASKS; j++){
  int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
  int realTaskWeeks =  realTaskDays / WORK_DAYS_PER_WEEK;
  sum += realTaskWeeks;
}

2.7 避免使用编码

匈牙利语标记法，Hungarian Notation，HN

匈牙利语标记法在现代编译器面前已无必要。

消除成员前缀或后缀。

小镭：
作者不喜欢在接口和实现中使用编码，如 IShapeFactory。但接口使用 I 前缀却是 .NET 的接口命名准则。
关于编码，应参照本原则并遵循特定语言的规范与约定风格。
扩展阅读：Brad Abrams: Why do interface names begin with “I”

2.8 避免思维映射

不应当让读者在脑中把你的名称翻译为他们熟知的名称。这常常出现在选择是使用问题领域术语，还是解决方案领域术语。

2.9 类名

类名和对象名应该是名词或名词短语。

2.10 方法名

方法名应当是动词或动词短语。

2.11 别扮可爱

不要使用特定文化的俗语。言到意到，意到言到。

2.12 每个概念对应一个词

给每个抽象概念选一个词，并一以贯之。

思考：

• fetch、retrieve 和 get 的不同。
• DeviceManager 和 ProtocolController 的不同。

2.13 别用双关语

同一术语用于不同概念，基本上就是双关语了。
应尽可能写出易于阅读的代码，大众化的平装书模式好过晦涩的学院派模式。

思考 add、insert 和 append 的不同。

2.14 使用解决方案领域名称

你的代码的读者是程序员，所以应尽可能使用他们所知术语。

2.15 使用源自所涉问题领域的名称

优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念。
与所涉问题领域更为贴近的代码，应当采用源自问题领域的名称。

2.16 添加有意义的语境

名称很难自我说明。你需要拥有良好命名的类、函数或名称空间来放置名称，给读者提供语境。

代码清单2-1，语境不明确的变量

private void printGuessStatistics(char candidate, int count){
  String number;
  String verb;
  String pluralModifier;
  if (count == 0){
    number = "no";
    verb = "are";
    pluralModifier = "s";
  } else if (count == 1){
    number = "1";
    verb = "is";
    pluralModifier = "";
  } else {
    number = Integer.toString(count);
    verb = "are";
    pluralModifier = "s";
  }
  String guessMessage = String.format(
    "There %s %s %s%s", verb, number, candidate, pluralModifier
  );
  print(guessMessage);
}

代码清单2-2，有语境的变量

public class GuessStatisticsMessage{
  private String number;
  private String verb;
  private String pluralModifier;

  public String make(char candidate, int count){
    createPluralDependentMessageParts(count);
    return String.format(
      "There %s %s %s%s", verb, number, candidate, pluralModifier
    );
  }

  private void createPluralDependentMessageParts(int count){
    if(count == 0){
      thereAreNoLetters();
    } else if (count == 1){
      thereIsOneLetter();
    } else {
      thereAreManyLetters(count);
    }
  }

  private void thereAreManyLetters(int count){
    number = Integer.toString(count);
    verb = "are";
    pluralModifier = "s";
  }

  private void thereIsOneLetter(int count){
    number = "1";
    verb = "is";
    pluralModifier = "";
  }

  private void thereAreNoLetters(int count){
    number = "no";
    verb = "are";
    pluralModifier = "s";
  }
}

2.17 不要添加没用的语境

只要短名称足够清楚，就要比长名称好。

2.18 最后的话

取好名字最难的地方在于需要良好的描述技巧和共有文化背景。

第3章 函数

3.1 短小

函数的第一条规则是短小，第二条规则是还要更短小。

3.2 只做一件事

函数应该只做一件事并做好它。

3.3 每个函数一个抽象层级

如果函数只做了该函数名下同一抽象层上的步骤，则函数只做了一件事。

向下规则：我们想要让代码拥有自顶向下的阅读顺序。

3.4 switch 语句

单一权责原则，SRP，Single Responsibility Principle
开放闭合原则，OCP，Open/Closed Principle

3.5 使用描述性的名称

长而具有描述性的名称要比短而令人费解的名称好，要比描述性的长注释好。
选择描述性的名称能清理你关于模块的设计思路，并帮你改进它。追索好名称，往往导致对代码的改善重构。

3.6 函数参数

最理想的参数数量是零，其次是一，再次是二，尽量避免三。

参数不易对付，它们带有太多概念性。参数与函数名处在不同的抽象层级，他要求你了解目前并不特别重要的细节。

从测试的角度看，参数越多越麻烦。

输出参数比输入参数还要难以理解。因为我们习惯性地认为信息通过参数输入函数，通过返回值从函数中输出。

3.6.1 一元函数的普遍形式

两种普遍理由：

• 问关于该参数的问题。

boolean fileExists("MyFile")

• 操作该参数，将其转化并输出。

InputStream fileOpen("MyFile")

3.6.2 标识参数

向函数传入布尔值简直就是骇人听闻的做法。这样做就等于宣布函数不只做一件事。

render(boolean isSuite)

应将该函数一分为二：

renderForSuite()
renderForSingleTest()

3.6.3 二元函数

如非必须使用二元函数，就应该尽量利用一些机制将其转换成一元函数。

writeField(outputStream, name)

可以通过重构将 outputStream 做成类的一个

writeField(name)

3.6.4 三元函数

三元函数要比二元函数难懂得多。

3.6.5 参数对象

如果函数看来需要两个、三个或三个以上参数，就说明其中一些参数应该封装为类了。

3.6.6 参数列表

类似于 string.format 中的可变参数实则是二元函数。

3.6.7 动词与关键词

函数和参数应当形成一种非常良好的动词/名词对形式。例如 WriteField(name)。

3.7 无副作用

函数承诺只做一件事，但还是会做被藏起来的事。有时它会对自己类中的变量做出未能预期的改动，有时它会把变量搞成向函数传递的参数或是系统全局变量。

输出参数
应避免使用输出参数。如果函数必须要修改某种状态，就修改所属对象的状态。

3.8 分隔指令与询问

函数要么做什么事，要么回答什么事，两样都干常会导致混乱。

3.9 使用异常替代返回错误码

返回错误码会导致更深层次的嵌套结构，并要求调用者立刻处理错误。
使用异常替代返回错误码，错误处理代码就能从主路径代码中分离出来。

3.9.1 抽离 Try/Catch 代码块

最好把 Try/Catch 代码块抽离出来形成另外的函数，这样可避免把错误处理与正常流程混为一谈，不致搞乱代码结构。

3.9.2 错误处理就是一件事

错误处理的函数不该做其他事。

3.9.3 错误码依赖磁铁

错误码通常暗示某处有个类或是枚举定义了所有错误码，这个类或枚举就是依赖磁铁。其他许多类都得导入和使用它。当它修改时，其他类就得重新编译和部署。

3.10 别重复自己

DRY 原则，Don't Repeat Yourself

重复可能是软件中一切邪恶的根源。许多原则与实践规则都是为控制和消除重复而创建。

3.11 结构化编程

Edsger Dijkstra 的结构化编程原则。
只要函数保持短小，偶尔出现的 return、break、continue 语句没有坏处，甚至比单入单出原则更具有表达力。

3.12 如何写出这样的函数

先动手写，再打磨推敲，同时配合单元测试。

3.13 小结

编程艺术是且一直就是语言设计的艺术。
大师级程序员把系统当做故事来讲，而不是当做程序来写。那种领域特定语言的一个部分，就是描述在系统中发生的各种行为的函数层级。

第4章 注释

别给糟糕的代码加注释——重新写吧。Kernighan and Plaugher, The Elements of Programming Style

若编程语言足够有表达力或我们善于用这些语言表达意图，那么就完全没必要使用注释。
注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败——不用注释就表达不清楚。

注释难能被程序员坚持维护，唯有代码能忠实地告诉你它做的事。

4.1 注释不能美化糟糕的代码

与其花时间写清楚注释，不如花时间清洁代码。

4.2 用代码来阐述

代码对比：

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65))

与

if (employee.isEligibleForFullBenefits())

4.3 好注释

4.3.1 法律信息

尽可能指向一份标准许可或其他外部文档。

// Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
// Released under the terms of the GNU General Public License version 2 or later.

4.3.2 提供信息的注释

应尽可能利用函数名或调整代码来取代注释。

4.3.4 阐释

如果阐释是必要的，一定要保证注释的正确性。

4.3.5 警示

public static SimpleDateFormat makeStandardHttpDateFormat()
{
  //SimpleDateFormat is not thread safe,
  //so we need to create each instance independantly.
  SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
  df.setTimeZone(TimeZone.getTimeZone("GMT"));
  return df;
}

4.3.6 TODO 注释

不要以此为借口留下糟糕的代码，要定期查看及维护。

4.3.7 放大

注释可以用来放大某种看来不合理之物的重要性。

// the trim is real important. It removes the starting
// spaces that could cause the item to be recognized
// as another list.
String listItemContent = match.group(3).trim();

4.3.8 公共 API 中的 Javadoc

被良好描述的公共 API 实用且优雅。

4.4 坏注释

坏注释是借口。
如果决定要写注释，就要写好写清楚。
迫使读者查看其他模块的注释才能弄清原委的注释是糟糕的。
不要写废话注释与误导性注释。
要用整理代码的决心替代写废话的冲动。
不应在代码中保留日志、归属、署名以及注释掉的代码等内容，应使用版本控制系统。
如果想要在括号后面写注释，那么更好的做法是缩短函数。
别在注释中给出与被注释代码无关的信息。
注释与其代码之间的联系应显而易见，以便阅读理解。

范例

代码清单 4-8 PrimeGenerator.java

/**
 * This class Generates prime numbers up to a user specified
 * maximum. The algorithm used is the Sieve of Eratosthenes.
 * Given an array of integers starting at 2:
 * Find the first uncrossed integer, and cross out all its
 * multiples. Repeat until there are no more multiples
 * in the array.
 */

public class PrimeGenerator
{
    private static boolean[] crossedOut;
    private static int[] result;

    public static int[] generatePrimes(int maxValue)
    {
        if(maxValue<2)
            return new int[0];
        else
        {
            uncrossIntegersUpTo(maxValue);
            crossOutMultiples();
            putUncrossedIntegersIntoResult();
            return result;
        }
    }

    private static void uncrossIntegersUpTo(int maxValue)
    {
        crossedOut = new boolean[maxValue + 1];
        for (int i = 2; i < crossedOut.length; i++)
            crossedOut[i] = false;
    }

    private static void crossOutMultiples()
    {
        int limit = determineIterationLimit();
        for (int i = 2; i <= limit; i++)
            if (notCrossed(i))
                crossOutMultiplesOf(i);
    }

    private static int determineIterationLimit()
    {
        // Every multiple in the array has a prime factor that
        // is less than or equal to the root of the array size,
        // so we don't have to cross out multiples of numbers
        // larger than that root.
        double iterationLimit = Math.sqrt(crossedOut.length);
        return (int) iterationLimit;
    }

    private static void crossOutMultiplesOf(int i)
    {
        for (int multiple = 2*i; multiple < crossedOut.length; multiple += i)
            crossedOut[multiple] = true;
    }

    private static boolean notCrossed(int i)
    {
        return crossedOut[i] == false;
    }

    private static void putUncrossedIntegersIntoResult()
    {
        result = new int[numberOfUncrossedIntegers()];
        for (int j = 0; i = 2; i < crossedOut.length; i++)
            if (notCrossed(i))
                result[j++] = i;
    }

    private static int numberOfUncrossedIntegers()
    {
        int count = 0
        for (int i = 2; i < crossedOut.length; i++)
            if (notCrossed(i))
                count++;
                
        return count;
    }
}

第5章 格式

5.1 格式的目的

代码风格和可读性会影响维护性和扩展性。

5.2 垂直格式

5.2.1 向报纸学习

原文件应像报纸文章。名称应当简单且一目了然。
源文件最顶部应该给出高层次概念和算法，细节应该往下渐次展开，直至找到源文件中最底层的函数和细节。

5.2.2 垂直方向上的区隔与靠近

独立的概念应用空白行隔开，相关的代码应该相互靠近。

5.2.4 垂直距离

相关函数
如果a函数调用了b函数，就应该把他们放到一起，而且a函数应该尽可能放在b函数上面，形成自然顺序。

5.3 横向格式

作者的代码行长度上限是120个字符。

小镭：关于对齐与缩进，可使用 IDE 默认的自动化格式或自定义格式。

5.5 鲍勃大叔的格式规则

代码清单 5-6 CodeAnalyzer.java

public class CodeAnalyzer implements JavaFileAnalysis{
    private int lineCount;
    private int maxLineWidth;
    private int widestLineNumber;
    private LineWidthHistogram lineWidthHistogram;
    private int totalChars;

    public CodeAnalyzer(){
        lineWidthHistogram = new LineWidthHistogram();
    }

    public static List<File> findJavaFiles(File parentDirectory){
        List<File> files = new ArrayList<File>();
        findJavaFiles(parentDirectory, files);
        return files;
    }

    private static void findJavaFiles(File parentDirectory, List<File> files){
        for (File file : parentDirectory.listFiles()){
            if (file.getName().endsWith(".java"))
                files.add(file);
            else if (file.isDirectory())
                findJavaFiles(file, files);
        }
    }

    public void analyzeFile(File javaFile) throws Exception{
        BufferedReader br = new BufferedReader(new FileReader(javaFile));
        String line;
        while ((line = br.readLine()) != null)
            measureLine(line);
    }

    private void measureLine(String line){
        lineCount++;
        int lineSize = line.length();
        totalChars += lineSize;
        lineWidthHistogram.addLine(lineSize, lineCount);
        recordWidestLine(lineSize);
    }

    private void recordWidestLine(int lineSize){
        if (lineSize > maxLineWidth){
            maxLineWidth = lineSize;
            widestLineNumber = lineCount;
        }
    }

    public int getLineCount(){
        return lineCount;
    }

    public int getMaxLineWidth(){
        return maxLineWidth;
    }

    public int getWidestLineNumber(){
        return widestLineNumber;
    }

    public LineWidthHistogram getLineWidthHistogram(){
        return lineWidthHistogram;
    }

    public double getMeanLineWidth(){
        return (double) totalChars / lineCount;
    }

    public int getMedianLineWidth(){
        Integer[] sortedWidths = getSortedWidths();
        int cumulativeLineCount = 0;
        for (int width : sortedWidths){
            cumulativeLineCount += lineCountForWidth(width);
            if (cumulativeLineCount > lineCount / 2)
                return width;
        }
        throw new Error("Cannot get here");
    }

    private int lineCountForWidth(int width){
        return lineWidthHistogram.getLinesforWidth(width).size();
    }

    private Integer[] getSortedWidths(){
        Set<Integer> widths = lineWidthHistogram.getWidth();
        Integer[] sortedWidths = (widths.toArray(new Integer[0]));
        Arrays.sort(sortedWidths);
        return sortedWidths;
    }
}

第6章 对象和数据结构

6.1 数据抽象

曝露抽象接口可以使用户无需了解数据的实现就能操作数据本体。

代码清单 6-3 具象机动车

public interface Vehicle{
  double getFuelTankCapacityInGallons();
  double getGallonsofGasoline();
}

代码清单 6-4 抽象机动车

public interface Vehicle{
  double getPecentFuelRemaining();
}

我们不愿曝露数据细节，更愿意以抽象形态表述数据。

小镭：
此处没有完全理解。作者的意思是否是说，此处需要的就是百分比，所以接口应直接表示所需数据，而不是简单地曝露变量、让使用者利用获取的变量自行计算完成。
但如果换成是生日（属性）和年龄（方法），而两项数据又都必要，两者就都需要曝露。

6.2 数据、对象的反对称性

对象把数据隐藏于抽象之后，曝露操作数据的函数。

数据结构曝露其数据，没有提供有意义的函数。

代码清单 6-5 过程式形状代码

public class Square{
    public Point topLeft;
    public double side;
}

public class Rectangle{
    public Point topLeft;
    public double height;
    public double width;
}

public class Circle{
    public Point center;
    public double radius;
}

public class Geometry{
    public final double PI = 3.1415926;

    public double area(Object shape) throws NoSuchShapeException{
        if (shape instanceof Square){
            Square s = (Square)shape;
            return s.side * s.side;
        }
        else if (shape instanceof Rectangle){
            Rectangle r = (Rectangle)shape;
            return r.height * r.width;
        }
        else if (shape instanceof Circle){
            Circle c = (Circle)shape;
            return PI * c.radius * c.radius;
        }
        throw new NoSuchShapeException();
    }
}

代码清单 6-6 多态式形状代码

public class Square implements Shape{
    private Point topLeft;
    private double side;

    public double area(){
        return side * side;
    }
}

public class Rectangle implements Shape{
    private Point topLeft;
    private double height;
    private double width;

    public double area(){
        return height * width;
    }
}

public class Circle{
    private Point center;
    private double radius;
    public final double PI = 3.1415926;
    
    public double area(){
        return PI * radius * radius;
    }
}

注意，两者是对立的，它们各有优势。他们之间的二分原理：
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。

反过来讲：
过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。

6.3 得墨忒耳定律

一种松耦合的方案。

得墨忒耳定律：模块不应了解它所操作对象的内部情形。
Law of Demeter, wiki

例如，类 C 的方法 f 只应该调用以下对象的方法：

• C
• 由 f 创建的对象；
• 作为参数传递给 f 的对象；
• 由 C 的实体变量持有的对象。

方法不应调用由任何函数返回的对象的方法（只跟朋友谈话，不跟陌生人谈话）。

违反了得墨忒耳定律的例子：

火车失事代码

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

6.3.1 火车失事

小镭：思考 Lambda 表达式与火车失事代码。

火车失事代码的切分：

Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

这些代码是否违反得墨忒耳定律取决于 ctxt、Options 和 ScratchDir 是对象还是数据结构。
如果是对象，则它们的内部结构应当隐藏而不曝露，以上代码涉及其内部细节就违反了定律。如果它们是数据结构，没有任何行为，则他们自然会曝露其内部结构，定律在此也就不适用。

属性访问器函数的使用把问题复杂化了。不会提及违反定律的代码：

final String outputDir = ctxt.options.scratchDir.absolutePath;

6.3.2 混杂

一半是对象，一半是数据结构，这是一种糟糕的设计。它增加了添加新函数的难度，也增加了添加新数据结构的难度。

小镭：
不幸的是很多编程书籍的例子都是这种混杂设计，作者只是想通过简单的一次性代码来讲解编程概念，但这些欠缺设计的代码却在设计上误导了读者。

6.3.3 隐藏结构

既然取得路径的目的是为了创建文件，那么不妨让 ctxt 对象来做这件事：

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

6.4 数据传送对象

数据传送对象

最为精炼的数据结构，是一个只有公共变量、没有函数的类。

这种数据结构有时被称为 DTO，Data Transfer Objects，数据传送对象。

小镭：MVC 模式中的模型就是这样的数据结构。

豆结构

豆结构拥有由赋值器和取值器操作的私有变量。

小镭：Java 没有属性

代码清单 6-7 address.java

public class Address{
    private String street;
    private String streetExtra;
    private String city;
    private String state;
    private String zip;

    public Address(String street, String streetExtra,
                   String city, String state, String zip){
        this.street = street;
        this.streetExtra = streetExtra;
        this.city = city;
        this.state = state;
        this.zip = zip;
    }

    public String getStreet(){
        return street;
    }

    public String getStreetExtra(){
        return streetExtra;
    }

    public String getCity(){
        return city;
    }

    public String getState(){
        return state;
    }

    public String getZip(){
        return zip;
    }
}

Active Record

Active Record 是一种特殊的 DTO 形式。
Active record pattern, wiki