继承的尴尬，我该如何避免？

这个最好是用状态模式， 因为有一个状态转换的过程（这个过程也可能带有一些复杂的业务逻辑）。

状态转换是可以用状态模式，不过就楼主提供的这个例子，两个状态下，返回的结果不同，连类型都不一样。必须对这两个状态返回的方法进行规范化，提供统一的接口方法。
视情况定，如果两种状态的行为差异太大，就不适合状态模式。

这里的设计应该是这样的
person作为party对象，teacher和student是role对象，如果一个人由学生变为老师，仅仅只是注销一个角色，新增一个角色。person和teacher/student是关联关系。

父类写个方法
method（Object o）
if （xxx）{
状态改变为已执行
}else{
状态改变会为执行
}
子类通过重写这个方法和控制传递的参数来修改他
(@*#^%(#@^%(@
我随便说说....

不太明白为什么这么说，我觉得可以用状态模式啊……

有点跑题了，我的本意不是在于要讨论这个类是如何设计的，它只是一个例子而已，也许在这里不是很恰当。
我其实是想知道在hibernate的继承体制下，如何去更改子类的状态，比如说学生变老师了。也许目前想不出恰当的例子，但是我想一定是会有这样的应用场合的。

最好的一个方法，通过一个临时的字段来判断，要执行的操作，假如1已执行计划，0是不执行计划·，
楼主的意思（父类派生2个子类）而且是有一张表产生2张字表，说白肯定添加一个临时的字段，进行逻辑控制，判断 到底执行那个操作！

这确实是个有意思的应用场景，找个时间好好研究一下。你能能否把整个例子代码传上来，这样我们也好和你在同一个场景应用。

不建议用Hibernate的继承支持，会有很复杂的性能问题，是“复杂”不是“容易产生”。
光是一个查询时的下溯造型就经常让人费解。

还是用状态标志位，因为实际的需求，在这一个状态标志位相关的需求的变更概率和调整概率是非常高的。

从需求变更调整的概率上来讲，我认为决大多数场景都不适合用Hibernate继承，重构成本太高。性能也不好控制。这部分的学习曲线也不低。

就这个例子来说，从OO角度讲，“计划”这个概念本来就是一个独立的概念，而是否完成只是他的一个属性而已，如果“执行结果”和“当前进度”比较复杂的话，可以采用将这两个概念提取成独立的类，数据库设计也类似，（不会贴图，要不就来张图说明）。
如果要使用状态模式，类和数据库的设计也不是像楼主这样的，而应该是“计划”作为一个独立的类，而“计划状态”作为一个独立的类关联到“计划”，这样的话，当状态转换时，对于“计划”来说，只是需要修改状态这个属性，并且将当前的“计划状态”类关联到计划类，这个“计划状态”类可以是新建或者之前已经存在的；
其实说白了，这种需要考虑状态转换类型的需求就不应该使用继承来进行数据库和类设计，当然楼主如果只是想研究hibernate的继承是如何实现和使用的，就另当别论了