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'.
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 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).