以解耦的思路解决问题——经纬度转换

  由于历史原因，整个项目中有些接口里有些坐标是百度的，有些坐标是高德的。然而App只接入了高德SDK，这就意味着接口给的百度坐标都必须转成高德坐标后App才能使用，如果接口要求请求的坐标是百度那么手机里拿到的坐标得先转成百度坐标再请求，否则必定是BUG。
  可能你觉得没啥，不就是来回转坐标嘛，转坐标的算法网上一搜就有，写个util不就ok了么。但是，很多时候经常发现有人忘记转换导致了BUG，还有重复转换也导致了BUG，因为接口返回的坐标可能App会有很多处使用，每次使用前都要转化成高德坐标，一不留神就多转了，所以得非常非常细心才行，光业务代码开发有时候就很烦，还要折腾经纬度转换，实在心烦。
  所以，这里的耦合就是一边要写复杂的业务代码，一边复杂的业务代码里要来回折腾坐标转换。其实，这个场景非常类似新婚夫妇去国外度蜜月前先把人民币兑换成外币，回国后把多余的外币再兑换成人民币一样，因为是个人都知道人民币在国外使用不方便，外币在国内使用也不方便。其实，把这种思路用在代码里未尝不可：接口请求到数据在给业务处理前先一次性把要转换的坐标先转化了，在访问http接口前一次性把需要转化的坐标一次性转成百度坐标，这样业务代码里从头到位接触到的坐标都是高德，专心写业务即可，也就是所谓的“以不变应万变”。至于接口请求和返回中哪些坐标要转百度、哪些坐标要转高德，只要打个标签即可，在标签上注明转高德还是百度，Java打标签无非就是用Annotation了，自定义Annotation并在接口请求和返回的收口处通过反射寻找打了标签的坐标字段并做经纬度转化就可以了。
加了标签的接口代码如下：

// GD：高德， BD：百度
@LatLngInside(ConvertTo.GD)
private static class SearchParams {
    public String cityId;
    public String poiId;
    @Lat
    public double lat;
    @Lng
    public double lon;
    public String starIndex;
}

class上有@ LatLngInside意味着此class内部有坐标需要转化，参数值标明了要转化的坐标（转成百度还是高德）, 内部要转化的经度和纬度分别加上@Lat和@Lng以告知哪两个字段是经纬度，看到类的定义就知道这里需要转化，一目了然，连注视都省了。
关于这里的Annotation如何定义以及如何解析Annotation，以前写过一篇文章。