• Post Reply Bookmark Topic Watch Topic
  • New Topic

Convert Object to its real type  RSS feed

 
Theodore David Williams
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there an east fast way to determine what type a big O Object is?

I am working with a legacy class that has an Object as a member. But there is no constructor or setter the takes an Object type as a parameter. Instead there are multiple overridden methods that take different types. i.e.


My life would be a lot easier if I could have a constructor that takes an Object. I.E. I want to deprecate some methods in this case and start using things like Map<String, Object> since I want my map to contain Objects I cannot iterate through the values which are objects and call the setter in this class.

so I need:



I don't think there is an easy answer as I asked for something fast ;) but thought I would ask anyways.

Thanks!!!
 
fred rosenberger
lowercase baba
Bartender
Posts: 12563
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
would something like this help?
 
Theodore David Williams
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah I was thinking that was my only option but as Pete says in the link you sent:

Java is an object-oriented language (some would say not 100% so, but...). One therefore has powerful features like polymorphism available, to make objects of different types behave differently when sent the same message (method call). One should use those object-oriented features as much as possible.

It is usually bad practice to write code that conditionalises (if, switch etc.) on the type of an object. As much as possible, this should be replaced by something more object-oriented.

It's not a hard-and-fast rule. Although some Ranchers may disagree, I favour pragmatism. If a particular problem can be solved much quicker by using instanceof than by refactoring to use polymorphism, then it may be OK to use instanceof. But don't get too much into the habit.

If you were thinking of using getClass() or instanceof in an "if" or "switch" statement, you should probably go back and revisit your design.


Also another reason I really do not want to do this is I need a case for every expected type. Since my constructor takes an Object the number of types is infinite. I cannot account for infinite cases. I guess I was looking for a polymorphic way to pass an Object but have it call a constructor that takes an Integer (if it really is an Integer) rather than the constructor that takes an Object.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Theodore,

is the code calling this code (= mess) under your control? That means can you modify the client code of this thing?

If so you could create one or more wrapper classes for int, String etc. which implement a common interface and encapsulate the action you want to do for each type. Something like

Then the code you want to clean up could simply use ONE method which takes an object of the type of this interface and calls the "doSomething()" method on it. So the logic wouldn't be a cascaded switch or if-else statement inside the code which receives the object but instead inside the objects which are wrapping this primitive types.

Anyway, the typical reason for large switch or if-else statements in OO languages is that functionality is not where it really belongs. So you have to decide what to do depending on the type of a parameter like in your example. The alternative is to move this action into a place where it simply has to be called independent of the concrete type used.

I hope his was more or less clear Of course it depends on how much influence you have on this code.

Marco
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!