• Post Reply Bookmark Topic Watch Topic
  • New Topic

set method return type , determined inside method  RSS feed

 
Daniel Gurianov
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All.

I need to write a method that will consume string representation of Object type and will return one object of this type.
How to set return type for the method in this case?

Here is exmaple :







 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not just return a Class object?

I say that because I have no idea why you need this method. For one thing, most classes don't have a canonical object like in your example.
 
Daniel Gurianov
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul, you are seducing me to spoil whole story ))).

Ok, i`m dragging metrics from apache Cassandra NOSQL DB from JMX bean connection.
From the JMX end (if you will try to fetch this property from JMX), each metric is java.lang.Object type, but in fact , metric value falls under 3 java types :
it is eather Integer or Long or Double . I havent checked all metrics , but i hope that i will not find boolean somewhere, so i`m skipping it.
So, when i extract metric, i need to cast it from Object to something it is supposed to be .
The only way to hadnle it , at this time , is to fill -in any type of config file where state that metric X returns double and metric Z returns Integer.
While i parse this confing, i have type in form of String object and i need to make transition from String representation of type to actual Type object (Ineger, Long... etc).
Method what i`m asking about , will be this tool that will help me to get object of the type i need to cast metric from Object to proper type.

I hope i was clear in my explanation .
 
Deepankar Narang
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at your explanation, I am bit curious to understand why do you need the config file. If I understand your problem correctly, this is what you need :-

ApacheCassandra (Actual type) -> JMX (Object type)

At JMX end you need to know what type it is and use it appropriately?

You could get the type using instanceof operator.

 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deepankar Narang wrote: . . .
You could get the type using instanceof operator.
. . .
Whenever I see that sort of code, I start to think that is not an object‑oriented solution.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Daniel Gurianov wrote:The only way to hadnle it , at this time , is to fill -in any type of config file where state that metric X returns double and metric Z returns Integer.

Actually, I'm not convinced (see below).

While i parse this confing, i have type in form of String...

And there's your basic problem in a nutshell. Strings are NOT objects - except in the very broadest sense - they are simply a sequence of characters that has no intrinsic meaning unless YOU decide they do.

As I see it, there are two possible solutions:
1. Pick a numeric type (eg, BigDecimal) that can hold any "numeric string" you're likely to encounter.

2. Have your program decide what type it is supposed to get. For example, if this value is in a properties file, then it might be able to do this via the label. Then you might be able to do something like:Unfortunately, it won't give you much in the way of compile-time type checking; but it will save you having to cast the result.
It also relies on the program knowing what to expect at runtime.

HIH

Winston
 
Deepankar Narang
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Deepankar Narang wrote: . . .
You could get the type using instanceof operator.
. . .
Whenever I see that sort of code, I start to think that is not an object‑oriented solution.


An API is returning Object. And we have no control on this API. As a receiver I need to determine the type. I would love to know what is the OOP alternative for this?


Happy to learn
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deepankar Narang wrote:As a receiver I need to determine the type. I would love to know what is the OOP alternative for this?

Well, many OOP languages support dynamic typing; unfortunately, Java isn't one of them.

There are also things like interface-based factories, but unfortunately it doesn't really apply in Daniel's case, because Java doesn't provide any interface for numbers other than Number, which is basically pretty useless.

Did you read my post above?

Winston
 
Deepankar Narang
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston, I did see your post and its quite relevant but it is more of UI Design driven than Data Driven. If we have loads of fields on the UI then your approach is quite painful. Adding any new field would mean adding it to this method. Data Driven approach would reduce this to some extent.

I do understand the limitations in *Java* and did not knew any alternatives so was curious to know if there were any
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deepankar Narang wrote:Winston, I did see your post and its quite relevant but it is more of UI Design driven than Data Driven. If we have loads of fields on the UI then your approach is quite painful. Adding any new field would mean adding it to this method. Data Driven approach would reduce this to some extent.

I'm not sure it would (I've actually used DDD myself); however, what I don't know about GUI (or UI) design would flll the Smithsonian.

What I do know is that Java is statically-typed, and therefore truly "introspective" (ie, reflective) logic tends to be cumbersome, error-prone, and SLOW.

Java's paradigm is to drive behaviour (and error-detection) by type, so if you don't know what a type is going to be until runtime, then you're into a new layer of complexity for the language. Interfaces, if well-designed, can provide some relief, but not total; so if you're really into a "I don't what it is until I get it" scenario, then you have a lot of decisions to make - the primary one of which is probably:
Is Java the best language for what I want to do?

It's possibly worth noting at this point that there are other. more "dynamic", languages around that also use a JVM, so perhaps a mixture of them might be best solution. My post was simply to show that "partial" solutions might be possible even in Java without delving heavily into the murky depths of reflection.

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