Intro to Design

• Read Chapter 5.
• Objects
  • We already have that an class consists of
    • Member data
    • Member functions.
  • These are some times called properties and behaviors.
  • An objects are instances of classes
    • The have a state which is the exact value of the member data.
    • Object properties are the state.
  • A class is a template for building an object.
  • His discussion of 124-126 is headed towards OO terminology. I don't think we need that yet.
  • One thing to note, is that he discusses Components
    • I don't see this in most discussions directly.
    • But it introduces the notion that objects are composed of other objects.
    • We started on that last time
      • My soda machine will be composed of
        • An array of can bins
          • Which will contain cans.
          • A can will be a basic object.
        • A Bank
          • Which will consist of an array of MonitaryUnits
          • These can be either a coin or a bill, or even perhaps a credit card in the future.
        • A bank
          • Responsible for handling the money transactions.
        • This may be expanded later.
          • I might need to add user interface objects
          • But this will do for now.
      • 
• Picking the objects
  • They should have behaviors and properties
    • 7 is probably not an object, it doesn't really have behaviors, only properties.
    • InsertionSort is probably not an object, it doesn't have properties, only behaviors.
  • They should have "crisp" boundaries.
    • I moved the banker out of the bank.
      • The bank is responsible for storing money.
      • The banker is responsible
        • Tracking the money deposited.
        • Making change.
      • The bank is a holder, I can use it many places.
  • I was toying with a parser object
    • It takes a string (command) and returns an action and an array of arguments.
    • "Deposit 25c" would become DEPOSIT (enumerated constant), and a Coin (value 25, currency "USD"), in an array of size 1.
    • This is possibly a valid object, but it could equally be just a function.
    • I think this would not be an appropriate object. But perhaps I will change my mind later.
    • But I know that this is not part of my soda machine.
      • By the button push actions, the input is already parsed.
      • I don't want to tie my soda machine to a text interface.
  • That also covers the input objects in the soda machine
    • There might be a button class, but that is a physical object what would call the soda machine button press method.
    • There is a Model-View-Controller pattern that suggests this is the proper way to do this.
    • Your mileage may vary here.
  • I think I would probably add a output device class
    • This will take a coin, can or message and display it.
    • Later this could be replaced with a set of physical mechanisms
  • 
• Some Relationships in this diagram.
  • OOD and UML has many different relationships they show.
  • We will discuss three now.
    • Inheritance
      • One object is derived from another.
      • It receives the properties/behaviors of the parent
      • Plus it can add additional properties/behaviors.
      • This is a "is-a" relationship.
      • A frog is an animal
      • A fish is an animal
        • Each has common properties such as age, alive, ....
        • Each has common behaviors such as eat, look
        • Each has a move behavior, but it will be different for each subclass/ derived class.
        • Each might have unique behaviors and properties.
        • 
      • This is a fundamental requirement for Object Oriented
      • We made coins/bills derived classes of the MonityUnit class.
        • Because of this we will be able to return an array of MonittaryUnits, made up of either type.
        • We can also extend the monitaryUnit to include other types.
        • I am not sure that there is sufficient difference in a coin or bill to require the subclasses.
          • Right now they both have a value and a currency.
          • But if we add credit cards, there is a major difference.
      • If we were designing a generic vending machine, we might build a VendingUnit in place of a Can.
      • With inheritance we can
        • Add functionality
          • A frog is an animal which can move via walk or hop or swim.
        • Replace Functionality
          • A fish's move method is replaced by a swim method.
        • Add/override Properties
      • inheritance is used to support polymorphism
        • We can have an array of monitaryUnits composed of either coins or bills.
        • Each retains their own characteristics.
        • But we can add up the value of all of the items we have with a single loop.
          • We don't need a totalCons and a totalBills loop.
    • Aggregation (composition)
      • This is a "has-a" relationship where existence is dependent on the objects.
      • A frog has a heart.
        • The heart can not exist without the frog.
        • Ok, perhaps in some biology class scope.
        • But not in the "frog pond" world of my game.
      • 
      • The relationships can have multiplicities

      • Multiplicity	Meaning
        N	Exactly N instances
        0..1	Zero or one instance
        0..*	Zero or more instances
        N..*	N or more instances
        none given	1 to 1

      • 
      • Notice above
        • A soda machine has a bank, which can not exist outside of a soda machine.
        • The same is true for a Banker, Output and CanBin
        • But not coins and cans.
    • Aggregation (Shared aggregation)
      • Another Has-a relationship
      • In a shared aggregation, items can exist without each other.
      • This make sense in our soda machine.
        • A can of soda exists after it has been vended.
        • A coin exists outside of the bank.
      • 
      • A frog is in 0 or 1 pond
      • A pond has zero or more frogs.