虽说有了 matugen 这样强大的音乐 tag 信息处理库
那最多也就能为本地音乐构建一个数据库而已，只解决了数据获取的问题，所以大头并没有解决。
问题是这样的：
之前的 Player 的设计有问题。Player 依赖于 MusicModel 的实现，要想获取关于 song 的信息，大家都从 Player 这里拿音乐数据。
现在我觉得大家要拿数据，只需要从 Player 这里拿到一个 ID 信息。或者，根本不从 Player 这里拿，Player 由另外一个外部 controller 来控制，大家就从外部 controller 拿数据。Player 就变成无状态了的？
而目前来看，外部 controller 就是 ControllerApi 了。
So, ControllerApi 保存当前播放列表和当前歌曲的相关信息。player 只管播放的 url. 把东西都丢给了 ControllerApi, 这东西以后还能维护么... 表示担忧 -.0
我貌似还记得以前为什么那样设计。当时想的是：如果 Player 不保存歌曲信息的话，当切换歌曲时，其他模块就比较难拿到歌曲信息。
好吧，暂时就这么决定了。
然而，对于 MusicModel，以前要想拿到一个歌曲的 url, 就是 music_model['url']，这样貌似也是不科学的，最好有一个 get 的方法。这样比较好适应不同的歌曲类型吧。
另外一个纠结的问题是：
我要获取一首歌的歌手信息。
原来的话，我会这样：music_model['artists'][0]['id']
但是对于本地歌曲：我不想给它加 id 的信息。也不想给它建数据库。
所以对于本地歌曲，重载获取歌手信息的方法。
要区分本地歌曲和网络歌曲（网易云），那就加上一个 type 信息。
想了一两天，渐渐发现问题的关键可能不是 Model 的设计不科学，也不是 Player 设计不科学。
而是我想用相同的 MusicTable 来显示这两种类型的歌曲信息，要求太高。
想想，对于本地歌曲，用户点击歌手名字，就不需要有啥反应，所以用同一个 MusicTable 反而显得有些偷懒。
写给自己看的独白。
答应了 要支持本地音乐 现在，我后悔了 -
虽说有了
matugen这样强大的音乐 tag 信息处理库 那最多也就能为本地音乐构建一个数据库而已，只解决了数据获取的问题，所以大头并没有解决。问题是这样的： 之前的 Player 的设计有问题。Player 依赖于 MusicModel 的实现，要想获取关于 song 的信息，大家都从 Player 这里拿音乐数据。 现在我觉得大家要拿数据，只需要从 Player 这里拿到一个 ID 信息。或者，根本不从 Player 这里拿，Player 由另外一个外部 controller 来控制，大家就从外部 controller 拿数据。Player 就变成
无状态了的？ 而目前来看，外部 controller 就是 ControllerApi 了。So, ControllerApi 保存当前播放列表和当前歌曲的相关信息。player 只管播放的 url. 把东西都丢给了 ControllerApi, 这东西以后还能维护么... 表示担忧 -.0
我貌似还记得以前为什么那样设计。当时想的是：如果 Player 不保存歌曲信息的话，当切换歌曲时，其他模块就比较难拿到歌曲信息。
好吧，暂时就这么决定了。
然而，对于 MusicModel，以前要想拿到一个歌曲的 url, 就是
music_model['url']，这样貌似也是不科学的，最好有一个 get 的方法。这样比较好适应不同的歌曲类型吧。另外一个纠结的问题是：
我要获取一首歌的歌手信息。 原来的话，我会这样：music_model['artists'][0]['id'] 但是对于本地歌曲：我不想给它加 id 的信息。也不想给它建数据库。
所以对于本地歌曲，重载获取歌手信息的方法。
要区分本地歌曲和网络歌曲（网易云），那就加上一个 type 信息。
想了一两天，渐渐发现问题的关键可能不是 Model 的设计不科学，也不是 Player 设计不科学。 而是我想用相同的 MusicTable 来显示这两种类型的歌曲信息，要求太高。 想想，对于本地歌曲，用户点击歌手名字，就不需要有啥反应，所以用同一个 MusicTable 反而显得有些偷懒。
2016-3-11 的思考
对于本地音乐和网络音乐。我打算把它们功能都写成插件形式。
目前对于问题想到的解决方案是：把 MusicTable 抽象出来，本地音乐要显示，他自己重新继承，控制并绑定相应的点击事件等。对于网络音乐也一样。 换句话说：这两个插件能自己控制 MusicTable。
但是这也会引发一些问题，目前我能想到的就有：
所以接下来要做的事情：
model.get_id()代替以前的mode['id']从上面的分析来看，一个音乐插件自己需要干哪些事情？
恩，这样该下去的结果就是工作量超级大，中途产生怨念的可能性非常大。 另外一个犹豫就是：官方版就快有了，从实用价值的角度来看，这东西不值得做这种大改动 ！！！ 但是很烦的是：不改不爽，官方的有些地方还是很不习惯的。这时候，我会去看看
netease-musicbox哎，要怪就怪以前设计的不好啊！！！