类
类的组织
标准的Java约定，类结构定义如下：
- 公共静态变量
- 私有静态变量
- 私有实体变量
- 公共函数
- 私有函数
类应该短小
不应有太多全责。
单一权责原则
Single Responsiblility：类或模块应该有且只有一条加以修改的理由。
职责越清晰，被复用的可能性就越大。
内聚
类应该只有少数实体变量，方法操作的实体变量越多，内聚性越强。
保持内聚性就会得到很多短小的类
为了修改而组织
对类加以组织，以降低修改带来的风险。
当派生类的共有方法所需参数不同时，可通过构造函数赋值给派生类的成员变量解决。有点像模板模式的概率。
隔离修改
需求会改变，写代码时应主动应对未来可能的改变，保证扩展性。
DIP（Dependency inversion principle）：依赖倒置原则，依赖抽象方法或接口，防止具体实现修改带来的影响。
系统
如何建造一个城市
明确抽象层级，各司其职，就像树结构一样。
将系统的构造与使用分开
对象的初始化应该和使用分开，反例：在第一次使用时执行初始化操作。
创建复杂对象时，可使用抽象工厂模式。
依赖注入
Dependency Injection，分离构造与使用。控制反转（Inversion of Control）是依赖管理的一种应用手段。
扩容
主动面向扩展。
纯Java AOP框架
尽管Spring的XML冗长且难以阅读，配置文件中定义的策略还是要比隐藏在幕后自动创建的复杂的代理和切面逻辑更简单。利用“约定胜于配置”理念，减少配置。
测试驱动系统架构
不要先做大设计，很多时候写代码是编写边优化，甚至会推倒前面写的。
对系统总的覆盖范围、目标、项目进度和最终系统的总体架构要有所预期，并且要有随机应变的能力。
优化策略
延迟决策至最后一刻也是好手段，这不是懒惰或不负责，而是让我们能够基于最有可能的信息做出抉择。提前决策是一种预备知识不足的决策。如果决策太早，就会缺少太多客户反馈、关于项目的思考和实施经验。
小结
在所有的抽象层级上，意图都应该清晰可辨。
无论是设计系统还是单独的模块，别忘了使用大概可开展工作的最简单方案。（和上诉的优化策略相关）
迭进
通过迭进设计达到整洁目的
简单设计原则（按照重要程度排序）
- 运行所有测试
- 不可重复
- 表达了程序员的意图
- 尽可能减少类和方法的数量
表达力
针对运用设计模式的类采取标准模式名，如Command、Vistor。
时常照拂自己创建的东西，用心是最珍贵的资源。
