views:

55

answers:

3

Hi all,

public class Elevator ()
{
 Button firstFloorbutton      = ButtonFactory.getButtonInstance(this, 1);
 Button secondFloorbutton  = ButtonFactory.getButtonInstance(this, 2);
 Button thirdFloorbutton     = ButtonFactory.getButtonInstance(this, 3);
 Button fourthFloorbutton   = ButtonFactory.getButtonInstance(this, 4);

 Fan fan1 = FanFactory.getFanInstance(this);

 Light light1 = LightFactory.getInstance(this);

 private void goUp()
 {
    .....
 }

 private void goDown()
 {
   ......
 }

   .............   

 }

        ============================

 public class Button()
 {

   Elevator E;
   int floor;

   public button (Elevator E, int floor )
   {
    this.E = E;
    this.floor = floor;
   }

   public void buttonPressed()
   {

   //logic to determine which floor the elevator is currently at and determine whether to go up or down to reach "this.floor"

   E.goUp();  // if need to go up

   else

   E.goDown()   // if need to go down

   }
} 


    ==========================


    public class ButtonFactory()
    {

      public Button getButtonInstance(Elevator E, int floor)
      {
         Button b =new Button(E, floor);
         return b;
      }
    }

     ==================

    public class FanFactory(){ .................}

     =====================

    public class LightFactory() { ........... }


     ==========================

What kind of relationship exist between the Elevator and Button class?

According to Kathy and Bert (SCJP) page 92 : HAS-A relationship are based on usage rather than inheritance. In other words, class A HAS-A B if code in class A has a reference to an instance of class B.

In my example Elevator class code have a reference to a instance of Button and Button have a reference to instance of Elevator class.

Can anyone please clarify on this.

A: 

It is a Has-A relationship, which is a simple way of remember the composition model. Button class is composed of Elevator class; i.e. Button class has a Elevator class.

HTH,

EB

echobravo
+1  A: 

The Elevator has a button. Actually, it has four, but with each of those buttons, there's a has-a relationship.

Has-a is a somewhat informal term used to refer to two more formal kinds of relationship: association and aggregation. In both cases, one party in the relationship has a pointer to the other, but they're distinguished by semantics: in an association relationship, the first party knows about the other, but doesn't completely dominate it (think you and a colleague, or a boss, or a subordinate), whereas in an aggregation relationship, the latter party is part of the former party, and has no independent existence (think you and your liver). In this case, i'd say the Button is more specifically on the subordinate end of an aggregation relationship with the Elevator, not merely an association relationship.

Other examples of association might be a Customer and a Salesman, or a Department and an Employee. Of aggregation, an Order and and OrderLine, or a Structure and a Component. Interesting corner cases are a Category and a Product, and an Order and an Invoice.

One practical consequence of the kind of relationship is object lifetime: in an association, if the first object dies, the second may live, but in an aggregation, it will die. Think about your Elevator: if you deleted one (or removed it from your live data structures and let it be garbage collected, at least), would you want the Buttons to survive?

Tom Anderson
Great explanation Tom. Thanks.
AKh
A: 

I have heard of "Composition" relations.... Is there any composition relationship between these two classes?

AKh