父类对象和子类对象之间究竟能否equals
http://www.iteye.com/topic/1119409?page=4

楼主的问题，让我现在思维都还不能停止。现整理了一番，同时也是对自已一次认知的梳理。

楼主的问题是：父类对象和子类对象之间究竟能否equals。并举了一个例子：
public class Employee｛//员工; private Manager manager;//身份，不为null表示经理，否则是普通员工 public Employee load(xxxx){//从数库中加载，并形成一个实例。 //算法描述为： 先在经理表中，查询该员工是否是经理，如果是经//理，按经理类的加载方法加载，并返回一个Manager对象；如果//不是经理，按普通员式方法加载,并返回一个Employee对象。 ｝ ｝ public class Manager extends Employee｛//经理 public Manager load(xxxx){//从数库中加载，并形成一个实例 ｝

所以，在我的软件设计世界中，不同类的对象之间equals永远是false.

我把我的理解整理出能，希望能给某些朋友以启迪

最后，我已经把上面这一段，存放到我的blog里，望楼主不要介怀。


//==========================本想结束，有朋友继续问，只好继续一下=========

kidneyball 写道楼上的朋友，你的设计在父类里硬编码了子类，没法扩展呀。如果我又想从Employee里继承出来一个TempEmployee（临时工），那不是又要往Employee里加一个TempEmployee的对象域？

另外，“如果在项目中，身份最低就是员工，最多是经理，没有其他时，可以化减模型”这句话谁也不敢写包单的，还是遵循开闭原则比较稳妥。

朋友说得很到位。

关于硬编码 ，就要看怎么编码了，编得好就能扩展，编得不好，就扩展不了。 本来第一感觉是用策略模式，把不同的加载方法进行封装。但时，在使用中是非常不方便的，当需要用父类加载所有子类的实例时，通常不知道子类的类型，所以取消策略模式的念头。

那么上面的方法就真的不能扩展子类了吗？ 答案是否定的。关键在于，保存上的数据格式设计问题。 在数据库中，有一表专门存储各种子类的检索表，当某个子类保存到数据库时，他保存的地方，就必须要在检索表中注册，并严格按照检索表的约定去存放。 这样父类加载时，先查遍检表的信息，以确定子类身份，并按相应方式加载。

这种方法效率有点低，特别是当子类众多时。 但是，不管怎么说，至少有一种方法能实现子类扩展问题。再有的继承上，去优化，去思考效率更高的方法。

另外，当这种情况----即子类特别众多，我会怎么办？

在我的软件设计世界中，我又会马上去检查我的需求模型设计，这里又出了致命的重大问题。

因为，在我的软件设计世界中，这种类继承关系，不是用来表示软件的被操作部份-----即数据部份；而是用来表示操作者--即程序本身。 道理非常的简单，现在的大多数面向对象的编辑语言，一旦类写好，类继承关系确定好，在程序运行里，是非常难改变继承关系的，也很难改把运行实例的类，改成另一个全新运行的类。 如果用类继承关系去描述那些被操纵的数据部份，这些对象的继承关系一旦发生变化，整个项目再难继续进行。

那么，当程序要操作的 对象的类，本身有众多的继承关系怎么办？

在我的软件设计世界中，我会把这些关系，用数据结构去描绘，去建模，而不会用类继承关系建模。类继承关系建模，永远给软件的控制系统部份。注：请对数据结构重视不够，或理解不够深的朋友，请不要轻易让其他同行放弃数据结构的学习与领悟。 当然了，这是从我的理解角度 说出的建议了。

故当有众多子类需要保存到数据库中，我会检查我的需求建模。

对于第二个问题：
引用 另外，“如果在项目中，身份最低就是员工，最多是经理，没有其他时，可以化减模型”这句话谁也不敢写包单的，还是遵循开闭原则比较稳妥。

首先你的这个提法，不错，我赞同。
但是，如果项目价值不大，花的成本很小，需求变化特小，按适合就是最好的原则，按简化的做，没问题。