Hi Folks, I am new to the forum. I have a doubt. The doubt is in abstract class vs. Interface.The question is ----
Can an Interface have Composition relationship with some class
What I understand ---- it is preferable to use interface than Abstract class. I got from some of the links that Abstract class is better if ease of evolution is more important than flexibility and power. Now keeping this in mind what is your opinion ; can I make VEHICLE an Interface which has composition relation. Actually what is the significance of composition relation of an interface with a class -- is it valid UML?
There are 3 classes : 1.VEHICLE (Abstract class OR Interface???) 2.SEAT 3.BUS (extends OR implements VEHICLE???) 4.TAXI (extends OR implements VEHICLE???)
VEHICLE has composition relation with Seat. ************* Diagram *************
First of all, I must say that I do not know if it is correct to say that it is better to use interfaces instead of abstract classes.
There are advantages and drawbacks for every approach, and those you have to understand, it is not just saying that one is better than the other. Thinking this way would imply the deprecation of the abstract class approach.
Abstract classes have the adventage of providing partial implementation that can be reused by all the subclasses. However, in Java, a class can only extend another class.
Interfaces do not provide implementation, which implies that you may need to do the same work over and over again in every class that implements one of them, but they have the advantage that a class could implement multiple interfaces.
Now, when it comes to real implementation, a composition is implemented as the WHOLE class having a collection or array field member containing references to objects of the PART class.
Since interfaces cannot define instance field members, at least in Java, it is no possible to define a composition relationship where an interface plays the role as the WHOLE. But you could do it with an abstract class.
What do you guys, think? Do you think that is correct? [ May 27, 2006: Message edited by: Edwin Dalorzo ]
In this situation, I think there is room for both interface and abstract class.
the arrangement shown of
1.VEHICLE (Abstract class OR Interface???) 2.SEAT 3.BUS (extends OR implements VEHICLE???) 4.TAXI (extends OR implements VEHICLE???)
Seems not quite flexible enough to model the real world. It can't handle (for example) walker-guided or robotic vehicles, or vehicles where everyone stands.
I'd probably do something else, maybe like
Vehicle: interface, only the methods which define a vehicle, maybe name, position, heading and current velocity (or whatever)
PassengerVehicle: interface, extends Vehicle, adds methods about seats and occupancy
FixedOccupancyVehicle: abstrct class, implements PassengerVehicle, has member variable for number of seats set in constructor
VariablOccupancyVehicle: abstract class, implments PassengerVehicle, has member variables for min/max passengers etc.
Bicycle: class extends FixedOccupancyVehicle(1)
SportsCar: class extends VariableOccupancyVehicle(1,2)
FamilyCar: class extends VariableOccupancyVehicle(1,5)
Bus: class extends VariableOccupancyVehicle(1,50)
TourBus: class extends VariableOccupancyVehicle(2,50)
I hope you get the idea. Common domain objects typically extend an abstract class which provides a "standard" implementation an interface. Unusual objects (a remote-guided cargo trolley, for example) can implement the interface directly. Most importantly, Mock objects used for testing can implement the interfaces directly.
I'm coming late to this, but to one specific question in the OP, you don't really specify composition in an interface. You can specify signatures. The Vehicle interface might have a method that returns a collection of Seats. That tells us that Vehicle has some relationship to Seat but the exact relationship is not specified. That lets the Vehicle implementing class use Seat in any way that makes good sense. One implementation might "own" the seats and destroy them when we destroy the vehicle. Another might "borrow" them and return them to the parts department when we destroy the vehicle. (goofy example, sorry)
As for when to use Interface and when to use abstract class ... use the most abstract thing that will work at the moment. Say you're building this package of vehicles and I'm going to buy your package and use it. You could provide interfaces for everything and I would write my code to use the interfaces. You might also provide abstract classes or default implementations of a few things and I might or might not use those.
For example, my code might look like this. I'd import the interfaces from your code.
I use the most abstract choice I can at any time. I use interface types to refer to objects. I use a concrete Vehicle of some default class (that I'll never need to know the name of) when that works. I extend the abstract vehicle if it provides some good default behavior, or implement the interface if I'll provide all my own behavior.
There are many right choices depending on my needs. The only seriously wrong choice is trying to extend a concrete class like DefaultVehicle. That's why it's good that I never need to know its class. Maybe I can't even access it inside your package.
This idea of providing a product, a shrink-wrapped package to another team or your mates or yourself is pretty good. It focuses you on providing good abstractions, keeping your code open for extension but closed for modification.
Let me know if all that lined up with the original question.
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
Hi kaveri Both Abstarct classes and Interfaces have there own significance.1 thing i would like clarify before comming to your doubt that Interfaces are not the replacement of multiple inheritence
Let me give a wonder full example to elaborate ur doubt
vechicle | four wheeler | car
we have a heirarchy like i have shown above In this case vechile SHOULD BE ABSTRACT CLASS now Think of this scenario
clothes | above waist | t-shirt
This is also self explanatroy and in this case also the clothes should be abstract class
Now we have seen two hierarchies ,where does the interfaces comes in picture?
see We have a class called sporty and another class called formal
Our concreate class car can be a sporty car(ferrari) or a formal car(Mercedez benz) Isn't it? And at the same time our t-shirt can be a formal t-shirt(duke) or sporty t-shirt(nike)
vechicle | four wheeler | car
clothes | above waist | t-shirt
Word interface says it all interface means somthing acting as a adapter between two unknown things
Ok Here's a better example
YoU HAVE A GAME APPLICATION BRICKS
where this application is a gaming application you want it to be a multithreaded application.Reason being this class is doing multiple tasks together
ball moving bar moving bricks falling
So what will u do to give it a multithreaded effect extends Thread and boom U are denying app from using if any requried gaming effect class. So what will you do
class BricksApplication extends GenericBrickApp implements Runnable
So your application is multithreaded gaming application The adjective effect given by multithreaded keyword signifies interface
I know its exhaustive u might have never reached this sentence but i cant help it this is my favorite topic
in case of any doubt please post a reply
Joined: Jan 29, 2003
I think I disagree with almost all of that. Given a hierarchy like:
I wouldn't see any strong reason YET to make Vehicle an abstract class. There MIGHT be some reasons like Vehicle winds up with useful behavior that every possible vehicle will want but we'd have to know quite a bit more about the design to say that. The same goes for FourWheeler. If Vehicle is an interface FourWheeler could be as well unless it provides some useful behavior. One thing I would say is Vehicle and FourWheeler should NOT be concrete classes; extending a concrete class opens up too many opportunities to go bad.
An interface "acting as a[n] adapter between two unknown things" doesn't ring true either. It's no more than a contract that promises any implementing class has a certain number of methods. Your example tells us that Sporty Cars and Sporty Shirts both implement the methods defined by Sporty. "Adapter" has a very different meaning.
Preferring implementing Runnable over extending Thread is definitely good, though. We've had this discussion many times up in the threading forum. Thread being Runnable was probably a poor design to start with, we are hard pressed to make up a reason to extend Thread, and again extending any concrete class is something to avoid.
Use the most abstract thing that will work!
[ May 30, 2006: Message edited by: Stan James ] [ May 31, 2006: Message edited by: Stan James ]