kotlin的數(shù)據(jù)類，由于其內(nèi)部封裝了getter和setter方法，極大地簡化了我們的編程代碼，但同時其不能像java那樣方便的重寫getter或者setter方法，也給大家造成了一定的麻煩。

舉個例子：

data class OrderBean(val createTime: Long)

后端返回的訂單數(shù)據(jù)中，createTime這個字段是長整型的時間戳，但是前端需要轉(zhuǎn)成yyyy-MM-dd這種格式，或者yyyy年MM月dd日這種，再或者更加友好一點，根據(jù)時間段，轉(zhuǎn)成1小時前、2天前、一周前這種，在實際開發(fā)中都是常有的情況，在Java中我們可以很方便的在getter方法中做這些處理，但是kotlin的getter方法都是內(nèi)部封裝的，并不直接支持重寫，我看到網(wǎng)上有些答案是像這樣處理的：

data class OrderBean(val _createTime: Long){
    val createTime:String
        get() = { ...do something }
}

這樣處理其實并沒有真正改變createTime的值，反而會造成一些更大的麻煩，比如，數(shù)據(jù)類中自動生成的equals()，toString()等一些方法還是會沿用長整型的值，而且當(dāng)你做某些值對比的時候，會產(chǎn)生一些不可預(yù)測的結(jié)果。

正確的姿勢

有以下三種，你可以根據(jù)自己的業(yè)務(wù)邏輯和團隊的話語權(quán)進行選擇：

• 讓后端改：如果有可能的話，這是最合理，最恰當(dāng)?shù)姆绞?，后端直接返回我們需要的字段形式，?jié)省了移動端，web端，小程序端等每端各寫一套邏輯的時間，并且萬一哪段比較坑，實現(xiàn)出來的時間跟你們不一樣，可能你們每個都要復(fù)查一遍。另外，后端寫的話，一旦需求變更，后端處理起來要更加簡單方便。

• 不用data class，使用常規(guī)的class：不要拘泥于建議，誰說這些數(shù)據(jù)實體類就必須要用data class的，使用IDE去自動生成，照樣可以，而且還實現(xiàn)了自己的完全控制。

• 另外創(chuàng)建一個安全的變量：如果在團隊中實在人微言輕，有非要用data class，那就去另外創(chuàng)建一個變量，比如：

data class OrderBean(val createTime: Long){
    val createTimeShow:String
        get() = { ...do something }
}