aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Interface and Composition realtion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Interface and Composition realtion" Watch "Interface and Composition realtion" New topic
Author

Interface and Composition realtion

Kaveri Das
Greenhorn

Joined: May 27, 2006
Posts: 11
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
*************

...............VEHICLE <#>---------------> Seat
..................^
..................|
------------------|----------------
|...............................................|
Bus........................................TAXI


REGARDS

KAVERI
[ May 27, 2006: Message edited by: Kaveri Das ]
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
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 ]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.

    Does that make sense?


    Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
    Kaveri Das
    Greenhorn

    Joined: May 27, 2006
    Posts: 11
    Thanks Frank and Edwin! Very Good Explanation!
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    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
    Bob Mathews
    Ranch Hand

    Joined: Feb 26, 2006
    Posts: 43
    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

    ||

    sporty

    ||

    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

    regards
    Nishant
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    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 ]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Interface and Composition realtion