I know that we have to use abstract class when in future we want to add some method which can be common to all subclasses and we use interface so that the implementation class can not only inherit the methods in the interface but can also extend another class. Can someone give me one real world scenario where we can use an abstract class instead of an interface and vice verse?
You can use interface in the place of abstract class, but in some critical cases you have to use abstract class, the best example is, if you are developing an authentication framework, this authenication framework can connect to any external system, and the rules are follow,
User should extend this class and must and should override userid and password and systemtype methods but not login method, you implement authentication mechanisam in the login method.
in this senario you have to go for abstract class.
I did not find a good scenario online.. that is why I have posted it here.. I know the differences and I have mentioned it too.. it's just that I was wondering if someone could tell me a real world scenario.
We have an service where our customers have to implement their own implementation of the service, since we do not know how they want to use the data that we are provide.
Since this service render a cost for the implementor when they go live and they acctually might break the server if the implementation don't respond in the way we need it to, we have three different implementation of the same abstract base class. The first one is just a stubbed one that creates log files. When the customer can show us a log that shows the right stuff for our test-cases, also provided in the test-ourservice1.0.0.jar, we ship the ws-ourservice1.0.0.jar that has the web-service implementation and the configuration to our test-servers. Normally, the implementors pass the acceptance test within hours after getting the ws-version of our abstract class and can then go live.
We change the WS to meet new demands nearly every release but we never break the internal API but that never effects the customer. They just get the test-ourservice.1.1.0.jar and link to it and see if the test cases is successful or not and can then move to the production environment when needed.
I think Arjun knows what is the abstract class and what is the interface. He is searching.... when we should use abstract class and when we should use interfaces
Interfaces also denote an IS-A relationship. Building could just as well have been an interface: House implements Building.
I tend to go for interfaces as much as possible, because then you can implement the interface and extend another class. That's why I made my own copy of java.util.Observable - because it's an abstract class I cannot extend another class. And having a field of type Observable just seems dumb.
My structure, usually: - interface X - class AbstractX implements X (for the basic functionality) - class ConcreteX extends AbstractX
Kind of how the Collection framework is defined: - interfaces Collection, List, Set, Map - classes AbstractCollection, AbstractList, AbstractSet, AbstractMap - classes ArrayList, HashSet, TreeMap, etc
That way, you can extend the abstract class if you're feeling lazy, but still implement the interface if you're already extending another class.
I did not find a good scenario online.. that is why I have posted it here.. I know the differences and I have mentioned it too.. it's just that I was wondering if someone could tell me a real world scenario.
Thanks.
I meant using the search facility of Javaranch provided above.
Post by:autobot
Arch enemy? I mean, I don't like you, but I don't think you qualify as "arch enemy". Here, try this tiny ad:
a bit of art, as a gift, that will fit in a stocking