Java類是由屬性與方法組成，如何編寫類其實就是如何決定一個類應該包含哪些屬性或者方法，如果我們已經有了一些業務需求，也知道了需要哪些功能，那這個問題就變成了如何去判斷一個屬性或者方法是否屬於一個類。
我們從上自下，寫一個類最先要做的是命名，命名是一個很難的事情，一方面是概念的提取與抽象能力，另一方面是語言的使用能力，避免詞不達意。當我們遇到不知道如何去給一個類命名時，我們就應當注意了，到底是我找不到合適的詞彙呢，還是本來就需要多個詞彙來表達。與編寫方法類似，都是通過關注命名來約束職責。我們可以首先將類的職責解釋出來，再進行提煉概念。
然後是如何判斷一個屬性與方法是否屬於一個類，主要是方法，因爲屬性往往是跟隨方法變化的。這裏常常使用到SRP，SRP的核心要求類應該有且僅有一條修改的理由。SRP看起來簡單，但是使用起來不容易，原因就是職責是不能量化與很好的定義。同一件事件不同的人有不同的看法，職責的維度與層級都會影響單一職責的使用。例如《clean code》中的Version類，那主版本跟子版本算不算一個職責呢，如果我想修改主版本的規則或者子版本的規則算不算兩個修改的理由呢。因此如果我們不追求SRP，改成追求一個概念，一個可以通過一個單詞映射出來的概念，然後來檢查這個方法是否屬於這個概念。
public class Version {
public int getMajorVersionNumber();
public int getMinorVersionNumber();
public int getBuildNumber();
}
另外一個方式就是判斷類的內聚性，內聚性比較容易量化，就是計算類的方法操作了多少個屬性。內聚性也是減少方法參數的一種方式，當我們給方法添加參數時，需要去思考這個參數是否應該作爲類的屬性。但是在工作中遇到的類往往並沒有什麼屬性，一般僅僅包含一些依賴的service屬性。主要是因爲工作中使用到的多數都是貧血性的對象，也就是數據結構，然後通過service來操作這些數據接口，這種結構是分佈式服務架構以及IOC框架的一些特點，但是我們可以在這種 大框架下將業務邏輯通過業務類來處理。
通過這種方式編寫的類有什麼好處呢，首先概念清晰，便於閱讀與理解，清晰的代碼往往難以出錯；其次是如果類的概念劃分的比較細，更易擴展，需求的修改測試迴歸成本更低。