• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Interface and Composition realtion

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
     
    Kaveri Das
    Greenhorn
    Posts: 11
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Frank and Edwin! Very Good Explanation!
     
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Ranch Hand
    Posts: 43
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ]
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic