More Design

• I am still working on chapter 4.
• He has mentioned design patterns several times in the text.
  • These are known solutions to existing problems.
  • You see these all over the place
    • Model View Control in web design
    • Factories in Game Programming.
  • In my experience, they are mostly related to Object Oriented problems.
  • He really discusses this on page 145, so you should read Reusing Designs
  • We will encounter a few of these this semester.
  • For most of these, we will need a bit more c++ for implementation.
  • But I wanted to draw your attention to them.
• I am going to skip ahead to page 157, Designing A Chess Program
• He starts by listing requirements
  • Please note, his set of requirements are not complete.
  • But these are a list of things the code has to do.
• Based on the requirements, he begins to partition the code into systems.
  • As I stated he uses the Model-View-Controller pattern.
  • The model is the data of the application.
  • The view is a representation of the data.
  • The controller accepts input and converts it to commands or calls to the model or view. This is the "brains" of the program.
• (From Wikipedia)
• (from https://www.educative.io/blog/mvc-tutorial)
• This means
  • The model does not have to worry about display
    • Different views or user interfaces can be attached
      • GUI
      • Text Base
      • Something else, (I am thinking of some form of a chessboard where the pieces are projected and the user moves them somehow)
    • This means that classes developed here can be reused in future code.
• In his design
  • The model consists of a ChessPiece and a ChessBoard
  • The view consists of a ChessPieceView and a ChessBoardView
  • The controller consists of a GamePlay and a Player.
• The easiest of these are the *View components
  • The ChessBoardView displays the chessboard
  • The ChessPieceView displays individual pieces.
  • In the end, the board view will call the individual piece views to display their representation.
• The model:
  • ChessPiece is responsible for
    • Moving its self
    • Checking for legal moves
  • The ChessBoard
    • Is a container that stores the chess pieces
    • Checks for end of game conditions
• The controller
  • The GamePlay
    • The main logic for the game.
    • Starts the game
    • Controls the flow of the game
    • Controls drawing
    • Declares the winner
    • Ends the game.
  • The Player
    • Interacts with the view to get player commands (if it is a human player)
    • Interacts with AI to get commands
    • Executes these commands
• This is summarized on page 150.
  • Note, he includes
    • Interfaces Exported or methods each system should supply
    • Interfaces Consumed or methods the system will call.
  • Look this chart over, understand it.
  • Figure 4-5 provides an overview of the interaction of these parts
  • 
• Skip the Threading models, we have not discussed threading.
• He then goes on to design a hierarchy.
  • ChessPiece will need to be specialized.
    • It is responsible for knowing how to move each piece.
    • Therefore we will need a specialization for each different piece.
    • This means a hierarchy
  • The same, for different reasons for the ChessPieceDisplay
• He is now ready to begin to design the classes for this program.
• The table on 163 is probably hard to read because we don't know c++ terminology for a hierarchy.
  • Think of an abstract class as the parent of all derived classes
  • A concrete class then is a derived class
  • Don't worry about this too much.
• What is important is that at this point, he has the classes described above.