Java类是由属性与方法组成，如何编写类其实就是如何决定一个类应该包含哪些属性或者者方法，假如我们已经有了少量业务需求，也知道了需要哪些功能，那这个问题就变成了如何去判断一个属性或者者方法能否属于一个类。
我们从上自下，写一个类最先要做的是命名，命名是一个很难的事情，一方面是概念的提取与笼统能力，另一方面是语言的使用能力，避免词不达意。当我们遇到不知道如何去给一个类命名时，我们就应当注意了，究竟是我找不到合适的词汇呢，还是原本就需要多个词汇来表达。与编写方法相似，都是通过关注命名来束缚职责。我们可以首先将类的职责解释出来，再进行提炼概念。
而后是如何判断一个属性与方法能否属于一个类，主要是方法，由于属性往往是跟随方法变化的。这里常常使用到SRP，SRP的核心要求类应该有且仅有一条修改的理由。SRP看起来简单，但是使用起来不容易，起因就是职责是不能量化与很好的定义。同一件事件不同的人有不同的看法，职责的维度与层级都会影响单一职责的使用。例如《clean code》中的Version类，那主版本跟子版本算不算一个职责呢，假如我想修改主版本的规则或者者子版本的规则算不算两个修改的理由呢。因而假如我们不追求SRP，改成追求一个概念，一个可以通过一个单词映射出来的概念，而后来检查这个方法能否属于这个概念。
public class Version {
? ? public int getMajorVersionNumber();
? ? public int getMinorVersionNumber();
? ? public int getBuildNumber();
}
另外一个方式就是判断类的内聚性，内聚性比较容易量化，就是计算类的方法操作了多少个属性。内聚性也是减少方法参数的一种方式，当我们给方法增加参数时，需要去思考这个参数能否应该作为类的属性。但是在工作中遇到的类往往并没有什么属性，一般仅仅包含少量依赖的service属性。主要是由于工作中使用到的多数都是贫血性的对象，也就是数据结构，而后通过service来操作这些数据接口，这种结构是分布式服务架构以及IOC框架的少量特点，但是我们可以在这种 大框架下将业务逻辑通过业务类来解决。
通过这种方式编写的类有什么好处呢，首先概念清晰，便于阅读与了解，清晰的代码往往难以出错；其次是假如类的概念划分的比较细，更易扩展，需求的修改测试回归成本更低。
