• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 177
Hibernate Python Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 177
Hibernate Python Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Been there. Done that. Went back for more. But this time, I took this tiny ad with me:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic