前言:

• 对于一个大项目而言，最烦恼的就是在众多界面难以找到对应的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都适用。