# Ooga API Changes
### Team 7
### Names

Livia Seibert - las120
Rachel Luria - rl213
Martha Aboagye -mfa23
Patrick Liu - pyl8
Montana Lee - mal115

### Changes to the Initial APIs

#### Data External

* Method changed: loadExistingGame was added

* Why was the change made?

Initially, we hadn't considered in depth how we were going to implement the load existing game feature, so I had planned to have only one function in the GameDataInitializer class for creating a game. However, once I started implementing the ability to load an existing game, I realized that loaded objects would have to be instantiated with more data than the brand new objects. This meant that I would need a new function to access this extra data.

* Major or Minor (how much they affected your team mate's code)

Minor, the only time this function is called is through one button on the view, so this didn't impact my team very much at all.

* Better or Worse (and why)

Better, this new function offers a lot of new functionality to the game with a very simple change.

* Method changed: Data became a record

* Why was the change made?

I realized that Data could be immutable once it was created because the engine shouldn't need to set any of its values. This means that a record would work nicely here, and make the code much more concise.

* Major or Minor (how much they affected your team mate's code)

Minor, the engine only needs to access the fields of the Data record right in its constructor, so changes to function names would only need to happen in one place.

* Better or Worse (and why)

Better, using a record makes much more sense here as the class would only have instance variables and getters.

#### Data Internal

* Method changed: added load functions to most of the XML parser classes

* Why was the change made?

Similarly to the loadExistingGame method mentioned above, I hadn't accounted for the fact that loading objects would require different data than just instantiating new objects. I had to add this load function to make sure that the proper parameters were being passed to objects to return them to their saved state.

* Major or Minor (how much they affected your team mate's code)

Minor, the only place that XML parser functions are called is from GameDataInitializer, so all of the changes were condensed to one place.

* Better or Worse (and why)

Better, these new functions offer a lot of functionality to the game.

#### Frontend External

* Method changed: Controller package

* Why was the change made?
* Up until sprint 2, the main view class initialized the game and obtained a poker game object and distributed different game objects to other view classes as needed. We setup a controller class that initialized the game and handled all the game logic and distributing game objects. We also created two interfaces that allowed the view classes to send messages to the controller classes and vice versa.

* Major or Minor (how much they affected your team mate's code)
* Major. Implementing a controller package meant that we had to move all the game logic that was previously in the view. We added additional interfaces so that the game logic could set active players, new round and other details about the flow of the information from game logic to view.

* Better or Worse (and why)
* This method/class change made our overall design better because we completely seperated the implementation of view from the game logic. We werent passing around game objects such as pokergame or Table to a lot of classes.

* Method changed: createAction -> setActivePlayer

* Why was the change made?
* After we seperated the game logic from the view, we changed the method that tells the view to display the game information such as displaying cards for the player table.

* Major or Minor (how much they affected your team mate's code)
* Minor. This method change utilized observables and didnt change any other methods in the view or the controller classes interacted with the view.

* Better or Worse (and why)
* The change in method name and implementation better reflect the purpose of this method and also utilizes abstraction by just notifying the relevant observable field in each class.

#### Frontend Internal

* Method changed:SceneElement Class

* Why was the change made?
* After sprint 2 when most of the core view Classes were created, i realized that most of them shared the same structure. For example almost every major view classes needed a theme and language resource and needed to be notified when those changes. As such I created a SceneElement abstract class that all other view scenes could extend.

* Major or Minor (how much they affected your team mate's code)
* Minor. This change did not affect any of my teammates code. It also didn't significantly change implementation within the view classes itself since most of them had all the methods in the abstract class to begin with.

* Better or Worse (and why)
* Creating an abstract SceneElement class was better since it created a clear hierarchy of how all view classes function.

* Method changed: SetLanguage

* Why was the change made?
* After the SceneElement abstract class was created the setLanguage method had to be changed to call `notifyListener` on the relevant class instead of calling a setLanguage method.

* Major or Minor (how much they affected your team mate's code)
* Minor. This change did not affect any of my teammates code or how other view classes worked.

* Better or Worse (and why)
* Better. Instead of creating a protected setLanguage method in each view class, there is instead only one setLanguage method in view which calls the appropriate notifiers for each class.

#### Engine External

* Method changed: `getRequiredInputs` and `giveRequiredInputs` in `ActionManager`

* Why was the change made?
These methods had to be added in order to support `RaiseAction` and `DiscardAction`, which require user input in order to run.

* Major or Minor (how much they affected your team mate's code)
These changes affected code in the view, since the view had to add support for collecting user input. However, we agreed upon a format by which the view would pass input to the engine, so this API change did not have a major impact on other code.

* Better or Worse (and why)
Much better, since this change enabled raising and discarding.

#### Engine Internal

* Method changed: `completeBetAction` in `BetManager`

* Why was the change made?
This method was replaced by `getPossibleBetActionsForPlayer` in order to avoid giving the method too much responsibility. The `BetManager` is no longer responsible for running a `PokerAction`.

* Major or Minor (how much they affected your team mate's code)
Did not affect teammate's code because the communication between the `BetManager` and the view is almost exclusively conducted through the controller.

* Better or Worse (and why)
Much better, since the old plan of having the `BetManager` present and run actions was not compatible with how the view shows actions to users and responds to user input (in the form of button presses)

* Method changed: `getRequiredInputs` and `giveRequiredInputs` in `PokerAction`

* Why was the change made?
As with `ActionManager`, these methods were added to support `RaiseAction` and `DiscardAction`

* Major or Minor (how much they affected your team mate's code)
All of the implementation details for `PokerAction` subclasses are shielded from other APIs, so this change had virtually no impact on my teammates' code.

* Better or Worse (and why)
Much better, since this change was essential for supporting any action that requires additional user input.