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