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'.
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here
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).