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

请教一下hibernate继承和sql建表时的继承有什么区别呢？

hibernate继承没用过,但我自己做过类似的事情,感觉很复杂.

如果计划的状态不同时,行为没有很大的区划别,可以考试以下方式
计划是个类,有状态属性
另外应有个行为接口,根据状态不同,接口有不同的实现.
计划类中有行为接口,它的状态不同,依赖接口执行不同的行为.

数据库设计,一般就一个表,有时可能两个表会好点.

不知道大家有何其它见解~

简单起间。可以把teacher和student写成一个Role的enum。Person包含了一个Role。这样的改动对原有的数据库没有影响。以前我们都是利用Hibernate的自定义类型，实现方式类似于用类代替enum的方法（相见《Effective Java》）

这回答甚合我心。

Java继承机制中有一点是这么说的：一个对象创建的时侯一定是某个确定的类实例，就像人出生性别就已经确定一样。要改变子类的状态，就像男人变成女人，则要做手术，JAVA类子类之间是不能做“手术”互相转化的，所以，手术只有删掉“男人”再造一个“女人”。

子类的状态可以独立出来作为一个关联对象使用，所谓学生变老师，只是身份的变化学生身份变成了老师身份，而不是个体的之间的转化，不能是A学生变成了B老师。已经执行和未执行的计划之间不能相互转变是因为你把执行和未执行当成了完整个体的一部分了，这部分恰好是不可分隔的。

这一问题,无关乎状态的变更.假设这样一个场景,一个学生XX在学校读书有历年的成绩，当他毕业后留校任教.此时当他自己去查询以前的成绩时，他看到的是教师XX，数学多少分呢，还是学生XX,数学多少分?

我也是想知道学生XX转变成老师XX后，存在什么相应的改变呢？怎么去适合这种改变？有什么比较平稳的办法？

你这样不尴尬那就怪了

既然状态是可变的，那就应该封装起来做为一个单独的类，当计划改变时，就发消息给状态类，而不是只用继承。 面向对象不只是继承。 很多时候是可以用一个间接层来解决问题的

get
new
set
delete
save