Anstract class, Interface real world scenario

[Arjun Reddy]

Hi all,

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?

Thanks.

[praveena mukkavilli]

Hi,

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.

[Amit Ghorpade]

This question has been asked many times before.Try searching the forum for more inputs.

[Amit Ghorpade]

And welcome to Javaranch praveena mukkavilli

[Arjun Reddy]

Hi Amit,

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.

[Ove Lindström]

Well, yes.

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.

[Ragav Baskaran]

 
public abstract class Car {
 
   public abstract String getCarMake();
   public abstract double getTotalCarWeight();
   public abstract int getCarSeatingCapactiy();
 
   public int getNumberOfWheels() {
      //Assuming car has 4 wheels (i mean in running condition)!!!  :)  
      return 4;
   }
 
   public double getSpeed(double distance, double time) {
       return (distance/time);
   }
 
}
 

 
public class XYZCar extends Car {
 
   public String getCarMake() {
      return "XYZ-Brand";
   }
   public double getTotalCarWeight() {
      double weight = 500;
      return weight;
   }
   public int getCarSeatingCapactiy() {
      // six seater car.
      return 6;
   }
 
   // If needed you are free to override other methods too..
 
}
 

I tried to explain with a different scenario. Let me know if it helps.

Thanks
Ragavendran

[Brij Garg]

Hi Raga,

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

[Brij Garg]

We should go for abstract class when we can find some is-a relation ship. Otherwise we should go for interfaces.

Example:

House is a Building.. so we can have Building as a abstract class and House can extend Building.

Now suppose we want some methods regarding bathroom in the house.

Then House has-a BathRoom relation sounds good as compared to its visa-a-versa.

But we can not have another class BathRoom and then House extend BathRoom... ( I hope reason is clear )

Therefore it is better to have BathRoom as a interface.


Few More Points:-----

1) look at few interfaces Cloneable , Runnable , Serializable....
All these interfaces defines some role instead of who they are.

2) Keep coupling in mind we should prefer interface to a situation where both abstract class and interface looks fine.

[Rob Spoor]

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.

[Brij Garg]

Below given statement is wrong.

We should go for abstract class when we can find some is-a relation ship. Otherwise we should go for interfaces.

Either we extend a class or implements interface.... this represents is-a relationship.

Thanks Rob

[Amit Ghorpade]

Originally posted by Arjun Reddy:
Hi Amit,

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.