Android结构设计系列[2]--解耦合

2019-04-01 · 大约 600 个字 · 预计 3 分钟读完

声明:

本文是对Mark Allison系列博客的翻译和学习笔记，感谢作者提供的demo和这么好的博客。

在上一篇《Android结构设计系列[1]–初识工程》中我们认识了我们显示天气的APP,接下来将开始我们的结构优化。

在优化项目结构之前我们得先知道什么样的工程才是结构合理的工程。在最早的一篇博文中我对这个问题进行了简要归纳,请参考《六大设计原则浅析》，符合这些设计原则的工程就是一个结构合理的工程，我们要实现这样的结构得先从耦合性方面考虑，第一步我们先做分离。

逻辑分离

接下来我们回顾一下上一篇中的工程目录结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
src
│  Converter.kt                     #转换工具类
│  WeatherStationApplication.kt     #自定义的Application
│
├─model
│      Common.kt                    #天气数据具体的Json实体类
│      Current.kt                   #天气数据接口接收实体类
│
├─net
│      OpenWeatherMap.kt            #Retrofit的Api Service定义接口
│
└─ui
        CurrentWeatherFragment.kt   #天气显示Fragment
        MainActivity.kt             #主界面
        NoPermissionFragment.kt     #无权限fragment
        PreferencesFragment.kt      #设置fragment

从整个结构和上一篇的分析中会发现大部分逻辑都集中在CurrentWeatherFragment,包括获取位置信息、初始化网络请求框架、请求数据、绑定显示数据。获取位置信息的方式有很多种，部分手机并不支持系统获取定位，这个时候我们需要更换定位系统，则会发现我们的定位是和逻辑混合在一起，不容易拆解而且更加麻烦的是不容易进行单元测试。接下来我们将定位功能先拆分出来。