一、Android 编程反例

旨在提高项目的可维护性等，让我们做Android开发的都少掉点头发吧。。。

1、父类中定义没必要的抽象方法，强制要求子类去实现

劣质指数：五星

在项目中，我相信大家一定见过下面的代码

abstract class BaseActivity : AppCompatActivity() {
​
   override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)
       init()
  }
​
   protected abstract fun init()
}

这样写真的好吗，有什么问题呢？

init() 方法通常会被预期用来做一些 UI 的初始化工作，但是我认为这种强制性是完全没有必要的，因为父类并依赖子类中此方法的执行结果。所以子类完全可以实现一个空的 init() 方法来绕过设计者最初的期待。

弊端：增加了后期维护成本。因为这种方法是大家没有共识的，后面的开发需要去了解这些抽象方法的含义和父类中的逻辑。这样的写法一旦蔓延开来，有10个甚至更多个抽象方法，那简直就是一场灾难，太难维护了。

如果真有人一定要这样写，Init() 作为一个抽象方法，请把注释加上去吧。

init() 这种命名也不规范，init 什么呢？init view？or others？

经验小结：在写基类（父类）的时候，不要去约束子类的行为，除非父类需要用到子类执行的结果。

再看个真实案例吧：

abstract class BaseActivity : AppCompatActivity() {
​
   override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)
       onChildCreate()
  }
   
   override fun onStart() {
       super.onStart()
       onChildStart()
  }
   
   override fun onResume() {
       super.onResume()
       onChildResume()
  }
   
   protected abstract fun onChildCreate()
   
   protected abstract fun onChildStart()
   
   protected abstract fun onChildResume()
 
   // ... 其他的生命周期方法，和上面一样
}

我实在不能理解这样写的好处是什么？当我想要写一个类继承自 BaseActivity 时，我想说，我必须实现这些抽象方法的理由是什么呢？

其实看看Android系统和androidx提供的库就能发现，是不会有这种写法的。

2、