Hello everybody I have seen many people use this pattern and cannot figure what does it really buy you ? You have an interface which and abstract class implements an dfinally you have ur implementation that extends the abstract class Ex: public interface Command { ..... }
abstract class TransactionalCommand implements Command { .... }
class UpdateCommand extends TransactionalCommand { .... }
What does this buy me ? why do i need to abstract the implmentation ? why not use public interface Command { ..... }
class UpdateCommand implements Command { .... }
I would greatly appreciate your feedback than you -Reeve
In this context, the abstract class can be a way to provide a "basic" (or partial) implementation of the interface, making it easier for concrete classes to use the interface.
For example, suppose the interface declares 30 methods. Perhaps 25 of these can be implemented in a basic way (in an abstract class), leaving only 5 that a programmer must write implementation for in a concrete class. This is a great convenience. And of course, any basic implementation in the abstract class could still be overridden if needed.
For a good example of this in the API, see the class description for java.util.AbstractList. [ December 14, 2005: Message edited by: marc weber ]
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Jim Yingst
Wanderer
Sheriff
Joined: Jan 30, 2000
Posts: 18670
posted
0
Well the theory is that if there's some code that many or most (but probably not all) of your Command implementations will need, putting this code into an AbstractCommand is a convenient way to allow the code to be re-used by concrete Command implementations. However often this technique can increase the chance of errors in your code, as it can be easy for people to make mistakes when extending classes. I recommend Effective Java (Items 14-16 in particular) for more discussion of this point, and alternate strategies.
"I'm not back." - Bill Harding, Twister
Jason Rodrigues
Greenhorn
Joined: Oct 20, 2005
Posts: 21
posted
0
Thank you guys for your quick response , you guys are really wonderful . I appreicate you insight and why it might be applied . It makes more sense now and thank you pointing me in the right direction . I guess its time ot read some more
Ken Blair
Ranch Hand
Joined: Jul 15, 2003
Posts: 1078
posted
0
Also don't mistake that there's more or less two separate concepts being combined here. The first being that an interface defines the contractual obligations rather than a concrete type, which I agree with. The second being that it's a good idea to provide an abstract implementation of an interface, which I disagree with. The advantages of defining the contract through an interface should be obvious: it allows clients to define type by an interface and allows for multiple implementations that are interchangeable.
The second issue boils down to whether or not you think concrete inheritance is appropriate. Some will go so far as to call concrete inheritance a language defect and believe it should never be used, others think it's great to use all the time. I think most programmers fall somewhere in between, believing it is appropriate sometimes though not necessarily agreeing on when. I personally think concrete inheritance is rarely appropriate I agree with Joshua Bloch that you should "prefer composition over [concrete] inheritance." Usually any benefits to be had from creating an abstract class for an interface could be better served using composition and a class whose responsibility is to provide the common functionality desired. I'm actually tempted to say that's true always but I'm not experienced enough to be so set in my ways, so I'll leave the possibility open.
Stan James
(instanceof Sidekick)
Ranch Hand
Joined: Jan 29, 2003
Posts: 8791
posted
0
There's probably a hint in here that if an interface is so big that you need an abstract default implementation so you only have to override a few select methods, the interface was too big to start with. With other people's interfaces you may be stuck with this. With your own, see if you can't make a more focused design by dividing up the interface.
This practice gives a lot of us theoretical pause, but I just extended the abstract FilterInputStream the other day and was glad I didn't have to implement every method.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ernest Friedman-Hill
author and iconoclast
Marshal
Originally posted by Stan James: There's probably a hint in here that if an interface is so big that you need an abstract default implementation so you only have to override a few select methods, the interface was too big to start with.
Often there's also the aesthetic consideration, though. The classic example of this sort of "interface adapter" are the java.awt.event.XXXAdapter classes; the interfaces have fewer than a half-dozen methods, but if you only need to implement one, it's just plain ugly to have to see
public void doDiddlyOne(DiddlyEvent unused) {} public void doDiddlyTwo(DiddlyEvent unused) {} public void doDiddlyThree(DiddlyEvent unused) {}
In your code. So the event adapters do some good, even though they do nothing at all!
Originally posted by Stan James: I just extended the abstract FilterInputStream the other day and was glad I didn't have to implement every method.
Now image someone writing a database driver: interface java.sql.ResultSet has (... ResultSet.class.getMethods().length ...) 139 methods! Let's not even mention its subinterfaces!
Implementation inheritance come to Papa!
There is no emoticon for what I am feeling!
Tony Morris
Ranch Hand
Joined: Sep 24, 2003
Posts: 1608
posted
0
Originally posted by Jeff Albrechtsen:
Now image someone writing a database driver: interface java.sql.ResultSet has (... ResultSet.class.getMethods().length ...) 139 methods! Let's not even mention its subinterfaces!
Implementation inheritance come to Papa!
Perfect Symbiotism of Contractual Operations come to Papa! Interface inheritance, as we currently define it, assumes that time does not move. We are such silly creatures. [ December 15, 2005: Message edited by: Tony Morris ]
True story: I was visiting the town where I had lived for a spell (ah, the Moosewood Restaurant), and I saw the bumper sticker "My child is an honor role student" on a parked car. Just around the corner was a pickup truck with another bumper sticker "My kid just beat up your honor role student"
So, before our kids commence to fighting, could you locate for me a dictionary that defines Symbiotism?
Stan James
(instanceof Sidekick)
Ranch Hand
Joined: Jan 29, 2003
Posts: 8791
posted
0
I learned all about Symbiotism on Star Gate on the Skiffy channel.
Ernest Friedman-Hill
author and iconoclast
Marshal
Originally posted by Jeff Albrechtsen: "My child is an honor role student" on a parked car. Just around the corner was a pickup truck with another bumper sticker "My kid just beat up your honor role student"
Am I spoiling your irony, or enhancing it, by pointing out that it's "honor roll"?
Jeff Albertson
Ranch Hand
Joined: Sep 16, 2005
Posts: 1780
posted
0
Originally posted by Ernest Friedman-Hill:
Am I spoiling your irony, or enhancing it, by pointing out that it's "honor roll"?
A little of both.
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.