前言:
- 对于一个大项目而言，最烦恼的就是在众多界面难以找到对应的viewController,要改个东西都要花好长的时间去找对应的类。
- 特别是当你接手一个大项目的时候，对整体的业务逻辑不熟悉，整体的架构体系不熟悉，让你修复某个页面的BUG，估计你找这个页面所对应的viewController都要找好久。
思考
- 能否有一种方式可以快速让你上手一个大项目？快速找到某个页面所对应的viewController ?
思路
- 在每一个页面出现的时候，都打印出哪个类即将出现，如下图所示
解决方案
- 方案1
- 整个项目中建立一个基类的viewController，然后将项目中所有的viewController都继承于基类的viewController，然后重写基类中的viewWillAppear方法
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
NSString *className = NSStringFromClass([self class]);
NSLog(@"%@ will appear", className);
}
- 方案2
- 给UIViewContoller建立一个分类，在分类里进行方法的交换，既保留了原本的方法，又有打印信息
//
// UIViewController+Swizzling.m
// CollectionsOfExample
//
// Created by mac on 16/10/1.
// Copyright © 2016年 chenfanfang. All rights reserved.
//
#import "UIViewController+Swizzling.h"
#import <objc/runtime.h>
@implementation UIViewController (Swizzling)
+ (void)load {
//我们只有在开发的时候才需要查看哪个viewController将出现
//所以在release模式下就没必要进行方法的交换
#ifdef DEBUG
//原本的viewWillAppear方法
Method viewWillAppear = class_getInstanceMethod(self, @selector(viewWillAppear:));
//需要替换成 能够输出日志的viewWillAppear
Method logViewWillAppear = class_getInstanceMethod(self, @selector(logViewWillAppear:));
//两方法进行交换
method_exchangeImplementations(viewWillAppear, logViewWillAppear);
#endif
}
- (void)logViewWillAppear:(BOOL)animated {
NSString *className = NSStringFromClass([self class]);
//在这里，你可以进行过滤操作，指定哪些viewController需要打印，哪些不需要打印
if ([className hasPrefix:@"UI"] == NO) {
NSLog(@"%@ will appear",className);
}
//下面方法的调用，其实是调用viewWillAppear
[self logViewWillAppear:animated];
}
@end
优缺点分析
-
方案1适用于一个新项目，从零开始搭建的项目，建立一个基类controller,这种编程思想非常可取。但对于一个已经成型的项目，则方案一行不通，你总不能建议一个基类，让后将所有的controller继承的类都改成基类吧？这工程量太大，太麻烦。
上面所述：我个人认为“建立一个基类controller,这种编程思想非常可取”，但遭受到简书朋友们的质疑，但我始终坚持自己的观点。（面相切面编程、继承的争论）具体大家可以看评论，择其优而从之。也欢迎大家阐述自己的意见。
个人对AOP和继承的总结
就从全新开始搭建一个架构，到底该使用基类Controller还是直接用AOP的问题上进行分析。
有简书朋友说直接使用AOP的眼观更加长远，但我不以为然。若用基类Controller之后,你还可以使用AOP，两者各施所长。若起初直接用AOP，后期需要使用到基类特性，那只能和你说抱歉了。所以，是否还认为一开始直接使用AOP就体现眼观更加长远？可能每个人的编程思想不一，得到的答案也不同。有的简书朋友或许是考虑到超大项目解耦的问题而始终坚持AOP也是可以理解的。
是否觉得AOP真的很万能？
AOP编程在某些情况下可控性较差，比如，项目中总有会用到第三方框架，以UIViewController来说吧，或许你并不想自己的操作影响到第三方框架的controller,那么你AOP编程的时候就需要刻意去筛选出需要过滤哪些controller,你就需要去各种找，找到第三方框架哪些是controller，然后进行相应的过滤。而基类Controller并不存在影响第三方框架的问题。若你非要扯到超大项目，超多模块，需要解耦问题，那我也不多说什么了，场景不一，没什么可言。
是否觉得基类Controller耦合性太强？
其实针对耦合性问题，每个人的观点不同，答案也不一。我个人认为，一个基类Controller可以完全替代UIViewController,你就默认它就是UIViewController，那么就不存在什么耦合性问题了。简书朋友所说的耦合性太强我也能理解。
小结：
上面所述仅代表个人的观点，简书朋友可理智选取可选部分。
AOP、继承，没有谁更优，不同开发情况有不同的选择。始终坚持AOP的简书朋友们，可能现在你们并没发现它的不足，但或许今后的哪一天你们会发现，AOP也有不足。所以个人还是挺坚持自己的想法：基类Controller与AOP共存才能发挥出最大的优势。
至部分简书朋友
其实一开始我对一个简书朋友评论的回复不当（观点不同，难免有些小情绪），在此表示抱歉。
开发技术水很深，谦虚一点还是必要的。有位简书朋友说的一句话真的很伤人：“估计楼主刚接触 iOS 开发不久”，或许你真的对子自己的技术够自信。
至简书朋友们
学无止境，互相学习。广大简书朋友们，就以上面的例子请你们“和平”阐述你们的观点，最好拿出实际例子来与大家分享。
-
方案2不论是从零开始搭建的项目，还是已经成型的项目，方案2都适用。
