OO Design

• Central to OO design is the concept of Abstraction
  • Booch: An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the prospective viewer.
  • Berzins: a concept qualifies as an abstraction only if it can be described, understood, and analyzed independently of the mechanism that will eventually be used to realize it.
  • Gregorie uses the example of a TV
    • We know about the interface (on/off, volume, channel, display, ...)
    • It might even have the ability to add components (dvd player, ...)
    • But we don't know how the thing works inside.
    • Additionally, the implementation is separated from the interface
      • You can purchase a "universal" remote control.
  • Think about this a little.

    • ChessPiece chessboard[8][8]{}
      chessBoard[0][0] = new Rook{}; 

    • vs

    • class ChessBoardT {
           void SetPieceAt(CoordinateT position, ChessPieceT piece);
           const ChessPieceT & GetPieceAt(CoordinateT position); const;
           bool IsEmpty(CoordinateT position);
      } 

    • Notice in the first I am thinking about an array.
    • In the second, I am thinking about boards and things I can do to boards.
    • Also, notice in the second, the idea of a position has been abstracted.
• Object oriented design begins when you
  • Look at the components that make up your "simulation" (ie program)
  • Think abstractly about these components.
    • What are their properties? - what are the essential thinks that make up this component
    • What things can I do to this component?
  • If you have both of these things, you possibly have an object.
  • Notice, there is no mention of "how will I make this work?" That is for later.
• But do I have an object?
  • Perhaps:
    • If it only has actions (or functions) it is not an object, likely, it is a function.
    • If it only has values, but no actions it is not an object, likely, it is a structure or variable.
  • But also
    • Can I break it into smaller identifiable components? Perhaps it is a Composition.
    • Can I add properties to an existing object to make a new one? Perhaps it is part of a Hierarchy.
• A couple of terms
  • In c++ a class is the way to implement an object.
  • A variable of a class, or a realization of an object is called an instance.
• Objects must have crisp clear lines of responsibilities.
  • These are spelled out in the interface.
  • This defines how users can use the object.
  • And should be mostly immutable.
  • And should be easy to use correctly.
  • And must provide all the actions needed to use the object.
• Note on I/O
  • We would like our object to be reusable in any situation.
  • Therefore we frequently do include I/O in the object.t
    • This can be handled in helper functions.
    • Or in a "view" class.
  • Think of a gameboard.
    • Is it possible that we will use this in
      1. A text based environment?
      2. A gui?
      3. A network application?
    • What will happen to cout statements in the last two?
  • Better is to build a
    • BoardTextDisplay class.
      • This holds a reference to an instance of a board class.
      • It knows how to ask for board details.
      • It knows how to display a board.
      • What's more, it probably knows how to hand a piece on the board to a PieceTextDisplay.
• In chapter four he discusses designing a chess program page 157.
  • This uses a well known design pattern: Model View Control.
    • This breaks a system into three pieces
      • The model contains the data
      • The view displays the data
      • The user interacts with the control to update the model and potentially update the view.
  • These components are composed of smaller objects.
    • The model contains the board.
    • Which contains o or more pieces.
  • As a side note, the pieces constitute a hierarchy.
    • A generic chess piece has potentially
      • A movement function, but this might not actually be implemented.
      • A value, but again, this might not have anything.
      • A color value, that is implemented.
    • Derived from this is a pawn class
      • This specifically implements how a pawn can move.
• Inheritance can
  • Add or replace functionality to a class.
  • Add or replace properties of a class.
• When we implement a hierarchy, we gain access to polymorphous
  • This allows us to put many different, yet related objects into a common container.
  • Like the pieces on the chessboard.
• In general, you really should read chapters 4 and 5
  • They are not overly long.
  • And they are very informative.