基础概念Basics

丑陋 与 完美

坏味道Bad Smell

代码中不好的部分

设计模式Design Patterns

使用固定的语法、摆出固定的代码结构、解决固定的问题

下后下前拳

设计原则

所有改进的方案中，和设计模式中，背后隐藏的核心价值观

重构Refactorings

在不更改 对外功能 或 API 的前提下，修改内部代码结构

测试Testing

能够验证出来，改后没崩溃

需求 与 预判

需求可变

最经典的一或多问题

用户的头像

处理方法

后期更改

如果后期很靠后，能省下大量时间

如果后期近在咫尺，那么现在的代码，可能多此一举

前期设计

预测成功，可省下大面积代码修改

预测失败，现在的代码就是过度设计 Over Design

什么是好的设计

反思

前期设计 / 后期更改

完美 / 丑陋

魔法师与火球

最合适的代码，才是最好的代码

能控制的法师，才是最好的法师

意识阶层

设计层级

语句级

一个函数内的执行代码

执行代码质量

函数级

函数的 API 签名

API 设计

结构级

不同的类之间的协调

设计模式

模块级

不同的可重用模块之间的协调

系统设计

应用级

多个不同的应用程序间的协调

系统设计

语句级设计

变量改名Rename Variable

变量抽取Extract Variable

变量去除Inline Variable

表达式

不能太长

不能太短

函数级设计

生命化

1 2 3 4 5 6 
class A {    f() {        B b = new B();        b.g();    }}   

对象 是 生物

方法调用 是 传递消息（说话）

方法名 和 参数 是 消息的内容

对象支持哪些方法 是 生物能听懂或理解哪些消息

模块化

电脑组装的故事

我们希望如果电池坏了，不用把电脑都扔了，可以只换电池

毛线团的故事

代码不能都堆在一起

好的代码，是要把毛线团尽可能的清晰的拆开

服务化

函数声明的 / 被调用的 / 听别人消息的 / 提供服务的

需要有服务心态

如何设计 API 才能让调用者调的舒服

才能让跟你（被调用的函数所有在的对象）对话的人（调用对象）舒服

API 分割标准化

一旦定义 API ，将形成一套标准，使用者按标准使用，实现方努力实现

1 2 
public int max(int a, int b) { // 这一行}

电源标准和供电的故事

订好三个眼后，供电系统和电器就可以分开行动

如果不按规矩来。。。

你的实现代码，别人可能并不会按照你的预期去调用

设计要素

简单

直接

1 
Burger b = Burger.newBurgerInDefaultWorld(new Place()); 

对比

1 2 3 4 5 6 7 8 
World w = new World();Place p = w.createPlace();Factory f = new Factory();f.setOn(p);f.supplyPower();f.makeProduct();Product product = f.generatedProduct;Burger b = (Burger)product; 

精准传参

参数不多到恶心

1 
Math.max(int a, int b)

对比

1 2 3 4 5 
Math.max(    int a, int b,     int defaultForA, int defaultForB,     boolean isRandomEnabled)

参数不少到无法实现

1 
Math.max(int a, int b)

对比

1 
Math.max(int a)

无歧义

方法名可读

1 
Math.max(3, 4);

对比

1 
ma(3, 4);

参数名可读

1 
devide(int number, int by)

对比

1 
devide(int n1, int n2)

开放

尽可能容纳各种可能

Node
+   value:Object

对比

Node
+   value:int

单一

1 
Math.max(int a, int b)

对比

1 2 3 4 5 
Math.max(    int a, int b,     int defaultForA, int defaultForB,     boolean isRandomEnabled)