检测对象类型然后相应地转换它？
我的方法将对象作为输入。我如何确定它的类型，然后进行相应的转换？
例如： binarySearch( Object o );
在binarySearch方法中，我需要一种方法来确定Object o的类型（或类）。然后我需要用那种类型来投射它。我该怎么办？
更具体地说，Object o 是基类的子类（EG SalariedEmp 是 Employee 的子类），而我特别需要基类。
编辑： 我弄清楚了如何做我想做的事，这确实应该是一个完全不同的问题。我需要使用 Comparable 中的 .compareTo 方法来设置一种方法，根据这些对象的私有数据来比较两个对象。我所要做的就是使用 implements 关键字将我的类实现为“Comparable”。因此，无论在我的binarySearch方法中比较什么类型的对象，如果它们属于相同（未知）类型并且实现了Comparable，那么它就会起作用。这使得我的 binarySearch 方法非常适合任何类型的类似类的重用。
因此，平心而论，我会接受涵盖原始问题的答案。
:)
My method takes as input an Object. How do i determine it's type, then cast it accordingly?
So for example: binarySearch( Object o );
Inside the binarySearch method, i need a way to determine the type (or class) of Object o. Then i need to cast it with that type. how would i do that???
And more specifically, Object o is a child of a base class (EG SalariedEmp is child of Employee), and i specifically need the base class.
EDIT:
I figured out how to do what I wanted, which really should be a completely different question. I needed to use the .compareTo method from Comparable to set up a way to compare two objects based on private data from those objects. All i had to do was implement my class as 'Comparable' using the implements keyword. So no matter what Type of objects are compared in my binarySearch method, it works if they are of the same (unknown) type and have Comparable implemented. This makes my binarySearch method very re-usable with any type of comparable class.
So, in all fairness, I'll accept the answer that covers the original question.
:)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有两种方法可以实现此目的：
使用
instanceof运算符。在对象上调用
getClass()（确保首先检查 null）。Two ways to do this:
Use the
instanceofoperator.Call
getClass()on the object (make sure to check for null first).您可以通过使用instanceof运算符或在实例上调用.getClass()来使用RTTI（运行时类型识别），但这几乎总是表明您正在使用的超类型要么是错误的超类型，或者设计不好。
就您而言，您不需要使用对象，因为您已经知道您至少有一个员工。
面向对象范例是，您不会询问对象实例它是什么，而是要求它执行某些操作。在这种情况下，您可以选择要求 Employee 对象执行的几项操作。哪一个对您来说是最佳选择取决于您要建模的具体内容：
您可以询问它是否受薪，然后通过添加虚拟方法
boolean isSalaried()来转换它到 Employee 基类。基本方法将返回 false，但 SalariedEmployee 将重写该方法并返回 true。但是，虽然这避免了（可能更昂贵的）RTTI，但它并不能避免强制转换。您可以添加一个方法 SalariedEmployee asSalariedEmployee()，该方法在基类中将返回 null，而在 SalariedEmployee 中将返回
this。这为您提供了“安全”的强制转换，但您仍然需要针对 null 进行测试。或者您可以只向 Employee 添加 Money getSalary() 方法。现在您不必进行任何选角，但您需要确定无薪员工的薪水是多少；可以是 null、零或 NaN（特殊的非数字值）。
如果您决定返回 null，在某些情况下（例如，添加值）您必须针对 null 进行测试，而在其他情况下（例如，将薪水传递给 .equals()），您不需要针对 null 进行测试，因为根据 Object.equals() 的规范，任何 instance.equals(null) 都应返回 false。
如果返回零，则可以添加而不测试 null，但 equals 可能有点奇怪 - 两个小时工，每个人都没有薪水，有相同的（不存在的）薪水，真的是这样吗？这取决于您要建模的内容。如果为真，则返回零。
如果两个小时工的工资不存在相同，则返回 NaN 值。这只是“空对象模式”的一个特例。
You can use RTTI (Run-Time Type Identification) by using the instanceof operator or by calling .getClass() on the instance, but that's almost always an indication that the super-type you're using is either the wrong super-type, or is badly designed.
In your case, you don't need to be using Object, as you already know that you at least have an Employee.
The Object Oriented paradigm is that you don't ask an object instance what it is, you ask it to do something. In this case, you have a choice of several thing you might want to ask an Employee object to do. Which one is the best choice for you depends on exactly what you're trying to model:
You could ask it if it is salaried, and then possibly cast it, by adding a virtual method
boolean isSalaried()to the Employee base class. The base method would return false, but a SalariedEmployee would override that method and return true.But while that avoids (the likely more expensive) RTTI, it doesn't avoid the cast. You could add a method SalariedEmployee asSalariedEmployee(), which in the base class would return null and in a SalariedEmployee would return
this. That gives you a "safe" cast, but you still need a test against null.Or you could just add a Money getSalary() method to Employee. Now you don't have to do any casting, but you'd need to decide what the salary of a non-salaried employee is; that could be null, zero, or NaN (the special Not a Number value).
If you decided to return null, in some cases (e.g, adding values) you'd have to test against null, in others (e.g, passing the salary to .equals()) you wouldn't need to test against null, as any instance.equals(null) should return false by the specification for Object.equals().
If you return zero, you can add without testing against null, but equals might be a bit weird -- is it really true that two hourly workers, each of whom get no salary, have the same (nonexistent) salary? That depends on what you're modeling. If it is true, return zero.
If it's not true that two hourly workers have the same non-existent salary, return a NaN value. This is justa specific case of the "Null Object Pattern".