top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Design a object oriented class for a vending machine?

+4 votes
391 views
class VendingMachine
    - boolean takeMoney(Money money);
    //Here item will contain type & quantity, no smart search required 
    //say user need half litere Coke.
    - Item pickItem(Item item); 
    - boolean isAvilable(Item item)
    - Double askForAmount(Input input);
    - Double valiDateAndReturnBalance(Money money);
class Money
    -CurrencyType type;
    -Double amount  
class MoneyValidator
    - boolean validate(Money amount);
class Item
    -ItemType type;
    -Double quantity
    -String barcode; // May be anything else to identify it
class Input
    - CommandType type;
    - Double quantity
    - ItemType type;
class display
    - void updateDisplay(String instructions)
class KeyPad
    - Input readUserInput(Key key);
class Key
    -KeyType type
    -Double value

enum CurrencyType
enum ItemType
enum KeyType
enum CommandType
posted Jan 19, 2014 by Atul Mishra

  Promote This Article
Facebook Share Button Twitter Share Button LinkedIn Share Button


Related Articles

Liskov substitution principle aka known as LSP principle concept in object oriented design states that 

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."

 

This principle was written by Barbara Liskov in 1988.

The idea here is that the subtypes must be replaceable for the super type references without affecting the program execution.

This principle is very closely related to Open Closed Principle(OCP), violation of LSP in turn violates the OCP. Let me explain:

If the subtype is not replaceable for the supertype reference, then in order to support the subtype instances as well we go ahead and make changes to the existing code and add the support. This is a clear violation of OCP.

This is mostly seen in places where we do run time type identification and then cast it to appropriate reference type. And if we add a new subtype implementation then we would have to edit the code to test for instance of for the new subtype.

Let me give a subtle example:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

class Bird {

  public void fly(){}

  public void eat(){}

}

class Crow extends Bird {}

class Ostrich extends Bird{

  fly(){

    throw new UnsupportedOperationException();

  }

}

 

public BirdTest{

  public static void main(String[] args){

    List<Bird> birdList = new ArrayList<Bird>();

    birdList.add(new Bird());

    birdList.add(new Crow());

    birdList.add(new Ostrich());

    letTheBirdsFly ( birdList );

  }

  static void letTheBirdsFly ( List<Bird> birdList ){

    for ( Bird b : birdList ) {

      b.fly();

    }

  }

}

What do you think would happen when this code is executed? As soon as an Ostrich instance is passed, it blows up!!! Here the sub type is not replaceable for the super type.

How do we fix such issues?

By using factoring. Sometimes factoring out the common features into a separate class can help in creating a hierarchy that confirms to LSP.

In the above scenario we can factor out the fly feature into- Flight and NonFlight birds.

 

 

 

 

 

 

 

class Bird{

  public void eat(){

}

}

class FlightBird extends Bird{

  public void fly()()

}

class NonFlight extends Bird{

}

So instead of dealing with Bird, we can deal with 2 categories of birds- Flight and NonFlight.

How can we identify LSP violation?

  • Derived class may require less functionalities than the Base class, so some methods would be redundant.
  • We might be using IS-A to check for Super-Sub relationships, but LSP doesn’t use only IS-A, but it also requires that the Sub types must be substitutable for the Super class. And one cannot decide the substitutability of sub class in isolation. One has to consider how the clients of the class hierarchy are going to use it.
READ MORE
...