我发现很多开发人员,包括一些大的公司都喜欢把所有的网络请求方法放在同一个类中,好象很方便使用和管理,我自己也曾经这么做,但是使用一阵子后我发现其实并没有必要.
这是我早期的代码,和大多数人一样,写了一个专职于网络请求的类,将所有需要和服务器交互的方法都定义在这个类中


但是使用起来并没有感觉多方便,代码量也没有减少,原因如下

  • 首先,网络请求的目的绝大多数都是数据交互,那么数据对谁有用?当然是你发起请求的对象才需要啊,而并不是你管理请求的那个类需要数据,所以你请求完之后基本上大家都需要通过回调将数据返会给发起请求的那个类,这样的话直接在那个类中处理掉不就行了吗?
  • 另外,网络请求这个事基本上是唯一的,没有复用的价值,比如你在登录的界面才需要并只需要一次调用登录接口,同样只有在评论列表你才需要并只需要调用一次评论列表接口,因此你将这些接口放在一个类中并没有更方便啊
  • 最后,这么做还会导致维护成本增加,你出现问题的时候首先要确定问题发生的位置,找到出现问题所在类,如果是网络请求的数据问题,直接在当前的类中就能断点处理,省去了来回切换单元文件的麻烦

可能还有同学会问了,类设计的原则之一就是单一原则,一个类只负责做一件事,这样做的话很符合单一原则啊,这个问题我也认真思考过了,还在网络上查了关于单一原则的资料,基本上大家都是举了modem调制解调器的例子

就是把modem的功能分为了两个类来实现,一个负责拨号,一个负责数据交换
这个问题我是这样理解的,就是单一原则要分两个角度来看,一个是功能角度,就是modem的例子,他其实是包含了拨号和数据传输两个功能,所以设计两个类来分别负责相应的功能非常的科学
但是我们还有另外一个角度来看这个事,那就是业务角度,从这个角度来看,登录功能只不过是用户这个类的一个行为,同样获取评论列表也只是评论管理模块的一个行为,或者我们换一个说法,就是功能划分,这样比较说的清楚,登录和获取评论列表这两个功能其实已经划分到对应的类的功能中了,所以你另外新建一个类来归纳这些功能无异于画蛇添足
在这个案列中如果要体现单一原则,我觉的最能体现的地方就是你必需设计一个统一的网络请求接口,包含统一加密解密数据,错误处理等等,这个类只负责发起和处理请求,而不处理数据

1
2
3
4
5
static func generalRequest(paramInfo:Dictionary<String,String>,apiPath:SERVERPATCH,activityView:UIView?,callBack:@escaping callBack) -> DataRequest
{
do something....
})
}

最后我想说的是,我们在软件开发中要设计很多界面,包含大量的lable,button等控件,如果将网络请求的功能统一放在一个类中,这种作法和将所有创建label的功能放在一个类中有什么区别呢?我想大多数人的作法会是设计一个类,只有一个生成通用样式的label的方法,以上