HW4

How are the MVC connected??
 - Model should not know anything about View/Controller
 - View can be combined with controller (the line is blurry)
 - If View == Controller
   - View/Controller should have pointer/reference to model
   - Model should not know anything about view
   - just present nice interface to the View/Controller

What should I turn into C++?
  - Pretty much everything should be C++
    - Maybe leave out Array2D implementation (use extern "C")
    - Forced to leave out GTK (use extern "C")
    - C is a subset of C++, should be easy to convert C into C++
  - What should I turn into a class? Two options:
    - Each M/VC piece is a class
    - Only turn some into classes
      - If Model is only class, View will need Global "Model" var
        - All view methods will need to edit the model object
        - Works, but can b ugly/hard to understand
      - If View/Controller is only Class, Model state C struct will need to be global
        - All model methods will need to edit the model struct state
        - Works, but can be ugly/hard to understand

What classes should I have?
  - Why turn C in hw3 into classes?
    - Makes memory management easier (things are destroyed on delete)
    - Makes things more extensible (Candy class, more candies!)
    - Clear separation of roles within the program (each presents its own interface)
    - Each knows how to deserialize & serialize itself
  - Candy
    - Int value of Candy
    - Good for implementing future candy types
  - GameState (Model)
    - Present nice interface to your view/controller
    - Things to store in the model (2 2D arrays suggested)
      - The candy positions
      - The board state # of explosions
      - Moves taken
      - Score
  - GameDef
    - Defines game definition
    - There will only be one per game:
      - Can be held by the model (GameState)
      - Can be a singleton (Similar to global var, but there can only be one ever)
    - Queried by model to know how to fill board
  - View
    - Handles all GTK code
    - Private class for every callback type (for C gtk compatibility)
    - Static methods for callback adapters
  - Optional (but maybe useful)
    - Class for templates, can ask a template object if it can fire given board state

How to deal with global variables?
  - Use static class variables for global vars (ie View::labels[...])
  - For GTK callbacks use adapters, static methods in classes

HW5

What is this new library?
  - Two classes: ClientSocket and ServerSocket
  - ServerSocket -> BindAndListen, Accept
  - ClientSocket -> Provides Read & Write wrappers

What new classes do we need for this hw?
  - Message class - handles all deserialization of itself
    - Option 1: subclass for each message type
    - Option 2: message class provides methods to create each message (factory)
  - Message Manager - Essentially wrapper for ClientSocket class
    - Methods like -> getNextMessage(), sendMessage()

What steps does main in the view have?
  - BindAndListen - Creates a socket, binds to it (assigns an address), sets it to listen
  - Accept - blocks until it find something to connect to
  - Create ClientSocket using ret val of accept
  - Wait for the "hello" message

What steps does the main in the model have?
  - Create ClientSocket using port and ip of server
  - Send a "hello" message

How should the model be represented in the view server?
  - As a second instance of the model class
  - Model class should have "reloadFromGameState" method

Makefile wat do?
  - Three vars
    - SOCKET_OBJS = socket obj files
    - VIEW_OBJS = view obj files
    - MODEL_OBJS = model obj files
  - Two targets -> hw5-view, hw5-model