Manuel Petermann wrote:
I do know that he is free to choose. I just don't like it in this case.
It's not clear at all to me what you don't like.
From my point of view one should use extends only when absolutely necessary.
That's a little extreme, but yes, classes are extended in a lot of cases when they shouldn't be. In particular, it's generally a bad idea to extend a concrete class.
I read that getters in interfaces are bad practice so i assumed that was the case for all types. Maybe the word getter even is the wrong word for my case.
Thanks for your answers.
I'd say "getters in interfaces are bad practice" is a bit too broad, vague, and absolute. It may be coming from a good place though, just poorly worded. I would say that interfaces are meant to specify what behavior must be present, and requiring a class to expose its internal state (the usual use of a getter) is usually a sign of bad design.
However, requiring a class to produce some object, such as to provide an implementation for another interface, is covered by one or more well established patterns, and if that's what we're doing, then the real issue may be, "Should we name this method something other than getXxx(), so as not to have it confused with a normal getter method?" Some would say don't use the getXxx() name, to avoid that confusion, and others would say it's fine to use it, since it is (at least in some cases) a properly descriptive name, and it's clear from the context (and documentation) that it's not a normal getter. I personally go back and forth in my opinion on that, and I don't think it's that big a deal in most cases, but if you're in a context where it's likely to cause confusion, or could result in some aspect of your app incorrectly treating that as a property in a JavaBean, then I would find a different name.