This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Java in General and the fly likes Ho to not use casting on this generics? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "Ho to not use casting on this generics?" Watch "Ho to not use casting on this generics?" New topic
Author

Ho to not use casting on this generics?

Johan Zahri
Greenhorn

Joined: Oct 20, 2009
Posts: 9
Dear all,
I have the following code:



Does anyone knows a better way of the usage of generic to avoid using

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Regards,
Johan


Best regards,
Johan
Johan Zahri
Greenhorn

Joined: Oct 20, 2009
Posts: 9
never mind I just did away without using generics..
i guess it's sufficient..

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7892
    
  21

Johan Zahri wrote:Does anyone knows a better way of the usage of generic to avoid using

I was thinking well since I know that XResult has a way to instantiate itself there is no way that the casting would not work., would it?
But it just doesn't feel good using casting, somehow.

Well spotted. "Code smell" is a good sense to acquire, so don't ignore it.

And to answer your question: yes there is - make Result generic too.
In this case, it's as simple as:then whatever class extends Result uses the notation:which results in a getNewInstance() method that returns a Failure.

BTW, generic types, by convention, are usually a single upper-case letter, rather than things like 'XResult'. This is so you can distinguish them from regular class/interface names. The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

HIH

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7892
    
  21

Johan Zahri wrote:never mind I just did away without using generics..
i guess it's sufficient..

Looks fine to me. You don't always have to use generics .

Winston
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19697
    
  20

Winston Gutkowski wrote:The norm is to use 'T' (for 'Type') unless you have a good reason not to, but it's not required. For instance, an interface like Map<K, V> uses its notation to distinguish between 'Keys' and 'Values'.

Don't forget E for element types, like those of collections and iterables. But keep in mind that the name is always free to choose. For instance, I have one interface with I for the input type and O for the output type, because these make more sense than T and U, for instance. I therefore am more inclined to use either a simple T (for type), or the first letter of what the generic type represents (Key, Value, Element, Input, Output).


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7892
    
  21

Rob Spoor wrote:...or the first letter of what the generic type represents (Key, Value, Element, Input, Output).

Absolutely. I was just trying to say that 'T' is normal unless you can think of something better.

Winston
Johan Zahri
Greenhorn

Joined: Oct 20, 2009
Posts: 9
Thanks guys for all the input.

Just realized that what I was actually trying to do (quite a distance from the topic.. sigh)
turned out its already implemented in java.util.concurrent.RunnableFuture<Result> :P

As one wise man says..
"reuse!"

Cheers.
 
GeeCON Prague 2014
 
subject: Ho to not use casting on this generics?