特殊情况特殊处理

最近要全新架构另一个App，总结之前的经验，体会到了一个道理：特殊问题特殊处理。

在之前的App架构中，我总是趋于实现一个普遍的通用的框架，想把所有的业务、功能都纳入到这种框架的规则之下，这导致我的框架越来越庞大、臃肿，基本的普通的业务和功能模块倒是没什么问题，而那些特殊的业务和功能模块，也要硬生生地被拉进去听从这个规则，显得非常勉强。

比如，所有的子页面，会为它们抽象出一个BaseActivity和BaseViewHolder分别当做公用的Controller和View。但App的首页，是一个ViewPager+Fragment实现的Tab页，于是我又给它实现了个BaseFragmentActivity，代码基本跟BaseActivity一样，这导致了重复代码。并且还导致BaseViewHolder既要处理BaseActivity又要处理BaseFragmentActivity，代码很臃肿。这次全新架构App我想明白了，首页只有一个，别的地方根本不会用，为什么还要抽象一个Base出来？把首页当做一个特殊情况特殊处理就行了。

再比如登录页，虽然它页面本身不是特殊的，可以纳入到BaseActivity下，但它的跳转却是特殊的。举例子来说，A页面跳转到B页面，B是一个需要用户登录后才能看到的页面，这个时候，A->B就要插入一个登录页C变成A-C-B，如果到C后用户放弃登录，就又变成了A-C-A，如果在登录后的B页面用户异外登出，需要再次跳转到登录页C然后再返回到B，那么上一个B页面可能已经失效了，这种情况最好的产品策略是B-C->首页，让用户从首页重新进入B，而不是B-C-过期的B。所以登录页的跳转是复杂的、特殊的。我之前一直想把跳转到登录页纳入到BaseActivity中，就是当到达一个BaseActivity之后，才去检查是否需要登录，然后自动跳转到登录页，再拉回来。这样搞导致代码臃肿，逻辑复杂，代码不容易看懂，坑很多。最后我想明白了，登录页的跳转就是个特殊情况，在所有需要登录才能查看的页面的入口处检查下是否登录不就行了，这种入口一共也没有几个。

我觉得我之前的架构思路是一种轴和偏执，想用模板规范个体，不允许多元化，扼杀个性。