GeeCON Prague 2014*
The moose likes Java in General and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark ""Has a" vs "is a" in Interfaces or "Getters in Interface"" Watch ""Has a" vs "is a" in Interfaces or "Getters in Interface"" New topic
Author

"Has a" vs "is a" in Interfaces or "Getters in Interface"

Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

When I use libraries I always hate it to use extends rather than implementing some interfaces.
I now am to program such a library and i am sort of reluctant to force the user to use the extends keyword.
Now lets say we have the case:


Problems with case 1:
If the implementation for A is not likely to change, you are forcing the user into an abstract base class.
This again would force the user to extend from this base class to add his own functionality leaving no room for other base classes.

Problems with case 2:
Writing an interface just to get another interface fells like a big code smell to me.
It might be more problematic to get some field references to A without breaking the code depending on the implementation.

I think case 2 is better but i have a big concern about the getter interface.
I have read this on stackoverflow but my concerns are still valid i guess.


Please correct my English.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11350
    
  16

Manuel Petermann wrote:If the implementation for A is not likely to change

I guarantee that the implementation for A IS likely to change. I don't care what it is or what it does, but about the only constant in software is change.

There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Manuel Petermann wrote:When I use libraries I always hate it to use extends rather than implementing some interfaces.
I now am to program such a library and i am sort of reluctant to force the user to use the extends keyword.
Now lets say we have the case:


Problems with case 1:
If the implementation for A is not likely to change, you are forcing the user into an abstract base class.


Eh? By "user" I assume you're referring to the programmer who's implementing your interface. No, he is free to choose an abstract or concrete implementation. Which one is appropriate depends on what he expects his implementing hierarchy to look like.

This again would force the user to extend from this base class to add his own functionality leaving no room for other base classes.


Again, I don't see what you're getting at here. The user can provide any combination of concrete and abstract implementations for that interface.



It's fairly common actually. I think it usually corresponds to the Abstract Factory Pattern, though it may also fit with Builder or something like it. I'm a little rusty on the Pattern details. Also, I think the convention is to use a different method name, so as not to look like a normal getter method, if that's not how it's being used, such as newInstance(). This of course depends on the semantics though. We wouldn't call it newInstance() if it didn't always create a new instance.

Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

fred you are not helping... but i failed to explained what i meant correctly so shame on me.
What I meant was:
I provide a default implementation of A.
The Class IsAnA or HasAnAImpl are from my point of view very likely to be also implementing classes of an interface B.
I do not assume that anywhere in my code, rest assured.
I do not provide a default implementation for said interface B.
The thing I want to actually achieve is a cleaner cut of responsibilities for this class.
I think you helped me nonetheless. ;)

Thanks Jeff
Yes I meant programmer.
I do know that he is free to choose. I just don't like it in this case.
From my point of view one should use extends only when absolutely necessary.
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.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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.
 
GeeCON Prague 2014
 
subject: "Has a" vs "is a" in Interfaces or "Getters in Interface"