重做项目时，用UserDefaults缓存了一些简单数据，UserDefaults用的频次稍多一点，就看到一个不太合理的现象。
1、每次都要完整的写出UserDefaults.standard，然后才去存取，代码看起来不是很整洁
2、key的管理、value的类型没有统一的约束，非常散乱
然后就想到了提炼代码。
针对问题，出两条对策：
1、封装UserDefaults的调用方法，缩减代码量
2、整理key和value
之前代码中（二手项目），是对UserDefaults.standard加了一个全局方法处理，kUserDefaultsSet这样的写法，简单压缩一下调用方法，key和value还是一盘散沙。
这种再封装的方法意义不大，项目中还有key没有聚合起来，随着版本改动，这些key重复创建，或者随着版本变化逐渐被遗忘在项目中不再维护，导致UserDefaults被逐渐写烂。
后来尝试把key整理在一个类里面，使用DefaultsKey.xxx 这样的写法，还是觉得不美观。如果有新人来看项目，他就需要去看全局方法和一个常量聚合类，很不人性。
然后针对命名空间又进行优化，引出了二级命名空间DefaultsKey.User.xxx，DefaultsKey.Home.xxx。树壮结构思维清晰了一些，看起来也美观了，但上一条说的问题依然存在--UserDefaults还是得写两处（方法和key）。
但是，引入了命名空间的思想，意外的给解决问题带来了灵感。
我为什么不直接在key上下功夫呢?
直接给key赋值，结合get和set，省略kUserDefaultsSet的全局方法。
然后就有了如下操作：
extension UserDefaults {
struct Ex {}
}
用UserDefaults自身做命名空间扩展，方便记忆。
所有的自定义key扩展都写在Ex下面，不会与他本身冲突
再给UserDefaults.Ex做扩展
extension UserDefaults.Ex {
//用户信息
struct User {
/// 用户token
static var Token : String? {
get {
return UserDefaults.standard.string(forKey:"user_Token")
}
set {
UserDefaults.standard.set(newValue, forKey:"user_Token")
UserDefaults.standard.synchronize()
}
}
}
}
User就是用户分类，Token就是用户的Token
调用时，就很简单了
//存入
UserDefaults.Ex.User.Token = "1234567890"
//读取
let token =UserDefaults.Ex.User.Token
总结：
- 命名空间很好地解决了Key的问题，对于多个同样子类的字段，可以创建二级/三级命名空间，树状结构思路清晰；在外部使用点语法时会自动补全提示，调用也更加方便
- set和get刚好贴入UserDefaults的读与写，能规范value的类型，符合扩展类的设计思路
- 相对于老的写法，此处代码相对较多，但是Defaults本身不会存太多东西，适合放在一个单独的文件中管理，什么时候新增或者弃用值都是一眼能看出来的，并且这种做法思路清晰，结构安全
